数据架构管理

一、简介

　　数据架构管理是定义和维护如下规范的过程:

　　　　• 提供标准的、通用的业务术语/辞典。

　　　　• 表达战略性的数据需求。

　　　　• 为满足如上需求,概述高层次的整合设计。

　　　　• 使企业战略和相关业务架构相一致。

　　数据架构是用于定义数据需求、指导对数据资产的整合和控制、使数据投资与业务战略相匹配的一套整体构件规范。它也是主蓝图在不同层面的抽象之大集。数据架构包括正式的数据命名,全面的数据定义、有效的数据结构、精确的数据完整性规则,以及健全的数据文档。

　　数据架构在支持整个企业的信息需要时才最有价值。企业数据架构整合整个企业的数据并标准化。本章将着重于企业数据架构,相同的技术也适用于组织内的有限的特定功能或某个部门。

　　企业数据架构是更大的企业架构中的一部分;在企业架构中,数据架构与其他业务和技术架构相整合。企业架构整合了数据、流程、组织,应用和技术架构。它帮助各个组织进行变更管理,提高效率、灵活性,以及明确管理责任。

　　图4.1显示了数据架构管理职能的关联图。

　　企业数据架构是一套规范和文档的集合。它主要包括如下3类规范。

　　　　(1)企业数据模型:企业数据架构的核心。

　　　　(2〉信息的价值链分析;使数据与业务流程及其他企业架构的组件相一致。

　　　　(3)相关数据交付架构:包括数据库架构,数据整合架构,数据仓库]商务智能架构、文档和内容架构,以及元数据架构。

　　企业数据架构是一个不准确的说法。它不仅是关于数据的,更是关于术语的。企业数据架构定义了组织中重要事项的标准术语-这些事项对业务至关重要,而关于这些事项的数据对经营业务是必不可少的。这些事项是--些业务实体。也许企业数据架构对企业来说最大的收益就是建立-一套关于业务实体及其重要属性(特征)的通用的业务术语。企业数据架构定义了企业中的语义。

二、概念和活动

2.1 架构综述

　　架构是对构成要素的有组织安排,它优化整个结构或系统的功能,性能,可行性,成本以及美感。"架构”这个词是信息技术领域应用最广泛的术语之一。“架构”一词非常令人回味——了解设计建筑物和设计信息系统之间的相似点极其有用。架构,是一组反映不同利益相关者的问题和看法的,相互密切相关的综合视图。对架构的了解,可以使人们明白一些非常复杂的事务,无论这个复杂的事务是自然的(地质构造、数学、生物)抑或是人造的(包括建筑、音乐、机械、组织、流程、软件和数据库)。

　　理解建筑物的蓝图有助于承建商在成本和时间要求范围内,建成安全、功能实用而且美观的楼宇。学习解剖学(生物活体的结构)有助于医学学生们学习如何提供医疗救治。当结构和系统变得复杂时,人员和组织都可从了解架构中受益。系统越复杂,人们通过了解架构受益则越多。

　　架构可以存在于不同层面,从宏观的城市规划到微观的机械部件构建都会有架构的体现。在每个层面,标准和协议都用来确保构成的不同部件可以协同工作。架构包括标准及其在特定设计需求方面的应用。

　　在信息系统的语境中,架构是“任何复杂的技术对象或系统的设计”。

　　技术--定是复杂的。信息技术领域极大地受益于架构设计:它帮助管理软硬件产品的复杂性。技术架构包括特定厂商自有的“封闭”设计标准和任何厂商都可用的“开放”标准。

　　组织机构也是复杂的。整合组织中的不同部分,若使其符合企业战略目标,通常需要全面的业务架构,可能包括对业务流程、业务目标、组织架构、组织角色的通用设计和标准。对组织机构来说,架构完全是关于整合的。通过并购而发展的组织机构,通常面临重大的机构整合挑战,因此会从有效的架构中大大获益。

　　信息系统通常是非常复杂的。愈来愈多相对简单的独立应用系统增加,并且采用战术的方法在各个孤立业务应用系统之间移动和共享数据,使大部分机构的应用系统组合看上去像一盘意大利面条,用来理解和维护这类复杂系统的成本越来越高。因此,根据整体结构来重构应用系统和数据库的收益越来越有吸引力。

2.1.1 企业架构

