如何编写业务架构 如何编写业务架构 1. 背景 大型 2B 系统复杂度很高，目前业界一般会被拆分成业务需求、技术实现两部分加以讨论。基于对大量失败项目失败原因的分 析统计：导致大型 2B 项目失败的因素，需求分析、逻辑设计相关问题占到 80% 以上，而由纯技术因素导致失败的情况几乎微 乎其微。而需求分析经常遇到的一个问题是，懂业务的人不懂技术，懂技术的人不懂业务，业务逻辑实现与技术实现混杂在一 起导致双方的沟通出现大量不确定因素，导致需求未必理解一致；实现规划也未必一致。决策层需要在项目开始前做出决策， 需要判断一个系统规划是否具备可行性，其中无技术背景人员可能不清楚实施方案是否可行。通过一些深度分析，我们提出 了 “ 业务架构 ” 这个概念来解决这个问题，那么什么是业务架构？一个业务架构应该包括哪些内容？通过怎样的路径去完成一个 业务架构呢？ 以下是笔者对一段时间的业务架构工作的思考和总结。 本文试图给出 : 业务架构的准确定义 业务架构的构成元素 完成业务架构的基本方法 2. 业务架构是什么？ 2.1 传统解决方案的描述方式 缺点：无技术背景的商务分析人员、产品经理缺少对实现的了解 2.2 业务架构描述方式 2.2.1 特性与优点 它是一种架构层面的 ” 大图 “ ，，便于快速理解一个复杂系统，核心需求如何实现，整个体系如何整合，满足关键需求的关键机 制是怎样的？关键系统性的内部能力和支撑机制有哪些？它是对复杂系统的一种高度抽象。通过这样的描述，完成了系统的问 题定义和领域划分。 同时业务架构也提供最基本的设计 脱离技术实现，描述业务实现 只描述重大架构性元素 高抽象度 根据特点，可以看到它的优点是：无技术背景人员可参与实现的讨论 向技术人员描述解决方案核心要做什么，它必须实现的关键特性是什么 高度抽象使得重复使用成为可能，提高交付质量和效率 对比一下，先前的拆分，无技术背景的人是难以参与到实现讨论中来的，管理层无法确认是否靠谱，而业务架构在关键点上对 无技术背景人员实现了可见；抓住重点，对于非重点内容，无需通过这种方式去沟通；高度抽象，一个具备通用性的元素可以 在多个地方使用，从而提高了交付速度。 2.2.2 与业务逻辑层设计的区别 一般在解决方案文档或者分析设计文档中，包括了业务逻辑层设计，需要描述一下和业务架构的区别。 2.2.2.1 服务范围 业务逻辑层设计罗列所有功能性需求，包括所有业务逻辑；一般不包括非功能性需求（非功能性需求在解决方案文档中一般独 立成章） 业务架构只描述架构层重大功能性需求，也反应非功能性需求。 也就是说业务逻辑层设计包括的内容远高于业务架构。 2.2.2.2 表达内容 业务逻辑层设计是一种罗列，表示出逻辑内容即可 业务架构是一种抽象，要揭露问题的本质 简单来说（这不正确，后续会给出完整说明）业务架构包括的是某个模型的描述，模型具有较高抽象性，可能有多种技术实 现。因为不涉及技术实现，所以可以和无技术背景的人讨论。 2.2.3 与需求说明书的区别 需求说明书和业务架构有不同的编写目的，所以差别比较大。 总体来说，需求说明书，重在写 “ 需求 ” ；业务架构，重在写 “ 实现 “ 。在描述功能性需求的部分有一部分重叠的地方，但是对功 能性需求的描述的目的和手段完全不一样，功能性需求是需求说明书的主体和关键；而在业务架构中，只是整理典型功能性需 求，存在是为了引出架构元素的设计和后续实现草案。 2.3 业务架构的定义 提供一种概念性的视角去观察系统架构，用粗线条描述一种概念级别的重大设计。用来描述系统中最基本最重大的设计，帮助 阅读者快速理理解一个复杂系统。一般来说业务架构实现为一系列业务架构图和描述说明文字。 关键元素的定义或角色，起一个能表达特征的名字 关键元素的功能职责 关键元素与其它元素有哪些协作关系，一般包括关联关系或者交互关系 使用场景 与基本机制的集成 业务架构表述了一个系统的关键架构元素和他们之间的关系，即描绘了该系统的轮廓，描述关键架构，表达了元素之间的关 系，由此，读者可以基本了解一个复杂系统的构成与原理。2.3.2 业务架构的边界 业务架构只描述重大需求和实现 业务架构不描述技术实现 2.4 包括的内容 业务架构包括业务架构图和架构元素描述两部分内容。 2.4.1 业务架构图 2.4.2 架构元素描述 用于对业务架构图中包括的元素进行描述，一般采用固定格式 一般采用 CRC-R （ Component-Responsibility-Collaborator-Rationale ）格式描述关键架构元素 ,CRC-R 采用以下固定格式： 2.4.2.1 元素名称 元素的名称，要求明确清晰易理解。 2.4.2.2 功能职责 描述该元素的角色、承担的职责，要实现的特征。 2.4.2.3 协作关系 描述该元素和其它哪些元素有关系，每个关系用一句话描述。关系包括但不限于：组合、聚合、依赖、相关等。 2.4.2.4 解释说明 分析为什么抽象出这个元素、该元素的定位、以及关键功能的说明等，让阅读者清楚写作者的意图。 2.4.3 架构机制 对一些通用机制，比如安全、性能等进行支撑的机制进行描述。架构机制和重大架构元素的区别在于，架构机制适用范围更 广，几乎涉及整个系统，或者主要机制。 架构元素的设计本质做出一些草稿性构思，要求能形成映像、能传基本达观念。一般来说要包括： 实现的思路 预设条件结构描述（类似最基本的数据结构，但是要说清楚，不用技术术语） 注意事项 这部分内容要求不涉及技术，无技术背景者能看懂。 3. 如何写业务架构 其中橙色表示业务架构文档需要包括的内容。 3.1 整理 重大需求（ significant requirements ） 首先不能凭空写业务架构，是从需求中来。 3.1.1 需求采集 重大功能性需求 非功能性需求 重大需求只关注核心且属于架构层面的需求。如果有需求文档、 PRD 文档，那么很大程度可以从中提炼；如果还没有，可以 自己找客户或者真实需求方调查。一般来说，需要业务架构师加入需求分析团队深入了解需求。 3.1.2 用例 整理用例图或者用例，这部内容无需包括到业务架构中，便于理解。 3.2 模型图 （ diagram ） 整理一张图，包括所有业务模型。 3.2 业务模型（ model ） 3.2.1 职责（ responsibility ） 描述该业务组件负责完成的功能。 3.2.2 关系（ relationship ） 描述该业务组件和其它业务组件之间的关系。 3.2.3 分析解读（ rationale ） 分析该业务组件设计的原因 3.2.4 设计草案（可选） 在 CRC-R 之后，提供一些方法对内容进行描述 3.3 整理 架构机制（ architectural mechanism ） 除模型以外，还有一些基础机制，都需要使用，也需要描述到文档中。模型是某一种或者 2 、 3 种业务涉及的通用结构，具备区域性 如果该模型从横切的角度看，具备全局性，那它就成了一个架构机制 5. 验证 完成的业务架构需要进行讨论、验证。架构是平衡的艺术。