企业架构研究总结（22）——TOGAF架构开发方法（ADM）之信息系统架构阶段

1.4 信息系统架构——数据架构（Information System Architecture——Data）

企业架构开发方法各阶段——信息系统架构

      信息系统架构的建设着眼于明确用于支持企业业务架构的各种数据和应用，因而信息系统架构的建设可以分为针对数据架构和应用架构的建设。在本章中，我们将针对数据架构的建设进行探讨。

 

1.4.1 目标

      数据架构建设的目标是通过一种完整、一致、稳定且能够为干系人所理解的方法对支持业务所必需的数据的类型与来源进行定义。需要注意的是，数据架构的建设并不关注于数据库的设计，即数据架构并不是针对存储系统在逻辑或物理方面的设计，而是对企业相关的数据实体进行定义（不过对于现存文件和数据库的关联需要被明确，并阐明各重要的改进领域）。

1.4.2 方法

      在数据架构的建设过程中所涉及到方法包括如下几点：

数据架构的主要考虑因素

• 数据管理（Data Management）：当企业将要承接大型的架构改造任务时，理解并解决数据管理方面的问题将会是非常重要的，而一个结构化且全面的数据管理方法则可以促进对于数据的有效使用，从而充分利用其竞争优势。对于数据管理来说，企业或组织需要在如下几个方面进行思考：
• 对于用来担当企业主数据记录和引用系统的各应用组件需要被定义清楚。
• 是否存在需要被所有的应用组件遵循的企业级标准？
• 针对业务功能、流程和服务如何使用数据实体要有清晰的认识。
• 针对企业数据实体是在何处以及如何被创建、存储、传输和汇报的要有清晰的认识。
• 用于支持应用之间信息交换需求的数据转换的复杂程度如何？
• 用于支持企业客户和供应商之间数据集成的软件的需求都有哪些？（例如，针对在数据迁移过程中用到的ETL（Extraction-Transformation-Loading）工具和用来评估数据质量的数据分析工具的使用都有哪些需求？）
• 数据迁移（Data Migration）：当现存应用被替代后，对于新应用的数据迁移将会成为一个非常重要的需求。数据架构应该识别出数据的迁移需求，并且能够提供有关数据转换和清洗等级等方面指标，而这些指标表达了目标应用对于转换后数据的格式的要求。此外，组织还需要确保存在一个用于支持企业级数据转换的通用数据定义。
• 数据治理（Data Governance）：数据治理确保企业或组织拥有足够的能力来促成数据转换，这包括如下几个方面的内容：
• 结构：这一维度是关于到企业是否具有必要的组织结构和标准体系来管理数据实体。
• 管理系统：企业应该具有必要的管理系统与数据相关程序，从而在数据实体的整个生命周期中对其治理方面进行管理。
• 人员：这一维度表述了企业对于数据转换所需的各种数据相关的技能和角色的需求。如果企业缺乏这样的资源和技能，则需要考虑通过一系列精心编制的培训课程来对现有资源进行培训，或直接从外部获取。

使用架构资源库

      在当前阶段的各项活动中，架构团队需要考虑在架构资源库中是否存在与数据架构相关的可利用资源，特别是与组织所在行业相关的通用数据模型，例如：

• 零售行业技术标准组织（ARTS：Association for Retail Technology Standards）为零售行业定义了一个数据模型。
• Energistics也已为石油技术行业定义了一个数据模型。

1.4.3 输入与输出

      在当前阶段所需的输入材料以及此阶段输出的各种交付物归纳如下：

输 入	参考资料	架构参考资料
	非架构性输入	架构工作要求书
		能力评估
		沟通计划
	架构性输入	企业架构组织模型，包括： 受影响的组织范围 成熟度评测、差距及解决方法 架构团队所担当的角色和职责 架构工作的约束 预算需求 治理和支持策略
		定制的架构框架，包括： 定制的架构方法 定制的架构内容（交付物和制品） 配置和部署工具
		数据原则（如果存在）
		通过的架构工作说明书
		架构愿景
		架构资源库，包括： 可重用的构建块 公开且可得的参考模型 组织特定的参考模型 组织标准
		架构定义文档草案，包括： 基线业务架构1.0版 基线技术架构0.1版 基线数据架构0.1版 基线应用架构1.0或0.1版 目标业务架构1.0版 目标技术架构0.1版 目标数据架构0.1版 目标应用架构1.0或0.1版
		架构需求说明草案，包括： 差距分析结果 适用于此阶段的相关技术需求
		架构路线图的业务架构组件
输 出	经过改善和更新的架构愿景阶段中的各交付物，包括： 架构工作说明（如有需要，进行修改） 经过验证的数据原则或新的数据原则（如果产生的话）
	更新的架构定义文档草案，包括： 基线数据架构1.0版 目标数据架构1.0版 业务数据模型 逻辑数据模型 数据管理流程模型 数据实体/业务功能矩阵 代表相关干系人关注点的视角下的各种视图
	更新的架构需求说明草案，包括： 差距分析结果 数据互操作需求 适用于这一架构开发循环演进阶段的相关技术需求 对于将要设计的技术架构的约束 更新的业务需求 更新的应用需求
	架构路线图的数据架构组件

