读DAMA数据管理知识体系指南08数据架构（下）

1. 活动

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. 实例包括由于数据错误减少而改变的客户保留率和在递交报告中政府评论的减少率
    
  
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。