　　企业架构是一套整合的业务与IT规范模型和构件,用以反映企业整合和标准化的需求。企业架构定义对数据、流程、组织和技术的业务整合背景,协调企业资源与企业目标之间的一致性。企业架构包含业务架构和信息系统架构。

　　企业架构为管理信息和系统资产提供了一套系统化的方法,以满足战略性的业务需求，赋予企业管理机构项目组合的能力。企业架构通过帮助变更管理、追踪机构变更对系统的影响以及系统变更对业务的影响,来支持战略决策。

　　企业架构包括很多相互关联的模块和构件。

　　　　• 信息架构-—业务实体、关系、属性、定义、(代码)参考值。

　　　　• 流程架构-—职能、活动、工作流、事件、周期、产品、步骤。

　　　　• 业务架构-—目标、战略、角色、组织结构、场所。

　　　　• 系统架构-—应用、软件组件、接口、项目。

　　　　• 技术架构-—网络、硬件、软件平台、标准、协议。

　　　　• 信息价值链分析构件(artifact)-——-绘制数据,流程、业务、系统和技术之间的关系。

　　企业模型从整合的规范中产生了大量相关的构件。这些构件包括图形、表格、分析矩阵和文字档案。这些构件在不同细节程度上描述组织如何运作以及需要何类资源。这些规范应可追溯至其支持的目标意图和目标,而且应该遵从内容和表达方式的标准。很少有组织机构的企业架构包括所有潜在可能的组件模块和构件。

　　企业架构经常把“现有的”和“将来的”的愿景相区别,有时会包括中间阶段和迁移方案,一些企业架构试图把一个理想状态作为参照模型,把目标模型定义为朝着理想状态迈进的系列实用的、可达到的步骤。时时更新企业的架构规范体现当前的情况,才可使其具有相关性和实用价值。没有任何机构能一次性完全完成其企业架构的维护和丰富的工作。

　　每个机构都基于其对业务需要和业务信险的理解来投资于企业架构的开发和维护。一些机构选择对企业架构定义到具体细节,以更好地管理风险。

　　企业架构是非常重要的知识资产,能带来诸多益处。它是规划、IT治理和组合管理的工具。企业架构可以:

　　　　• 有效地整合数据、流程、技术和人们的努力。

　　　　• 使信息系统与业务策略一致。

　　　　• 使得我们可以有效地使用和协调资源。

　　　　• 改善跨组织的沟通和理解。

　　　　• 降低管理IT基础设施的成本。

　　　　• 给业务流程的改进提供指引。

　　　　• 使组织有效地应对不断变化的市场机会、业界挑战和技术进展。企业架构帮助评估业务风险、管理变更、改进业务有效性、敏捷性和可问责性。

　　定义企业架构的方法包括IBM的“业务系统规划"(Business Systems Planning,BSP)方法和James Martin的信息工程方法“信息系统规划”(Information Systems Planning,ISP)。

2.1.2 架构框架（Architectural Framework）

　　架构框架提供了一种思考和理解架构的方法,以及需要架构的结构和系统。架构是复杂的,架构框架从总体上提供了“架构的架构”。

　　有两类不同的架构框架:

　　　　• 分类框架——将指引企业架构的结构和视图组织起来。框架定义构件的标准语法来描述以上视图以及视图之间的关系。构件大多数是图形、表格和矩阵。

　　　　• 流程框架―—规定业务和系统规划分析,以及流程的设计方法。有些IT规划和软件开发生命周期(SDLC)包括其自定义的复合分类。不是所有流程框架都规定同一套东西,有些是很专用的。

　　架构框架的范围不只限于信息系统架构。架构框架帮助定义软件分析和设计过程中产出的逻辑、物理和技术构件,这些构件又指导更具体明确的信息系统解决方案设计。组织机构采用架构框架用于IT治理和架构质量控制、组织机构有可能在批准一个系统设计之前要求IT部门提交特定的构件。

　　目前已经存在一些框架,例如:

　　　　• TOGAF—一开放组织架构框架是开放群组(The Open Group)所开发的一套标准流程框架和软件开发生命周期(SDLC)方法。这是一个供应商和技术中立的组织，旨在定义和推广全球互操作性公开标准的合作团体。TOGAF8企业版可被任何机构采用,无论是否为开放组织的会员。

　　　　• ANSI/IEEE 1471-2000—一推荐用于软件密集型系统的架构描述,它有望成为ISO/IEC 25961标准,是用来定义解决方案的构件。

