Wang 业务架构定义
（1）业务架构是 TOGAF 最早定义的，指的是
企业的战略、组织结构、关键流程
等内容。
TOGAF 9
企业架构思想诞生于 1987 年，这时候，工程化已经搞了快 20 年了，但大家还是没有搞清楚，在 B 端怎么设计软件合适。IBM 的雇员 Zachman 在 IBM 的内部刊物上发表了一篇文章《信息系统架构框架》，谈到了“架构”这个词在软件行业应用上的混乱，并提出了自己的架构设计思想，这篇文章后来被奉为企业架构的开山之作。Zachman 的思想最重要的一点就是，架构是多视角的集合，是“一套架构（a set of architecture）”，而非“一个单一的架构（a single of architecture）”。架构是从多个视角观察企业得到的结果的总和，这实际上也是上一讲中提到的架构思维的全面性。换句话说，我们不应该总抱着自己认定的视角去跟别人争，而是要努力去看看，到底需要多少种视角，才能理清企业的全貌，这样才能让我们设计的系统与企业的实际环境匹配上。Zachman 的思想后来在 Open Group（开放组）的努力下发扬光大了。Open Group 在 1995 年提出了一个体系结构非常完整的方法论 The Open Group Architecture Framework（开放组架构框架，简称 TOGAF）。TOGAF 首次正式定义了什么是企业架构，他们提出，企业架构就是“具有共同目标的组织集合体的基本组成部分及其内外部关系与治理原则”。这个很怪异的“组织集合体”指的就是企业，只不过它比你平时理解的企业范围大些，能被一个目标圈进来的组织，都可以被当成一个企业看，所以，TOGAF 是支持建立跨组织的架构的。TOGAF 认为企业架构包括业务、数据、应用、技术四部分，也称“4A 架构”，实际上是 4 种架构视角。Zachman 主张的多视角架构，在这里算是成型了，做企业架构就要完整地做出这 4 种架构。
（2）偏操作性的定义：业务架构是以实现企业战略为目标，构建企业
整体
业务能力规划并将其
传导
给技术实现端的
结构化
企业能力分析方法。
整体：
从整体出发进行合理布局。
这样的设计是最经济的，但是难度相对也是高的，业务分析上，每个领域都不能只看自己家的领域。只要是跟你的领域相关的，都要横向考虑到。此外，要落地企业战略，也需要看到企业的全貌，完整知道企业各个部分之间的相互关系，这样才好分解战略，不然，就可能出现对战略分解上的盲区，影响战略的落地。全面是架构思维的首要特点，业务架构也是如此。
结构化:
结构化是业务架构分析问题的方式。
有了刚刚的对业务横向拉通的全面认知，还要把你的认知结果表达出来，这样才能把它们传导给要去做开发的技术人员。表达可以有很多种方式，而用来跟技术人员衔接的最好方式莫过于结构化地表达，通过模型之类的手段，把业务架构设计成果表达成技术人员比较好理解的形式。在做模型的时候，如果有设计系统的支持就更好了。如果总是把方案搞成一大堆 Word 文档和 PPT，谁也不好查找。现在也有一些可用的建模工具和架构管理工具（比如可以用来与 TOGAF 过程配合使用的 ArchiMate 建模工具，有一套标准的、可相互集成的软件工具集支持的 ARIS 模型框架，等等），有些是架构管理的，有些是流程管理的。不过，相对来说，工具还是比较缺乏的，这主要是因为架构方法论的实践不够充分，再加上架构管理工具与软件开发全生命周期管理的衔接本身也不容易，所以这方面还需要逐步完善。
传导:
把自己对业务的认知准确地传导给技术，也是业务架构的任务。
实现好的传导需要两个条件：优质的内容；相应的机制。
要注意的是，这两个不是并列的条件，而是相辅相成的。在内容方面，业务架构要先帮助业务理清自己的环境、搞清业务痛点、设计出解决方案，这样才能向技术传导准确的东西，不然，大家都是一头雾水，就没办法进行下一步了。如果不能帮助业务一侧找到合理的解决方案，就不会有什么好的技术方案诞生。但这一点，也正是机制上的一大缺陷。业务架构的工作方式没有走出技术圈子，没有走到业务人员中间去。实际上，应该让业务架构思维在业务一侧被广泛接受、使用，这样才能保证持续产生好的业务架构解决方案，促进业技融合，这并不是有了业务架构师就万事大吉了。目前能做这种架构思维推广的人还很少，而人少的原因其实就是企业本身没有采用这种工作机制，自然也就培养不出这样的人。现在，有了业务架构，战略、业务、技术这三个在企业管理中很容易出现衔接问题的东西，就被一根绳子串起来了，自然也就可以帮助业务人员找到可落地的业务解决方案，帮技术人员理解战略和业务到底要怎么实现，从而找到更好的技术解决方案。这就是业务架构的价值所在。你想想，这不就是数字化转型的要求吗？大家要通过数字化创造新模式、新业态，要加强技术对业务的支持作用，要实现业务和技术的深度融合，说到底不也是这些东西吗？当然了，业务架构不是“银弹”，更不是“无懈可击”，无论是企业还是个人，如果想有持续的进步，一定要有能力去发展和改进自己的工作方法。想把它用好，也要清楚如何去完善它的不足，这样才能进一步提升你的数字化能力。那怎么改进呢？
如何进一步改善业务架构的设计思路？
很多技术人员觉得它很“虚”
，也就是跟软件详细设计的关系不紧密。技术人员好像可以通过这个更好地了解企业，但是又认为梳理出来的东西往往是偏宏观、偏业务的。可以当个背景资料参考，但是如果用它继续去做详细设计，总觉得差点儿意思。
这个问题的根源是，当前的业务架构设计实践没能把数据和流程很好地结合起来。现在，大家都知道数据很重要，是新的生产要素，甚至还有“一切业务数据化，一切数据业务化”的口号。
但是，具体怎么做呢？
当然得用笨法子一点一点做，骐骥一跃，也不能十步啊，咱们只能一个流程一个流程地去分析，把流程中要用到的、会创建的数据找出来才行。虽然传统的需求分析也会这么做，但是做出的成果是分开的，流程的归流程，数据的归数据，该一起做的事情，却分成了两块。不仅分析过程可能浪费了时间，也达不到理想的效果。要是数据分析直接跳过与业务过程的衔接，跑到数据库表的设计层面，那就更糟糕了。
其实，软件设计的核心就是
分析行为和数据
，也就是软件的功能以及这些功能要涉及到什么数据。
把数据和流程一起说明白，是技术人员最愿意看到的业务分析结果。
所以，
业务架构的改进方向之一，就是将原有的业务架构和数据架构融合起来，形成新的业务架构。
可以考虑把 TOGAF 中原来的业务、应用、信息（数据）、技术四个架构视角，去掉一个，让数据架构融入其他架构视角中。
当然，这不是说数据模型没了，而是业务模型和数据模型应该一起建，两者结合在一起考虑流程怎么切分、数据实体怎么切分，切分后的流程和数据实体到底是什么关系，这样才能更有利于对技术的衔接，同时又不至于失去业务友好性，让业务人员不好理解。
如何改进工作机制？
如果只改进设计思路，还不足让业务架构得到广泛使用，业务架构总在技术圈子里的打转儿是没前途的，得走出来，才能真正发挥出作用。
业务架构以往的工作方式，尤其是在 TOGAF 体系中，经常被认为是为了构建企业级系统而延伸出来的一个分析业务的环节。这就导致，在很多时候，业务架构会被当作企业级工程的一部分，采用的是类似于需求分析工作的管理模式，按流程坐等需求上门，忽略了独立应用业务架构方法，去解决业务人员落地企业战略、搞业务创新的可能性。
实际上，业务架构的核心价值，包括推动企业战略落地、通过架构设计提升业务协同性、促进业务与技术融合，这些都不是待在技术圈子里可以解决的问题，也不是待在技术圈子里就能培养出来的能力，必须得走到业务中间去。
那咋做呢？很关键的一点就是把业务架构师派到业务部门去工作，让业务架构师第一时间接触到业务人员的各类创新想法，并用企业的业务架构合理引导业务创新落地，帮助业务人员更好地理解技术可以带来的想象力。
当然，这也面临一个问题：现在大家都觉得好的业务架构师很少，无人可用，这个问题怨不得别人，只能怨我们自己，不培养，怎么会有呢？挖墙脚都没地方挖去。不能等有合适的人了再去做，而是要通过做起来去培养人。
而且，对于个人来说，这么好的时代机会摆在面前，在业务架构师如此稀缺的情况下，你具备了这样的能力，自然也就能走在别人的前面，关键是要有前瞻性。所以，
你要经常训练自己的结构化思维和沟通能力，看到啥都想着用结构化的思路拆解下，经常模型化地思考问题，好好把自己的思路传达给别人。
通过设计思路和工作机制的改善，业务架构的桥梁作用还可以发挥得更好，而这座桥正是业务人员面向数字化转型最需要的。接下来，我再来说说业务架构对数字化转型最独特的一个价值。
业务架构对数字化转型最独特的价值
在数字化转型过程中，最艰难、最痛苦的很可能是现在的业务人员。现在技术变化太快，技术对原有业务形态的冲击很大。
比如，移动互联网兴起大约也就十年的时间，移动端的开发技术、安全技术变化都非常快，在业务侧，网约车、社区团购、黑客增长、私域流量等玩法纷纷涌起。技术的变化速度让搞技术的专业人员都应接不暇，感叹自己职业寿命太短，学不过来，那业务人员情何以堪啊？哪些技术哪天会替代一个旧工种搞出一个新工种，谁也说不清。
现在人们常说，“最可能击败你的不是对手，是新手”。一些跨界而来的人，带着新思维、新手段，还没有旧包袱，占尽天时地利人和，传说中的“降维打击”也都是这个道理。无论是企业还是个人，都会面临这样的冲击。
那数字化转型是要业务人员现在转行去学技术吗？当然不是，
提升对业技融合的支持能力才是出路。
就像我一开始提到的，想要实现业技融合，形成合力，就需要相近的思维模式和共同语言，这就是业务架构能做的事情，不然就会像修“通天塔”的故事那样，各说各话，最后导致修塔失败。
提升业务与技术之间的沟通效率，是未来企业竞争的焦点。
你想想，如果经过数字化转型，大家都成为具有一定科技实力的数字化企业了，那最终我们要比拼什么？是不是又回到了谁家的业务人员能帮技术人员更快了解市场这个点上？而这个拼的就是沟通效率。
只要业务人员能够适当结构化自己的思维，好好利用、打磨业务架构方法，在不转行学技术的前提下，也能更好地跟技术人员沟通。
总结
业务架构最早是 TOGAF 定义的，关注的是企业的战略、组织结构、关键流程等内容。
操作性的定义：“业务架构是以实现企业战略为目标，构建企业整体业务能力规划并将其传导给技术实现端的结构化企业能力分析方法。”
现在，业务架构的作用被忽视了，需要改进。
方向有 2 个：
一个是要把业务架构与技术设计衔接得再紧密些，把数据架构吸收进来；
另一个是改进工作机制，走到业务人员中间去，把业务架构思维推向业务人员，帮助业务人员进行数字化转型。
这种两边“讨好”的方式，正是业务架构的价值所在，当然，它对业务架构师们也提出了不小的挑战，你要培养好自己思维的逻辑性，还要把自己打造成业务和技术两边都具备适当深度的复合型人才。
业务和技术融合
