架构师书库
企业级业务架构设计：
方法论与实践
点击查看第二章
点击查看第三章
付晓岩 著
|第一部分|
业务架构基础篇
业务架构并非软件工程中新诞生的领域，但是提及的人却很少。这个偶尔走进读者视线的词汇，经常带着一种“花非花、雾非雾”的“朦胧感”，很多人对业务架构究竟在软件设计中发挥了什么作用、有什么好处，以及业务架构和应用架构的关系、业务架构师和产品经理的区别等基本问题说不清、道不明。《软件工程》《软件系统架构》《系统分析与设计》等大家耳熟能详的经典教材也很少提及业务架构这个概念，更不用说企业级业务架构了，目前市面上也几乎没有专门论述业务架构及其设计方法的书籍。本书作为一本企业级业务架构专述，将从业务架构的发展历程、基本理念讲起，让读者对业务架构有一个基本的了解。
|第1章|
业务架构的发展历程
与软件的发展历史相比，业务架构的发展历程其实并不算短，而且也具有几个颇具影响力的架构设计理论。
1.1 Zachman模型
业务架构这个词最初是隐藏在企业架构（Enterprise Architecture，EA）中的。企业架构是20世纪80年代的产物，其标志就是1987年Zachman提出的企业架构模型，该模型按照“5W1H”，即What（数据）、Where（网络）、Who（角色）、When（时间）、Why（动机）、How（功能）6个维度，结合目标范围、业务模型、信息系统模型、技术模型、详细展现、功能系统这6个层次，将企业架构分成36个组成部分，描述了一个完整的企业架构需要考虑的内容，如表1-1所示。
Zachman模型虽然没有明确提出业务架构这个概念，但是已经包含了业务架构关注的一些主要内容：如流程模型、数据、角色组织等，既然没有提出业务架构的概念，自然也就没有包含构建方法，所以，Zachman模型应该算是业务架构的启蒙，同时，它也表明了这一工具或技术的最佳使用场景—面向复杂系统构建企业架构。
1.2 TOGAF
1995年，大名鼎鼎的TOGAF登场了，这个在企业架构市场中占据了半壁江山的架构模型明确提出了业务架构的概念。TOGAF将企业定义为有着共同目标集合的组织的聚集。
例如，企业可能是政府部门、一个完整的公司、公司部门、单个处/科室，或者是通过共同拥有权连接在一起的地理上疏远的组织链。TOGAF进一步定义企业架构分为两大部分：业务架构和IT架构，大部分企业架构方法都是从IT架构发展而来的。业务架构是将企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，其包括业务的运营模式、流程体系、组织结构、地域分布等内容。
TOGAF强调基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统，复杂系统集成的关键，是基于架构（或体系）的集成，而不是基于部件（或组件）的集成。TOGAF还提供了一个详细的架构工件模型，如表1-2所示。
从表1-2中可以明确看到业务架构阶段的交付物，这些内容也清楚地说明了业务架构在软件工程中的位置。相信很多对架构有兴趣的读者都认真学习过TOGAF模型，此处不再赘述。
1.3 FEA和DODAF
在TOGAF之后，又先后诞生了FEA（联邦企业架构）和DODAF（美国国防部体系架构框架）。前者的体系由5个参考模型组成：绩效参考模型（PRM）、业务参考模型（BRM）、服务构件参考模型（FRM）、数据参考模型（DRM）和技术参考模型（TRM），该方法应用于美国电子政务领域，着眼于跨部门、跨机构提升业务效率，解决重复建设、信息孤岛等问题，相当具有“企业级”理念；虽然没有明确的业务架构定义，但是很好地应用了业务架构的思维。后者体系比较复杂，共有8个视点52个模型，但是实用性不错，据说美国国防部和一些相关企业都在使用，详细内容如表1-3所示。
表1-3中的能力视点和作战视点就是我们做企业架构时通常关注的业务部分。这两个模型在网上都有相关资料，感兴趣的读者可以自行查阅。
1.4 沉吟至今
通过寻根溯源我们可以发现，即便是从TOGAF算起，业务架构这个词也有20多年的历史了，但是在开发人员中，业务架构显然没有需求分析的概念明确，业务架构师也远不如产品经理常见。笔者曾就职的单位曾经实施了一个长达数年的、以企业级业务架构驱动的转型项目，但是很多企业并没有这样的经历，因此，每当与技术人员讨论至此，他们就会觉得业务架构有点儿虚，细究可能有如下几点原因。
1.用得少
原有的单体式或竖井式开发依然是企业更常采用的项目构建方法，而这种开发基本上没有横向视角，所以无需强调业务架构，通常的产品分析或者需求分析即足以满足其开发需要。
2.难设计
业务架构，特别是大型企业这种错综复杂的业务架构，说起来容易做起来难。业务架构对战略的分解、业务架构自身的整合与标准化，到IT设计的过渡都存在不少陷阱，业务越复杂宽泛就越难驾驭。因此，即便是尝试过业务架构设计的企业，也有不少是将业务架构设计保持在高阶状态，让做过的人自己都觉得有点儿没底气。
3.易偏离
施工期间由于客观因素可能会导致实施对业务架构的偏离，这种偏离如果没有得到及时纠正或架构调整，那么累积久了就会造成业务架构的失真。
4.难维护
少数度过了业务架构落地困难期的企业，也会由于感受到维护架构的难度而心生放弃，从而降低了对业务架构的评价。
1.5 业务架构的定义
业务架构从诞生之初就很清楚地定义了自己的使命：面向复杂系统构建。也就是说，业务架构与其他架构一样，其目的也是要降低复杂度，从更好地规划和实现系统，因此TOGAF将业务架构归属于IT战略部分。但是从笔者的实践经验来看，业务架构更突出的特点是影响了参加过企业级业务架构设计工作的业务人员，他们的逻辑思维能力、结构化能力、企业级观念和意识都发生了明显的改变，所以，应当将业务架构从IT战略中独立出来，更多地面向业务人员，以充当业务与技术之间的桥梁。当然，业务架构要想真正承担起这一职责，还需要改进、简化业务架构设计的方法，对业务人员更友好，并且坚持使用业务架构方法做企业级需求管控，否则，“熵增”一定会将已经建好的架构秩序回归到混沌状态。
说到这里，本书也尝试为业务架构提供一个简单的定义：以实现企业战略为目标，构建企业整体业务能力规划并将其传导给技术实现端的结构化企业能力分析方法。业务架构就其方法本身而言，既可以用于单个产品线或业务种类的领域级分析，也可以用于跨越产品线、业务领域的企业级分析；就价值而言，后一种显然对企业具有更高的价值，更值得企业去尝试、推广。因此，本书如无特殊说明，使用“业务架构”一词时多是指“企业级业务架构”。不同于一般基于业务诉求的需求分析或产品设计，业务架构的首要责任在于实现业务与技术的深度融合，在于打造能够让企业整体，尤其是业务与技术之间有效沟通的“通用语言”。
如今大热的“中台”概念，说到底也是一种业务架构设计结果，是对企业能力的一种规划，只不过阿里的实践代表的是自下而上的积累方式，而业务架构设计通常是自上而下的规划与演变。如果认真回顾软件设计的发展历程，那么你一定可以发现，所谓的“中台”绝非是一种超越了“企业架构”这个概念的存在。因此，若想要深入理解“中台”，那么多学习业务架构、软件架构的历史还是很有必要的。
