数据架构与数据治理的一体化实践
国内企业全面开展数据治理有好几年了，已经走到数据资产化和要素化的层面。然而我深切感受到数据治来治去，最后都是数据架构问题，比如有企业在八年前声称在做主数据治理，请了知名大厂，最近风闻又要重新做主数据治理。同时我发现国内很多企业数据架构管理工作基本处于荒废状态，甚至没有架构部门。我认为有必要写点文字，论一论，分享一下我们的见解和实践，欢迎指正的同时，希望对您有帮助。
01
数据架构的理论与目标
数据治理中的数据架构
随着数据在企业中发挥越来越重要的作用，数据治理成为企业在这个时代必备的管理活动，在企业的组织和制度中获得了认可和资源分配，这非常重要。
在DAMA2的车轮图中，数据架构是12点钟方向的初始管理活动，是数据治理的基础框架，扮演着至关重要的角色，它定义了数据的组织结构、流程、存储和使用方式。在数据治理中，数据架构的设计和管理是确保数据质量、安全性和合规性的关键因素。以下是数据治理中数据架构的重要作用：
数据一致性和标准化：数据架构定义了数据的标准和结构，确保数据在组织中的使用方式一致，并且符合标准化的数据格式和定义，从而提高数据一致性和可理解性；
数据流程与集成管理：设计和管理数据流程和数据管道，包括数据库、数据仓库、数据湖等，确保数据能够在不同系统和组件之间流动和集成，保证数据的完整性和及时性；
数据标准与元数据管理：制定数据标准和规范，管理和维护数据的元数据信息，包括数据结构、字段定义、数据类型等；
数据治理框架：数据架构为数据治理提供了基础和支持，通过制定数据治理框架和流程，确保数据管理和使用符合法规和组织标准，从而提高数据管理的透明度和合规性。
综上，数据架构是组织数据管理的核心，它提供了数据管理和使用的基础框架，确保数据能够安全、高效和可靠地支持组织的业务需求。数据架构的设计和管理需要综合考虑技术、业务和法规等多个方面的需求，以实现数据管理的最佳实践和业务目标。
企业架构中的数据架构
企业架构（Enterprise Architecture，EA）是指对企业整体架构进行规划、设计和管理的一种方法和框架。它包括了企业的业务架构、信息架构、技术架构和应用架构等各个方面的内容，旨在确保企业的各项业务活动、信息系统和技术基础设施能够有效地协同工作，以支持企业的战略目标和业务需求。
信息架构，在理论的术语中，信息是等价于数据的，所以也称为数据架构（IA等价于DA）。EA是个专属的管理领域，经过了数十年的发展，在业界也有成熟的方法论，可以参考学术界的Togaf，Zakaman框架。以下是企业架构中数据架构的主要方面：
企业级数据模型管理：数据架构设计了企业级概念，逻辑和物理数据模型，定义了数据实体、属性和关系，用来指导企业的信息化建设；
数据分布与集成：数据架构规划了数据分布与共享，以及集成方式，包括数据的抽取、转换和加载过程，确保数据能够在不同系统和组件之间流动和集成；
数据存储与管理：数据架构设计了数据的存储结构和管理方式，包括数据库、数据仓库、数据湖等，以及数据的分区、索引和备份策略；
数据质量与治理：数据架构定义了数据质量标准和监控机制，通过数据质量规则和指标对数据进行评估和监控，确保数据的准确性、完整性和一致性。
数据架构的设计和管理需要与企业架构的其它方面相互配合和协调，以支持企业的整体发展和运营。
数据架构的工作目标
虽然数据治理和企业架构分别用不同术语和要求描述数据架构工作，那么我们总结一下数据架构工作目标：
数据架构体系建设：主要包括数据领域目标、能力、原则、标准规范等，用来指导数据架构规划，支持架构决策；
数据架构资产建设：主要是面向业务的数据逻辑架构的主题，对象，属性的定义，以及与项目联动的端到端的数据架构资产和管理；
端到端的架构管理：主要对一些涉及领域范围内的应用和数据进行架构设计，如数据应用设计主要通过数据架构视图，从功能方面整体上规划布局数据类应用及数据集成关系；数据分布方案主要是通过数据分类和分层部署等内容，对数据进行合理布局，支持实施；
数据架构遵从分析：主要是对项目开展架构遵从分析，包括数据对象完整性，一致性，业务责任的数据同源。
02
数据架构在国内的探索
建设银行数据架构管理实践
建设银行师从IBM的FSDM企业级数据模型，构建了ABCD四层数据模型管理。通过制定架构管理原则，管理从ABC到D的过程，将数据架构管理落地到具体的应用或者项目。
该数据架构管理方法，兼顾了信息化规划治理和数据治理的两方面工作需要。这是到目前为止，我们能看到的比较全面的数据架构管理实践案例。
《建设银行数据模型管理》
华为数据架构管理实践
华为通过对数据架构制品制定标准的五级分层，定义了数据标准，数据模型，数据分布和资产目录等架构制品，在一个超大的非数字原生的组织中，实现了数据架构的框架统一。这个实践是基于企业阶段和组织特点，制定了一个面向数据治理的，上下结合的架构管理方法，这给了我们非常有意义的启发。详细可阅读《华为数据之道》。
《华为企业级信息架构的四个组件》
数据架构实践中的总结
建设银行与华为的数据架构看起来非常迥异，然而究其根源竟是同源，这个就不细说了。根据我的理解，对两家的架构做了打穿，大家可以看到本质仍然是一种东西，实践的规范做了客制化而已。
《华为与建行的架构对齐》
上述两个案例是比较典型的案例，分别在金融业和非金融业有广泛的追随者，当然也有不少师从经典EA方法论，基于OpenGroup，ARIS的框架来实践的。
根据我了解的情况，企业在实践中面临不少问题，主要是表现在下列几个方面：
方法论陷阱
方法论陷阱是指在采用某种方法论或方法框架时可能出现的一些常见问题或挑战，这些问题可能会影响到方法论的有效性和实施效果。在数据架构的实践中，我们经常面对的问题是方法论的过度理论化，完美理论与简陋现实之间的矛盾非常突出。在我们的组织中，懂这些理论的少，懂如何实践的更是少之又少，这些就带来组织和人文的阻碍，导致落地难。另一个矛盾是成本和可持续的矛盾，数据架构是个系统工程，没有一个可持续的制度框架支持，就想获得架构管理的效果，导致架构管理空中楼阁，不能起到应有效果，很可能成为一个不可持续的短期项目。
上下两张皮
上下两张皮也是非常典型的架构管理遇到的问题。架构管理本身具有上层规划与底层实现的天然矛盾，两者无法衔接，直接造成规划无法指导项目，项目无法反馈规划，久而久之，会形成架构失控局面。
形似神不似
形似神不似，就是得到一些类似的架构制品成果，但是并没有像学习对象企业那样，发挥出应有的作用。这个也是非常普遍的。据我了解，业界做了类似华为五级架构和C模型的企业非常多，还有很多企业专门成立项目组，直接做这个成果，这有点像应试教育，直奔目标，跳过过程。其实架构管理，重要的是管理过程，结果反而是个副产品，我们需要做到短期和长期的平衡。
上面这几个是比较典型的问题，虽然架构管理是个好东西，但在实践中又会有抓不住具体工作，输不出具体价值的尴尬。究其根本原因，有以下几点：
IT治理中，架构管理偏科，这个也是过去企业快速发展中，忽视了架构管理，甚至没有架构组织，造成了众多主数据问题，烟囱林立的问题；
敏捷开发过于敏捷，按道理这个锅不应该给敏捷，但是从执行过程看，只能被动背锅；
缺乏全局视角的人才，按照先鸡先蛋理论，没有架构组织，自然没有架构人才。先有事，才有人，是这个道理；
缺乏有效手段和工具，在一个组织中推广一个管理工作，无论理论多复杂，都需要简化为几个简单动作。走群众路线是无往不胜的法宝。
作为国内数据架构和模型的领导者，数语科技（Datablau）有幸参与了建行和华为的实践，并为众多企业实施数据架构与数据治理过程中总结了大量的实践经验，分享给各位探讨。
03
数据架构管理的新实践
数据架构管理的实施方案
基于Datablau的实践，本方案分为两个部分，前两部主要是建设基础模型管控体系，后两部是进行数据架构管理的升级，详情如下：
1. 做好物理数据模型管理
管理好物理模型就是为了管理好架构规划落地和架构反馈，这关系到架构工作的监管职能，这一步看起来和架构没有直接关系，实则是成败关键。
分门别类管理数据模型
根据数据来源类型，通常有自建系统和外购系统，按照重要性分类有核心，重要和一般系统。作为统一的数据模型管理规范，重要和核心系统的数据模型都要纳管。外购或者是套装软件的数据模型，更要重点管理。
建立数据模型管理评审流程
评审流程是模型质量的评价机制，是保障数据模型质量的重要卡点。这里主要提模型规范和评审机制。
模型规范就是数据模型的质量规则，通常数据模型的质量分为基础和高阶两个层面，高阶通常管理业务元数据的录入质量。评估一个模型质量包括正确性，完整性，可读性，一致性等基本维度，具体可以参考《数据模型记分卡》。
结合CICD，数据模型与执行落库一体
数据模型的持续构建集成是一个很好的可选项，方法将模型管理融入到Devops的流程中。
《D模型管理流程》
2. 做好数据标准落地工作
数据标准是关键业务的数据项集合，代表了企业最重要的数据，也是数据架构的关键业务语义层。落标工作不仅仅是防止出现不一致数据质量问题的关键，其本身也是数据架构对齐工作的一部分。
数据标准是个泛化的概念，通常有关键数据项标准，数量在一千左右；数据字典，数量在数万项；企业级模型，对象数千，属性项在数万。这些产物的质量和数量都不一样，但是都属于同类内容，达到的目标也是一样的。
关于落标，请参考扩展阅读区的Datablau干货文章《基础数据标准落标白皮书》
3. 开展架构制品建设
熟悉EA架构方法论的朋友一定好奇，为什么到这一步才开始正式的架构制品类建设。这个是我们从实践出发，先构建体系后构建内容的思路，让架构管理成为有源之水，有本之木系统化建设思维。这是我们实践过的可行方案，经过了数十家企业验证。
从BA-IA的经典理论构建，是比较典型的自上而下为主，自下而上为辅的方法。这种方式优点是贴合业务，当然缺点也是贴合业务带来的实施门槛和成本。虽然理论正确，但实践效果看，非常依赖人员素质和资源，更大的风险是上述两张皮问题。
我推荐的是IA为主要出发点，以数据标准和字典为基础，设计经过BA验证的重点业务对象。初期只做重点的关键主数据对象，以勾勒其分布为主要目标。
4. 开展架构管控工作
架构制品只是我们做架构管理的尺子，发现架构问题才是我们的目标。虽然架构管理有很多宏大的目标，然而今天实际的企业组织之下，这些工作已经部分的分解。比如管理标准和质量的有数据管理部门，管理集成的有数据仓库部门。那么我们架构部门就重点管好主要数据对象的数据分布问题，流向问题，不一致问题和权威源头问题等，做到宏观规划，微观验证的架构管理闭环。
数据架构师需要下沉到具体的项目中，与领域架构师，系统架构师一道，走到业务中去。具体的流程与第一步的D模型管理流程一致，与标准审核流程一致。这条流程是企业管理数据的黄金水道，以后安全分类分级，确权认责等等都会汇入这个流程，非常非常重要。
组织与制度建设
前文说到了如何做事，那么建设组织，安排合适的岗位就有的放矢了。无论企业级的架构部门是位于IT部门还是数据部门，都需要与数据治理部门，IT管理部门，运维中心（DBA）结成同盟军，因为大家的管理工作会共用一个流程，互相成就。
相关制度需要发布《数据模型管理规范》《数据模型管理细则》《企业数据标准或模型》等文件，重在落地和执行，规范可以逐年迭代。
《架构与治理组织建设》
结语
本文介绍了一个轻量，可分期迭代，基于分工协作，端到端的数据架构管理方案，同时不同行业的人员配置和行业基础不同，都可以根据这个方案做适度裁剪。限于篇幅，有些细节无法阐述，但只要理解其思路，适当变通，都会有帮助的。
Datablau的产品矩阵和解决方案，为以上方案提供支撑，经过多个案例验证，并取得了显著的效果，希望对您有借鉴意义。
End