架构定义文件

(一)概述

架构定义文件是项目过程中创建的核心架构制品的可交付物容器,这份文档跨越了所有的架构领域(业务、数据、应用和技术),并检查了架构的所有相关状态(基线状态、各过渡状态和目标状态)。

它首先在阶段B被创建,最初只包含与业务架构相关的制品,接下来在阶段C被更新加入信息系统架构的制品,接着在阶段D被加入技术架构的制品。

架构定义文件是架构需求规约的伴随物,它们互为补充:①架构定义文件是提供了解决方案的定性视图,其目的在于表达架构师的意图。②架构需求规约提供了解决方案的定量视图,说明了在架构实施过程中必须满足的度量标准。

以下是架构定义文件中的典型内容。

1.范围。

2.目标、目的和约束。

3.架构原则。

4.基线架构。

5.架构模型(建模的每种状态),包括业务架构模型、数据架构模型、应用架构模型、技术架构模型。

6.架构方法的依据和论证。

7.与架构存储库的映射,包括与架构景观的映射、与参考模型的映射、与标准的映射、可重用性的评估结果。

8.差距分析的结果。

9.影响分析的结果。

(二)各类架构分述

1.业务架构 业务架构在阶段B被开发。在架构定义文件中应阐明的与业务架构相关的主题如下。

(1)基线业务架构,如果合适的话—这是对现有业务架构的描述。

(2)目标业务架构。

①组织结构:识别出各个业务场所并将其关联到相应的组织单元上。

②业务目标和目的:为企业和每个组织单元描述其业务目标和目的。

③业务职能:将大的职能区域逐步地、递归地连续分解为各子职能。

④业务服务:企业及其各业务单元向其客户提供的服务,包括内部服务和外部服务。

⑤业务流程,包括其测度和交付物。

⑥业务角色,包括对技能需求的开发和修订。

⑦业务数据模型。

⑧组织和职能间的相互关系:以矩阵报告的形式,将业务功能与组织单元进行关联。

(3)选定视点的相应视图,用来处理关键利益相关者关注问题。

2.信息系统架构 信息系统架构在阶段C被开发。在架构定义文件中应阐明的与信息系统架构相关的主题如下。

(1)基线数据架构,如果适当的话。

(2)目标数据架构,包括业务数据模型、逻辑数据模型、数据管理流程模型、数据实体或业务职能矩阵。

(3)选定视点相应的数据架构视图,用来处理关键利益相关者关注的问题。

(4)基线应用架构,如果适当的话。

(5)目标应用架构,包括:流程系统模型、地点系统模型、时间系统模型、人员系统模型。

(6)选定视点相应的应用架构视图,用来处理关键利益相关者关注的问题。

3.技术架构 技术架构的开发是阶段D的一部分。在架构定义文件中应阐明的与技术架构相关主题如下。

(1)基线技术架构,如果适当的话。

(2)目标技术架构,包括:①技术架构及它们与信息系统之间的关系技术平台及其分解、用来展示实现一个特定技术体系(“stack”)所需的技术的组合环境和位置:一组计算环境(如开发环境、生产环境)中所需的技术预计的处理负载量以及跨技术构件的负载分布。②物理(网络)通信。③硬件和网络规格。

(3)选定视点的相应视图,用来处理关键利益相关者关注的问题。

4.架构需求规约 架构需求规约提供了一套量化的声明,概要地说明了为了符合架构,实施项目必须做到什么样的程度。架构需求规约一般会成为一份实施契约或更详细的架构定义契约的主要组成部分。

如上所述,架构需求规约是架构定义文化的伴随物,它对架构定义文件进行了补充,提供了定量的视图。

架构需求规约通常包括以下内容:①可进行有效度量的测度(Success measures);②架构需求;③业务服务爽约;④应用服务契约;⑤实施指导原则;⑥实施规约;⑦实施标准;⑧可互操作性需求;⑨约束;⑩假定。

5.业务架构需求 业务架构需求在阶段B填入到架构需求规约中,包括如下内容:①差距分析的结果。②技术需求。初始的一套技术需求应该来自阶段B(业务架构)的输出。这些需求会驱动随后的技术架构阶段的工作,技术架构阶段会识别出这些需求对其他架构领域工作的影响,并对其进行分类,确定其优先级。例如,使用一个依赖性或优先级矩阵(如,该矩阵可指导在事务处理程度与安全性之间的权衡);列出希望创建的具体模型(如,以Zachman框架初始模型表达的模型)。③被更新的一些业务需求。业务场景技术可用来发现和记录这些业务需求。

6.信息系统架构需求 信息系统架构需求在阶段C填入到架构需求规约中,包括以下内容:①差距分析的结果。②数据可互操作性需求。③应用可互操作性需求。④业务架构中可能需要变更的区域,以符合数据架构和(或)应用架构中的变化。⑤对将被设计的技术架构的约束。⑥更新的业务需求,如果适当的话。⑦更新的应用需求,如果适当的话。⑧更新的数据需求,如果适当的话。

7.技术架构需求 技术架构需求在阶段D填入列表到架构需求规约中,包括如下内容:①差距分析结果;②更新的技术需求。

8.互操作性要求 可互操作性的意图体现在整个ADM的周期中。TOGAF9第三部分之第29章中给出了定义和建立可互操作性需求的一套指导策略。

9.架构路线图 架构路线图列出了变迁的各个增量,并将它们放在一条时间轴上,展示了从基线架构向目标架构的演进过程。架构路线图是过渡架构的关键构件,并在ADM从阶段B到阶段F的过程中,以增量的方式被开发。

以下是架构路线图中包含的典型内容。

(1)项目列表:①每个项目名称、描述和目的。②实现目标架构的项目的优先顺序列表。

(2)面向时间的迁移计划:①确认的迁移的效益(包括与业务需求的映射)。②各个候选迁移方案的预估成本。

(3)实施建议:①项目有效性的标准或测度。②风险和相关问题。③解决方案构建块,对其的描述和模型。