揭秘IBM架构设计方法论 —— Solution Design II

2. 设计解决方案

2.1 开发架构概览

架构概览是解决方案要构建系统的高阶抽象，开发架构概览的主要目的是和项目的干系人沟通系统的主要结构和重要特征，因为不同的干系人的关注点有所差异，系统的架构概览也有不同的展现形式，但其描述的重点都是目标系统。

第一张示例展现的是企业视角，常用于和项目发起人的业务团队沟通，其展现了系统包括哪些大的功能模块，有哪些用户通过哪些渠道使用系统，以及系统需要哪些资源的支撑。

第二张示例是展现的是分层架构视角，常用在SOA架构方案的设计中：

第三张示例展现了从IT视角绘制的架构概览图：

2.2 调研候选资产

在此步骤中，架构师应当调研可以利用的资产，资产包括套装软件、开源软件、之前项目开发的可复用构件等，分析这些资产和项目需求的切合程度及差距。调研完成后，调研的结果编制成候选资产列表（Candidate Asset List）。候选资产列表举例如下：

2.3 定义关键服务

在设计SOA架构方案时，定义项目相关的服务是一个重要环节，这些服务可以是已有的，也可以是需要新建的。在定义关键服务时，要评估服务如何满足重要的功能需求和非功能需求。

2.4 开发高阶组件模型

组件（Component）也称为构件。组件模型用于宏观地描述系统结构，描述组件的职责、关系边界和交互。如下图所示，常见的组件模型包括组件关系图和组件交互图。如下图，组件关系图展示了组件或子系统间的静态依赖关系。

组件交互图则展示了组件之间如何协作以实现一个场景，同时也展现了组件间的调用流程：

2.5 开发高阶运维模型

运维模型描述了组件将部署在哪些地理位置，在哪种类型和配置的硬件上，以及这些硬件间如何连接。和组件模型相比，组件模型更关注于系统如何实现功能需求，而运维模型对于系统实现非功能性需求至关重要。下图是一个典型的运维模型：

2.6 完善可行性评估

可行性评估是一个在解决方案开发过程中多次进行的活动，在方案设计接近尾声时，应当再次完善可行性评估。此时，要谨慎评估方案在计划的人员、费用、时间，预知的风险和现有技术水平下可能实现；要重新协商不切实际或者有重大挑战的需求；评估方案的对业务和组织的冲击是否可承受。
2.7 评估整体方案

在向客户宣讲解决方案前，要正式的审阅整个技术方案，评估方案是否满足了客户的成功条件，客户是否可能接受这个方案。

2. [印]蒂拉克·米特拉. 实用软件架构：从系统环境到软件部署. 机械工业出版社, 2017