11、信息架构方法篇：破译通往数字世界的罗塞塔石碑

原本最近没有计划总结架构工作。相比于当下热门的人工智能、机器学习、微服务、迭代开发，架构几乎成了冷门工作。甚至更有思想超前的先进分子，在开始琢磨架构工作是不是可以由人工智能来取而代之。 

直到上篇文章后，有位曾经一起共事的前同事留言，“ 确实，让IT人员具备数据架构意识和方法，是大多数没有人力没有财力的企业唯一可行的一条路，虽然很难，至少在主数据和关键业务数据上还是可以拉通的。" 

对于各方条件均具备的企业，当然可以尽早启动数据管理体系建设。但对于大多数企业及其IT员工，退而求其次，开始引入数据管理方法，并应用到实际工作中。静水潜流，逐步提升数据质量，也不失为一种合适的选择。 

题记：破译通往数字世界的罗塞塔石碑 

熟悉埃及历史文化的朋友肯定知道著名的罗塞塔石碑。在罗塞塔石碑被破译之前，古老的埃及文明在后人的眼里，完全是一个谜。因为没有人能够读懂古埃及遗留下来的文字。

直到1799年，拿破仑远征埃及，发现了这块石碑，由于石碑是在罗塞塔郊外出土的，因此根据发现地点而命名为罗塞塔石碑。直至1821年，法国人商博良经过了21年的不断努力，解开埃及象形文字之谜，从此也打开了通往远古、神秘的古埃及文明的入口。

在架构师这个圈子里，我算不上是最牛的，甚至连号排不上。架构领域常用的那些术语，“模式”、“原则”、“分层”不是本篇讨论的主题。虽然我也经常跟大家讨论架构设计，但我一直致力于如何让曾经被业务嘲讽为“鸡爪图”的数据模型转变为业务能够理解的语言。  

01

为什么叫信息架构而不是数据架构？ 

2006年初，我荣幸而纠结的加入公司信息工程部。我所在的二级部门负责IT规划。IT-PC部，即IT  Plan & Control部，私下自嘲为 Copy & Paste部。没错，那时候还不是流程IT部。

流程管理部是与之并列的另一个一级部门，其下设立了一个名叫BIE的部门，同样也负责IT需求与规划。BIE是Business Informatioin Excellence的英文缩写。如果仿照Operational Excellence的中文翻译“卓越运营”的话，勉强可以翻译为“卓越业务信息（部）”，还不如保持英文缩写来得直接一些。 

没多久，2006年底我们负责应用规划的团队也从原来的IT-PC部门整体合并到了BIE部门。由于两边领导都在圈内，不便多加评价。 

BIE部门以“Business”打头，当然必须强调其独特的业务视角。“数据架构”闻起来似乎有点过于IT的味道，那就叫“信息架构“吧。也就是说，叫“信息架构”还是“数据架构“并没有特别的区别。至于许多关于”数据“和”信息“内涵之争，更多基于“DIKW”模型来讨论的。 

之所以八一下这段历史，主要是为了说明，为什么华为的数据管理工作从业务开始。或许有其内在的必然性，也有发展的偶然性。 

02

用数据模型说话 

谈信息架构，为什么要谈数据模型呢？ 

通常来说，企业信息/数据架构要回答的关键问题 

• 企业（应该）有哪些关键的数据资产？ 

• 这些数据资产的定义、业务规则是什么？ 

• 这些数据产生的源头在哪里（哪个业务环节，哪个IT系统）？ 

应该来说，采用数据建模来回答“企业（应该）有哪些关键的数据资产”这一问题是最好的选择。数据建模的成果自然就是数据模型。 

记得当初开始给新加入数据组织的同事提供了一门数据模型入门培训课程：用数据模型说话。 

（图片来自网络，侵删）

引用了建筑行业的例子来解释什么是模型，相信大家都有所了解。软件工程中的做法，许多都是从建筑行业的“舶来品”。

有了与民生息息相关的房子作比喻，大家理解数据模型是什么东东应该并不难，我曾经一直这么以为的。但从来没有事后找听众问问，究竟是否理解了。 

只是，在我接下来应用数据建模的方式参加的第一个大型变革项目中，列出了关键逻辑数据（超过40个）。当我展示在项目组的业务代表们前面时，大家都傻眼了。完全没有人能理解我要表达什么意思。 

为了让项目组能够理解数据人员输出的成果，将数据模型的形式上做适当的变化，可以取得一定的效果。 

“I am an Orphan（孤儿）!”

这是IFS数据组顾问Carl有一天对我说的一句话。当然不是因为他不会说中文，因为数据组其他同事也有类似感受，只是程度不同而已。十几年过去了，我依然记忆深刻。

Carl那时候看起来三十来岁，光头，大肚皮，典型的美国大叔形象。Carl在项目组的角色是数据建模工程师。他跟IBM的其他业务、IT顾问没有太多的交流，而我是刚刚被部门拉过来“救火的” ，没有太多的时间跟他讨论模型设计方面的技术细节。 