　　有些咨询公司开发出有用的自有专利的架构框架。有些政府和国防部门也开发出了一些架构框架,包括:

　　　　• 联邦企业架构(FEA)—由管理和预算办公室产生,供美国政府内部使用。

　　　　• 政府企业架构(GEA)-—立法规定由澳大利亚昆士兰省政府各部门使用。

　　　　• DODAF———美国国防部架构框架。

　　　　• MODAF-——英国国防部架构框架。

　　　　• AGATE——法国DGA架构框架。

2.1.3 Zachman企业架构框架

　　Zachman企业框架2是最广为人知并被广泛使用的架构框架。尤其是企业数据架构师,自从John Zachman于1987年在 IBM的一篇系统刊物文章里首次发表此框架的描述之后,就开始对其采纳和使用。

　　如图4.2所示的Zachman企业框架⒉使术语更加面向业务管理,同时在描述中保留了数据和信息系统专业人员的用词。各个角度提供者(右手行标题)所用的术语、各种角度内容的确定(左手行标题)以及对每个问题的通用答案识别(列页脚标题),在某种程度上使得对每个简单分类的理解更加清晰。

　　为企业架构建模在美国联邦政府中是常规实践,旨在报告其资本规划和投入控制(CPIC)过程。克林杰-科恩法案(CCA,或称1996年信息技术管理改革法案)要求所有联邦政府职能部门都拥有并使用正规的企业架构。

　　新版企业架构标准和Zachman企业框架⒉的图表,可以在以下网址 http;//zachmaninternational, com/经过注册免费访问。Zachman 所著的A Concise Definition ofthe Framework 一书也可以在这个网站上找到。

　　如创建人Zachman所言,其框架是--个逻辑结构,用于管理企业和开发系统的识别和描述性表达(模型)。事实上,Zachman框架是一个适用于任何复杂系统设计构件的通用分类模式。Zachman框架不是用于定义某个单元的表示方法。它是一个用于描述企业和架构模型的结构。

　　为理解系统架构,Zachman研究了建筑业和航空工程业如何定义复杂的系统,并将这些例子映射到信息系统构件中。Zachrman框架是表现两种分类———系统架构的两个维度交集的一个6×6矩阵。

　　在第一个维度中,Zachman认识到在创建房屋、飞机和IT系统的过程中,有很多利益相关者,每个人都对“架构"有着不同的视角。规划者,所有者、设计者,建造者,实施者和参与者,他们每个人都有不同的问题去识别,理解和解决。Zachman将这些视角进行了如下描述。

　　　　• 规划者视角(范围背景)-一―定义(业务)范围的一系列业务元索﹐由作为理论家的策略制定者识别。

　　　　• 所有者视角(业务概念)——关于业务元素之间的关系的语义模型﹐由作为所有者的管理领导人定义。

　　　　• 设计者视角(系统逻辑)——详细描述系统需求和不受约束的设计逻辑模型,由作为架构师的设计者描绘。

　　　　• 建造者视角(技术物理)---一作为建造者的工程师,在特定技术,人员、成本和时间限定下,为实现特定应用而对设计进行优化的物理模型。

　　　　• 实施者视角(组件组装)——关于技师作为实施者,如何组装、运作和配置系统组件，利用专有技术的、不受背景约束的视角。

　　　　• 参与者视角(运营等级)-—--作为参与者的人员使用的实际运作系统的实例。

　　对第二个维度来说,每个视角的问题需要从不同方面来回答那些沟通中被问到的最基础性的问题:何人做、用什么做、为何做,何时做,何地做、如何做。每个问题要求不同形式的答案。Zachman将每个基础性问题用列表示。

　　圆括号中为每列修订后的标签。

　　　　• 用什么做(数据列)——建造系统所用的材料(库存项Inventory Sets)。

　　　　• 如何做(功能列)--—履行的活动(流程转换)。

　　　　• 何地做(网络列)——地点,拓扑和技术(网络节点)。

　　　　• 何人做(人员列)-—一-角色和组织(组织中的团队)。

　　　　• 何时做(时间列)——事件、周期和日程(时间阶段)。

　　　　• 为何做(目标列)——目标.策略﹑出发点(动机原因)。

　　Zachman框架中的每个单元格都代表了一个唯一的设计组件,由框架中行和列交汇点定义。

