转载

业务架构20多年，技术人员理解了吗？

业务架构这个词大家时常听到，但是能解释得清楚的却不多，撩撩度娘，你就会发现，不少人问及业务架构和应用架构的关系，聊天时，也常有人问起业务架构师和产品经理什么区别？业务架构分析和需求分析什么区别？为了思考这个问题，我把《软件工程》、《软件系统架构》、《系统分析与设计》都翻了，这些经典教材确实没讲过业务架构这件事；我把《聊聊架构》也翻了，发现其中的讨论有解释到业务、架构和技术的关系，但是也没有特别强调业务架构，所以本文就先梳理下几个较为有名的业务架构理论。

Zachman 模型

其实，业务架构这个词并不新，它隐藏在企业架构（EA）中。企业架构是上世纪 80 年代的产物，其标志就是 1987 年 Zachman 提出的企业架构模型，该模型按照“5W1H”，即 what（数据）、how（功能）、where（网络）、who（角色）、when（时间）、why（动机）六个维度，结合目标范围、业务模型、信息系统模型、技术模型、详细展现、功能系统六个层次，将企业架构分成 36 个组成部分，描述了一个完整的企业架构要考虑的内容，详图如下：

业务架构20多年，技术人员理解了吗？

资料来源：网络

Zachman 模型虽然没有明确提出业务架构这个概念，但是已经包含了业务架构关注的一些主要内容：如流程模型、数据、角色组织等，既然没有提出业务架构概念，自然也就没有包含构建方法，所以，Zachman 模型应该算是业务架构的启蒙，同时，它也表明了这一工具或者技术的最佳使用场景——面向复杂系统构建企业架构。

TOGAF

1995 年，大名鼎鼎的 TOGAF 登场了，这个在企业架构市场中据说（2009 年统计）占了半壁江山的架构模型明确提出了业务架构的概念。TOGAF 将企业定义为有着共同目标集合的组织的聚集。例如，企业可能是政府部门、一个完整的公司、公司部门、单个处 / 科室，或通过共同拥有权连接在一起的地理上疏远的组织链。TOGAF 进一步认为企业架构分为两大部分：业务架构和 IT 架构，大部分企业架构方法都是从 IT 架构发展而来的。业务架构是把企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，它包括业务的运营模式、流程体系、组织结构、地域分布等内容。TOGAF 强调基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统，复杂系统集成的关键，是基于架构（或体系）的集成，而不是基于部件（或组件）的集成。TOGAF 还提供了一个详细的架构工件模型：

业务架构20多年，技术人员理解了吗？

资料来源：百度

其中可以明确看到业务架构阶段的交付物。相信很多对架构有兴趣的朋友都认真学习过 TOGAF 模型，此处不再赘述。

FEA 和 DODAF

TOGAF 之后，又先后诞生了 FEA（联邦企业架构）和 DODAF（美国国防部体系架构框架）。前者的体系由五个参考模型组成：绩效参考模型（PRM）、业务参考模型（BRM）、服务构件参考模型（FRM）、数据参考模型（DRM）、技术参考模型（TRM），该方法应用于美国电子政务领域，着眼于跨部门、跨机构提升业务效率，解决重复建设、信息孤岛等问题，很具有“企业级”理念，虽然没有明确的业务架构定义，但是很好地应用了业务架构的思维。后者体系挺复杂的，8 个视点 52 个模型，但是实用性不错，美国国防部和一些企业在用，详细内容如下：

业务架构20多年，技术人员理解了吗？

资料来源：网络

其中能力视点和作战视点就是我们做企业时关注的业务部分。这两个模型网上有相关资料，感兴趣的话可以自行查阅。

为何沉闷至今？

通过寻根溯源，可以发现，即便从 TOGAF 算起，业务架构这个词也有 20 多年的历史了，但是在开发人员中，业务架构显然没有需求分析的概念明确，业务架构师也远不如产品经理常见。作者所在单位曾经实施了一个长达数年的企业级转型项目，其中有明确的业务架构组织，但是，每每与技术人员讨论，他们也常觉得业务架构有点儿“虚”。细究其原因，可能有如下几点：

用的少。原有的单体式或者竖井式开发依然是大家更经常采用的项目构建方法，而这种开发基本上没有横向视角，所以无需强调业务架构，通常的产品分析或者需求分析足以满足开发需要；