记得，项目组第二天要跟项目群经理汇报数据工作进展，总体的汇报材料还没成型。Carl老人家还在埋头从逻辑数据模型抽取出类型属性，作为单独的逻辑实体，以帮助提供数据质量。数据组长气得无话可说。

数据模型原本就让非专业人士难以接受，如果数据建模工程师一味的沉静在自己的专业中，而忽略跟业务的沟通交流，其工作的效果就可想而知。 

后来反思总结，之所以数据建模以及数据模型让业务人员如此难以理解。除了大家对陌生事物的接受度低的原因，也因为并没有把数据建模的完整过程呈现出来。 

在数据/IT专家在开始按照实体关系模型、面向对象模型，或者图模型等专业建模方法开始前，有两个以业务专家为主的建模过程，即分类、提取结构化特征，往往将此排除在建模方法之外，而将此称之为提出业务需求。数据建模变成一个纯粹专业的活动，从而导致业务人员看不懂。 

百度百科： 

数据模型（Data Model）是数据特征的抽象，它从抽象层次上描述了系统的静态特征、动态行为和约束条件，为数据库系统的信息表示与操作提供一个抽象的框架。 

维基百科： 

A data model is an abstract model that organizes elements of data and standardizes how they relate to one another and to the properties of real-world entities. 

我要说，数据模型并不是简单的“数据”的“模型”，而是 通过“数据”表达的客观事物特征的“模型”。 

03

信息架构的定位 

在许多传统的架构理论中，信息架构是IT系统架构的一部分。甚至相比于IT功能架构（也称应用架构），信息架构属于后台数据库结构设计。例如为大家熟知的TOGAF便是如此。

但也有许多理论框架，以及西方企业实践，倡导信息架构与IT架构相对独立性。当然，目的是为了强调信息架构的重要性。每个企业有自己的特点，这一点可以灵活运用，达到目的即可。

和业务/流程架构一样，信息架构是从数据视角描述企业业务视图。 下面列出了历史上某个时期的其中一个版本，供朋友们参考。

04

企业数据模型分层 

数据建模只是一种数据设计方法，本身并不等于架构。这一点存在一定的迷惑性，因为数据建模、架构都需要经过抽象处理过程。 

下面是大家所熟悉的DMBOK中介绍的企业模型分层框架：

下面是华为当初从18M公司引入的企业数据模型分层框架：

坦白来说，在企业数据模型分层方法方面，各种国际组织或者企业并没有什么本质差异。 

我认为，无论是架构分层，还是数据模型分层，其核心的目的是与架构管控机制相匹配的。换句话说，如果企业没有架构团队，也没有管控机制，为了分层而分层的意义并不大。设计人员带有架构思维，按照概念、逻辑、物理数据模型的设计阶段开展即可。 后续将结合信息架构管控进一步展开介绍。

05

数据资产目录分层 

以数据模型为核心的信息架构无法让业务部门理解和接受，无法跟业务说清楚，数据是什么，要业务管什么等等。 向业务部门推行数据管理责任的进程也大大受阻。

2010年开始，几乎满世界找“业界最佳实践”，包括DOD、NGOSS、DAMA公开组织，也有西方各大企业的方法，期望从中有所启发。

此时，公司企业架构部门也开始引入TOGAF方法论。由于TOGAF中，数据架构作为IT系统架构的一部分，与我们推行的理念并不吻合。但这并不阻碍我们从中吸取可借鉴之处。研究了TOGAF Framework之后，惊奇的发现，数据架构的交付件包括： 

• Data Entity /Data Component  Catalog 

• Data Entity /Business Function Matrix 

• Application /Data Matrix 

• Conceptual Data Diagram 

• Data Dissemination Diagram 

首要的并不是数据模型，而是数据实体清单！

开始意识到，数据实体并不是必须以数据模型的”鸡爪图“的形式，而是可以单独示人。加上自2007年开始，一直倡导“数据是企业的核心资产”，那数据实体清单不就是”数据资产目录“吗？ 

数据资产目录也经历了一个演进的过程，才有了如今在《华为数据之道》一书中介绍的模样。其中主题域、业务对象这两层始终没有变化。

主题域延续了18M提供的简单方法和自身的案例，华为从开始”依葫芦画瓢“到最终自己推行，在下一篇”信息架构实践篇“将展开介绍。

业务对象作为数据管理基本单元，也是跟业务架构衔接的重要载体。同时，我一直认为业务对象无论从命名还是方法论，都是华为数据管理方法中独特创造之一。因此，值得多花些笔墨，将在下一节专门介绍。 

V1：在开始的数据资产目录中，为了彻底的去掉IT技术的影子，业务对象下直接挂数据属性，这也符合业务的理解习惯。

