IBM架构思维介绍

Keynote 原件地址

什么是IT架构

IT架构的定义

IT架构指该系统具有的一种或多种结构，结构包含软件和硬件元素，元素对外呈现特征，及元素之间的关系。

架构与设计的区别

• 架构为设计提供背景环境：架构创建系统的逻辑层和物理层；搭建技术依赖和非技术依赖的结构；通过定义方案中主要的静态及动态元素，为整个系统的开发提供指引。
• 设计围绕架构实现：创建架构元素的内部行为及附加细节描述

IT架构师的工作

通过定义（架构）解决方案，运用合理的应用信息技术来解决相关的业务问题。这些解决方案以架构形式进行呈现，包含系统、应用程式和流程组件等。

系统性思维与架构思维

两者关系

• 系统性思维是理解事情如何运作的思维方式。具体可参考：《系统思考》、《系统化思维导论》
• 架构思维建立在系统性思维之上，包含如下特性：
  • 运用由上至下的方式解决问题
  • 基于系统方案的递增建设实现从混乱到有序
  • 以结构化的方式呈现结果

架构思维包含的技术

• 需求分析：解决需求间的冲突
• 运用原则：尽可能在企业架构中进行定义
• 在正确的抽象层级建构模型：
  • ❗️围绕更大的场景进行设计
    • 一把椅子在一间屋子
    • 一间屋子在一个房子
    • 一个房子在一个社区
    • 一个社区在一个城市
    • 一个城市在一个省份
    • 一个省份在一个国家
    • …
  • 隐藏不相关的细节
• 建立满足不同利益相关者关注点的视图：常用视图包括但不限于用例视图、逻辑视图、运行视图、开发视图、部署视图
• 提供一个决策跟踪机制

架构思维技术要达到的目标

• 将复杂的信息技术系统分解
• 分析功能性和非功能性需求
• 创立物理层的系统规格
• 建立一个可建构和联结系统元素的策略
• 创建决策跟踪机制，保障系统按期建设
• 定义系统元素组成和分解的规则

架构原则

• 区分关注点
• 信息隐藏
• 按合约设计
• 接口与实施分离
• 职责的区分和分配

架构描述

ADS（Architecture Description Standard） 提供一个标准的架构语言

功能方面

定义：

• IT架构的一个纬度
• 描述了系统的功能性行为
• 用来说明
  • 组件的职责及组件间的依赖关系
  • 组件间的交互关系
  • 组件分组形成的子系统 描述方式：
• IT组件：一个信息技术系统功能的模块元件，可通过接口实现相关功能
• 接口：一个组件可提供的一系列操作
• 合作：在一个特定的场景下，记录组件间互相交换的信息
• 互动：在合作的过程中，一两个组件之间互相交换信息，这些信息发送的顺序与组件间发送/接收的事件相关

操作方面

定义：

• IT架构的一个纬度
• 说明在IT系统的物理结构上如何部署应用组件
• 描述如何满足系统服务等级需求
• 作为详细的基础架构设计蓝图，例如网络设计、平台设计、系统管理设计 描述方式：
• 信息技术节点：在系统中提供特定的服务质量具有指定功能的硬件和软件组件集合体
• 关连性：信息技术节点间必须的连通性
• 部署元件：基于IT组件创建的一个抽象概要简化放置过程
• 地点：地理性区域或位置

需求方面1：功能性需求

什么是需求？

• 功能性需求
  • 能帮助使用者完成工作的能力
  • 回答「什么」是客户需要的（但通常不是指如何达到）
• 质量
  • 定义系统需要满足的期望和足有的特性
  • 可能是运行时（如性能和可用性）或非运行环境的需求（如可扩展性或可维护性）
• 约束条件
  • 被给定的，在项目生命周期和系统范围内不能被改变的

需求的来源

• 企业架构（Enterprise Architecture）：界定了一系列指导原则、标准，以及架构合规性流程
  • 解决方案须支持一个长期的战略性IT目标
  • 解决方案必须要遵守相关的原则和标准
  • 解决方案的策略性目的和意图
  • 必须要遵守的支配性的概念架构
  • 制定审核和批准的管理结构
• 业务案例（Business Case）：
  • 投资的驱动因素会影响技术的选取
  • 重要的需求，例如通过单一客户视图来提供更好的服务，这类因素会影响数据的摆放、现有系统的用户权限设计等
  • 持续的支持费用，例如对支持团队的单点接触需求，会对系统的管理能力提出更好的要求
