第6章：C阶段：信息系统架构——数据架构
本章描述了阶段C的数据架构部分。
6.1 目标
C阶段数据架构部分的目标是：
- 开发目标数据架构，以解决架构工作说明书和利益相关者关注的问题，实现业务架构和架构愿景
- 根据基线和目标数据架构之间的差距确定候选架构路线图组件
6.2 输入
本节定义了阶段C（数据架构）的输入。
6.2.1 企业外部参考资料
- 架构参考资料（见TOGAF标准——架构内容）
- TOGAF®系列指南：信息架构——客户主数据管理
- Open Group指南：信息架构：商业智能与分析以及元数据管理参考模型
6.2.2 非架构输入
- 架构工作请求（见TOGAF标准——架构内容）
- 能力评估（见TOGAF标准——架构内容）
- 通信计划（见TOGAF标准——架构内容）
6.2.3 架构输入
■ 企业架构的组织模型（见TOGAF标准——架构内容），包括：
— 受影响组织的范围
— 成熟度评估、差距和解决方法
— 架构团队的角色和职责
— 建筑工作的限制
— 所需预算
— 治理和支持战略
■ 定制的架构框架（见TOGAF标准——架构内容），包括：
— 量身定制的架构方法
— 量身定制的架构内容（可交付成果和工件）
— 已配置和部署的工具
■ 数据原则（见TOGAF标准-ADM技术）（如果存在）
■ 架构工作说明书（见TOGAF标准——架构内容）
■ 架构愿景（见TOGAF标准——架构内容）
■ 架构库（见TOGAF标准——架构内容），包括：
— 可重复使用的构建块（特别是当前数据的定义）
— 公开可用的参考模型
— 特定组织的参考模型
— 组织标准
■ 架构定义文件草案，其中可能包括任何架构域的基线和/或目标架构
■ 架构需求规范草案（见TOGAF标准——架构内容），包括：
— 差距分析结果（来自业务架构）
— 适用于本阶段的相关技术要求
■ 架构路线图的业务架构组件（参见TOGAF标准
— 架构内容）
6.3 步骤
C阶段所涉及的详细程度将取决于整体架构工作的范围和目标。
作为这项工作的一部分，引入的新数据构建块需要在C阶段详细定义。在目标环境中继承和支持的
现有数据构建块可能已经在之前的架构工作中得到了充分定义；但是，如果没有，它们也需要在
阶段C中定义。
此阶段的步骤顺序以及正式开始和完成的时间应根据既定的架构治理适应当前的情况。特别是，
确定在这种情况下，是否适合首先进行基线描述或目标架构开发，如TOGAF标准——应用ADM中所述。
在完成数据架构步骤期间，应关闭在这些步骤中启动的所有活动（见第6.3.8节）。这些步骤生成
的文档必须在创建/更新架构定义文档步骤中正式发布（见第6.3.9节）。
阶段C（数据架构）的步骤如下：
- 选择参考模型、视点和工具（见第6.3.1节）
- 制定基线数据架构描述（见第6.3.2节）
- 制定目标数据架构描述（见第6.3.3节）
- 进行差距分析（见第6.3.4节）
- 定义候选路线图组件（见第6.3.5节）
- 解决整个建筑景观的影响（见第6.3.6节）
- 进行正式的利益相关者审查（见第6.3.7节）
- 最终确定数据架构（见第6.3.8节）
- 创建/更新架构定义文档（见第6.3.9节）
6.3.1 选择参考模型、视点和工具
审查和验证（或在必要时生成）数据原则集。这些通常会构成一套总体架构原则的一部分。TOGAF标准-ADM技术中给出了开发和应用原则的指南以及一组示例数据原则。
根据业务驱动因素、利益相关者、关注点和业务架构选择相关的数据架构资源（参考模型、模式
等）。
选择相关的数据架构视角（例如，数据的利益相关者——监管机构、用户、生成器、主体、审计
师等；各种时间维度——实时、报告期、事件驱动等；位置；业务流程）；即，那些将使架构师
能够演示如何在数据架构中解决利益相关者关注的问题。
确定用于数据捕获的适当工具和技术（包括表格），与所选视点相关联地进行建模和分析。根据所保证的复杂程度，这些可能包括简单的文档或电子表格，或更复杂的建模工具和技术，如数据管理模型、数据模型等。
数据建模技术的示例包括：
- 实体关系图
- 类图
有关信息架构参考模型的进一步指导，请参阅以下文档：
- TOGAF®系列指南：信息架构——客户主数据管理
- Open Group指南：信息架构：商业智能与分析以及元数据管理参考模型
6.3.1.1 确定总体建模过程
对于每个视点，使用所选工具或方法选择支持所需特定视图所需的模型。
确保涵盖所有利益相关者的关切。如果没有，则创建新模型来解决未涵盖的问题，或增强现有模
型（见上文）。
开发数据架构的推荐流程如下：
- 从现有的业务架构和应用架构材料中收集与数据相关的模型
- 合理化数据需求，并与任何现有的企业数据目录和模型保持一致；这允许开发数据清单和实体关系
- 通过将数据与业务服务、业务能力、业务功能、访问权限和应用程序相关联，更新和开发整个架构中的矩阵
- 通过检查数据的创建、分发、迁移、保护和归档方式，详细阐述数据架构视图
6.3.1.2 确定所需的数据构建块目录
数据的描述可以被捕获为一个目录，显示相关模型实体之间的分解（例如，数据实体->逻辑数据
组件->物理数据组件）。
在业务架构阶段，创建了一个业务服务/信息图，显示了主要业务服务所需的关键数据实体。这是
数据架构活动成功的先决条件。
使用从业务功能/业务能力到应用程序和数据实体的可追溯性，可以创建支持架构愿景所需的数据
清单。
一旦数据需求被整合到一个位置，就可以细化数据清单，以实现语义一致性，并消除差距和重叠。
TOGAF标准——体系结构内容包含对数据体系结构中应考虑开发的目录的详细描述，详细描述了它们将它们与TOGAF企业元模型中的实体、属性和关系相关联。
6.3.1.3 确定所需矩阵
在这个阶段，可以生成一个实体到应用程序的矩阵来验证这种映射。现在，人们将开始理解数据
是如何创建、维护、转换和传递给其他应用程序的，或者是如何被其他应用程序使用的。需要注
意明显的差距，例如似乎从未由应用程序创建的实体或创建但从未使用的数据，以便以后进行差
距分析。
合理化的数据清单可用于更新和细化数据与架构其他方面的架构图。
一旦进行了这些更新，可能适合进入应用程序架构的简短迭代，以解决所识别的更改。
TOGAF标准——架构内容详细描述了在数据架构中开发时应考虑的矩阵，详细描述了它们，并将其与TOGAF企业元模型中的实体、属性和关系联系起来。
6.3.1.4 确定所需图表
图表根据利益相关者的要求，从一组不同的角度（视点）呈现数据架构信息。
一旦数据实体被细化，就可以生成实体与其属性之间关系的图。
在此阶段，值得注意的是，信息可能是企业级数据（来自系统服务提供商和软件包供应商信息）
和个人数据库和电子表格中保存的本地级数据的混合体。
建模的详细程度需要仔细评估。一些物理系统数据模型将存在到非常详细的级别；其他人只会对
核心实体进行建模。随着应用程序的修改和扩展，并非所有数据模型都会保持最新。重要的是在
提供的细节水平上实现平衡（例如，再现现有的详细系统物理数据模式或呈现高级流程图和数据
要求突出了两个极端的观点）。
TOGAF标准——架构内容详细描述了在数据架构中开发时应考虑的图表，详细描述了它们，并将其与TOGAF企业元模型中的实体、属性和关系联系起来。
6.3.1.5 确定要收集的需求类型
一旦开发了数据架构目录、矩阵和图表，就可以通过形式化实现目标架构的以数据为中心的需求
来完成架构建模。
这些要求可能：
- 与数据域相关
- 为应用程序和技术架构提供需求输入
- 在设计和实施过程中提供详细的指导，以确保解决方案满足原始架构要求
在此步骤中，架构师应确定架构应满足的要求（见第13.5.2节）。
6.3.2 制定基线数据架构描述
制定现有数据架构的基线描述，以支持目标数据架构。定义的范围和详细程度将取决于现有数据
元素在多大程度上可能被转移到目标数据架构中，以及是否存在架构描述，如第6.5节所述。在可
能的情况下，利用架构库（参见TOGAF标准——架构内容）确定相关的数据架构构建块。
如果需要开发新的架构（architecture）模型来满足利益相关者的担忧，请使用步骤1中确定的模
型 作 为 创 建 新 架 构 （ architectural ） 内 容 的 指 导 方 针 ， 以 描 述 基 线 架 构 （ Baseline
architecture）。
6.3.3 制定目标数据架构描述
为数据架构制定目标描述，以支持架构愿景和目标业务架构。要定义的范围和详细程度将取决于
数据元素与实现目标架构的相关性，以及架构描述是否存在。在可能的情况下，利用架构库确定
相关的数据架构构建块（见TOGAF标准——架构内容）。
如果需要开发新的架构（architecture）模型来满足利益相关者的关注，请使用步骤1中确定的模
型作为创建新架构（architectural）内容的指导方针，以描述目标架构（architectures）。
如果合适，调查不同的目标架构备选方案，并使用架构备选方案和权衡技术与利益相关者讨论这
些方案（见TOGAF标准-ADM技术）。
6.3.4 执行差距分析
验证架构模型的内部一致性和准确性：
- 执行权衡分析以解决不同视图之间的冲突（如果有的话）
- 验证模型是否支持原则、目标和约束
- 注意对架构存储库中选定模型中表示的视点的更改，并记录
- 根据需求测试架构模型的完整性
使用TOGAF标准-ADM技术中描述的差距分析技术，确定基线和目标之间的差距。
6.3.5 定义候选路线图组件
在创建基线架构、目标架构和差距分析后，需要一个数据路线图来确定未来阶段活动的优先级。
此初始数据架构路线图将用作原材料，以支持在机会和解决方案阶段更详细地定义整合的跨学科
路线图。
6.3.6 解决整个架构景观的影响
一旦数据架构最终确定，就有必要了解任何更广泛的影响或含义。
在此阶段，应检查架构景观中的其他建筑构件，以确定：
- 这种数据架构是否会对任何现有的架构产生影响？
- 最近是否进行了影响数据架构的更改？
- 是否有机会在组织的其他领域利用此数据架构的工作？
- 此数据架构是否影响其他项目（包括计划中的项目和正在进行的项目）？
- 此数据架构是否会受到其他项目（包括计划中的项目和正在进行的项目）的影响？
6.3.7 进行正式的利益相关者审查
对照拟议的数据架构，检查架构项目的原始动机和架构工作说明书。进行影响分析，以确定业务
和应用程序架构（如业务实践）可能需要改变的任何领域，以适应数据架构的变化（如表格或程
序、应用程序或数据库系统的变化）。
如果影响很大，这可能需要重新审视业务和应用程序架构。
确定应用程序架构（如果此时生成）可能需要更改的任何领域，以适应数据架构的变化（或确定
即将设计的应用程序架构的约束）。
如果影响很大，此时可能适合对应用程序架构进行简短的迭代。
识别即将设计的技术架构的任何约束，仅在必要时完善拟议的数据架构。
6.3.8 最终确定数据架构
- 为每个构建块选择标准，尽可能多地重复使用从架构库中选择的参考模型
- 完整记录每个构建块
- 根据业务需求对整体架构进行最终的交叉检查；在架构文档中记录构建块决策的基本原理
- 记录最终需求可追溯性报告
- 在架构库中记录架构的最终映射；从所选的构建块中，确定可能重复使用的构建块，并通过架构存储库发布
- 最终确定所有工作成果，如差距分析
6.3.9 创建/更新架构定义文档
在架构定义文档中记录构建块决策的基本原理。
准备架构定义文档的数据架构部分，包括以下部分或全部：
- 业务数据模型
- 逻辑数据模型
- 数据管理过程模型
- 数据实体/业务功能矩阵
- 数据互操作性要求（例如XML模式、安全策略）
- 如果合适，使用建模工具生成的报告和/或图形来演示架构的关键视图；将文件发送给相关利益相关者审查，并纳入反馈
6.4 输出
阶段C（数据架构）的输出可能包括但不限于：
■ 架构愿景阶段交付成果的改进和更新版本（如适用）：
— 架构工作说明书（见TOGAF标准——架构内容），必要时进行更新
— 经过验证的数据原则（见TOGAF标准-ADM技术），或新的数据原理（如果在此处生成）
■ 架构定义文档草案（见TOGAF标准——架构内容），包括：
— 批准的基线数据架构（如适用）
— 已批准的目标数据架构，包括：
— 业务数据模型
— 逻辑数据模型
— 数据管理过程模型
— 数据实体/业务功能矩阵
— 与解决关键利益相关者问题的选定观点相对应的观点
■ 架构需求规范草案（见TOGAF标准——架构内容），包括以下数据架构要求：
— 差距分析结果
— 数据互操作性要求
— 适用于架构开发周期演变的相关技术要求
— 对即将设计的技术架构的约束
— 更新业务需求（如适用）
— 更新申请要求（如适用）
■ 架构路线图的数据架构组件（见TOGAF标准——架构内容）
TOGAF标准——架构内容包含了这个阶段可能产生的架构工件的详细描述。
6.5 方法
6.5.1 数据结构
数据架构应该能够处理：
- 静态数据——存储中的数据
- 动态数据——事务或服务/API中的数据
- 使用中的数据——应用程序边界处的数据（例如GUI）
- 开放数据——组织为公众使用提供的数据，以及自愿或法律要求提供的数据
将添加使用这些类型的数据架构的不同替代方法。
数据架构是通过使用三个元模型实体创建的：数据实体、逻辑数据组件和物理数据组件。
数据实体可用于创建概念数据模型，以帮助IT开发人员理解他们将要处理的概念。通常，实体关
系模型还包含对关系的一些要求（例如，客户只能有一个地址）。
逻辑数据组件可用于创建逻辑数据模型。对于it领域来说，清楚地了解it环境中使用的所有数据
通常很重要。逻辑数据模型通常用作对存储在应用程序中的数据（静态）的要求，数据在应用程
序之间移动应用程序（运动中）或应用程序用户界面上的数据（使用中的数据）。
物理数据组件是由一些早期项目（例如XML消息、数据库模式的链接）或新实施项目的要求实现的
逻辑数据组件的集群。
所有三个数据实体都可以用于在IS服务、逻辑应用程序组件或物理应用程序组件之间传递/传入/
传出数据的数据交换模型。
所有数据实体都可以具有特定情况下的质量属性。
6.5.2 数据架构的关键考虑因素
6.5.2.1 数据管理
当企业选择进行大规模的架构转型时，了解和解决数据管理问题非常重要。结构化和全面的数据
管理方法能够有效地利用数据来利用其竞争优势。
考虑因素包括：
- 明确定义环境中哪些应用程序组件将作为企业主数据的记录或参考系统
- 是否会有一个企业范围的标准，包括软件包在内的所有应用程序组件都需要采用？（总的来说，包可以规定数据模型，可能不灵活。）
- 清楚地了解业务能力、业务功能、流程以及业务和应用程序服务如何利用数据实体
- 清楚地了解企业数据实体是如何以及在何处创建、存储、传输和报告的
- 支持应用程序之间的信息交换需求所需的数据转换的级别和复杂性是多少？
- 在支持与企业客户和供应商的数据集成方面，对软件的要求是什么（例如，在数据迁移过程中使用提取、转换、加载（ETL）工具，评估数据质量的数据分析工具等）？
有关数据管理的更多指导，请参阅TOGAF®系列指南：信息架构——客户主数据管理。
6.5.2.2 数据迁移
当替换现有应用程序时，将迫切需要将数据（主数据、事务数据和引用数据）迁移到新应用程序。
数据架构应确定数据迁移要求，并提供有关转换、清除和清理级别的指标，以满足目标应用程序
的要求和约束的格式呈现数据。目标是目标应用程序在填充时具有高质量的数据。另一个关键考
虑因素是确保建立企业范围的通用数据定义来支持转换。
6.5.2.3 数据治理
数据治理考虑因素确保企业具有必要的维度来实现转型，如下所示：
- 结构：此维度涉及企业是否具有必要的组织结构和标准机构来管理转换的数据实体方面
- 管理系统：在这里，企业应该有必要的管理系统和数据相关程序来管理数据实体在其整个生命周期中的治理方面
- 人员：此维度解决了企业转型所需的数据相关技能和角色
如果企业缺乏这些资源和技能，企业应考虑获取这些关键技能，或通过明确的学习计划培训
现有的内部资源以满足要求。
6.5.3 架构存储库
作为此阶段的一部分，架构团队需要考虑组织架构库中可用的相关数据架构资源（见TOGAF标准——架构内容 ） ； 特别是与组织的行业“垂直”部门相关的通用数据模型 。