V2：经过一段时间的实践尝试发现，由于有些业务对象的颗粒度太大，一个业务对象下上百个属性非常普遍，业务人员理解起来也有困难。在研究了逻辑数据实体，发现其实质上就是属性分组，只是分组的依据是根据三范式（对于ER模型来说）而已，于是增加了一层：属性组。

V3：接下来，Z领导接管数据管理部之后，Z领导本身有很强的IT背景，提出要求需要考虑跟IT的衔接，于是将属性组改为逻辑数据实体，同时也完全遵从范式建模规则。 

V4：2014年确定的版本，一直沿用至今。

（摘自《华为数据之道》）

经过近十年的实践证明，数据资产目录对于数据管理推向业务，从技术角度来说，功不可没。

但并非完全没有弊病，本质上来说，数据资产目录没有架构分层的思想。因此，对于架构管控来说是不利的。 

只是华为发展到今天，更加强调数据资产管理职能，与架构管控职能有所差异。因此这一弊病所导致的问题在实际运作中并没那么突出。

06

关于业务对象 

但凡了解传统的实体关系（Entity-Relationship）数据建模的朋友都清楚，Entity是最基础的概念。

可惜，无论是Entity，还是翻译成中文”实体“，非数据建模专业人士来说，如同”外语“。记得当初熟悉财务、公司法的同事看完，联想到Legal Entity，但又发现完全无法类比。 

但用什么样的术语替代呢？首先想到的就是”对象“一词。软件工程领域，面向对象分析和设计曾经风靡一时。虽然说并非所有人都一定理解其真实含义，但至少相比而已更加“面熟”。 

将”对象“取代”实体“，那是应该叫”数据对象“、“业务数据对象”吗？

尝试搜索“度娘”，还算有点意外的惊喜（虽然以前从来不用度娘搜数据专业知识）： 

企业管理，按照管理对象划分包括：人力资源、项目、资金、技术、市场、信息、设备与工艺、作业与流程、文化制度与机制、经营环境等。 

“业务对象”，用白话可以解释为“业务管理的对象”。就这么定了！虽然后来一再受到一些挑战，但不管什么原因，一直坚持下来。 

此时，公司在流程、数据、应用、技术架构方面已经有各自的积累。企业架构经过漫长的酝酿之后也开始见到一些起色。所谓的”4A“集成逐渐提到日程上来。

并进一步提出跟业务/流程架构的集成关系（示意图）： 

后来，部门其他专家接收信息架构工作，进一步制定了业务对象识别原则： 

• 企业运作和管理中不可缺少的重要人、事、物 

• 业务对象有唯一身份标识信息 

• 业务对象相对独立且有属性描述 

• 业务对象可实例化 

• 不要过度抽象处理 

我对其中的第二条并不苟同，业务对象应该有唯一的身份标识信息，但不是作为业务对象的前提条件，而是管理要求。就像我们每个人的身份证号码一样，并非生而有之，而是后天“组织”赋予我们的。 

与此同时，我建议追加一条“不要过度抽象处理”。

数据建模（包括图模型）本身就是一个抽象过程。将你、我、他，都统称为"人“，并非彼此绝对一样，而是具有某些相同的特征而已。

在数据建模中，有一经典的“模式”，就是将组“人”、“组织”（含企业内部组织、客户、供应商、合作伙伴等）都称之为“Party”（参与人），这也是一种抽象。但由于超出了跟”业务“的映射，而失去的意义。 

畅想：关于数字孪生 

随着数字化、人工智能技术的飞速发展，数字孪生（Digital Twin）一词应运而生。

关于数字孪生，在维基百科中如是解释：”A digital twin is the generation or collection of digital data representing  a physical object." 

业务对象概括了企业的“人”、“物”、“事”，在概念上是否可以延续到数字孪生呢？

至少，“人”是智能的；“物”也可以变得智能；“事”不在数字孪生定义的范围，但我认为，发展到一定阶段，赋予“事件”以智能和生命并不是没有可能的。 

最后，在面向数据分析的领域，信息架构如何构建，例如多维数据模型，本篇未展开系统的分析论述。对于图模型方面，本人方法的适应性也缺乏足够的研究。

END

本篇完成于春节期间，在惠东某乡下角落。当我走到民宿阳台，抬头仰望天空，恰好看到了儿时记忆里才有的北斗七星。

数据之于企业，或轻或重；我之于世界，或重或轻？在不断的数据工作实践与内省中找到属于自己的答案。

您的关注，

我分享的动力

---

关于公众号：数据不能承受之重

米兰.昆德拉在《生命不能承受之轻》中灵魂拷问般的写道：最沉重的负担压迫着我们，让我们屈服于它，把我们压在地上。同时，最沉重的负担，也成了最强盛的生命力的影像。负担越重，我们的生命越贴近大地，它就越真切实在。相反，当负担完全缺失，人就会变得比空气还轻，就会飘起来，就会远离大地和地上的生命，人也就只是一个半真的存在，其运动也会变得自由而没有意义。那么，到底选择什么？是重还是轻？