　　框架中的列并不按重要性顺序排列,但行的顺序非常重要。每一列中,每个单元格(标题)的内容都约束着其下方单元格的内容。从视角到视角的转化确保企业所有者的意图与其后的决策相一致。

　　每个单元格都描述一个原始模型,重点限于列的单独视角。Zachman框架在细节上的粒度隶属于任何单个的单元格,与行无关。依据需要,每个单元格模型可以包括相对少的细节,也可以极度细节化。为避免歧义,整合的要求越高,所需的细节越多。

　　没有任何架构框架天生就是正确和完整的,采纳任何设计框架并不是成功的保证。有些组织和个人采用Zachman框架作为“思考工具”,而另一些人用它作为解决方案实施的工程质量保证体系。

　　Zachman框架被广泛采用,有数个原因:

　　　　• 它只有两个维度,相对简单,容易理解。

　　　　• 它既充分考虑了整个企业,又管理了各个部门的架构。

　　　　• 它采取非技术语言,帮助人们更为精确地思考和交流。

　　　　• 它可被用来帮助表达和理解广泛层面上的问题。

　　　　• 它帮助解决设计问题,在关注细节的同时又不失全局观。

　　　　• 它帮助传授很多不同的关于信息系统的话题。

　　　　• 它是很有用的规划工具,为更好的决策提供背景。

　　　　• 它独立于专有的工具和方法。任何设计工具或方法都可映射到此框架,以查看此工具或方法可以做什么,不可以做什么。

2.2 活动

　　数据架构管理职能包括若干定义数据资产管理蓝图的活动。这些活动的概要将在以下各节中介绍。

2.2.1 理解企业信息需求

　　为创建企业数据架构,企业需首先定义其信息需求。企业数据模型是获取和定义企业信息需求和数据需求的一种方法。它表述了全企业范围内数据整合的主蓝图。所以,企业数据模型是所有未来系统开发项目的关键输人,也是项目级附加数据需求分析和数据建模工作的基线。

　　项目的概念和逻辑数据模型基于企业数据模型中适用的部分。有些项目比其他项目更能从企业数据模型中受益,这取决于项目的范围。事实上每个重要项目都会从中受益,并且影响企业数据模型。

　　决定企业信息需求的一个方法,是基于组织内部和外部目标评估目前组织所需要的输入和输出。利用真实的系统文档和报告采访参与者。这个材料提供重要的数据实体、数据属性和数据计算的一览表。将这些项目以业务单元和主题域形式组织成列表,与参与者一起审核,以确保分类的适合性和完整性。该表就成为企业数据模型的基本需求。

2.2.2 开发和维护企业数据模型

　　业务实体是业务上真实事物和概念的分类。数据是一系列我们采集的关于业务实体的事实。数据模型定义的是业务实体以及运营和指导业务所需的那些事实(数据属性)。数据模型是一种分析和设计方法,用于:

　　　　(1)定义和分析数据需求。

　　　　(2）设计满足以上需求的逻辑和物理数据结构。

　　数据模型是反映数据需求和设计的一系列规范和相关图表。企业数据模型(EnterpriseData Model,EDM)是企业范围内的整合的、面向主题的数据模型,用来定义关键的数据生产者和消费者。

　　　　• “整合的”意味着组织中所有数据和规则都只被描述一次并无缝地相互配合。模型中的概念配合在一起,如同CEO看待整个企业,不应采用分离的有限的某个职能或部门观点,只有一个版本的“客户”实体、一个版本的“订单”实体等。每个数据属性也只有唯一的一个名字和定义。数据模型另外也可能对常见的同义词加以识别,并识别通用业务实体下不同子类型之间的重要区别。

　　　　• “面向主题”意味着模型分解为跨多个业务流程和应用系统的有共识的主题域。主题域关注最至关重要的业务实体。

　　　　• “关键的”意味着数据对组织高效运作和决策制定至关紧要。很少有企业数据模型能够定义企业内部的所有数据。这些关键的数据需求,在多个应用系统或项目中，有可能是共通的,也有可能不是。多个系统可能会共享某些企业数据模型定义的数据,但另一些数据也许更为关键重要,但只在单独系统内部产生并使用。随着时间的推移,企业数据模型应该定义所有对企业来说重要的数据。关键数据的定义会随着业务的变化而改变;EDM 必须与这些变动保持同步。

　　数据模型是数据架构管理和数据开发工作使用的关键技术。数据开发实施数据架构，使其扩充并适应企业数据模型,来满足专门的业务应用需要和项目需求。

　　1)企业数据模型

