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采用以下固定格式：
| 项 | 内容 |
|---|---|
| 元素名称（Comonent） | |
| 功能职责（Responsibility） | |
| 协作关系（Colaborators） | |
| 解释说明（Rationale） |
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.验证
完成的业务架构需要进行讨论、验证。架构是平衡的艺术。
