第4章

4.1 简介

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

提供标准的、通用的业务术语/辞典。
表达战略性的数据需求。
为满足如上需求，概述高层次的整合设计。
使企业战略和相关业务架构相一致。

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

数据架构管理职能的关联图：
在这里插入图片描述
企业数据架构是一套规范和文档的集合。它主要包括如下3类规范。

（1）业数据模型：企业数据架构的核心。
（2）信息的价值链分析：使数据与业务流程及其他企业架构的组件相一致。
（3）相关数据交付架构：包括数据库架构、数据整合架构、数据仓库/商务智能架构、文档和内容架构，以及元数据架构。

4.2 概念与活动

4.2.1 架构综述

架构是对构成要素的有组织安排，它优化整个结构或系统的功能、性能、可行性、成本以及美感。

企业架构

数据架构是企业架构中的一部分。企业架构整合了数据、流程、组织、应用和技术架构。帮助组织进行变更管理，提高效率、灵活性，以及明确管理责任。使得组织可以应对不断变化的市场机会、业界挑战和技术进步，帮忙评估业务风险、管理变革、改进业务有效性、敏捷性和可问责性。企业架构包括：

信息架构：业务实体、关系、属性、定义、代码项（参考值）；
流程架构：职能、活动、工作流、事件、周期、产品、步骤；
业务架构：目标、战略、角色、组织结构、场所（场景）；
系统架构：应用、软件组件、接口、项目；
技术架构：网络、硬件、软件平台、标准、协议；
信息价值链分析构件：绘制数据、流程、业务、系统和技术之间的关系；

所有的组织都是基于对业务需要和业务风险的理解来开发和维护企业架构。企业架构是规划、IT治理和组合管理的工具。它可以有效的整合数据、流程、技术和改进措施，使信息系统与业务策略一致，改善跨组织的沟通与理解，更有效的使用和协同资源，降低管理IT基础设施成本，为业务流程改善提供方向。

架构框架

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

分类框架——将指引企业架构的结构和视图组织起来。框架定义构件的标准语法来描述以上视图以及视图之间的关系。构件大多数是图形、表格和矩阵。
流程框架——规定业务和系统规划分析，以及流程的设计方法。有些IT规划和软件开发生命周期（SDLC)包括其自定义的复合分类。不是所有流程框架都规定同一套东西，有些是很专用的。

目前已经存在一些框架，例如：

TOGAF——开放组织架构框架是开放群组（The Open Group）所开发的一套标准流程框架和软件开发生命周期（SDLC）方法。这是一个供应商和技术中立的组织，旨在定义和推广全球互操作性公开标准的合作团体。TOGAF8企业版可被任何机构采用，无论是否为开放组织的会员。
ANSI/IEEE1471-2000——推荐用于软件密集型系统的架构描述，它有望成为
ISO/IEC25961标准，是用来定义解决方案的构件。

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

联邦企业架构（FEA)——由管理和预算办公室产生，供美国政府内部使用。
政府企业架构（GEA)-——立法规定由澳大利亚昆士兰省政府各部门使用。
DODAF——美国国防部架构框架。
MODAF——英国国防部架构框架。
AGATE——法国DGA架构框架。

Zachman 企业架构框架

Zachman企业框架2是最广为人知并被广泛使用的架构框架。尤其是企业数据架构师，自从John Zachman于1987年在IBM的一篇系统刊物文章里首次发表此框架的描述之后，就开始对其采纳和使用。
Zachman 企业架构框架3.0：
在这里插入图片描述
第一个维度以利益相关者进行划分，Zachman从以下视角进行描述：

规划者视角(范围背景)——定义(业务)范围的一系列业务元素，由作为理论家的策略制定者识别。
所有者视角（业务概念)——关于业务元素之间的关系的语义模型，由作为所有者的管理领导人定义。
设计者视角（系统逻辑）——详细描述系统需求和不受约束的设计逻辑模型，由作为架构师的设计者描绘。
建造者视角(技术物理)——作为建造者的工程师，在特定技术、人员、成本和时间限定下，为实现特定应用而对设计进行优化的物理模型。
实施者视角（组件组装)——关于技师作为实施者，如何组装、运作和配置系统组件，利用专有技术的、不受背景约束的视角。
参与者视角（运营等级）——作为参与者的人员使用的实际运作系统的实例。

第二个维度从问题的不同方面来回答问题：

用什么做（数据列）——建造系统所用的材料（库存项Inventory Sets)。
如何做（功能列）——履行的活动（流程转换）。
何地做（网络列）——地点，拓扑和技术（网络节点）。
何人做（人员列）—角色和组织（组织中的团队）。
何时做（时间列）——事件、周期和日程（时间阶段）。
为何做（目标列）——目标、策略、出发点（动机原因）。

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

Zachman框架和企业数据架构

企业数据架构是更大的企业架构中的重要组成部分，企业架构包括流程、业务、系统和技术架构。数据架构师关注企业数据架构，并和其他企业架构师一起工作，将数据架构整合进更广义的企业架构。
企业数据架构一般包括3套主要设计组件：

（1）企业数据模型，识别主题域、业务实体、控制实体元素之间关系的业务规则，以及若干重要的业务数据属性。
（2）信息价值链分析，使数据模型组件(主题域和/或业务实体)与业务流程及其他企业架构组件相一致；这些组件可能包括组织、角色、应用、目标、战略、项目和技术平台。
（3）相关的数据交付架构，包括数据技术架构、数据整合架构、数据仓库/商务智能架构、企业对内容管理的分类方法，以及元数据架构。

第一个“数据”列中的单元——现在称为Inventory sets，代表常见的数据建模和设计构件

规划者视角（范围背景)——一系列主题域和业务实体。
所有者视角（业务概念）——表达实体间的关系的概念性数据模型。
设计者视角（系统逻辑）——具有全部属性的规范化（范式化)逻辑数据模型。
建造者视角（技术物理)-—在既定技术限制下优化的物理模型。
实施者视角（组件组装)——数据结构的具体实现，通常是SQL中的数据定义语言（DDL)。
运作的企业——实际实施的实例。

4.2.2 活动

理解企业信息需求

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

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

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

开发和维护企业数据模型

业务实体是业务实体是企业真实的事物、人员、地点的概念和类别（分类）。数据是一系列采集的关于业务实体的事实。数据模型定义的是业务实体以及其应用所需的事实（数据属性）。因此，数据模型是定义和分析数据需求，设计满足这些数据的逻辑和物理数据结构，是规范和相关图表。

企业数据模型EDM是企业范围内的整合的、面向主题的数据模型，用来定义关键的数据生产者和消费者。

整合的：组织中所有数据和规则都被描述一次并无缝配合，是一个整体。不管组织内如何划分业务和职能，就数据来说只有一个版本，一个唯一的名字、定义，并规定同一个词在不同业务实体下的不同含义。
面向主题：数据模型可以分解为跨多个业务流程和应用系统的共识主题域，主题域关注的是业务实体。
关键的：企业的数据模型不能定义组织内的全部数据，应该关注关键的数据需求。这些需求可能是共享的，也可能只是单个系统生产和使用。但不管现在如何，随着时间的推移，企业的重要数据也会发生变化。关键数据的范畴会随着企业的变化而变化，应保持同步。

企业数据模型可以是自建，也可以外购。不同的企业数据模型在细节上差异较大，但成功的企业数据模型经常是通过递增和迭代开发出来的。分层次建造：
在这里插入图片描述