《企业级业务架构设计方法论与实践》解读

导读：

“ 数字化转型的必经之路是架构设计，企业级架构设计方法论中 Togaf 首屈一指。理论性较强的架构体系总给人一种术高莫用之感，付晓岩老师的《企业级业务架构设计：方法论与实践》将 Togaf 之中的阶段 B 业务架构显化，详细说明了如何使用价值链进行业务架构设计。

现将韩老师个人解读的读书笔记公布于此，与各位看官分享。”

01

—

Togaf 业务架构

在执行企业架构过程中，将会产生大量输出，如业务流程、架构需求、项目计划、项目合规评估等。

为了能以一致的、结构化的方式来校对和展示工作产出物，需要一个架构模型框架来放置这些工作产出物。

这样方便工作产品的引用和标准分类，帮助改善不同结构的工作产出物之间的关系。

Togaf 内容原模型阐述了构建快如何被描述和构建快间如何关联。

其中战略是付晓岩老师在业务架构设计中一直强调的基础。

架构工作同开发一样，也需要交付。在 Togaf 定义中架构会输出制品、交付物等。其中 Togaf 业务架构输出的制品包括：目录、矩阵、图。

目录包括：组织/执行者目录、角色目录、流程/事件/控制/产品目录等。

矩阵包括：业务/交互矩阵、执行者/角色矩阵。

图形包括：业务足迹图、业务服务图、功能分解图、用例图、组织分解图、流程图、事件图等。

Togaf 业务架构交付物包括：风险管理、架构定义文档、架构需求规格说明书、业务场景、差距分析、架构构建快、解决方案构建快等。

其交付物与付晓岩老师此书第三部分相吻合。

Togaf 一直强调是基于能力的业务规划，其方式之一是使用价值链完成业务分析工作，与付晓岩老师此书第二部分不谋而合。

02

企业级业务架构设计：方法论与实践

企业架构 EA 的理论框架总给人高高在上，术高莫用之感。

这一方面是因为，企业架构本身是一个高阶软件研发课题，能够真正有机会参与到企业架构设计的人并不多；

另一方面是因为，企业架构某些方面来讲偏形而上，从几套业界的方法论，到具体实践层面，存在着一个鸿沟，很多人可以泛泛的谈论这套鸿沟上的桥梁的模糊形状，但具体如何搭建这座桥梁，其实并不清楚。

整本书的核心，是通过价值链模型作为理论基础，基于价值链塑造的业务流程为出发点，分析多场景下的业务对象本质，并经过超越了业务场景的实体抽象过程，得到企业级视角下的数据模型。

Togaf 业务架构定义：

所谓业务架构，是把企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，它包括业务的运营模式、流程体系、组织结构、地域分布等内容。

付晓岩：

业务架构从企业战略出发，按照企业战略设计业务及业务过程，业务过程是需要业务能力支撑的，从战略到业务再到对业务能力的需要，就形成了支持企业战略实现的能力布局，可以将这个布局理解为业务架构，它是企业为客户创造价值的设计过程。

业务架构设计完成后，“灵魂”就诞生了，IT 架构则是根据“灵魂”的需要来设计“容器”。

我们会看到战略设计变革组织设计，组织设计影响战略设计，业务分析推导组件设计，组件设计优化业务分析。战略与组织设计约束业务架构设计，业务架构设计实现战略与组织设计。

作者在书中提到业务架构设计含两条线：行线与知线。

不少技术人员不重视企业战略，认为企业战略与技术无关，这种想法大错特错。

如果一个企业的战略使得员工觉得与自己无关，那么只能说明这个战略本身以及对战略的宣导是失败的。

不落到流程中的战略是无法被执行的，而与战略落地无关的流程又是在干什么呢？创造的什么价值呢？为这样的流程开发的系统又是干什么呢？

这震耳发聩的提问也反映出了现实的问题，在韩老师从业的过程中也发现同样的问题：业务人员、技术人员，甚至是管理人员对战略的忽视，这也严重制约了企业的数字化转型。

有句话叫：未来以来，你爱来不来。