• 项目背景（Project Context）：
  • 项目应该是解决怎样的业务目标
  • 有什么样的基准技术假设
  • 架构师角色是如何被组织和资助的
  • 牵涉哪些资源？（角色和职责）
  • 与其他进行中和计划中的项目里有什么样的关系？（例如依赖关系）
• 系统关系（System Context）:
  • 澄清系统在何种环境下运行
  • 分清系统界限
  • 辨别外部接口（用户或系统）

Step1：记录需求

• 业务流程：业务流程描述了在部门内部或跨业务部门间，工作任务现在是如何执行的以及未来可以如何设计优化
• 用例：一个用例捕获了系统的功能性需求；每一个用例定义了一个参与者与系统之间一连串的交互，以达成可度量的结果；一个用例由一个主要的场景以及一个或多个备选场景组成
• 用例举例：
  • 主场景：
    • 1. 系统需要个人的细节
    • 2. 使用者提供姓氏和城镇
    • 3. 系统提供住址和电话
    • 4. 用例成功的结束
  • 备选场景：
    • 3a. 不唯一的人名或城镇名
      • 3a1. 系统提供可选的名字和邮编清单
      • 3a2. 使用者从清单中选择了一项
      • 3a3. 系统提供相应的住址和电话
      • 3a4. 用例成功的结束  

Step2：确定关健需求

定义架构时哪一类需求是重要的？进行优先级排序，优先实现重要需求！28原则：哪20%的需求可以驱动80%的用户活动？

• 高回报的业务功能
• 关键的业务操作
• 高容量、高使用率功能
• 必要的系统功能
• 用外部系统交互与同步
• 移动用户
• 覆盖范围广，可影响到许多架构元素
• 安全需求
• 复杂度（例如复杂的业务规则）
• 针对架构的严格需求（例如性能和可行性需求）
• 变化的可能性很高（例如和报税相关的规则）
• 已被确认的重要议题和风险

Step3：管理和追踪需求

• 迭代方式记录、审阅和签署需求，以保证及时的更新
• 建立一个明确定义的和可执行的变化管理流程
• 充分重视定义未来可能的需求（可能对架构的影响）
• 架构和应用系统的持续性评估

好用例的标准

SMART原则

• Specific（具体的）：必须明确的、前后一致的、具有足够的细节
• Measurable（可测量的）：需求必须可以被验证，包含成功的标准
• Attainable（可获得的）：在现实状况允许的情况下必须是技术上可实现
• Realizable（可实现的）：在给定约束情况下可实现（例如资源、技术、时间、基础架设等）
• Traceable（可追踪的）：从概念开始就必须与规格、设计、执行和测试中进行连结

常用的七个经验法则

• 必须是一个完整的句子
• 避免简写，除非有非常明确的定义
• 一致地使用一下词语
  • 应当、将要、必须等表强制性要求
  • 也许、可能等表示选择性需求
  • 能够等表示期待性需求
• 必须包含成功的标准，并且确保是可以度量和测试的
• 提供唯一的识别码，举例NFR-PERF-001
• 指向参考的材料，尽可能不去复制信息
• 避免
  • 模糊（写得清楚和简单明了）
  • 没有重点，冗长的句子和艰涩难懂的语句
  • 不切实际的想法（如100%可靠、彻底安全等）

好的用例七个经验法则

• 一个用例是一个人在某个时间、某个地点所做的事情
• 用例步骤：
  • 一般使用现在时句式（对英语人士）
  • 一个主动动词
  • 描述一个角色为了达成一个目标所进行的过程
• 用例主要是以文字叙述（不是那个椭圆和箭头）
• 用例中不要包含「系统内部」的实现
• 在一个用例中不要有分支（可以利用「可选路径」）
• 不要考虑图形需求
• 设计用例时先基于「广度优先」原则

架构的功能性部分

什么是架构的功能性部分？

• 是技术架构的一个维度
• 描述了系统的功能性行为
• 用来说明：
  • 组件的职责及互相依赖关系
  • 组件间的交互关系
  • 组件分组形成的子系统

什么是组件？

• 组件是描述功能的基本概念
• 组件是功能的模块单元
• 组件通过一个或多个接口实现其功能
• 组件的例子包含：
  • 业务处理组件（例如客户处理组件）
  • 业务服务组件（例如客户经理组件）
  • 技术组件（中间件，例如消息处理或交易软件）
  • 系统软件组件（例如操作系统）
  • 硬件组件（例如加密设备）

