1.1. 面向质量
1.1.1. 专注于业务和IT开发周期内对数据架构进行不断改进
1.1.2. 如果架构没有得到妥善管理，也会慢慢遭到破坏，系统逐渐变得越来越复杂和缺乏扩展性，因而给组织带来风险
1.1.3. 面向质量的方法与传统的数据架构工作保持一致，其中架构质量改进是逐步完成的
1.2. 面向创新
1.2.1. 专注于业务和IT转换，致力于新的期待和机会
1.2.2. 用创新性技术和数据使用驱动创新，已经成为现代企业架构的一种功能
1.2.3. 对面向创新的方法通常不用面面俱到的考虑，可以应用未经广泛验证的业务逻辑和前沿技术
1.2.4. 该方法通常要求架构师与组织中那些缺少互动的IT专家进行联系（如产品经理和业务设计者）
2. 建立企业数据架构2.1. 在理想情况下，数据架构应该是企业架构的组成部分
2.2. 如果没有企业架构，则依然可以构建数据构架团队
2.3. 工作
2.3.1. 战略
2.3.1.1. 选择框架，制定方法，开发路线图
2.3.2. 沟通与文化
2.3.2.1. 建立沟通机制，并激励积极参与者
2.3.3. 组织：通过明确责任和职责来组织数据框架工作
2.3.4. 工作方法
2.3.4.1. 与企业架构保持一致，在开发项目中定义最佳实践并执行数据架构工作
2.3.5. 结果
2.3.5.1. 在总体路线图中产出数据架构产品
2.4. 影响项目和系统开发的范围边界
2.4.1. 定义项目数据需求
2.4.1.1. 通过数据架构为企业提供每个项目的数据需求
2.4.2. 审评项目数据设计
2.4.2.1. 通过设计审评来确保概念、逻辑和物理数据模型与架构一致，与组织的长期策略一致
2.4.3. 确定数据溯源影响
2.4.3.1. 确保数据流在应用中的业务规则一致并且可追溯
2.4.4. 数据复制控制
2.4.4.1. 复制是一种常见的，能够提供改善应用性能和便于获取数据的方法，但是也有可能导致数据的不一致
2.4.4.2. 数据架构治理能保证充分的复制控制（方法和机制）来达到所需的一致性（并不是所有应用要求的严格程度都一致）
2.4.5. 实施数据架构标准
2.4.5.1. 为企业数据架构生命周期制定和实施标准
2.4.5.2. 标准可以表示为原则、流程、指南和规划蓝图
2.4.6. 指导数据技术和更新决策
2.4.6.1. 数据架构与企业架构一起管理每个应用的数据技术版本、补丁和数据技术路线图策略
2.5. 现有数据架构规范评估
2.5.1. 每个组织都保存着现有系统的一系列文档
2.6. 开发路线图
2.6.1. 如果一个企业是从零开始开发的（不依赖于现有的流程），那么一个最佳的体系结构将仅仅基于运行该企业所需的数据，优先级将由业务战略确定，决策可以不受过去的阻碍
2.6.2. 路线图提供了一种管理这些依赖性并做出前瞻性决策的方法
2.6.3. 路线图有助于组织权衡并制订夯实的项目计划，使其与业务需求和机会、外部需求、可用资源保持一致
2.6.4. 路线图应以数据管理成熟度评估为指导
2.6.5. 在理想中，建议从产品管理和客户管理能力开始路线图，然后从上到下解决每一步依赖关系
2.7. 在项目中管理企业需求
2.7.1. 架构不应该受开发时间的限制
2.7.2. 利用数据模型及其有关规范描述的组织数据架构必须足够灵活，并能适应未来需求
2.7.3. 构建架构层级的数据模型不仅应有企业全局观，而且要有能够让企业内部完全清楚理解的定义
2.8. 数据架构师应该决定
2.8.1. 规范中所描述实体是否符合标准
2.8.2. 在需求中，哪些实体应该被包括在整体企业数据架构中
2.8.3. 规范中的实体和定义是否需要扩大或加深以满足将来的趋势
2.8.4. 是否更新了数据架构或者是否向开发人员指出了哪些可以重用
2.9. 组织经常要等到项目需要重新设计数据存储和集成的时候，才来解决数据架构问题
2.9.1. 最好在规划的早期和整个项目生命周期中考虑这些因素
2.10. 企业数据架构项目相关的活动
2.10.1. 定义范围
2.10.1.1. 保证范围和接口与企业数据模型一致
2.10.2. 理解业务需求
2.10.2.1. 获取数据相关的需求，如实体、资源、可用性、质量和痛点，以及评估满足这些需求的业务价值
2.10.3. 设计
2.10.3.1. 形成详细的目标规范
2.10.3.1.1. 数据生命周期内的业务规则
2.10.3.1.2. 验证结果的有效性
2.10.3.1.3. 需要提供的时间
2.10.3.1.4. 提升模型的扩展性和改进标准模型等
2.10.4. 实施
2.10.4.1. 什么时候购买
2.10.4.2. 什么时候重用数据
2.10.4.2.1. 强制使用管理该结果的系统记录或其他权威数据，以便识别和存储差异
2.10.4.3. 什么时候构建
2.11. 方式
2.11.1. 瀑布方式
2.11.1.1. 作为整个企业设计的一部分，在连续阶段中理解需求和构建系统
2.11.2. 迭代方式
2.11.2.1. 逐步学习和构建
2.11.3. 敏捷方式
2.11.3.1. 指在离散的交付包中学习，构建并测试（称为“sprints”冲刺）
2.11.3.2. 离散的交付包很小，如需要丢弃，也不会损失太多
2.12. 企业数据架构是一个逐步演变的过程
3. 整合其他企业架构3.1. 从主题域层级到更细化的层面，对每个层面都需要建立与其他类型架构的联系
3.2. 开发企业数据架构规范的工作通常是在某些项目中一并进行的，这些项目决定了架构工作的优先级
3.3. 最好把企业数据架构问题和项目组合管理进行整合
3.3.1. 这样做能促进路线图的实施，有助于获得更好的项目效果
3.4. 企业数据架构师的工作应被包含在企业应用开发和整合计划中，同时将数据架构视图应用于目标应用场景以及该场景的路线图中
4. 工具4.1. 数据建模工具
4.1.1. 在管理所有层级数据模型的过程中，数据模型工具和模型库都是非常必需的
4.1.2. 很多数据模型工具具有数据血缘和关系跟踪功能
4.2. 资产管理软件
4.2.1. 资产管理软件用于管理数据资源目录，描述其内容以及跟踪它们之间的关系
4.2.2. 利用这些工具还可以确保组织遵循软件许可相关的合同义务，并收集资产相关的数据，最小化成本，优化IT流程
4.3. 图形设计应用
4.3.1. 可以用于创建架构设计图形、数据流、数据价值链和其他架构构件
5. 生命周期预测5.1. 当前的
5.1.1. 当前支持和使用的产品
5.2. 部署周期的
5.2.1. 未来1～2年内部署使用的产品
5.3. 策略周期的
5.3.1. 未来两年后期待使用的产品
5.4. 退役的
5.4.1. 一年内，组织已经停止使用或打算停止使用的产品
5.5. 优先的
5.5.1. 被多数应用优先使用的产品
5.6. 限制的
5.6.1. 在一定应用中限制使用的产品
5.7. 新兴的
5.7.1. 为将来可能的部署研究和试行的产品
5.8. 审核的
5.8.1. 已经评估的产品，评估结果目前不能用于以上状态的产品
6. 图标使用规范6.1. 运用模型和图标呈现信息是指以已定义好的且达成共识的一套图标来表达待说明内容的一种方式
6.1.1. 该方式是通过使用图标来实现视觉转换，以达到提高可读性和便于理解的目的
6.2. 对图标的使用必须保持一致，如果使用不当，会给读者造成误解或者曲解，那么就可能会适得其反
6.3. 对图标的使用需要遵从干扰最小化、有用信息最大化的原则
6.4. 清晰一致的说明
6.4.1. 应该清晰标识并说明所有对象和线条及图标所代表的内容
6.5. 所有图表对象与说明相匹配
6.5.1. 在使用的说明模板中，并不是所有的说明对象都会在图标中出现，但是所有的图标对象都应该有与之相匹配的说明
6.6. 清晰一致的线条方向
6.6.1. 所有线条的流向都应该从某一侧或角（通常为左侧）开始，尽可能流向对侧或对角
6.7. 一致的交叉线显示方法
6.7.1. 要清楚交叉点并非连接点，在无法避免交叉的情况下允许线交叉
6.7.2. 对同一个方向上的所有线使用跨线
6.7.3. 不要将线与线直接连接
6.7.4. 尽可能减少线交叉现象出现的次数
6.8. 一致的对象属性
6.8.1. 对任何大小、颜色、线条粗细等不同的图标均要求表示不同的内容，否则会因此增加读者的理解难度，容易造成混淆
6.9. 线性对称
6.9.1. 行和列排放整齐的图标比随机摆放的图标易读性更好，更容易理解
6.9.2. 虽然几乎不可能使所有对象都能够保持一致，且能够实现行和列排放整齐，但至少在某一个方向上（水平或垂直）排列整齐，这也将在很大程度上提高图标的可读性
7. 实施指南7.1. 建立企业数据架构团队和举办问题讨论会
7.2. 生成数据架构构件的初始版本
7.3. 在开发项目中，形成和建立数据架构工作方式
7.4. 提高组织对数据架构工作价值的认识
7.5. 数据架构实施应该至少包括其中两项工作内容，因为这样可以实现互补，以获得相对较好的效果
7.6. 在开发模型中获取数据模型和其他数据架构构件，然后被数据架构师标准化和管理
7.6.1. 数据架构工作在第一个项目中的投入相对比较大，但在此过程中形成的构件可以被后继项目重复使用，因而后继项目投入就会减少
7.7. 企业数据架构师要与其他业务和技术架构师合作，架构师的共同目标是提高组织的有效性和灵活性
7.8. 对企业设计架构的质量驱动需求要求在规划项目时，强制将数据架构工作内容纳入企业的所有项目的开发计划中
8. 风险8.1. 缺少管理层支持
8.1.1. 确保在数据架构开发过程中多寻求一些能够理解数据架构并愿意支持的高层管理人员，这是数据架构成败的关键
8.2. 成功与否缺乏证据
8.2.1. 高层支持对于这项工作的成功至关重要，因为他或她的信任对成功执行数据架构功能是非常重要的
8.2.2. 执行最重要的步骤时，须寻求资深架构师的帮助
8.3. 缺乏管理者的信任
8.3.1. 如果高层要求所有沟通都需要经过他们允许，这可能暗示这些人不确定他们的角色，可能只对除了数据架构流程目标之外的东西感兴趣或不信任数据架构师的能力
8.3.2. 不管哪种原因，高层必须允许项目经理和数据架构师在项目中发挥主导作用
8.3.3. 争取获得高层信任，并在工作中保持独立
8.4. 管理层不正确的决策
8.5. 文化冲击
8.6. 缺乏有经验的项目经理
8.6.1. 确保项目经理具有企业数据架构经验，特别是项目具有非常重要的数据组件时
8.6.2. 如果不是这样，鼓励高层更换或培养项目经理
8.7. 单一维度视角
8.7.1. 有时业务应用的所有者可能会决定他们对整个企业级数据架构的看法，而牺牲一个更平衡、更包容的观点
9. 组织和文化9.1. 组织架构实施的速度依赖于适应文化的程度
9.1.1. 设计工作中要求架构师与组织中开发者和其他有创意的思想者进行合作
9.2. 一个组织接受并实施数据架构的能力依赖于
9.2.1. 对架构方法的接受度（开发架构的友好性）
9.2.2. 确认数据属于组织的业务资产，而不仅仅是IT的任务
9.2.3. 放弃局部数据视角，接受企业级数据视角的能力
9.2.4. 将架构交付成果整合到项目实施中的能力
9.2.5. 规范数据治理的接受程度
9.2.6. 立足企业全局，而不是仅仅局限于项目交付成果和IT解决问题的能力
10. 数据架构治理10.1. 数据架构活动能直接支持数据模型不同层级的映射管理及控制数据
10.2. 数据架构师通常充当数据治理活动的业务联络人
10.2.1. 在理想情况下，数据架构师和数据管理员对每个主题域，甚至每个主题域的实体都保持一致
10.3. 数据监督应该与流程监督保持一致
10.3.1. 业务事件主题域应该与流程监督保持一致，因为每个事件实体通常与业务流程相对应
10.4. 活动
10.4.1. 项目监督
10.4.1.1. 包括确保项目符合所需的数据架构活动、使用和提高架构资产，且必须根据架构标准实施
10.4.2. 管理架构设计、生命周期和工具
10.4.2.1. 必须对架构设计进行定义、评估和维护
10.4.2.2. 数据架构是企业长期整合规划的“分区规划”之一
10.4.2.3. 数据架构的未来状态不仅影响项目目标，而且也影响项目在项目群中的优先级
10.4.3. 定义标准
10.4.3.1. 制定数据在组织内如何使用的规则、指南和规范
10.4.4. 创建数据相关构件
10.4.4.1. 支持治理规范的构件
11. 度量指标11.1. 架构标准接受率
11.1.1. 可以测量项目与已建立的数据架构的紧密程度及项目与企业架构参与流程的遵循度
11.2. 实施趋势
11.2.1. 使用/重用/代替/废弃测量
11.2.1.1. 决定使用新架构构件与重用、代替或废弃构件的比例
11.2.2. 项目执行效率测量
11.2.2.1. 测量项目的交付时间和可重用构件及指导构件的交付改进成本
11.3. 业务价值度量指标
11.3.1. 业务敏捷性改进
11.3.1.1. 解释生命周期改进或改变的好处，改进延误成本的测量方法
11.3.2. 业务质量
11.3.2.1. 测量业务案例是否按期完成
11.3.2.2. 基于新创建或集成的数据导致业务发生的改变，测量项目是否实际交付了这些变更
11.3.3. 业务操作质量
11.3.3.1. 测量改进效率的方法
11.3.3.2. 实例包括准确性改进、时间减少，由于数据错误而导致的纠错费
11.3.4. 业务环境改进
11.3.4.1. 实例包括由于数据错误减少而改变的客户保留率和在递交报告中当局评论的减少率
