中台之上（七）：不神秘但很麻烦的业务架构落地过程

将模型转化成方案

业务架构设计不是替代需求分析的

经过之前的努力，我们终于建立了通过业务模型设计的企业级业务架构，建模过程中，已经分析了企业战略、企业价值、组织结构、价值链、业务领域、岗位角色、业务流程、数据等一系列架构元素，通过模型方法对上述元素进行了分析，并形成了组件、主题域的划分。业务架构设计并不是为了停留在纸上，而是为了实践，为了推动开发，尤其是面向复杂系统的企业级开发。但是，模型能够表达的信息其实是有限的，所以，将模型应用于开发之前，我们还是要明确好模型的使用价值和定位。

按照之前的方式做的模型是用来进行高阶设计的，从战略出发，分析企业的目标和为实现目标需要的业务能力。然后，按照业务领域，将能力需求落实到实际的业务流程中，并根据架构设计方法，划分出能力组件，形成企业的能力视图。这样，就产生了高阶架构。但是这个架构虽然分析的有条有理，却并没有细到可以直接出 IT 设计方案的程度，也就是说，它只能明确企业级架构，不足以替代具体的需求分析。它更关注的是企业视角的整体结构，而非每一个细节。企业级业务架构是一个规划，而非详细的实施图纸，它要求的是 IT 设计继承这套结构，继续向下分解为 IT 的设计元素。

业务架构设计到当前这个层级是可以与实施之间保持一定自由度的，即，不完全受实施方式的约束。这种自由度是好事儿，可以保持架构的稳定和灵活；但也有不利的一面，它与实施的结合离不开架构设计人员与实施人员的密切沟通，它不是一个无需解释就可以直接继承的设计。

业务模型向业务架构方案的转化

明确了这个定位，我们再继续探讨业务架构落地过程的第一步，也就是将模型转化成业务架构设计方案。模型涵盖了很多东西，但是直接看模型并不是一个好选择，特别是做企业级项目，多个项目组同时开工，如果业务架构设计以模型的方式直接扔下去，必然会解读的千奇百怪，这是很自然的事情，“一千个人眼中有一千个哈姆雷特”。所以将模型转化为方案的过程其实是个导读和解释的过程，我们一起理理方案应包含的内容。

IT 人员做系统分析时会关注三个比较重要的东西：边界、结构、关系。首先是边界，边界就是系统的范围，也是我们工作成果的范围，没有边界的项目永远做不成，因为永远也做不完。所以，业务架构方案要阐明业务的边界，这是最高阶的上下文。对于整体价值链和全领域视角的整体介绍可以单独形成文档，作为整体概念向整个企业传导。而领域级阐述的方式则应首先解释业务领域的定义、范围和利益干系人视图，利益干系人视图可以解释清楚所有业务参与方及其诉求，也就是大家对功能的期待。在阐述清楚上述内容之后，要明确业务目标，就是方案要达到的业务效果。如果目标比较宏大，则可以在总目标下分解出子目标或者分阶段的目标，以使 IT 人员能够理解具体的目标点或者实施路径。

解释了项目边界与目标之后，进入结构、内容的编写，也就是阐述活动、任务、实体及组件的设计，以及它们之间关系。对于新建领域，可以从价值链的简介开始，明确高阶的结构。之后，可以选择活动的介绍顺序，按照活动的内在顺序介绍还是按照价值链的顺序介绍其实都可以，并没有严格规则，但是一个企业内部最好采用同一种顺序，这样便于跨领域阅读架构文档。我们上一讲介绍的案例比较简单，如果我们采用它继续做示例，则可以按照价值链的顺序依次介绍各个活动，比如存款领域，依次介绍“设计上架产品”、“获取新客户”、“维护老客户”、“存款”四个活动，以活动为单位介绍活动的范围，要达到的目的以及活动之间可能的衔接关系；详细介绍参与到活动中的角色，包括其归属的部门；简述每个任务的执行过程，任务间的衔接关系、角色在任务中的权限，每个任务中如何创建、修改数据实体。对活动和任务介绍完后，则对本业务领域涉及的数据实体按照主题域进行 ER 图展示。流程模型和数据模型介绍完之后，介绍本领域涉及的组件，对每个组件的边界、包含的任务和数据实体进行说明。业务架构方案大体包含这些内容。

