【TOGAF系列】架构开发方法(ADF)第七章

第7章:C阶段:信息系统架构——应用架构

本章描述了阶段C的应用程序架构部分。

7.1 目标

C阶段应用程序架构部分的目标是:

  • 开发目标应用程序架构,以解决架构工作说明书和利益相关者关注的问题,实现业务架构和架构愿景
  • 根据基线和目标应用程序体系结构之间的差距确定候选体系结构路线图组件

7.2 输入

本节定义了阶段C(应用程序架构)的输入。

7.2.1 企业外部参考资料

■ 架构参考资料(见TOGAF标准——架构内容)

7.2.2 非架构输入

■ 架构工作请求(见TOGAF标准——架构内容)
■ 能力评估(见TOGAF标准——架构内容)
■ 通信计划(见TOGAF标准——架构内容)

7.2.3 架构输入

■ 企业架构的组织模型(见TOGAF标准——架构内容),包括:
— 受影响组织的范围
— 成熟度评估、差距和解决方法

— 架构团队的角色和职责
— 建筑工作的限制
— 所需预算
— 治理和支持战略
■ 定制的架构框架(见TOGAF标准——架构内容),包括:
— 量身定制的架构方法
— 量身定制的架构内容(可交付成果和工件)
— 已配置和部署的工具
■ 应用原则(参见TOGAF标准-ADM技术)(如果存在)
■ 架构工作说明书(见TOGAF标准——架构内容)
■ 架构愿景(见TOGAF标准——架构内容)
■ 架构库(见TOGAF标准——架构内容),包括:
— 可重复使用的构建块
— 公开可用的参考模型
— 特定组织的参考模型
— 组织标准
■ 架构定义文件草案,其中可能包括任何架构域的基线和/或目标架构
■ 架构需求规范草案(见TOGAF标准——架构内容),包括:
— 差距分析结果(来自业务架构和数据架构,如果可用)
— 适用于本阶段的相关技术要求
■ 架构路线图的业务和数据架构组件(如果可用)(见TOGAF标准——架构内容)

7.3 步骤

C阶段所涉及的详细程度将取决于整体架构工作的范围和目标。

作为这项工作的一部分引入的新应用程序构建块需要在C阶段详细定义。在目标环境中继承和支持的现有应用程序构建模块可能已经在之前的架构工作中得到了充分定义;但是,如果没有,它们也需要在阶段C中定义。

此阶段的步骤顺序以及正式开始和完成的时间应根据既定的架构治理适应当前的情况。特别是,确定在这种情况下,是否适合首先进行基线描述或目标架构开发,如TOGAF标准——应用ADM中所述。

在完成应用程序架构步骤期间,应关闭在这些步骤中启动的所有活动(见第7.3.8节)。这些步骤生成的文档必须在创建/更新架构定义文档步骤中正式发布(见第7.3.9节)。

阶段C(应用程序架构)的步骤如下:

  • 选择参考模型、视点和工具(见第7.3.1节)
  • 制定基线应用架构描述(见第7.3.2节)
  • 制定目标应用架构描述(见第7.3.3节)
  • 进行差距分析(见第7.3.4节)
  • 定义候选路线图组件(见第7.3.5节)
  • 解决整个架构景观的影响(见第7.3.6节)
  • 进行正式的利益相关者审查(见第7.3.7节)
  • 最终确定应用程序架构(见第7.3.8节)创建/更新架构定义文档(见第7.3.9节)

7.3.1 选择参考模型、视点和工具

审查和验证(或在必要时生成)应用程序原则集。这些通常会构成一套总体架构原则的一部分。TOGAF标准中给出了开发和应用原则的指南以及一组示例应用原则— ADM技术。

根据业务驱动因素、利益相关者及其关注点,从架构存储库中选择相关的应用程序架构资源(参考模型、模式等)。

选择相关的应用程序体系结构观点(例如,应用程序的利益相关者— 与应用程序的功能和个人用户相关的观点等);即,那些将使架构师能够展示如何在应用程序架构中解决利益相关者关注的问题。

确定与所选视点相关的用于捕获、建模和分析的适当工具和技术。根据所保证的复杂程度,这些可能包括简单的文档或电子表格,或更复杂的建模工具和技术。

考虑使用独立于平台的业务逻辑描述。例如,OMG模型驱动架构®(MDA®)提供了一种对应用程序架构进行建模的方法,该方法保留了业务逻辑,使其不受底层平台和实现技术变化的影响。

7.3.1.1 确定总体建模过程

对于每个视点,使用所选工具或方法选择支持所需特定视图所需的模型。

确保涵盖所有利益相关者的关切。如果没有,则创建新模型来解决未涵盖的问题,或增强现有模型(见上文)。