1.4.4 步骤

      在当前阶段中所要执行的各个步骤归纳如下：

• 选择参考模型、视角和工具
• 开发基线数据架构模型
• 开发目标数据架构描述
• 执行差距分析
• 定义路线图组件
• 通观整个架构景观来明确和解决相关影响
• 进行正式的关系人审查
• 最终确定数据架构
• 创建架构定义文档

1.5 信息系统架构——应用架构（Information System Architecture——Application）

      作为信息系统架构的另外一个组成部分，应用架构描述了各种用于支持业务架构并对数据架构所定义的各种数据进行处理的应用系统。在本章中，我们将针对应用架构的建设进行探讨。

1.5.1 目标

      应用架构建设的目的是定义各种用于处理数据并对企业业务进行支持的主要应用系统。需要注意的是，应用架构的建设并不关注于针对应用系统的具体设计，而是定义企业相关应用系统的种类，以及在管理数据和向用户展示信息方面的需求。这里所说的应用并不是指计算机系统，而是关于应用系统能力的逻辑分组。这些应用系统能力指的是用来管理在数据架构中定义的数据，并对在业务架构中定义的各项业务功能进行支持的能力。这些应用和能力的定义并不依赖于特定的实现技术，因而这些定义是相对稳定的，而其实现技术则不然。

1.5.2 方法

      在当前阶段的各项活动中，架构团队需要考虑在架构资源库中是否存在与应用架构相关的可利用资源，特别是如下几个方面的资源：

• 与组织所处行业相关的通用应用模型，例如由TMF（The TeleManagement Forum）开发的与电信行业相关的应用模型，以及由OMG中的一些领域小组开发的与特定行业（例如医疗保健、交通运输和金融等行业）相关的软件模型。
• 与通用的高层次业务功能相关的应用模型，例如电子商务、供应链管理等。

      除了上述内容之外，应用架构的建设还可以参考如下的内容：

• The Open Group也提供了一个集成信息基础设施参考模型（III-RM：Reference Model for Integrated Information Infrastructure），其中包括了一个集成信息基础设施所必须的各种应用级的组件和服务。
• 电子商务全球化标准（ebXML: electronic business using eXtensible Markup Language）也是可选的工具之一，它的目标是提供一个开放的基于XML的基础设施，从而使得电子化的商务信息可以通过一种可交互的、安全且统一的方式进行全球化的使用。

1.5.3 输入与输出

      在当前阶段所需的输入材料以及此阶段输出的各种交付物归纳如下：

输 入	参考资料	架构参考资料
	非架构性输入	架构工作要求书
		能力评估
		沟通计划
	架构性输入	企业架构组织模型，包括： 受影响的组织范围 成熟度评测、差距及解决方法 架构团队所担当的角色和职责 架构工作的约束 预算需求 治理和支持策略
		定制的架构框架，包括： 定制的架构方法 定制的架构内容（交付物和制品） 配置和部署工具
		应用原则
		通过的架构工作说明书
		架构愿景
		架构资源库，包括： 可重用的构建块 公开且可得的参考模型 组织特定的参考模型 组织标准
		架构定义文档草案，包括： 基线业务架构1.0版 基线技术架构0.1版 基线数据架构1.0或0.1版 基线应用架构0.1版 目标业务架构1.0版 目标技术架构0.1版 目标数据架构1.0或0.1版 目标应用架构0.1版
		架构需求说明草案，包括： 差距分析结果 适用于此阶段的相关技术需求
		架构路线图的业务和数据架构组件
输 出	经过改善和更新的架构愿景阶段中的各交付物，包括： 架构工作说明（如有需要，进行修改） 经过验证的应用原则或新的应用原则（如果产生的话）
	更新的架构定义文档草案，包括： 基线应用架构1.0版 目标应用架构1.0版 过程系统模型 位置系统模型 时间系统模型 人员系统模型 代表相关干系人关注点的视角下的各种视图
	更新的架构需求说明草案，包括： 差距分析结果 应用互操作需求 适用于这一架构开发循环演进阶段的相关技术需求 对于将要设计的技术架构的约束 更新的业务需求 更新的数据需求
	架构路线图的应用架构组件

1.5.4 步骤

      在当前阶段中所要执行的各个步骤归纳如下：

• 选择参考模型、视角和工具
• 开发基线应用架构描述
• 开发目标应用架构描述
• 执行差别分析
• 定义路线图组件
• 通观整个架构景观来明确和解决相关影响
• 进行正式的关系人审查
• 最终确定应用架构
• 创建架构定义文档