需要说明的是，从业务领域入手形成业务架构方案，实际上是从应用视角着手，对于较为复杂的业务领域，可能包含多个应用，比如金融市场领域中，外汇、贵金属、利率等业务都可以形成不同的应用，那么一个领域下就可以再细分为多个业务架构方案，而不必都混在一起，把方案搞得太过复杂，部头儿太大，难以阅读。另外，业务领域或者说应用与组件之间是多对多的关系，比如存款领域中的客户管理、账户管理组件跟贷款领域就是共用的。习惯上 IT 通常会按照应用视角组织项目，这样比较容易管理项目目标和处理协作关系，但是项目内部又会考虑按照组件来划分实施团队，这样便于功能开发的分工。

所以，业务架构方案必须具备两种视角的构造能力，既能从领域视角形成组件的协作视图，又能从组件视角形成一类业务能力如何被整个企业运用的分工视图，这是两种不同的文档，做为架构方案来讲都应该支持，否则，负责组件开发的实施团队就难以把握企业级的实施要求，对于粉“中台”的同学来讲，组件文档也是规划中台需要的，但是文档制作是件非常麻烦的事情，所以，最好采用工具支持文档生成。

写方案的过程要下定义、讲范围，好多时候看起来是枯燥的文字工作，甚至有些时候为了区分一些相近的概念，还会玩起“文字游戏”，但是，整理业务架构方案的过程其实是对业务架构设计的再次确认，而非单纯的图纸翻文案、搞 PPT 汇报，一定要把这个过程当作是一次全面的模型质量检验来做。

落地的关键：对模型的解释

人是社会性生物，群体力量远胜过个体，而群体力量的发挥依靠的是明确的分工和有效的沟通。沟通顺畅，不同族群的人也能一起把巴别塔修到天上；而沟通不畅，再伟大的工程也只能半途而废。企业级项目就是一类典型的巴别塔项目，巴别塔要成功就要所有人形成统一语言，而用于描述企业级业务架构的业务模型，其主要作用之一就是承担统一语言的职能，通过模型传播业务知识。

为什么还需要解释？

经过建模过程，我们将企业目标落实到业务过程中，并将其整理成业务架构设计方案，做为“语言”的模型和做为“书籍”的方案都齐备了，但是知识的传播并不会就这样顺理成章地进行下去，如同练功一样，需要一个不间断的实践过程。

大家可能会觉得，建模过程不就解决了各方对模型的理解了吗？如果项目范围小、参加人数少，这自然不会成为大问题，但是如果在大型企业，数万人、十几万人、甚至几十万人的企业，按照管理学定律，沟通的复杂度是呈几何级数上升的。大型企业中，直接参加项目的人也是非常多的，以笔者所在单位曾经做过的企业级项目而言，集中建模阶段，参加业务建模的人数约 500-600 人，而实际参加开发的人员则达到上万人次。可见，真正做过建模的与参加项目的人数比例大约在 1：20 以上。

集中建模阶段过后，常规负责建模工作的人大约不到 100 人，也就是后续需求产生时，即便只按照项目平均参加人数计算，在同一时间内，建模人员与项目人员的比例也在 1：50 左右，可以说还是非常少的。在这种情况下，如果建模完成后，没有建模人员到项目中去以模型沟通需求、以模型宣讲企业级理念，指望模型自己说话是不大可能的。

现实情况中更可能的是，做为需求提出方的业务部门和做为实施方的项目团队坐到一起，在双方对模型理解不一致或者对模型中有些地方解释不清时，如果得不到业务架构团队或者建模团队的及时支持，自然会倾向于双方直接协商需求，而这时的沟通结果很可能与最初的建模会有差异，如果这种差异在多个项目组中形成、累积，势必会造成业务模型的崩坏，最终结果可能使模型和企业级业务架构失效，而失效之后更麻烦的是，将没有一个统一的视图能够对模型失效产生的“真空”进行有效填补，时间一长，就会形成架构的紊乱，“统一语言”可能会变成“统一误解”。

跟上去，业务架构师