开发应用程序架构的推荐过程如下:

  • 根据基线应用程序组合、需求是什么以及业务架构范围,了解所需的应用程序或应用程序组件列表
  • 通过将复杂的应用程序分解为两个或多个应用程序来简化它们
  • 通过尽可能删除重复的功能,并将类似的应用程序组合成一个,确保应用程序定义集在内部保持一致
  • 确定逻辑应用程序和最合适的物理应用程序
  • 通过将应用程序与业务服务、业务能力、数据、流程等联系起来,在整个架构中开发矩阵。
  • 通过检查应用程序将如何运行,捕捉集成、迁移、开发和操作问题,详细阐述一组应用架构视图

所需的分解级别和严格程度因企业而异,也因企业而异。架构师应考虑企业的目标、目的、范围和企业架构工作的目的,以确定分解级别。粒度级别应足以识别差距和候选工作包的范围。

7.3.1.2 确定应用程序构建块所需的目录

该组织的应用程序组合被捕获为架构存储库中的目录。目录本质上是分层的,它捕获元模型实体的分解,也捕获相关模型实体(例如逻辑应用程序组件)之间的分解 物理应用组件 应用服务)。

目录是开发矩阵和图表的原材料,也是管理业务和IT能力的关键资源。

目录的结构基于元模型实体的属性,如TOGAF标准——架构内容中所定义。

TOGAF标准——架构内容详细描述了在应用程序架构中开发时应考虑的目录,详细描述了它们,并将其与TOGAF企业元模型中的实体、属性和关系联系起来。

7.3.1.3 确定所需矩阵

矩阵显示了相关模型实体之间的核心关系。

矩阵是绘制图表的原材料,也是影响评估的关键资源。

一旦组装了基线应用程序组合,就有必要将应用程序映射到其支持业务的目的。初始映射应侧重于业务架构中的业务服务,因为这是最可能需要架构上重要决策的粒度级别。

一旦应用程序映射到业务服务,还可以通过业务架构期间开发的业务信息图,将应用程序与数据关联起来。

如果可用,基线应用程序数据模型可用于验证业务架构,并确定哪些数据保存在本地,哪些数据可以远程访问。

数据架构阶段将重点关注这些问题,因此,如果认为数据架构对架构参与的范围有价值,此时可能适合进行一次短暂的数据架构迭代。

使用基线应用程序目录中的现有信息,应用程序体系结构应确定用户和组织对应用程序的依赖关系。这项活动将通过确定受影响的用户群体来支持未来的州规划,并促进按用户类型或用户位置对应用程序进行分组。

一个需要特别考虑的关键用户群体是运营支持组织。此活动应检查应用程序对共享操作功能的依赖性,并绘制一张图表,说明每个应用程序是如何有效操作和管理的。

具体考虑运营社区的需求,可以确定对新的或扩展的治理能力和应用程序的要求。

TOGAF标准——架构内容详细描述了在应用程序架构中开发时应考虑的矩阵,详细描述了它们,并将其与TOGAF企业元模型中的实体、属性和关系联系起来。

7.3.1.4 确定所需图表

图表根据利益相关者的要求,从一组不同的角度(视点)呈现应用程序架构信息。一旦知道应用程序的所需功能,就有必要对应用程序的最佳结构进行内部评估,以满足其要求。

在打包应用程序的情况下,应用程序可能支持许多配置选项、附加模块或应用程序服务,这些选项、模块或服务可以应用于解决方案。对于定制开发的应用程序,有必要从模块或子系统的角度确定应用程序的高级结构,作为组织设计活动的基础。

TOGAF标准——架构内容详细描述了在应用程序架构中开发时应考虑的图表,详细描述了它们,并将其与TOGAF企业元模型中的实体、属性和关系联系起来。

7.3.1.5 确定要收集的需求类型

一旦开发了应用程序架构目录、矩阵和图表,就可以通过形式化实现目标架构的以应用程序为中心的需求来完成架构建模。

这些要求可能:

  • 与应用程序域相关
  • 为数据和技术架构提供需求输入
  • 在设计和实施过程中提供详细的指导,以确保解决方案满足原始架构要求

在此步骤中,架构师应确定架构应满足的要求(见第13.5.2节)。

7.3.2 开发基线应用程序架构描述

制定现有应用程序架构的基线描述,以支持目标应用程序架构。要定义的范围和详细程度将取决于现有应用程序在多大程度上可能被转移到目标应用程序架构中,以及是否存在架构描述,如第7.5. 节所述,在可能情况下,利用架构库(参见TOGAF标准——架构内容)确定相关的应用架构构建块。

如果架构库中尚未存在,请根据应用程序组合目录定义每个应用程序(请参阅TOGAF标准——架构内容)。

如果需要开发新的架构(architecture)模型来满足利益相关者的担忧,请使用步骤1中确定的模型 作 为 创 建 新 架 构 ( architectural ) 内 容 的 指 导 方 针 , 以 描 述 基 线 架 构 ( Baseline architecture)。

7.3.3 开发目标应用程序架构描述

