业务架构这个词大家时常听到，但是能解释得清楚的却不多，撩撩度娘，你就会发现，不少人问及业务架构和应用架构的关系，聊天时，也常有人问起业务架构师和产品经理什么区别？业务架构分析和需求分析什么区别？其实为了写这篇文章，我把《软件工程》、《软件系统架构》、《系统分析与设计》都翻了，这些经典教材确实没讲过业务架构这件事；我把《聊聊架构》也翻了，发现其中的讨论有解释到业务、架构和技术的关系，但是也没有特别强调业务架构。
其实，业务架构这个词并不新，它隐藏在企业架构（EA）中。企业架构是上世纪 80 年代的产物，其标志就是 1987 年 Zachman 提出的企业架构模型，该模型按照“5W1H”，即 what（数据）、how（功能）、where（网络）、who（角色）、when（时间）、why（动机）六个维度，结合目标范围、业务模型、信息系统模型、技术模型、详细展现、功能系统六个层次，将企业架构分成 36 个组成部分，描述了一个完整的企业架构要考虑的内容，详图如下：
Zachman 模型虽然没有明确提出业务架构这个概念，但是已经包含了业务架构关注的一些主要内容：如流程模型、数据、角色组织等，既然没有提出业务架构概念，自然也就没有包含构建方法，所以，Zachman 模型应该算是业务架构的启蒙，同时，它也表明了这一工具或者技术的最佳使用场景——面向复杂系统构建企业架构。
1995 年，大名鼎鼎的 TOGAF 登场了，这个在企业架构市场中据说（2009 年统计）占了半壁江山的架构模型明确提出了业务架构的概念。TOGAF 将企业定义为有着共同目标集合的组织的聚集。例如，企业可能是政府部门、一个完整的公司、公司部门、单个处 / 科室，或通过共同拥有权连接在一起的地理上疏远的组织链。TOGAF 进一步认为企业架构分为两大部分：业务架构和 IT 架构，大部分企业架构方法都是从 IT 架构发展而来的。业务架构是把企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，它包括业务的运营模式、流程体系、组织结构、地域分布等内容。TOGAF 强调基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统，复杂系统集成的关键，是基于架构（或体系）的集成，而不是基于部件（或组件）的集成。TOGAF 还提供了一个详细的架构工件模型：
其中可以明确看到业务架构阶段的交付物。相信很多对架构有兴趣的朋友都认真学习过 TOGAF 模型，此处不再赘述。
TOGAF 之后，又先后诞生了 FEA（联邦企业架构）和 DODAF（美国国防部体系架构框架）。前者的体系由五个参考模型组成：绩效参考模型（PRM）、业务参考模型（BRM）、服务构件参考模型（FRM）、数据参考模型（DRM）、技术参考模型（TRM），该方法应用于美国电子政务领域，着眼于跨部门、跨机构提升业务效率，解决重复建设、信息孤岛等问题，很具有“企业级”理念，虽然没有明确的业务架构定义，但是很好地应用了业务架构的思维。后者体系挺复杂的，8 个视点 52 个模型，但是实用性不错，美国国防部和一些企业在用，详细内容如下：
其中能力视点和作战视点就是我们做企业时关注的业务部分。这两个模型网上有相关资料，感兴趣的话可以自行查阅。
通过寻根溯源，可以发现，即便从 TOGAF 算起，业务架构这个词也有 20 多年的历史了，但是在开发人员中，业务架构显然没有需求分析的概念明确，业务架构师也远不如产品经理常见。作者所在单位曾经实施了一个长达数年的企业级转型项目，其中有明确的业务架构组织，但是，每每与技术人员讨论，他们也常觉得业务架构有点儿“虚”。细究其原因，可能有如下几点：
用得少。原有的单体式或者竖井式开发依然是大家更经常采用的项目构建方法，而这种开发基本上没有横向视角，所以无需强调业务架构，通常的产品分析或者需求分析足以满足开发需要；
难设计。业务架构，特别是大型企业这种错综复杂的业务架构，说起来容易做起来难，业务架构对战略的分解、业务架构自身的整合与标准化、到 IT 设计的过渡都有不少坑，业务越复杂越宽泛就越难驾驭，因此，即便做过业务架构设计的企业，也有不少将业务架构设计保持在高阶状态，有点儿“虚”；
易跑偏。施工期间由于客观因素可能导致实施对业务架构的偏离，这种偏离如果没有及时纠正或者调整架构，累积久了会造成业务架构的失真，会变“虚”；
难维护。少数扛过了业务架构落地困难期的企业，也会由于感受到维护架构的难度而心生放弃，从而降低了对业务架构的评价。
其实，业务架构从诞生之初就很清楚地定义了自己的使命：面向复杂系统构建。也就是说，业务架构同其他架构一样，目的也是要降低复杂度，更好地规划系统，因此 TOGAF 是将业务架构归属于 IT 战略部分。
但是从本人的实践经验看，业务架构不仅具有上述作用，其更突出的影响是对参加过业务架构设计工作的业务人员的影响，他们的逻辑思维能力、结构化能力、企业级观念和意识都有明显的改变，所以，应当将业务架构从 IT 战略中独立出来，更多面向业务人员，以充当业务与技术之间的桥梁。当然，业务架构真正要承担起这一职责，还需要改进、简化业务架构设计方法，对业务人员更友好，并且坚持使用业务架构方法做企业级需求管控，否则，熵增一定会将已经建好架构秩序回归混沌状态。
原帖：https://www.cnblogs.com/dadadechengzi/p/10005773.html