解决上述问题的办法并不难，必须要求做建模的业务架构人员跟进各个项目组的概设过程或者敏捷过程，最好能实地跟进。项目启动时，首先由业务架构人员就业务模型向参加项目的业务和技术人员统一解释项目目标、架构方案、业务需求，由参加项目的业务和技术人员共同确认，因为这时参加项目的人员很可能并没有参加过建模，对模型中的细节、建模中对原有业务基于标准化进行过的处理并不了解，需要业务架构人员再次统一思想。之后，再由业务人员和技术人员在模型框架下进行需求沟通和功能分解，遵守基于模型产生的项目边界和分工。

如果要形成“统一语言”，业务模型必须对项目具有较强的指导性和约束力，但这也对负责建模的业务架构人员提出了较高要求，要对业务、模型、开发都具备足够的了解，这样的业务架构师必须长期培养才能产生，他们不同于产品经理和项目上的架构师，其对企业需求的宏观把握能力只有通过长期的积累才能达到。要求模型具有约束力并不是模型无论对错都要遵守到底的意思，没人会这么“死心眼”地去做架构，因此，业务架构人员跟进项目的另一个目的就是判断模型的适合性，在建模期间掌握的信息很可能是不足的，而到了实施阶段则会对细节有更多的讨论，随着信息的增加，包括对客观因素的考量，很可能会对原有模型进行适度调整，这时，业务架构人员必须切实履行其职能，承担起架构职责，而非一味要求对模型的遵守。架构是有原则的，但架构也不能失去灵活。建立“统一语言”是为了提升效率，安排业务架构师，是为了让“语言”被恰当使用，而不是造就新的“技术官僚”。因此，凡是要建立企业级业务架构工作团队的，务必考虑清楚对其职责的定位和应当给予的信任与权力，同时，也应当坚持选用具有足够能力的人员。如果不能确定企业会长期坚持这种策略，就不要建立这样的固定组织，否则对从事该项工作的个人而言，会造成极大的机会成本。

此外，还有一点就是应当在整个企业内部不断利用业务培训的机会，用业务模型去解释业务，使各个条线的员工都能对整体的企业架构有所了解，对模型化、结构化的思维方式有所了解。其实每个条线或者领域的业务本身都会经常制作流程图，很多业务培训也是用模型的方式在培训，那么在企业级项目建设的背景下，使用同一种建模方式对业务培训课件和宣讲方式进行统一，会对“统一语言”的建设有很大帮助。

业务架构师也要经常反思自己做过的设计，要“多吃自己的狗粮”；在有业务架构师团队的情况下，经常开会讨论设计得失，集体吃“狗粮”，对于提升业务架构整体和设计思维的一致性也非常有意义。

大家也可能对如此大费周章地建立业务模型、业务架构感到不解，我们不妨回想下业务架构最重要的作用：跨越“数字鸿沟”，尤其是帮助业务人员跨越。现在，科技与业务深度融合已经成为共识，但是融合首先是人与人之间的融合，这种融合非常依赖沟通方式和工具，在科技唱主角的时代背景下，如果业务人员与业务人员、业务人员与技术人员、技术人员与技术人员这三个层次之间的沟通都能具备更高的效率，那会为企业减少多少沟通成本、带来多大竞争优势！所以，在“统一语言”上投注多大的力量都不为过，而基于模型的沟通，就是打造“统一语言”一种有效方法。

现在很多企业都想仿效阿里的中台战略，通过这种中台方式支持业务的灵活变化，但是，大家是否深入思考过中台的积累过程？是像童年的小猪储蓄罐那样，你丢个硬币、我丢个硬币这样“攒”起来的吗？中台的沉降一定是个不断标准化、不断去伪存真的过程，反复也是一定会有的，而基于能够提供标准化判断依据的工具进行持续的沟通，是设计过程汇中必不可少的。阿里多以 DDD 方法为基础，而要想做更高一级的企业级规划，则需要采用能够从企业级视角着手分析的方法。并不是因为阿里的成功，那些看起来有点儿“老气”的方法就落后了，工具总是“尺有所短寸有所长”，工具的威力，更多还是在使用者自身的运用能力和决心毅力。