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

Solution Design概述

    Solution Design是IBM历史上一个知名的方法论，其设计的初衷始于售前的解决方案设计，因其对庞大复杂的UMF框架做了精选，相对简单又不失完整，在项目实施过程中也广受架构师欢迎。前几年，随着用户体验的崛起，客户越来越注重体验，IBM开始大力推行Design Thinking作为解决方案设计方法论。但是架构师、开发工程师和运维工程师难以使用Design Thinking方法论，所以Solution Design仍然在项目实施阶段被广泛使用。

    如图所示，IBM Solution Design定义了整个解决方案设计流程中的活动，每一项活动都会产生或者更新一些工件，最终形成的解决方案是由一组互相关联的工件共同组成的：

    注意，虽然工件构成的解决方案是最终的成果，不要错误的认为Solution Design方法论是由工件驱动的，应当是由活动驱动设计过程，按需创建并及时更新工件。下面，结合IBM杰出工程师Dr. Marcel Schlatter在苏黎世大学的讲义和IBM杰出工程师蒂拉克·米特拉的大作《实用软件架构：从系统环境到软件部署》，讲解一下方法论中的关键环节和工件。

0. 理解客户业务

    要设计符合客户需要的解决方案，需要对客户当前的业务和IT做适度的了解。包括：了解客户的业务方向，组织架构，IT技术环境和标准。将这些资料形成规范的文档，有助于实施团队和未来的解决方案团队更好的了解客户，提供更优质的服务。

1. 定义客户需求阶段

1.1 定义项目

    活动“定义项目”是回答这个项目要做什么、为什么做，并且得到项目发起人的签字认可。定义项目活动的主要产出工件是《项目定义》，其中包括了目标、背景、目标方案和整体方法、范围、计划框架和组织等。

1.2 识别和罗列需求

    在此活动中定义一组基本的用例以描述用户如何使用系统，理解额外的功能需求并以需求矩阵的形式记录。相较于用例，需求矩阵更适合于罗列大量的需求，同时建立好需求列表以后，也便于评估套装软件的适用性和开发工作量。

1.3 描述系统上下文

    “描述系统上下文”活动，通过绘制系统上下文，设定了所设计系统的边界，同时表现了新系统和已有系统之间地关系。如下系统上下文图，描述了要构建的电子商务系统需和客户端、外部实体以及遗留系统交互（即这些系统不属于电子商务系统），同时表现了系统间的调用方式和通信协议。

1.4 识别非功能需求

    非功能性需求也被称作系统的“质量指标”，常见的非功能性需求包括：性能、可扩展性、可用性、可维护性、可管理性、易用性、数据一致性等。

1.5 定义高阶数据源

    在此项活动中，架构师将识别组织所关注的主题（即主题域），然后建立主题域模型（Subject Area Model），下面的例子是一个航空公司的主题域模型：

1.6 记录架构决策

    在整个架构设计活动中，架构师和团队要做出很多的决策，Solution Design方法论强调要将决策规范的记录下来，一方面可以提高决策的质量，另一方面也可以作为未来需要调整时的参考依据。如下所示，架构决策主要包括问题、假设（或限制条件）、动机、选择（包括优缺点）、决定等内容。

    需要注意的是，及时记录架构决策是一项贯穿整个解决方案设计的活动，并非限于某一时间进行，也不宜等方案设计完成后再补记。

1.7 进行可行性评估

    在充分了解了客户和项目需求后，下一步可以对项目的可行性进行分析，分析项目对于干系人有价值。在分析可行性时，需对在前期工作中发现的风险、假设、问题和依赖做一梳理，并制定应对措施和可能的行动计划。

本文下半部分请看：揭秘IBM架构设计方法论 —— Solution Design II

参考资料

1.  CCRA 4.0 Overview_20140918_non_conf

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

3. https://wenku.baidu.com/view/4c21d7b1ee06eff9aff80768.html

4. https://files.ifi.uzh.ch/rerg/amadeus/teaching/courses/it_architekturen_hs10/

5. https://wenku.baidu.com/view/d77dcd32cf84b9d528ea7adb.html

6. http://walderson.com/IBM/Practices/ScalingAgile