　　企业数据模型是互相密切关联的一系列交付物的整合。这些交付物大多由数据建模工具产生,但没有任何数据建模工具可以创建整个企业数据模型中所有潜在的组件交付物。企业数据模型的中心存储可以是数据模型文件,也可以是数据模型存储库,这两者都由数据建模工具创建并维护。此模型构件包括在元数据中,详述见第11章。只有少数组织会创建一个完整企业数据模型中所有的组成构件。

　　企业数据模型是一项重要的投资,用来定义和记录一个组织中的术语、业务规则和业务知识。对它的创建、维护和丰富﹐需要持续地投人时间和人力,即使该模型是外购的行业数据模型也应如此。企业数据建模是对通用的、一致的视图所进行的开发和细化,也是对数据实体、数据属性及其在整个企业中关系的深入理解。

　　组织机构既可以外购一个企业数据模型,也可以从头开始自建。有一些厂商已经开发了具有行业标准的数据模型。大部分大型数据库厂商将其作为附加产品(出售)。但没有任何外购的逻辑数据模型可以表现完美,当中总要引入一些客户化工作。
不同的企业数据模型在细节程度上大相径庭。当一个组织首次认识到需要企业数据模型的时候，它必须对于建造这个模型所能付出的时间和工作量做出决策。随着时间的推移，以及企业的需求变化,企业数据模型的范围和所描述的细节通常也会逐步扩展。成功的企业数据模型经常是通过递增和迭代开发出来的。

　　分层次建造一个企业数据模型,如图4.3所示,最开始关注于最关键的业务主题域。层次越高则越基础,而其下的层级都取决于高层。由此来讲,尽管模型的内容经常受益于从下而上的输人,但企业数据模型是从上而下建立的。这些输人(数据)通过分析和综合现有的逻辑和物理模型的视角及细节得到。将这些输人整合进企业视角时,对现有模型的影响不能危害到通用的、共享的企业视角的发展。

　　2)主题域模型

　　企业数据模型的最上层是主题域模型(Subject Area Model, SAM)。主题域模型是一系列主要主题域的列表,共同表达企业最关键领域。在Zachman框架中,这个列表也是数据的一种“范围”视角(行1,列1)。在更细节的层级,业务实体和对象类也可以用列表表示。

　　表达主题域有两种主要的方法:

　　　　• 纲要——用较小的主题域组织成较大的主题域的一个轮廓。

　　　　• 图形—可以方便地用图表达和组织多个主题域。

　　企业关键主题域的选择和命名,对整个企业数据模型至关重要。企业主题域列表会变成企业中最重要的分类方法之一。企业数据模型通过主题域来组织其余的模型层次。面向主题域的(每一次)迭代将组织起进一步模型增量开发的范围和优先级。主题域模型只有在企业所有利益相关者全部(或大部分)接受的时候才是“正确”的,并且当其组织构造对数据治理、数据管理制度及进--步企业数据建模等工作有建设性的实用的益处时,才是“有用”的。

　　主题域一般与中心业务实体用同样的名称。对那些用来管理核心业务实体信息的高层业务功能,主题域必须与之密切匹配。其他的主题域则围绕解决中心业务实体的超类及其子类的问题。每个主题域的命名都应该简洁明了并且具备一个简要的定义。

　　主题域是数据管理制度和数据治理的重要工具。它定义基于主题域的数据管理制度团队的责任范围。

　　3）概念数据模型

　　企业数据模型往下一个层级是一系列针对每个主题域的概念数据模型图表。概念数据模型定义业务实体及这些业务实体之间的关系。

　　在概念数据模型中,业务实体是主要组成部分。业务实体是企业熟悉并感兴趣的那些事物、人员、地点的概念和类别。业务需要这些实体的数据。业务实体并不用IT语言命名;其命名方式采用业务术语。业务实体的一个例子是实例。应保留关于业务实体实例的数据,并使其易于识别。

　　很多业务实体会出现在若干主题域的范围中。不同主题域范围的边界经常会互相重叠，一些业务实体会被双方都包括进去。对数据治理和数据管理专员的目标来讲,每个业务实体都应由一个主要的主题域决定这个实体的主版本。

