在企业的发展过程中，业务架构模型起着至关重要的作用。它就像是一幅地图，为企业的发展指引方向。但这个模型并不是直接就能用在开发过程中的，还需要经过一些“转换”工作，才能变成切实可行的业务架构方案。
一、业务架构设计不是为了替代需求分析
经过一番努力，我们建立了企业级业务架构模型。在这个过程中，我们分析了企业战略、价值、组织结构、价值链、业务领域、岗位角色、业务流程、数据等很多方面，最后形成了企业级业务组件和数据主题域的划分。
业务架构设计可不是为了只停留在纸上，而是要推动开发，特别是面向复杂系统的企业级开发。不过，目前这个业务模型能表达的信息还是有限的。所以，在讨论怎么把它用在开发之前，我们得先明确它的定位。
我们做的这个模型是用来做高阶设计的。从战略角度出发，先分析企业的目标和需要的业务能力，然后按照业务领域把能力需求落实到业务流程中，再划分出能力组件，形成企业能力视图。但这个架构虽然很有条理，却还没精细到能直接出 IT 设计方案的程度。它只能明确企业级架构，不能替代具体的需求分析，它更关注企业的整体结构而不是每个小细节。
企业级业务架构是一种规划，要求 IT 设计继承这个结构，继续往下分解成 IT 设计元素。它就像一座桥，让业务以更结构化、逻辑化的方式进入软件过程。业务架构设计到这个层级，和实施之间有一定的自由度，这有好有坏。好处是能保持架构的稳定和灵活，坏处是需要架构设计人员和实施人员密切沟通，不能直接继承。
二、制作业务架构方案
明确了定位之后，我们来看看业务架构落地的第一步，就是把模型转化成业务架构设计方案。模型包含很多东西，但直接看模型可能不是个好办法，特别是企业有多个项目组同时开工的时候。如果把复杂的业务架构设计以模型的方式直接交付，肯定会有各种不同的解读。所以，把模型转化为方案的过程其实是导读和解释的过程。方案主要有三个部分的文档：企业级架构方案的整体描述、分领域或分应用的方案描述、业务组件的方案描述。
1. 企业级架构方案的整体描述
业务架构方案中需要单独整体介绍的内容有：
2. 企业级业务架构方案的分领域描述
对于大型企业来说，如果业务架构方案不分领域详细阐述，会很难阅读。所以，方案比较大的时候，应该分领域介绍，这样也方便查阅。但如果企业规模不大，业务不复杂，领域不多，也可以不拆分文档。
领域级方案描述的主要内容有：
业务领域的目标、范围：明确业务目标，要是目标很大，可以分成子目标或分阶段目标，让 IT 人员明白具体的目标点和实施路径。
业务领域的外部干系人介绍：解释各方与本领域的关系。
业务领域的全部业务活动介绍：分价值链环节介绍业务活动、承接的战略能力、活动触发和衔接关系。因为建模时活动有独立性，所以衔接关系要在领域级方案中重点说明。业务活动的介绍顺序没有标准，但企业内部最好统一，方便跨领域阅读。战略能力的承接不一定每个活动都很明确，这和战略能力的颗粒度以及企业战略重点有关。
对部分任务的“降范”描述：如果企业项目实施规模大，任务抽象导致范围大于实际需要，解读有困难，可以在领域级方案中对这类任务专门描述。但如果企业对业务模型的统一解读能力强，也可以不描述。
业务组件协作关系介绍：在价值链视角下，用高阶抽象的方式介绍业务领域涉及的业务组件之间的协同关系。
业务领域完整的实体关系图：展示业务领域中涉及的全部数据实体及其关系。
组织与角色描述：按照组织结构介绍业务活动中执行各个任务的岗位和角色。
分领域的业务架构方案描述是从应用视角介绍的。如果业务领域复杂，包含多个松散的应用，比如银行的金融市场领域，外汇、贵金属、利率等业务可以形成不同的应用，那么可以再细分应用视角的业务架构方案，免得增加阅读难度。
3. 业务组件描述
业务领域和业务组件一般是多对多的关系。比如在一个例子中，存款领域和贷款领域共用客户管理、账户管理组件。IT 人员通常按应用视角组织项目，方便管理目标和处理协作关系，但项目内部又会按组件或更细的功能边界划分实施团队，便于分工和组织。
所以，业务架构方案要有两种视角的表达能力，既能从业务领域视角形成组件的协作视图，方便单个项目组织；又能从组件视角清晰描述组件内部的业务能力，方便企业集约化实现和维护这些能力。企业级能力的整合体现在组件视角上。
业务组件描述的主要内容有：
业务组件的目标、范围：描述业务组件主要支持的能力方向和边界。
数据主题域的完整介绍：数据是业务组件聚类的基础，所以要介绍属性级别的完整数据模型，区分本组件负责的数据实体和引用其他组件的数据实体。
组件所包含任务的完整介绍：直接用建模结果，列明任务的写操作数据实体，不用详细列明业务规则和操作过程，降低文档维护量，提高稳定性。如果企业战略能力需求划分细，可以在任务描述中标注与细化战略能力的承接关系。
总之，制作文档很麻烦，最好用工具支持文档生成。这也意味着业务模型的设计过程最好也有工具支持，不然各种版本的 PPT、表格满天飞，会让架构工作更混乱。写方案会用到很多标准化描述，看起来很枯燥，甚至像玩“文字游戏”。但整理方案的过程是对业务架构设计的再次确认，不是单纯做文案和 PPT 汇报，要当成全面的模型质量检验来看待。
三、小团队的应对之道
上面说的内容比较完备，但对于规模小、开发团队人少、“敏捷”优先的企业来说，可能觉得文档处理过程太繁琐，负担不起。
大型企业要求高的文档制作标准，是因为规模大容易导致无序增加，需要消耗更多能量对抗无序，文档就是一种消耗能量的方式。而对于中小企业来说，规模带来的“熵增”没那么大，对抗“熵增”不需要那么多能量。这时重要的不是文档，而是“通用语言”的形成，也就是所有相关方对模型的一致解读能力。
在有一致解读能力的基础上，可以降低对文档的要求，专注于提升效率。但业务建模最好有合适的工具支持，除了提升协同效率，还方便快速查询架构设计。支持 BPMN 语法的流程分析工具大多能提供应用视角，但最好增加组件视角的统计与分析能力，这样即使不产生文档，也有较好的架构展示能力。
四、需要充分解释架构方案
业务架构方案做好后，不能指望 IT 设计自然产生，还需要业务架构人员充分解释，保证方案的传导。这有两个原因：
1. 建模过程不能代替对架构方案的解释
如果项目小、人少，可能不是问题。但在大型企业，参加项目的人很多，而业务建模不是所有人都参加的工作。如果建模后没有业务架构人员到项目中沟通需求、宣讲企业级理念，模型的传导可能会“信号衰减”。
2. 架构设计人员的缺位可能会导致方案失效
现实中，业务部门和项目团队可能在对模型理解不一致或解释不清时，得不到业务架构人员的及时支持，就会倾向于直接协商需求。这样可能与最初的建模有差异，如果多个项目组都这样，就会导致业务架构崩坏，最终失效。失效后更麻烦的是，没有统一视图来填补，会形成架构紊乱，“通用语言”可能变成“地方语言”。
要解决这个问题，业务架构人员要跟进各个项目组的建设过程，最好实地跟进。项目启动时，业务架构人员用业务模型向业务和技术人员解释项目目标、架构方案、业务需求，统一思想。因为参加项目的人可能没参加过建模，不了解模型细节和标准化处理。之后，业务和技术人员在模型框架下进行需求沟通和功能分解，遵守项目边界和分工。
五、努力打造“通用语言”
为了提高业务架构方案的传导效率，要把业务模型打造成“通用语言”。除了在项目中应用模型，还需要重视以下两个方面：
1. 培养合格的业务架构师队伍
业务架构师是业务模型的“嘴”，是“通用语言”的教师和传播者。
坚持选用具有足够能力的人员：业务架构师不一定要技术出身，但工作有技术性，所以选用技术出身的人更容易培养与技术端的沟通能力。还要选择有丰富业务系统架构设计经验和业务思维的人，不能只看技术背景。如果企业缺乏这样的人才，可以从业务端补充，但要加强技术知识学习。
坚持长期培养：好的业务架构师要对业务、模型、开发都有深入了解和足够知识储备，这需要长期培养。他们和产品经理、项目架构师不同，对企业需求的宏观把握能力要通过长期积累。如果企业不确定是否长期坚持这种策略，就不要建立固定组织，否则对个人机会成本很大。
坚持让其跟进项目而非只做架构设计：业务架构师要跟进项目判断模型是否合适，实施阶段会有更多细节讨论，可能需要对模型进行调整。只有跟进才能保证架构师不被项目“甩”在身后。
2. 加强项目外的宣讲
在企业内部利用业务培训机会，用业务模型解释业务，让员工了解企业架构和结构化思维方式。很多业务培训用流程图，在企业级项目建设背景下，统一建模方式对业务培训课件和项目宣讲方式，有助于“通用语言”的建设。
人是社会性生物，群体力量靠明确分工和有效沟通。企业级项目就像建巴别塔，需要在“通用语言”上花很多功夫。如果沟通顺畅，不同的人也能一起完成伟大的工程；如果沟通不畅，再伟大的工程也会半途而废。
参考：《企业级业务架构设计方法论与实践》 付晓岩著