组件的表示（UML）

• 通过组件关系图描述结构
• 通过组件交互图描述行为

什么是子系统？

• 一个子系统由多个概念上相关的组件组成。典型的组件分组情况有：
  • 依据在IT系统中的主要功能进行标识，例如会计子系统
  • 被标识为商业软件产品，例如CICS、SAP及其它
  • 与开发共奏团队相关的（平台团队）
• 子系统本身没有接口

组件建模的步骤（迭代进行）

1. 识别组件
   • 分隔成多个子系统和组件，并指定职责
   • 回顾架构模式，参考架构和可重用资产
   • 构建确保松散耦合、高内聚等架构标准
2. 描述组件
   • 明确接口
   • 明确行为和功能
   • 明确行为的先决条件和后置条件
3. 落实组件
   • 确认采用的产品或软件包
   • 定义开发实施方法

架构的操作部分

什么是架构的操作部分？

• IT架构的一个纬度
• 说明在IT系统的物理结构上如何部署应用组件
• 描述如何满足系统服务等级需求
• 作为详细的基础架构设计蓝图，例如网络设计、平台设计、系统管理设计

相关模型及作用

• 部署单元和部署单元模型：组件通过部署单元实现部署
• 节点模型：部署单元如何组织
• 位置模型：部署单元会被部署在哪里

如何设计架构的操作部分？

1. 创建逻辑性操作模型的应用层（ALOM）：记录应用系统部署单元在节点上的位置及相互间的交互，部署单元之间的连接及在系统位置上的分布
   • 找出部署单元可能最终会被放置的位置，并建立系统角色可能的部署地点
   • 基于多方面考虑（例如系统管理），将部署单元放置在应用逻辑节点上
   • 定义部署单元间必要的连接以支持单元间的互动
   • 通过关健场景模拟验证设计
2. 完成逻辑性操作模型（LOM）：详细说明了应用层逻辑性操作模型所包含的必需的技术组件
   • 在必要的约束条件下，识别必需的技术部署单元，以实现应用部署单元及之间交互所要求的规格特征
   • 考虑可替代方案来实现需求，必要的时候对架构进行权衡和重构
   • 定义节点间必需的连接以支持技术部署单元间的交互
   • 放置安装部署单元
   • 通过关健场景模拟验证设计
3. 创建物理性操作模型（POM）：将逻辑系统架构转变为一系列产品和技术的详细说明
   • 在产品选择流程中标识你的角色，并定义选取标准
   • 为节点和连接处进行必要的产品选择
   • 定义解决方案的细节，并描述多种技术如何一起运作以实现特定的SLR
   • 合理化解决方案架构以获得明确尺寸的POM

需求方面2：非功能性需求

什么是非功能性需求？

• 质量
  • 定义系统需要满足的期望和应有的特性
  • 可能是运行时（如性能、容量、可用性、安全性等）或非运行环境的需求（如可扩展性或可维护性）
• 约束条件
  • 被给定的，在项目生命周期和系统范围内不能被改变的事实。包括：
    • 业务约束：管理制度、组织要求、地域特点、市场环境、时间、资源、范围等
    • 技术约束：原有系统整合、发展技术、下游基础设施、可用的技术、信息技术标准、约束执行等

非功能性需求的来源

• 相关利益相关者的访谈和讨论（例如：业务用户、业务运营部门、应用开发部门）
• 现状分析报告或竞争者产品
• 系统需求规范
• 问题报告和某系统的改进需求
• 用户任务场景分析

收集非功能性需求的系统化方法

• 维护一个完整的非功能性需求清单（无论所有项是否与特定项目相关）
• 针对每一个非功能性需求，指定一个或多个问题，可帮助实现其具体化过程
• 识别项目的所有利益相关者，为他们举行JAD式的研讨会
• 通过展示每个问题的回答潜在影响，向利益相关者提供帮助，同时警惕偏见和过期的约束
• 记录利益相关者对每一问题的回答
• 确定利益相关者，为每个非功能性需求制定优先级或设定权重

架构决策

架构决策记录任何有关架构的决定，包含：

• 系统结构
• 功能的提供和放置
• 符合标准 通过「架构决策」输出物去记录用来平衡不同质量和限制条件的原理和标准：
• 做出明确决策的原因和依据
• 给那些重要架构决策预留单独的区域
• 在功能中和系统组件的分配中保留设计的完整性
• 确保架构是可延伸的
• 提供决策的参考文件
• 避免重复考虑同一的议题