　　概念数据模型图并不描述业务实体的数据属性。概念数据模型可能会包括实体之间多对多的业务关系。因为概念数据模型不显示属性,也就不会对数据进行规范化。

　　企业概念数据模型必须包括一个词汇表,此词汇表包括业务定义和与所有业务实体及其关系相关联的其他元数据。其他元数据包括实体同义词,实例样本以及数据安全等级分类等。

　　概念数据模型可以促进人们对业务的理解,以及有利于语义上的一致性。它可以作为框架来指导开发整合的信息系统,这既包括交易处理方面,也包括商务智能的方面。它描绘了企业如何看待信息的方方面面。关于概念数据模型,详见第5章。

　　4）企业逻辑数据模型

　　有些企业数据模型也包括针对每个主题域的逻辑数据模型,在概念数据模型之下,增加了更多细节来反映每个实体的关键数据属性。企业逻辑模型识别每个业务实体实例所需的数据。这种企业数据模型中包括的关键数据属性代表了通用的数据需求以及被那些广泛共享的数据属性的标准定义。关键的数据属性是指那些倘若缺失则导致企业无法正常运作的属性。判定企业数据模型中需包括哪些数据属性通常是非常主观的决策。

　　企业逻辑数据模型图继续反映企业视角。它们是中立的且不依赖于任何特定的需求、用途和应用背景。特别地，一些传统“解决方案”的逻辑数据模型则反映特有的用法和应用需求。

　　企业逻辑数据模型只含部分属性。没有任何企业逻辑数据模型可以定义所有可能存在的数据实体和数据属性。企业逻辑数据模型可能在某种程度上规范化,但其所需的规范化程度不如“解决方案”级别的逻辑数据模型。

　　企业逻辑数据模型应该包括所有业务定义的词汇表,和其他相关联业务实体及其数据属性(包括数据属性域)的元数据。关于逻辑数据建模,详见第5章。

　　5)其他企业数据模型组件

　　企业数据模型也包括一些其他组件。这些可选的组件可能包括:

　　　　• 各个数据管理专员负责的工作如主题域、实体、属性和参考数据值集合等。第3章更加深入地涵盖了这方面的话题。

　　　　• 有效的参考数值:代码和标签及其业务含义的受控值集合。这些企业范围的值集不时在各个部门、单位和区域之间交叉引用。第8章更加深入地涵盖了这方面的话题。

　　　　• 对关键数据属性的数据质量要求和规范,如准确/精确性要求,实时性要求、完整性规则、是否可为空,格式、匹配/合并规则,审计要求等。第12章更加深人地涵盖了这方面的话题。

　　　　• 实体生命周期是描绘那些最重要的实体在不同生命周期的状态,以及从一个状态改变到另一状态触发事件的一个状态迁移图。实体生命周期对确定业务实体各状态的合理值集(编码或标签)非常有用。4.2.2节第5部分展开了这个话题的讨论。

2.2.3 分析并与其他业务模型匹配

　　信息价值链分析映射出企业模型元素和其他业务模型的关系。这个术语来自业务价值链的概念,并被Michael Porter 在若干关于业务战略的书籍和文章中所介绍。业务价值链定义组织中那些直接或间接贡献于组织最高目标的职能,如商业利润、教育等,并将有直接贡献的那些职能,依其依赖关系和事件发生的顺序从左到右排列在图表中,间接的支撑职能则出现在这个排列之下。图4.4反映了一个保险公司的业务价值链。

　　信息价值链矩阵是个复合模型。信息价值链分析是数据架构的输出,其每个矩阵是某一业务流程、组织或应用架构的一部分。在此意义上,价值链分析是将企业架构中不同类型的“原始模型”黏合在一起的黏合剂。数据架构师﹑数据管理专员,其他企业架构师和领域专家对矩阵的内容共同负有责任。

2.2.4 定义和维护数据技术架构

　　数据技术架构指导数据相关的技术选择和整合。数据技术架构既是企业整体技术架构的一部分,也是其数据架构的一部分。数据技术架构定义了标准的工具分类、每类中的首选工具、技术标准以及技术整合协议等。

　　技术架构中的技术分类包括:

　　　　• 数据库管理系统(DBMS)。

　　　　• 数据库管理的工具。

　　　　• 数据建模和模型管理工具。

　　　　• 报告和分析用的商务智能软件。