数字化转型的今天如果还抱有原始软件思路，必定要被淘汰。

迈克波特价值链模型：在波特的价值链模型中，认为企业在创造价值的过程中，所有生产经营涉及的活动可以分为两类，即支持性活动和基本活动，前者支撑价值创造过程，后者完整价值创造和增值过程。

此价值链模型是付晓岩老师此书的核心方法论。

价值链代表了构建企业能力统一视图的“横向”结构，每个价值链环节中均包含了若干个业务流程；业务领域代表了构建企业能力统一视图的“纵向”结构，描述了各类业务流程应如何通过组合实现领域级的业务目标。

业务流程即业务活动，业务活动是由不同角色分别完成的若干任务组成的，任务执行过程中其必然与业务数据发生联系。数据主题域可以将关系紧密的数据进行聚类，再将与数据关系紧密的行为（也就是任务聚类），形成包含行为和数据的业务组件，组件代表了企业的某一类业务能力。

通过 When,Who,Where,Why,How,What 来做分析，分析到底为什么要干这件事，这件事到底有没有价值？其实有时候我们判断价值的时候，用一个简单粗暴的方式去判断的话，就是你产生一个新活动，产生一个新任务了，有没有产生新数据，如果没有产生数据的话，那这个任务本身它的价值就没有那么高了。

单从一个领域去分析，并看不出优势，当把两个、三个领域领域叠加起来，那么就可以抽象出公共能力、公共数据，就会形成整个业务视角，从价值创造过程到每个领域的具体活动任务。

标准化最重要的是数据标准化。企业级数据模型要保证数据实体和属性的唯一性，这样就不会产生重复的概念，重复的概念会造成“同义不同名”，影响数据的使用和统计结果。

任务标准化需要将流程模型与数据模型进行语义对接，分析重复的业务动作，做出标准化的建模判断。

业务上重新审视、理清业务流程，搞清楚具体差异；数据上重新检视实体划分的颗粒度是否正确，避免过度设计。

对于大型复杂的系统而言，需要践行标准化并持续建设，形成一张标准的企业能力地图。

如果架构设计人员缺位，业务部门和项目团队沟通的结果可能会和最初建模存在差异，久而久之积累出很多“地方语言”，业务架构只能“自说自话”。

一方面培养合格的业务架构师队伍，作为业务模型的“嘴”，另外是加强项目外的宣讲，用业务模型去解释业务。

不惜血本去做企业级开发，其实最重要的是转变企业文化，打破部门壁垒，让企业融为一体。这种一体化带来的内部变化、清晰分工和高效协作才是最具价值的，是未来长期竞争力的关键，也是打造“数字化”企业的基础。

做企业级难点不在于技术，企业级真正解决的问题是业务问题、组织问题、思想问题，是超越技术之上建立一个什么样企业的问题。

时间也是架构师的“盟友”，架构师不能指望一次性说服所有人，只能像“盗梦空间”一样，先在对方头脑中“植入”一个“想法”，再逐渐引导“想法”生长。

上述架构设计方法虽然也有基于流程和数据的标准化形成的组件和功能，但其对复用的表达依然偏重流程视角，是活动、任务的复用，而 IT 希望看到的，更直接的复用。

业务架构师的首要责任定义为：“促进业务与技术的深度融合”。

架构落地本质是一个沟通协调的过程。

虽然架构设计二十多年的历史中不愠不火，但在阿里集团内部发展的很好，证明了业务架构设计有助于建立中台规划。

企业级业务架构设计方法并非“银弹”，更不能简单照搬其他企业的架构套在自己身上。它更像一面镜子，镜子中照出的只能是你自己，而照镜子的过程也是一个“赋能”过程，赋予你认清自己的能力，达到“自知者明”的状态。

一个普通士兵想要变成一个特种兵，不是因为给了他一身价值高昂的装备，而是经过了地狱般的训练。上至管理者，下至普通员工，若人的思维不发生转变，则不会带来企业的转变。

软件行业没有“银弹”，任何方法都需要长期坚持并灵活运用，企业级架构是不断演进和迭代的。