难设计。业务架构，特别是大型企业这种错综复杂的业务架构，说起来容易做起来难，业务架构对战略的分解、业务架构自身的整合与标准化、到 IT 设计的过渡都有不少坑，业务越复杂越宽泛就越难驾驭，因此，即便做过业务架构设计的企业，也有不少将业务架构设计保持在高阶状态，有点儿“虚”；

易跑偏。施工期间由于客观因素可能导致实施对业务架构的偏离，这种偏离如果没有及时纠正或者调整架构，累积久了会造成业务架构的失真，会变“虚”；

难维护。少数扛过了业务架构落地困难期的企业，也会由于感受到维护架构的难度而心生放弃，从而降低了对业务架构的评价。

其实，业务架构从诞生之初就很清楚地定义了自己的使命：面向复杂系统构建。也就是说，业务架构同其他架构一样，目的也是要降低复杂度，更好地规划系统，因此 TOGAF 是将业务架构归属于 IT 战略部分。但是从本人的实践经验看，业务架构不仅具有上述作用，其更突出的影响是对参加过业务架构设计工作的业务人员的影响，他们的逻辑思维能力、结构化能力、企业级观念和意识都有明显的改变，所以，应当将业务架构从 IT 战略中独立出来，更多面向业务人员，以充当业务与技术之间的桥梁。当然，业务架构真正要承担起这一职责，还需要改进、简化业务架构设计方法，对业务人员更友好，并且坚持使用业务架构方法做企业级需求管控，否则，熵增一定会将已经建好架构秩序回归混沌状态。

中台说到底也是一种业务架构设计结果，回顾软件设计的发展历程，中台也不是石头中蹦出来的齐天大圣，它并非一种超越了企业架构这个概念的存在，因此，想要深入理解中台设计方式，多去学习下业务架构、软件架构的发展历程还是有帮助的。

架构伴侣：业务模型

业务架构是战略、流程、组织等业务元素的结构化表达，因此，说起业务架构，自然离不开业务模型，所以，本章我们讲讲架构的伴侣——业务模型。

模型与业务模型

业务模型也是模型的一种，因此我们先从模型讲起。模型的概念大家可以查到很多种，不过，度娘上有一种是我觉得比较容易理解的，这个解释中说，模型是所研究的系统、过程、亊物或概念的一种表达形式，也可指根据实验、图样放大或缩小而制作的样品。很多人一说起模型都喜欢说模型是抽象的东西，模型最重要的是抽象，这个说法对软件开发人员而言并无不妥，但是对于理解模型这个概念而言，还是有些狭窄了。模型可以是具象的，可以是实物，比如售楼处常见的楼盘模型，我们的老祖宗修故宫、给皇帝家造亭台楼榭时，也会先做出精巧的木制模型；模型不仅可是真实事物，也可以是虚拟的，只要脑洞开的够大，比如很流行的高达玩具模型、变形金刚等；模型当然也可以是抽象的，比如软件开发中常用的实体模型、时序图、状态图、用例图等等。例子参见下图：

业务架构20多年，技术人员理解了吗？

模型就是一种表达形式，其实说出来的话也可以视为一种模型，它是你头脑中的想法的表达，说的过程也就是个建模过程，还遵循了一定语法规则。所以模型不是个神秘的东西，对于业务人员而言，工作时候经常会画的业务流程图也是模型，与软件开发中用的模型相比，无非是个建模视角和抽象程度的差别。

理解了模型，我们再来看看业务模型。套用上边的概念，业务模型就是对业务的表达，至于这个业务的范围就看你的需要了，如果只是针对一个产品，那业务模型可能就是对产品的生产、销售、使用、售后管理过程的描述，其中还要包含所有参与方的目标、活动、角色、职责等等；如果针对的是一个大型企业，那业务模型的范围就可能包含多条产品线，每条产品线都有不同的业务过程，而涉及到的参与方也会更多、更复杂。所以，业务模型最主要描述的就是组织及其运作过程。企业的业务模型有一个最高阶抽象的三角形，如下：

业务架构20多年，技术人员理解了吗？