为应用程序架构制定目标描述,以支持架构愿景、目标业务架构和目标数据架构。要定义的范围和详细程度将取决于应用元素与实现目标架构愿景的相关性,以及是否存在架构描述。在可能的情况下,利用架构库(参见TOGAF标准——架构内容)确定相关的应用程序架构构建块。

如果需要开发新的架构(architecture)模型来满足利益相关者的关注,请使用步骤1中确定的模型作为创建新架构(architectural)内容的指导方针,以描述目标架构(architectures)。

如果合适,调查不同的目标架构备选方案,并使用架构备选方案和权衡技术与利益相关者讨论这些方案(见TOGAF标准-ADM技术)。

7.3.4 执行差距分析

验证架构模型的内部一致性和准确性:

  • 执行权衡分析以解决不同视图之间的冲突(如果有的话)
  • 验证模型是否支持原则、目标和约束
  • 注意对架构存储库中选定模型中表示的视点的更改,并记录
  • 根据需求测试架构模型的完整性

使用TOGAF标准-ADM技术中描述的差距分析技术,确定基线和目标之间的差距。

7.3.5 定义候选路线图组件

在创建基线架构、目标架构和差距分析之后,需要一个应用程序路线图来确定未来阶段活动的优先级。

此初始应用程序架构路线图将用作原材料,以支持在机会和解决方案阶段更详细地定义整合的跨学科路线图。

7.3.6 解决整个建筑景观的影响

一旦应用程序架构最终确定,就有必要了解任何更广泛的影响或含义。

在此阶段,应检查建筑景观中的其他建筑构件,以确定:

  • 此应用程序架构是否会对任何已有的架构产生影响?
  • 最近是否进行了影响应用程序架构的更改?
  • 是否有机会在组织的其他领域利用此应用程序架构的工作?
  • 此应用程序架构是否会影响其他项目(包括计划中的项目和正在进行的项目)?
  • 此应用程序架构是否会受到其他项目(包括计划中的项目和正在进行的项目)的影响?

7.3.7 进行正式的利益相关者

审查对照拟议的应用程序架构,检查架构项目的原始动机和架构工作说明书。进行影响分析,以确定业务和数据架构(如业务实践)可能需要改变的任何领域,以适应应用程序架构的变化(如表单或程序、应用程序或数据库系统的变化)。如果影响很大,这可能需要重新审视业务和数据架构。确定对即将设计的技术架构(尤其是基础设施)的任何限制。

7.3.8 最终确定应用架构

  • 为每个构建块选择标准,尽可能多地重复使用从架构库中选择的参考模型
  • 完整记录每个构建块
  • 根据业务需求对整体架构进行最终的交叉检查;在架构文档中记录构建块决策的基本原理
  • 记录最终需求可追溯性报告
  • 在架构库中记录架构的最终映射;从所选的构建块中,确定可能重复使用的构建块,并通过架构存储库发布
  • 最终确定所有工作成果,如差距分析

7.3.9 创建/更新架构定义文档

  • 在架构定义文档中记录构建块决策的基本原理
  • 准备架构定义文档的应用架构部分;如果合适,使用建模工具生成的报告和/或图形来演示

架构的关键视图;将文件发送给相关利益相关者审查,并纳入反馈

7.4 输出

阶段C(应用架构)的输出可能包括但不限于:
■ 架构愿景阶段交付成果的改进和更新版本(如适用):
— 架构工作说明书(见TOGAF标准——架构内容),必要时进行更新
— 已验证的应用原则,或新的应用原则(如果在此处生成)

■ 架构定义文档草案(见TOGAF标准——架构内容),包括:
— 批准的基线应用程序架构(如适用)
— 目标应用程序架构,已批准
— 与所选观点相对应的观点,解决关键利益相关者的担忧
■ 架构需求规范草案(见TOGAF标准——架构内容),包括以下应用架构需求:
— 差距分析结果
— 应用程序互操作性要求
— 适用于架构开发周期演变的相关技术要求
— 对即将设计的技术架构的约束
— 更新业务需求(如适用)
— 更新数据要求(如适用)
■ 架构路线图的应用架构组件(见TOGAF标准——架构内容)

TOGAF标准——架构内容包含了这个阶段可能产生的架构工件的详细描述。

7.5 方法

7.5.1 架构存储库

作为此阶段的一部分,架构团队将需要考虑架构库中可用的相关应用程序架构资源(请参阅TOGAF标准——架构内容)。

特别地:

  • 与组织行业部门相关的通用业务模型和相关应用模型
  • 与常见高级业务功能相关的应用模型,如电子商务、供应链管理等。

开放组织有一个集成信息基础架构参考模型(III-RM)——见TOGAF®系列指南:TOGAF集成信息基础设施参考模型(II-M)——它侧重于提供集成信息基础结构所需的应用程序级组件和服务。

你可能感兴趣的:(架构)