　　　　• 数据抽取、转换和加载(ETL)、变更数据捕获(CDC)和其他数据整合工具。

　　　　• 数据质量分析和清洗工具。

　　　　• 元数据管理软件,包括元数据存储库。

　　技术架构组件包括如下一些不同类别的内容:·

　　　　• 当前——-当前支持和使用的产品。

　　　　• 部署阶段——今后1～2年内会开发使用的产品。

　　　　• 战略阶段—2年以后期望会使用的产品。

　　　　• 退役——组织今年已退役或打算退役的产品。

　　　　• 首选——被大多数应用场景首选使用的产品。

　　　　• 限制—-被特定应用场景所限制使用的产品。

　　　　• 新兴——正被研究和试用,可能用于未来开发的产品。

　　详见第6章。

2.2.5 定义和维护数据整合架构

　　数据整合架构定义了数据如何在各系统中从头到尾流转。数据整合架构既是数据架构,也是应用架构,因为它包括了控制数据流入流出的系统及数据库两部分。数据血缘关系(Data Lineage)和数据流(Data Flows)两个名称也用于描述这个概念。

　　每个模型元素之间的关系,如同元素自身之间的关系一样重要。一系列的二维矩阵可以绘制和记录不同类型的企业模型元素之间的关系。除流程之外,矩阵还可以定义企业架构中的其他方面,如:

　　　　• 业务角色相关的数据,描述哪些角色在哪些业务实体上负责创建、更新、删除和使用数据(CRUD)。

　　　　• 关于这些职责的特定业务组织数据。

　　　　• 关于跨业务职能的应用数据。

　　　　• 关于存在区域差异的不同区域数据。

　　建立矩阵是存在已久的企业建模方法。IBM 在其业务系统规划(BSP)办法中首先引人了这个方法。James Martin随后在其信息系统规划(ISP)办法中将其普及。这个方法在今天仍有效并被广泛使用。

　　企业信息工厂(CIF)概念是数据整合架构的一个例子。一般来说,数据整合架构划分为支持商务智能的数据仓库、临时数据库(staging database)、数据集市以及支持交易处理和操作型报表的源数据库、操作型数据存储(ODS)、主数据管理和参考数据/编码管理。第8章涵盖了与数据整合架构相关的内容。

　　数据/流程关系矩阵可以有不同的细节层次。主题域、业务实体,甚至关键数据属性都可以在不同层次上表达数据。高层的职能、中层的活动或低层的任务都代表了业务流程。

2.2.6 定义和维护数据仓库/商务智能架构

　　数据仓库架构关注于数据的变化和快照如何在数据仓库系统中存储以达到最大可用性和最高性能。数据整合架构显示了数据如何从源系统通过临时数据库进入数据仓库和数据集市。商务智能架构定义如何使数据用于决策支持,包括商务智能工具的选择和使用。这个话题在第9章中有详细讨论。

2.2.7 定义和维护企业分类方法和命名空间

　　分类方法是用来给话题提供大纲的层级结构。最知名的分类方法是最初由植物学家林奈(Linnaeus)发展出来的对所有生命体分类的体系。杜威十进位制系统(Dewey DecimalSystem)是图书馆中组织和查找图书的分类方法的一个例子。正规的分类是类层次结构;而非正规的主题分类法是话题描述性的,这不一定符合从超类继承的特质。

　　组织机构在组织其对各种话题的集体思考时会发展出其自己的分类方法。在网站上呈现或是查找信息时,分类尤其重要。全面的企业数据架构应包括组织的分类方法。这样的分类使用的术语定义应与企业数据模型以及其他模型和分类系统一致。

2.2.8 定义和维护元数据架构

　　就如数据整合架构定义数据如何在各个应用系统之间流转一样,元数据架构定义元数据的受控流转。它定义元数据如何创建、整合、控制和访问。元数据存储是元数据架构的核心。元数据架构是关于元数据如何在各软件工具,数据存储、目录、术语和数据辞典中的整合设计。数据整合架构关注如何确保参考数据、主数据、商务智能数据的质量,整合和有效使用。元数据架构关注如何确保元数据的质量、整合和有效使用。关于这个话题详见第11章。

三、综述

