一、引言
数据架构是数据管理的基础
数据架构设计文件是正式的企业数据模型(EDM),包含数据名称、数据属性和元数据定义、概念和逻辑实体、关系以及业务规则。
物理数据模型也属于数据架构文件,但物理数据模型是数据建模和设计的产物,而不是数据架构的产物。
数据架构如果能够完全支撑整个企业的需求,它才是最有价值的
架构师设计的数据架构构件非常有价值的元数据的重要组成部分,数据架构构件应该在企业级元知识库中被集成存储和管理。
二、业务驱动因素
数据架构的目标是在业务战略和技术实现之间建立起一座通畅的桥梁。数据架构是企业架构中的一部分,主要职责为:
1、从战略上帮助组织快速改变产品、服务和数据
2、将业务需求转换为数据和应用需求,以确保能够为业务流程处理提供有效数据
3、管理复杂数据和信息,并传递至整个企业
4、确保业务和IT技术保持一致
5、为企业改革、转型和提高适应性提供支撑
2.1 数据架构的成果和实施
数据架构主要成果包括:
1、数据存储和处理需求
2、设计满足企业当前和长期数据需求的结构和规划
架构师为组织带来的价值主要通过合适的技术应用、有效运营、项目效率提升以及数据应用能力来加强体现。
为实现该目标:要求组织具有良好的设计和计划以及确保设计和计划能够被执行的能力
2.2 架构师需要定义和维护的内容:
1、定义组织中数据的当前状态
2、提供数据和组件的标准业务词汇
3、确保数据架构和企业战略及业务架构保持一致
4、描述组织数据战略需求
5、高阶数据整合概要设计
6、整合数据架构蓝图
2.3 总体数据架构实施包括:
1、使用数据架构构建来定义数据需求、指导数据整合、管控数据资产,确保数据项目投入与企业战略保持一致
2、与参与改进业务或IT系统开发的利益相关方合作。
3、通过数据架构及通用的数据词汇,搭建企业数据语言。
三、基本概念
3.1 企业架构类型
类型 | 企业业务架构 | 企业数据架构 | 企业应用架构 | 企业技术架构 |
目的 | 识别企业如何为消费者和其他利益相关方创造价值 | 描述数据应用如何组织和管理 | 描述企业应用的结构和功能 | 描述能使系统发挥功能和传递价值的实体技术 |
元素 | 业务模型、流程、功能、服务、事件、策略、词汇 | 数据模型、数据定义、数据映射规范、数据流、结构化数据应用编程接口 | 业务系统、软件包、数据库 | 技术平台、网络、安全、整合工具 |
依赖项 | 制定其他架构的需求 | 管理业务架构创建和需要的数据 | 依据业务需求来处理指定的数据 | 承载并执行应用架构 |
角色 | 业务架构师和分析师、业务数据管理员 | 数据架构师、建模师、数据管理员 | 应用架构师 | 基础设施架构师 |
3.2 企业架构框架
企业架构框架师用于开发广泛的相关架构的基础结构。
架构框架师提供了思考和理解架构的方式。他们代表了一个总体的“架构的架构”
IEEE计算机协会维护的企业架构框架标准是:ISO/IEC/IEEE
著名的企业架构框架是 Zachman 框架,Zachman 框架是一个本地,即6*6矩阵构成了一组模型,这组模型完整描述一个企业以及相互之间的关系。它不定义如何创建模型,知识显示哪些模型应该存在。
是什么 | 怎样做 | 在哪里 | 是谁 | 什么时间 | 为什么 | ||
管理层 | 库存标识 | 过程识别 | 分发识别 | 责任认定 | 时间识别 | 动机识别 | 上下文范围 |
业务管理 | 库存定义 | 流程定义 | 分布定义 | 责任定义 | 时间定义 | 动机定义 | 业务概念 |
架构师 | 库存表示 | 过程表示 | 分布表示 | 责任表示 | 时间表示 | 动机表示 | 系统逻辑 |
工程师 | 库存规格 | 流程规范 | 分布规范 | 责任规范 | 时间规范 | 动机规范 | 实施部署 |
技术员 | 库存配置 | 流程配置 | 分发配置 | 责任配置 | 时间配置 | 动机配置 | 工具组件 |
操作员 | 库存实例 | 流程实例 | 分发实例 | 责任实例 | 时间实例 | 动机实例 | 操作实例 |
库存集 | 过程流 | 分销网络 | 责任分配 | 时间周期 | 动机的意图 |
框架模型每个列:
什么(what),目录列,表示构建架构的实体。
怎样(How),流程列,表示执行的活动。
在那里(Where),分布列,表示业务位置和技术位置。
谁(Who),职责列,表示角色和组织
什么时间(When),时间列,表示间隔、事件、周期和时间表
为什么(Why),动机列,表示目标、策略和手段。
3.3 企业数据架构
企业数据架构描述必须包括企业数据模型和数据流设计
企业数据模型:是一个整体的、企业级的、独立实施的概念或逻辑数据模型,为企业提供通用的、一致的数据视图。
数据流设计:定义数据库、应用、平台和网络之间的需求和主蓝图。
模型链接定义和管理了模型的纵向从上到下以及横向之间的关联路径。
纵向:不同层级模型之间的映射。
横向:同一个实体和关系可能出现在同一层级的多个模型中。位于一个主题域中的逻辑模型中的实体可以和其他主题域中的实体相关联,在模型图中标记为其他主题域的外键。
企业概念数据模型是由主题域模型相结合构建的。
主题域结构基于现有逻辑数据模型向上提炼抽象而成。
主题域的识别准则必须在整个企业模型中保持一致。
主题域识别准则包含:
- 使用规范化规则,从系统组合中分离主题域,基于顶级流程或者基于业务能力从数据治理结构和数据所有权中形成主题领域。
- 数据流设计
- 数据流是一种记录数据血缘的数据加工过程,用于描述数据如何在业务流程中和系统中流动。端到端的数据流包含了数据起源于哪里,在哪里存储和使用,在不同流程和系统内或之间如何转化。数据血缘分析有助于解释数据流中某一点上的数据状态。
数据流映射记录了数据与以下内容的联系:
- 业务流程中的应用
- 某个环境中的数据存储或数据库
- 网段
- 业务角色
- 出现局部差异的位置
数据流可以用于描述不同层级模型的映射关系:主题域、业务实体,乃至属性层面的映射关系。
系统可以通过网络、平台、常用应用集或独立服务器呈现。数据流可以通过二维矩阵或数据流图的方式呈现。
通过矩阵可以展现创建和使用数据的过程。采用矩阵方法显示数据需求的优势是可以清晰看出数据不是只在一个方向上流动。
数据交换是多对多,并会在多个地方出现。
矩阵方法可以明确流程中的数据获取职责及数据依赖关系。
在企业模型中构建矩阵是一个长期的过程。
四、活动
简化数据和企业架构面临复杂问题基于以下两种方式解决
面向质量:专注于业务和IT开发周期内对数据架构进行不断改进。如果架构没有妥善管理,也会慢慢遭到破坏,系统逐渐变得越来越复杂和缺乏扩展性。
面向创新:专注与业务和IT转换,致力于新的期待和机会。用创新性技术和数据使用驱动创新。
面向质量的方法与传统的数据架构工作保持一致,其中架构质量改进是逐步完成的。
4.1 建立企业数据架构
数据架构师企业架构的组成部分
建立企业数据架构包含的工作:
- 战略:选择框架,制定方法,开发路线图。
- 沟通与文化:建立沟通机制,并激励积极参与者
- 组织:通过明确责任和职责来组织数据框架工作。
- 工作方法:与企业架构保持一致,在开发项目中定义最佳实现并执行数据架构工作。
- 结果:在总体路线图中产出数据架构产品。
企业数据架构影响项目和系统开发的范围边界:
- 定义项目数据需求
- 审评项目数据设计
- 确定数据溯源影响
- 数据复制控制
- 实施数据架构标准
- 指导数据技术和更新决策。
4.1.1 现有数据架构规范评估
每个组织都保存着现有系统的一系列文档。为了了解当前数据架构,需要识别这些文件,并评估其准确性、完整性和详细程度。
4.1.2 开发路线图
如果企业是从零开始开发的,那么最佳的体系架构将仅仅基于运行该企业所需的数据,优先将业务战略确定,决策可以不受过去的阻碍。路线图提供了一种管理这些依赖性并作出前瞻性决策的方法。路线图有助于组织权衡并制定夯实的项目计划,使其业务需求和机会、外部需求、可用资源保持一致。
企业数据架构描述了3-5年的发展路径。
企业数据架构路线图必须与企业架构路线图相整合,企业架构路线图包括:高层次里程碑事件、所需资源、成本评估、业务能力工作流划分。路线图应该以数据管理成熟度评估作为指导。
业务数据驱动路线图可以从最独立的业务能力开始,在处理相互依赖程度较高的业务能力。
4.1.3 项目中管理企业需求
架构不受开发事件的限制,利用数据模型及其有关规范描述的组织数据架构必须足够灵活,并能适应未来需求。
对获取、存储、分发数据的开发项目实施解决方案,需要以业务需求和企业数据架构的标准作为基础。
在项目级别上,通过数据模型定义需求的过程是审查业务需求开始的。
项目范围完成时,数据架构决定:
- 规范中所描述实体是否符合标准
- 在需求中,哪些实体应该被包括在整体企业数据架构中
- 在规范中的实体和定义是否需要扩大或加深以满足将来的趋势
- 是否更新了数据架构或者是否向开发人员指出了哪些可以重用
企业数据架构项目相关的活动包括
定义范围:保证范围和接口与企业数据模型一致。
理解业务需求:获取数据相关的需求,如实体、资源、可用性、质量和痛点,以满足这些需求的业务价值。
设计:形成详细的目标规范,包括:数据生命周期内的业务规则、验证结果的有效性、需要提供的时间、提升模型的扩展性和改进标准模型等
实施
- 什么时候购买
- 什么时候重用数据
- 什么时候构建
企业数据架构角色依赖软件开发过程,具体由三种:
瀑布模式:连续阶段中理解需求和构建系统。
迭代模式:逐步学习和构建。这种方式适合总体需求模糊的原型。
敏捷方式:这种方式指在离散的交付包中学习,构建并测试。DevOps 是一种流行的敏捷方法,可以帮助改进数据设计,并使得数据设计的选择更加高效。
4.2 整合其他企业架构
从主题域层级到更细化的,对每个层面都需要建立于其他类型架构的联系。数据架构可能会影响项目的范围。最好把企业数据架构问题和项目组合管理进行整合。
企业数据架构师的工作应包含企业应用开发和整合计划中。将数据架构视图应用于目标应用场景以及场景的路线图中。
五、工具
5.1 数据建模工具
数据模型工具和模型库都是非常必须的,有很多数据模型工具具有数据血缘和关系跟踪功能。
5.2 资产管理软件
资产管理软件用于管理数据资源目录,描述其内容以及跟踪它们之间的关系。
5.3 图形设计应用
可以用于创建架构设计图形、数据流、数据价值链和其他架构构件。
六、方法
6.1生命周期预测
存档:
当前的:当前支持和使用的产品
部署周期的:未来1-2年内部署使用的产品
策略周期的:未来两年后期待使用的产品
退役的:一年内,组织已经停止使用或者打算停止使用的产品。
优先的:被多数应用优先使用的产品
限制的:在一定应用中限制使用的产品。
新兴的:为将来可能的部署研究和试行的产品
审核的:已经评估的产品。
6.2 图标使用规范
清晰一致的说明:清晰标识并说明所有对象的线条及图标所代表的内容。
所有图标对象与说明相匹配:所有的图标对象都应该有与之相匹配的说明。
清晰一致的线条方向:所有线条的流向都应该从某一侧或角开始,尽可能流向对侧或对角。姚确保回流和循环的线条方向清楚可见。
一致的交叉线显示方法:清楚交叉点并非连接点,在无法避免交叉的情况下允许线交叉;对同一个方向上的所有线使用跨线;不要将线与线直接连接;尽可能减少线交叉现象出现的次数。
一致的对象属性:对任何大小、颜色、线条粗细等不同的图标均要求标识不同的内容。
线性对称:行和列排放整齐的图标比随机摆放的图标易读性更好,更容易理解。
七、实施指南
数据架构包括构件、活动和行为,实施企业数据架构主要包含的工作内容为:
建立企业数据架构团队和举办问题讨论会
生成数据架构构件的初始版本。
在开发项目中 ,形成和建立数据架构工作方式。
提高组织对数据架构工作价值的认识。
在开发模型中获取数据模型和其他数据架构构件,然后被数据架构师标准化和管理。
企业数据架构师要与其他业务和技术架构师合作,架构师的共同目的师提高组织的有效性和灵活性。整体企业架构的业务驱动策略也会明显影响企业数据架构实施决策。
7.1 就绪评估和风险评估
暴露出的风险有:
- 缺少管理层支持
- 成功与否缺乏证据
- 缺乏管理者的信任
- 管理层不正确的决策
- 文化冲击
- 缺乏有经验的项目经理
- 单一维度视角
7.2 组织和文化
组织架构实施的速度依赖于适应文化的程度。
以产出为导向,战略一致的组织能更好的适应架构实施,这些组织通常以目标为导向。
组织接受并实施数据架构的能力依赖于一下几个方面:
- 对架构方法的接受度
- 确认数据属于组织的业务资产,而不仅仅是IT的任务
- 放弃局部数据视角,接受企业级数据视角的能力
- 将架构交付成果整合到项目实施中的能力
- 规范数据治理的接受程度
- 立足企业全局,而不是仅仅局限于项目交付成果和IT解决问题的能力。
八、数据架构治理
数据架构活动能直接支持数据模型不同层级的映射管理及控制数据。
数据架构师通常充当数据治理活动的业务联络人。
企业数据架构和数据治理组织必须保持一致。
在理想情况下,数据架构师和数据管理员对每个主题域,甚至每个主题域的实体都保持一致。
数据监督应该与流程监督保持一致。
8.1 数据架构治理活动
项目监督:确保项目符合所需的数据架构活动、使用和提高架构资产,且必须根据架构标准实施。
管理架构设计、生命周期和工具。必须对架构设计进行定义、评估和维护。
定义标准:执行数据在组织内如何使用的规则、指南和规范
创建数据相关构件:支持治理规范的构件。
8.2 度量指标
企业数据架构衡量指标反应了架构目标:架构接受度、实施趋势、业务价值。
数据架构衡量工作通常作为项目总体业务客户满意度的一部分,每年开展一次。
8.2.1 架构标准接受率
追踪项目预期的衡量指标也有助于理解和采纳执行过程中出现的问题
8.2.2 实施趋势
改善组织实施项目能力的程度需要沿两个方向进行改善:
使用/重用/代替/废弃测量
项目执行效率测量
8.2.3 业务价值度量指标
业务敏捷性改进:解释生命周期改进或改变的好处,改进延误成本的测量方法
业务质量:测量业务案例是否按期完成,基于新创建或集成的数据导致业务发生的改变
业务操作质量:测量改进效率的方法。实例包括准确性改进、时间减少,由于数据错误而导致的纠错费。
业务环境改进:实例包括由于数据错误减少而改变的客户保留率和递交报告中当局评论的减少率