这个三角形可以说是一切盈利性企业的基本行为，企业为生产而投入成本，产品或服务销售后取得收入，而衡量企业业绩的最基本方法就是通过收入减去成本形成的利润。其实所有企业的行为都可以从这个三角形出发去分析，比如，一个企业基本流程就可以概括为：

企业准备向哪些人销售自己的产品或服务，这就体现了企业自身的价值定位；企业准备组织那些人生产，组织哪些人销售，在什么样的渠道上销售，为此投入什么样的资源，这就是企业的生产和销售流程；收入和成本都需要记账，这就是财务会计的流程；对利润实现情况的衡量、盈亏原因的分析等，体现在管理会计中；所有行为都会产生数据，这些数据是我们做系统设计时的必要输入，是结合业务流程做架构分析的基础。从这个最高阶的核心模型出发，我们可以演化出整个企业的过程，可以模型化地创造一个企业，这就是“大道至简，衍化致繁”吧。

建模原则与模型思维的应用

既然业务模型对业务架构、对系统设计如此重要，那么建模是否有什么诀窍呢？很遗憾，没有。这不仅是我个人的理解，不少关于建模的书中也都会提到，建模看似有很多方法、标准可以遵守，但是模型质量却十分依赖于建模者的经验，是一个“熟练工种”，“老司机”很重要。虽然没有捷径，但还是有两个原则可以时刻注意的：

整体性原则。做模型切忌快速上手，不要快速被业务细节吸引，更不要被立马解决问题的冲动左右，一定要将问题域或者说建模对象放在一个更大的环境中观察，要先找到建模对象的边界，也就是上下文环境。搞不清边界，就搞不清范围，即不知道起止，也不知道思虑是否周全，甚至无从检验建模成果，容易一叶障目，不见森林。

合适性原则。大家可能都听说过一个比方，把世界上最美的五官凑在一起，并不会成为世界上最美丽的脸，这就是合适性原则，美丽的脸通常是五官比例好、搭配好的脸，也就是说，模型中包含的各个部分、各类元素要有机结合在一起，不能在设计时为了图新潮、赶时髦，甚至为了建模者个人的“执念”，生搬硬套，强买强卖，忽视了模型的平衡。

业务模型是为业务架构服务的，所以细心的读者也一定注意到了，这两条其实也是架构设计的重要原则。建模唯有不断练习，不断参与项目实践，以获得对建模成果的必要反馈，才能有所提高，设计上我们经常把不管实现的架构师比作“PPT 架构师”，其实建模也一样，不能在生产环境中得到反馈，建模者也会成“PPT 模型师”，所以，“实践是理论之源”啊。

经历过的人都知道，认认真真建模是项枯燥繁琐的事情，而且，我也提到，业务架构设计可以帮助业务人员提升逻辑思维能力，应该让业务人员多参加，那么广大业务人员也会疑虑，投入这么大精力参与这事儿，做完了项目，这技能还用得上吗？肯定用得上啊，虽然不会到处去建模，但是重要模型思维可是非常有用的，我个人总结，有这么三点是在各类工作中都值得借鉴的：

把握整体。这条不再赘述，应用上，我建议，对于任何领导交办给你的工作，尽可能不要第一时间就“Just do it”，而是要挤出点时间，考虑下来龙去脉，前因后果，这样你才能控制好工作的度，过犹不及啊。

穿透现象。浮在水面上的往往是冰山一角，透过现象看本质是我们对建模人员的基本要求，这种注意事物内在联系、本质差别的能力，有助于你拨开现象的迷雾，找到最佳的解决方案。

保证落地。前一阵子曾经流行过一句话“一切不为业务目的服务的技术都是耍流氓”，套用一下，“一切不考虑落地的架构设计都是耍流氓”，架构不能飘在天上，印在纸上，所以，真正了解架构本质的人，无论做的是“矮穷挫”的搬砖方案，还是“高大上”的传奇方案，都要以落地为前提，对应到日常工作中，就是我们无论何时何地提出的工作建议都不能是“空谈”。

中台的表达方式其实也是一种模型化表现方式，毕竟当前的软件设计基本都是“模型驱动开发”，无非是模型工具的差别。关于模型的一些基础性介绍先到此为止，本文所讲的业务架构都是使用业务模型来构建的。

业务架构20多年，技术人员理解了吗？