企业架构规划-数据架构是否应该独立存在？

大家好，我是人月聊it。

最近关于企业架构方面的讨论，在我加入的几个数字化群里面讨论的相当的激烈。里面就谈到了一个关键的话题，就是对于数据架构是否应该单独存在。

首先我表明一下一个关键的观点，就是对于不管是你去做整体的企业架构规划设计，还是单独的一个独立的业务系统的架构设计，对于数据架构或者是相关的输出物，它一定是单独存在的。

所以这个时候讨论的焦点反而是在对于做数据架构工作是不是应该是独立的，类似于数据组这么一个小组来做，这个才是讨论的关键。

我在前面也专门解读过付晓岩老师出的《聚合架构-面向数字生态的构件化企业架构》这本书，在这本书里面实际是将数据架构的工作融入到了业务架构和IT架构中。业务架构中有业务对象的分析，IT架构中有传统的数据实体识别和数据逻辑模型设计。

如果拿单独的一个it系统的架构设计来看，往往架构师他一个人就需要去完成基于用例驱动的4+1的软件架构设计，包括独立的数据库设计，这两个工作往往是一个人来做的。

所以说在单个系统的软件架构设计里面，数据架构这个工作不会拆分，往往是掌握在一个人手里面，你去做了应用架构设计，去出了相关的逻辑模型以后，你自然而然会考虑到底层的数据库设计。因为只有掌握在一个人手里面，才能够更加准确的回答当前的数据模型能否支撑上层业务。

但是一定要注意，传统单个系统的架构设计，里面的数据架构工作只会涉及到底层数据库设计，面向的是OLTP应用。而对于面向数据分析层面的OLAP数据架构设计并不会做。单个系统本身你也没必要做这个事情，OLAP一定是站在整个企业IT视角来考虑的全量数据视图。

所以传统的单个IT层面的架构设计思想是否适合企业层面的企业架构设计，这里要打问号。大家所站的视角本身就不一样。你在做顶层企业架构规划设计的时候如果受传统IT软件架构设计思想约束，反而缺失了很多顶层全局思考。但是你完全不考虑IT应用层面的一些方法，又导致后续难以指导后续落地。

企业架构规划设计往往要做好两者的平衡。

所以再回来就谈到一个关键点，那么我去做一个大的信息化数字化的规划咨询项目，我按照企业架构的4A架构的思想，对于数据架构的工作它究竟是不是应该独立的一个数据组来做？

在这里我先谈一下我们原来真实的一些做法，像在类似于7，8年前我们接的一个关于轨道交通的整个大的企业架构规划设计，我们整个差不多投入了接近20个人做这个工作。在做这个咨询项目的时候里面，对于做数据架构工作确确实实就是有一个独立的数据组来做这个事情。

那数据架构工作它实际对应的输入是什么呢？

也就是我们前面去做端到端流程梳理和业务架构的时候，当你梳理到5~7级流程的时候，不管是不是叫业务建模，你梳理到末端流程的时候，他一定会搞清楚该流程对应的业务活动业务规则，每一个业务活动的输入输出，这个输入输出就可以识别出来关键的业务对象或者叫业务表单。

这个业务对象的识别，关键对象属性或业务表单数据项是业务架构组要完成的事情。但是业务架构组不会从数据视角单独对这些业务对象抽象并进行相应的数据建模。业务架构的完整输出加上业务对象的识别清单是作为数据组的关键输入。

有了这个输入以后，数据组会继续进行相关的数据架构的工作，包括底层我们经常会说到的识别关键的数据实体，进行概念模型、逻辑模型和物理模型的设计。包括面向OLAP分析型应用的数据架构分层规划设计，数据采集集成设计等，主数据识别和详细定义等。

这个确确实实是独立的一个数据组在做这个事情。

基于我们历史项目的一些时间，如果是独立的数据组在做这个事，带来的一个关键的问题就是什么呢？

也就是应用架构设计组和数据组拆分为了两个组，分别输出架构规划要求的应用架构视图和数据架构视图两个独立的产出物。但是对于数据组输出的数据架构和数据模型，包括后续的数据逻辑模型设计，这些能不能能不能支撑上层的应用架构和功能设计，这个事情反而到了后面没有人去回答了。