　　定义和维护数据架构是一项需要数据管理专员和其他领域专家积极参与的、需要数据架构师和其他数据分析师组织和支持的集体工作。数据架构师和分析师必须努力优化数据管理专员们在此项工作上所贡献的具有高价值的工作时间。数据管理经理必须保证适当人员的参与时间。对于数据架构及定义架构所做出的努力是需要业务关注的,获取这种关注的保证往往需要进行持续不断的沟通。

　　数据架构永远不会处于完成或静止状态,它是“活的”东西。业务变化自然驱动数据架构的改变。数据架构的维护需要数据管理专员的定期修订。参考现有的数据架构以及对数据架构进行相对简单的更新,可以快速解决很多问题。解决更重大问题则通常需要对新项目提出建议,进行评估、批准和执行。这些项目的产出就包括对数据架构的更新。

　　在数据管理专员参与、评审和细化数据架构,最终获得管理层批准以数据架构作为系统实施的指导之前,数据架构的价值是有限的。数据治理委员会是企业数据架构的最终赞助人和批准机构。同时,许多组织会成立企业架构委员会来协调数据、流程、业务、系统和技术架构之间的关系。

　　数据架构只是整个企业架构中的一部分。数据架构为数据整合提供指导。如下情况可参考数据架构。

　　　　• 定义和评估新信息系统项目——企业数据架构对长期信息系统集成来说起到分区规划的作用。企业数据架构影响项目的目标,并影响项目在项目组合中的优先级。企业数据架构也影响项目的范围边界和系统(版本)的发布。

　　　　• 定义项目的数据需求——企业数据架构提供个别项目的企业数据需求,加速这些需求的识别和定义过程。

　　　　• 评估项目的数据设计——设计评审确保了概念、逻辑和物理数据模型一致,并对企业数据架构的长期实施有所贡献。

3.1 指导原则

　　把数据架构管理职能融入一个组织要遵循以下8个指导原则:

　　　　(1）数据架构是一系列规范构件(主蓝图)的整合,用于定义数据需求,指导数据整合、控制数据资产,使数据投资与业务战略相一致。

　　　　(2)企业数据架构,与流程架构、业务架构、系统架构和技术架构一起,是整个企业架构的一部分。

　　　　(3）企业数据架构包括3个主要的规范,即企业数据模型,信息价值链分析和数据交付架构。

　　　　(4)企业数据架构不仅仅涉及数据,它还采用通用的业务术语来帮助建立企业内的语义。

　　　　(5）企业数据模型是整合的面向主题的数据模型,定义了跨越整个组织的关键数据。按照层级关系来建立一个企业数据模型:包括主题域总览,实体的概念视图,每个主题域之间的关系,以及更细节的,相同主题域的属性级别视图。

　　　　(6）信息价值链分析定义数据、流程、角色、机构以及其他企业元素之间的关键关系。

　　　　(7）数据交付架构定义数据如何在数据库和应用之间流转的主蓝图。它保障数据质量和完善性,以支持事务的业务处理和商务智能报告分析。

　　　　(8）如 TOGAF 和Zachman之类的架构框架在组织关于架构的集体思考上有很大帮助。这可以让不同目标和视角的人群共同工作并达成对共同利益的诉求。

3.2 过程总结

　　数据架构管理职能流程的过程总结如表4.1所示。表中列举了数据架构管理的每一项交付物、负责角色、批准角色和贡献角色。此表也在附录A.9中体现。

3.3 组织和文化问题

　　Q1:企业数据架构的实施有哪些不同的做法流派?

　　在企业数据架构的实施过程中，一个组织可以有很多不同的流派和做法进行选择。首先,组织中每个人都必须认识到整体数据架构的价值。在实施过程中一定会发现一些冗余的系统和流程,继而需要对机构团队和个人的角色、责任进行调整。因此,要注意消除员工对裁员的恐惧。工作在冗余系统上的人员可以到其他系统中从事更有意思的工作。其次，当业务需要或技术背景变更时,组织中的每个人都必须承诺确保数据架构会及时得到更新。

　　企业数据架构的实施,根据不同的企业文化,可以有多种做法。以应用为中心的IT部门必须要把自身的文化变为更有数据意识,并更加注意应用之间的数据流转,而不是仅仅关心每个应用本身的功能。数据意识是让IT部门变得更能洞悉业务需求和实践的手段之一,以使IT部门可以成为业务伙伴,而非仅仅提供服务。

文末说明：参考书籍来自《DAMA数据管理知识体系指南》