本文深入解析了业务架构的重要性，使用TOGAF框架，通过27个案例介绍了业务架构的核心概念、企业架构全景图、关键制品如组织单元、价值流图和业务能力图等内容，强调了业务架构在IT人员与业务人员沟通中的桥梁作用。
在架构系列文章中，我写过一篇《把业务架构搞搞懂，才算敲开了理解业务的大门！》，在拜读了TOGAF后，我觉得有必要重写一篇业务架构的文章，重新阐述我对业务架构的最新理解。
在这里，我会采用图、目录和矩阵的形式，附以27个案例，讲清楚业务架构的内涵。
有了业务架构的加持，IT人员在落地数据、应用和技术架构时，将会有清晰的指引。我甚至认为，搞清楚业务架构，IT就成功了大半。
对于业务人员来讲，能将自己的业务知识以业务架构的方式呈现出来，这是理解业务的大道，也是与IT人员沟通的桥梁。
一、企业架构全景图
TOGAF（The Open Group Architecture Framework）是一个工具集、术语集和流程集，提供了一个全面的方法来开发企业架构。TOGAF的中心是一个被称为"架构开发方法"（Architecture Development Method，简称ADM）的流程，如下图所示：
我们最关注的是业务架构、数据架构、应用架构及技术架构，这些架构层次的描述体现了从高层策略到低层实施的逐渐细化的逻辑。
四种架构域是层层递进、相互关联的。业务架构定义了“我们需要做什么”，数据架构和应用架构描述了“我们将如何做到这一点”，而技术架构则提供了“我们需要哪些工具和技术来实现这一目标”的答案。当一个组织制定企业架构策略时，这四个域通常需要协同工作，以确保策略的完整性和连续性。
二、业务架构的核心概念
业务架构是对企业的整体、多维度业务视图的表示，涵盖能力、端到端的价值交付、信息和组织结构。它描述了这些业务视图与战略、产品、政策、计划和利益相关者之间的关系，并将业务元素与业务目标及其他领域的元素相互关联。
要理解业务架构图，前提是正确理解业务架构最关键的实体概念和关系，下面是TOGAF给出的业务架构的核心元模型图，其中示意了业务架构核心实体（包括组织单元、参与者、角色、价值流、业务能力、业务功能、业务流程、业务服务等等）及之间的关系。
下表显示了业务架构主要实体的定义：
下表显示了业务架构易混淆实体的概念辨析：
三、业务架构目录、矩阵和视图详解
那么，由这些实体构成的业务架构具体长啥样呢？
TOGAF 提供了一个架构的的交付物制品列表，如下所示：
TOGAF在阶段B，通过27个制品（分为目录、矩阵、图三类表达形式，蓝字是图、棕字是矩阵、绿字是目录）来全面描述业务架构，为了方便理解和介绍，我基于这些制品包含的主要实体进行了分类，共分为组织、价值流、业务能力、业务功能、业务流程、业务服务、综合及其它等八类，如下表所示：
下面我会以案例的形式，给出每个制品的实例，让大家对制品的形式、要素和内容有感性的认识，从而更好的指导实践。
1、组织单位
（1）组织分解图
组织分解图（也称为组织结构图）是一个图形表示，展示了一个组织内的部门、团队或单位之间的层次结构和关系。它通常表示了报告结构和信息流的方向，并可能显示个体、职务、角色或团队之间的关系。
下面是一个电商的简化版的组织图的示例：
（2）组织地图
组织地图并不是一个单一的制品或特定的图表。而是指的是组织内的不同角色和部门、以及它们之间的关系和相互作用。组织地图可以帮助架构师理解组织的结构和各个部分是如何协同工作的。
下图示例了一个全国企业的组织地图：
组织地图和组织分解图还是有区别的，组织分解图图侧重于内部，并用于向其利益相关者传达业务的基本结构和报告关系。组织地图则以整个系统为导向，以准确地表示企业业务模型中各主要参与者之间的关系，无论是内部还是外部。传统的组织分解图对组织内部存在的复杂交互和关系几乎没有揭示。
组织地图则更准确地描述了业务单位和外部方之间的合作和协作关系。这种对关键关系的更丰富描述为了解业务条件或业务模型动态的变化如何影响整体运营和组织的交付能力提供了更好的工具。
（3）参与者/角色矩阵
这个矩阵的目的是显示哪些参与者扮演哪些角色，支持安全和技能需求的定义。了解参与者与角色的关系是定义培训需求、用户安全设置和组织变革管理的关键工具。
演员/角色矩阵显示以下元模型实体和关系：
■参与者
■角色
■演员扮演角色关系
以下是参与者/角色矩阵的示例：
（4）组织/参与者目录
组织/参与者目录的目的是捕获所有与IT互动的参与者的明确列表，包括IT系统的用户和所有者。在开发需求时，可以参考组织/参与者目录以测试完整性。例如，为服务客户的应用程序的需求可以通过准确验证需要支持哪些客户类型来测试完整性，并确定是否有针对用户类型的特定需求或限制。
以下是组织/参与者目录的示例：
（5）角色目录
角色目录的目的是提供一个企业内所有授权级别或区域的列表。通常，应用程序的安全性或行为是根据在用户桌面上结合时可能产生复杂和意外后果的本地理解的授权概念来定义的。角色目录可以在架构开发和变更管理过程中用作参考。
角色目录包含以下元模型实体：
■ 角色
■ 参与者（可选地）
以下是电商业务的角色目录的示例：
（6）驱动/目标/目的目录
驱动/目标/目的目录的目的是提供一个跨组织的参考，以了解组织如何通过目标、目的和（可选地）衡量标准来满足其驱动。发布驱动、目标和目的的明确细分允许企业内的变更计划识别组织内的协同效应（例如，多个组织试图实现类似目标），从而使利益相关者得以识别，以及相关变更计划得以对齐或整合。
驱动器/目标/目的目录包含以下元模型实体：
■ 组织单元
■ 驱动
■ 目标
■ 目的
■ 衡量标准（可以选择性地包括）
以下是驱动/目标/目的目录的示例：
2、价值流
（1）价值流图
价值流程图是一组图表，代表了为客户、利益相关者或最终用户创建整体结果的端到端增值活动的明确列表。在建模术语中，那些增加价值的活动是由价值流阶段代表的，每一个都从一个阶段到下一个阶段创建和增加递增的利益相关者价值。
价值流可能是外部触发的，如零售客户购买一些商品。价值流也可能是内部触发的，例如经理获得一个新的雇员。
价值流图包括以下的元模型实体：
■ 业务能力
■ 价值流
下面是一个简化版的客户购买商品的价值流图的示例：
价值流的一个关键原则是价值总是从利益相关者的视角定义的 - 产品、服务或交付物的客户、最终用户或接收者。获得的价值在观察者的眼中；它更多地取决于利益相关者对产品、服务、结果或交付物的价值的认知，而不是其固有价值；即，生产的成本。
（2）价值流/能力矩阵
这个矩阵的目的是显示支持每个价值流程阶段所需的能力。
以下是客户购买商品的价值流/能力矩阵的示例：
（3）价值流目录
价值流程目录是一个明确列出为客户、利益相关者或最终用户创建整体结果的端到端增值活动集合的清单。
下面给出了一个企业的典型价值流目录：
（4）价值流阶段目录
价值流程阶段目录是一个明确列出为客户、利益相关者或最终用户创建整体结果的端到端不同阶段的增值活动集合的清单。
下面给出了一个企业招聘员工的价值流阶段目录：
3、业务能力
（1）业务能力图
业务能力图是一种工具，用于描绘组织在达到其商业目标和目的时所需的核心能力。这些能力是组织的基础属性，并且与它们如何实现这些目标（即具体的过程或技术）是相互独立的。
业务能力通常是抽象的，不依赖于特定的组织、过程或技术。与经常变化的业务过程或组织结构相比，能力相对稳定。它们代表了组织的核心价值和竞争优势。业务能力界定了业务做什么，而不试图解释业务如何、为什么或在何处使用这种能力。
下图示例了某公司的业务能力图，为了管理方便，分了三层，战略、核心和支持，同时可以根据需要将每个顶级（级别1）业务能力分解为更低级别以传达更多详细信息，以适应关注的观众或利益相关者组的级别，在这里，人力资源管理是一级业务能力，有七个二级业务能力，包括人力资源绩效确定等等，同时通过色块表达能力的成熟度或者举目标的差距。
（2）能力/组织矩阵
这个矩阵的目的是显示实施每个能力的组织元素。
能力/组织矩阵包括以下元模型实体：
■业务能力
■价值流程
■组织单位
以下是能力/组织矩阵的示例：
（3）战略/能力矩阵
这个矩阵的目的是显示支持特定战略声明所需的能力。这种矩阵可以用于识别和描述组织的能力，并且可以帮助确保这些能力与组织的战略目标相一致。此矩阵可以为企业架构师提供一个清晰的视图，显示了不同的能力如何支持组织的战略目标
以下是电商业务的战略/能力矩阵的示例：
（4）业务能力目录
业务能力目录是一个明确列出企业可能拥有或交换以实现特定目的的能力的清单。
下面给出了一个业务能力目录示例：
4、业务功能
（1）功能分解图
功能分解图的目的是在一页上显示与架构考虑相关的组织能力。通过从功能角度审视组织的能力，可以快速开发关于组织所做的事情的模型，而不会卷入有关组织如何做到这一点的长时间辩论。一旦基本的功能分解图被开发出来，就可以在这个图上叠加热度图，以显示范围和决策。例如，不同阶段的变革计划中要实施的能力。
功能分解图通常使用分层矩形图来表示，其中每一层代表一种更具体的功能集合。这为业务和技术团队提供了一个清晰的、层次化的业务功能视图。
下图示例了电商的简化版的功能分解图，并用绿色颜色标注了成熟的功能，黄色代表了要优化的功能，红色代表了未实现的功能。
5、业务流程
（1）过程流程图
流程图的目的是描绘与流程元模型实体相关的所有模型和映射。流程图显示活动之间的控制顺序，并可能利用泳道技术来表示流程步骤的所有权和实现。例如，支持流程步骤的应用程序可能会显示为一个泳道。除了显示活动序列外，流程图还可以用来详细说明应用于流程的控制、触发或由流程完成而产生的事件，以及由流程执行生成的产品。
流程图在与主题专家详细说明架构时非常有用，因为它们允许专家描述某个特定功能的“工作是如何完成的”。通过这个过程，每一个流程步骤都可以变得更加细粒度的功能，并随后可以被详细描述为一个流程。
下图示例了一个电商下单的流程图，按照系统区分了泳道：
（2）事件图
事件图的目的是描述事件与流程之间的关系。某些事件（例如，某些信息的到达（例如，客户提交销售订单）或某个特定时间点（例如，财政季度结束））会引发工作，需要在业务中执行某些操作。这些事件通常被称为“业务事件”或简称“事件”，被认为是流程的触发器。重要的是要注意，事件必须触发流程并生成业务响应或结果。
下图示例了一个电商的事件图：
事件跟流程中的步骤还不太一样，事件触发的是整个业务流程的所有步骤的执行，而步骤往往只能触发下一个步骤，这里存在一个粒度的问题。
（3）流程/事件/控制/产品目录
流程/事件/控制/产品目录提供了流程、触发流程的事件、流程产生的输出以及应用于流程执行的控制的层次结构。例如，流程/事件/控制/产品目录允许企业查看流程与子流程之间的关系，以确定更改高级流程可能产生的全面影响链。
流程/事件/控制/产品目录包含以下元模型实体：
（1）流程
（2）事件
（3）控制
（4）产品
以下是电商业务的流程/事件/控制/产品目录的示例：
6、业务服务
（1）目标/目的/服务图
目标/目标/服务图的目的是定义服务对业务愿景或战略的贡献方式。服务与它们支持的驱动因素、目标、目标和度量相关联，使企业能够了解哪些服务对业务性能的类似方面有贡献。目标/目标/服务图还提供了关于什么构成特定服务高性能的定性输入。
以下是目标/目标/服务图的示例：
（2）业务服务/信息图
业务服务/信息图显示支持一个或多个业务服务所需的信息。业务服务/信息图显示了由业务服务消耗或产生的数据，还可能显示信息的来源。
主要价值是为组织提供一个清晰的视图，显示了业务服务是如何与关键信息相关联的，这对于信息管理、数据治理以及确保业务服务的连续性和一致性都至关重要。此外，它还有助于识别潜在的信息共享机会或重复的信息源，从而为进一步的优化和整合提供指导。
下面是一个电商的简化版的业务服务/信息图的示例：
（3）业务用例图
业务用例图展示了业务服务的消费者与提供者之间的关系。业务服务由参与者或其他业务服务消费，业务用例图通过描绘该能力如何以及何时被使用，为描述业务能力提供了更丰富的内容。
业务用例图的目的是帮助描述和验证参与者及其角色与过程和功能之间的互动。随着架构的进展，用例可以从业务层面发展，包括数据、应用程序和技术细节。架构业务用例也可以在系统设计工作中重复使用。
下图描述了业务用例图的示例：
7、综合
（1）业务足迹图
业务足迹图描述了业务目标、组织单位、业务功能和服务之间的链接，并将这些功能映射到提供所需能力的技术组件。业务足迹图提供了技术组件与满足业务目标的联系的清晰追踪，同时还展示了已识别的服务的所有权。
下面是一个电商的简化版的业务足迹图的示例：
（2）业务服务/功能目录
业务服务/功能目录的目的是提供一个可以由IT系统支持的业务服务或功能的明确列表。当然，列表也包括在整个企业中或由IT系统支持的商业活动和交易。
业务服务/功能目录包含以下元模型实体：
（1）业务服务
（2）业务功能
（3）交易（可选地）
以下是电商业务的业务服务/功能目录的示例：
（3）业务互动矩阵
业务互动矩阵主要描述组织内部的各种组织单位或角色之间如何互相交互，以及这些互动如何支持不同的业务功能和服务。它提供了一个结构化的方式来捕获和描述这些交互关系。
以下是电商业务的业务互动矩阵的示例，在此业务互动矩阵中，行代表提供服务的组织，而列代表接受服务的组织。例如，产品管理部门会向物流部门提供“产品上下架通知”服务，以确保物流部门知道哪些产品应该配送，哪些不应该。
8、其它
（1）位置目录
位置目录在TOGAF的业务架构中是一个清单，用于记录企业进行业务活动或存储与架构相关资产的所有地点。这些地点可以是办公地点、数据中心、分销中心或其他任何与企业运营有关的地方。当企业计划变更或部署新系统时，了解所有的业务地点是很关键的。这有助于确定项目的影响范围、计划资源的分配和评估各种与位置相关的因素（例如网络延迟、时区差异等）。
以下是电商业务的位置目录的示例：
（2）合同/度量目录
合同/度量目录提供了所有协议服务合同以及与这些合同相关的度量的列表。它形成了企业范围内同意的服务水平的主列表。
合同/度量目录包含以下元模型实体：
■业务服务
■信息系统服务（可选）
■合同
■度量
以下是合同/度量目录的示例：
（3）产品生命周期图
产品生命周期图的目的是帮助理解企业内关键实体的生命周期。了解产品的生命周期对于环境问题、法规和法规方面变得越来越重要，其中产品必须从制造到处理进行跟踪。同样，创建涉及个人或敏感信息的产品的组织必须在业务架构开发过程中详细了解产品生命周期，以确保在设计控制、流程和程序时具有严密性。这些示例包括信用卡、借记卡、商店/会员卡、智能卡、用户身份凭证（身份证、护照等）。
四、总结
我们平时经常在讲要懂业务，但到底什么才叫懂业务？对于IT人员来讲，如何才能把所谓的业务结构化的讲清楚，从而写出高质量的业务需求说明书？
唯有业务架构吧。
每个架构师都可以基于这27个制品，画出属于自己企业的逻辑严谨的业务架构图，从而跟业务、应用、技术和管理人员做出更好的沟通，这是数据、应用和技术架构的输入和起点。
有人说TOGAF把架构搞得太复杂了，一个业务架构就搞27个制品，还搞出这么多容易混淆的概念。但实际上，这恰恰体现出TOGAF的严谨性、系统性和全面性，你拿出实践中任何一张业务架构图，都会发现逃不出TOGAF的制品范围，最多不过是几个制品的编排而已，而且你一看就知道里面有些什么问题。
下面是我网上随便找的一张微信业务架构图，你看出了什么门道？
这张图对应业务架构制品中的一种，即功能分解图，但显然这张架构图混淆了应用架构和业务架构，理论上，微信公众平台这种组件不应该出现在业务架构的图中，即使不影响使用，这种图也是不严谨的，比如对于一个没接触过微信公众平台的业务人员来讲，很难去理解这张图的分类逻辑。
我们需要掌握的，是业务架构最底层的东西，27个制品就是你以不变应万变的武器。况且，我们总有考虑不完善的地方，当你需要更多启示的时候，这就是最后的救命稻草。
下次，跟大家聊聊技术架构，作为有技术情节的人，我自己也要把这一课补上。
埃森哲IT规划咨询方法论（3763）
把业务架构搞搞懂，才算敲开了理解业务的大门！（5262）
点击左下角“阅读原文”查看更多精彩文章，公众号推送规则变了，如果您想及时收到推送，麻烦右下角点个在看或者把本号置顶！
2018
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