因为我企业架构的输出就是一堆的架构视图，包括架构规范标准类文档。你也没有到实际马上去构建应用系统去验证。所以说即使没有匹配，大家也不会太关心，也没有去验证这个事情。

但是实际你到了真正的it系统应用建设的时候，你才会发现你原来输出的相关的数据模型，它很难支撑你上层应用架构构建。特别是我详细的去考虑这个业务本身的基本流，扩展流和业务规则的时候。会带来两个关键关键。

1. 数据库表为了满足业务规则在基础字段上扩展出大量字段
2. 数据库会为了扩展性或冗余等目标做出表级的抽象，扩展，合并

这些表级扩展或字段级扩展。在企业架构规划中，单独的数据组去做相关的数据模型，往往不可能考虑相当全。原因就是数据组成员很难完全精通和熟悉业务，另外就是我们做业务架构梳理往往有些颗粒度太粗，并不会做到底层的类似EPC详细的事件链流程图，包括详细业务规则的识别和定义。

所以这个就导致了数据组最终输出的数据架构跟应用架构之间它看起来是匹配的，但是实际的底层数据模型是没有办法完完整整支撑上层应用构建的。包括这些企业架构到了后面，他去指导信息化的it系统建设的时候，我们也发现这个情况。因为很多时候我们输出的这些企业架构规划实施规划，对于甲方客户他会拿这里面的内容去做相关的业务系统的招投标建设。

实际在招标建设进来的相关的it开发厂商的时候，他去参考你原来的企业架构规划的时候，相关的业务架构相关的应用架构规划，相关的核心的功能模块，它基本上都能够做到匹配。但是你原来的输出的数据模型，它要完完全全照搬拿过去用，那是绝对不可能的。所以说它底层的数据模型数据库设计，它往往仅仅是参考到最多你有哪些关键的数据实体数据对象，详细的数据库设计还是应用厂商自己会去重新做掉，这个其实就导致我做企业架构规划的时候，当时输出的数据架构至少在指导面向OLTP应用建设的时候的价值是不大的，说得不好听点就是没啥大用。

再回过头来为什么又要有独立的数据组来做相关的数据架构规划？

这个也是我在谈企业架构一直强调的，企业架构里面的数据架构一定包括两个层面的内容，一个是面向OLTP应用系统建设的底层的数据模型，架构设计和规划。还有一个就是面向OLAP的关于数据分析型的这么一个底层的数据架构规和设计。

整个数据架构规划底层模型输出不仅仅是为了支撑上层应用架构规划设计，更加重要的是如何更好的支持面向分析性应用的类似传统数仓的数据分层建模数据架构规划。除了最底层的贴源层数据模型外，我还要去考虑上面的宽表层，再上面的数据分析层类似维度表的设计。就这些东西它一定是独立的完整的一套东西。

同时做数据架构规划你还得考虑传统主数据，跨系统共享动态数据的数据设计，数据采集集成，数据共享，数据分布等内容。还需要考虑数据治理体系建设等。这些往往都需要独立数据组来完成。

这个东西你一般的去做应用系统规划建设的人也没办法做这个事情。所以这个也是为什么要拆分出独立的数据组的一个关键原因，数据组做数据架构这个事情更多的重心它不是在去做单个应用系统它本身的底层的数据模型，更多的是把整个企业所有的IT变成看成一个大系统，从一个更加高层全局的视角来考虑企业数据工作如何做，如何做好数据驱动，数据如何带来价值？围绕数据驱动和反哺业务，数据支撑分析和决策两个关键来开展工作，这个才是数据组工作的一个中心。

所以基于我刚才的思路，更加切实的可以落地的一个做法，应该是在企业架构规划设计里面，涉及到单个应用系统的架构规划，这个底层相关的数据模型的这个设计，应该是融入到业务架构和IT架构规划中。而数据组它更多的工作应该放到我刚才谈到的类似于BI，类似于数据中台这种分析型的数据架构的规划和设计上面，这个才是一个真正切实可以落地可以去执行的一个思路。

好了，今天的简单分享就到这里，希望对大家有所启发。