也许其中最难以捉摸的是数据沿袭。一些供应商已经设法创建可以扫描系统和收集元数据的工具，但它们通常无法连接到大多数现有系统环境。由于数据流通常没有在整个企业中进行结构性和一致的记录，因此主要依靠供应商知识和手动映射工作来编译它们。当供应商纷纷离开时，这种知识就会离开企业，情况也会变得更加严重。
此外，即使业务和技术元数据已被记录为协调补救计划的一部分，但由于元数据捕获和记录不是自动化的，大多数元数据很快就会过时。保持其最新需要持续的手动工作。
最后，组织将这些元数据共享到企业的业务部门，以实现除数据治理本身之外的业务目的。许多大型组织都有数据战略，以某种形式阐明数据管理基础也应该为数据科学等业务目的提供支持，但很少有人在实践中成功实现这一点。
基于云的技术的出现带来了可扩展性、弹性、更低的成本、快速部署和增强的数据技术兼容性的承诺。在过去几年中，我们与各种组织就其云迁移和数据现代化计划进行了合作，从设计的那一刻起就出现了如何智能管理数据的模式。
例如，可以为 API 定义互操作标准，以便未来数据沿袭可视化中的日志记录和治理实现自动化。数据质量控制可以基于一致的数据模型创建并直接嵌入到新的基础设施中。转换期间存在的知识不会丢失或降级，因为有关数据元素及其来源的关键信息会轻松记录在数据目录中。
接下来将进一步详细阐述数据治理设计的概念，并解释如何通过数据资产、数据管理中心和 API 驱动架构等功能（通过称为 Data Fabric 的数据层）实现数据治理。
二、框架
在基于服务的架构中，微服务连接组织的业务流程。在这样的架构中，四个基础组件可以共同实现数据管理和数据治理的设计。下面提供了一个示例：描述了一个拥有 5 个部门（风险与合规、财务、营销、客户管理和产品开发）的组织。每个部门创建并维护多个数据产品，其中一部分被归类为“数据资产”，因为其他部门的消费者也使用它们。不同部门之间，各种API交换数据和信息。所有这一切都是根据数据基础结构精心策划的，并由数据管理中心扫描并提供数据管理和服务。让我们快速浏览一下这些组件。
数据资产——每个域或部门通常都会生成供其他域使用的数据或信息。例如，客户管理域可以通过入职和客户关系管理流程收集客户数据，以生成和维护包含客户信息的中央数据库。营销团队可以使用该数据库来执行销售活动，风险部门可以使用该数据库来确认是否遵守数据隐私法规。此类数据产品被赋予了不同的标签，其中包括数据产品、数据资产、可信来源、权威数据源和记录系统。
API 驱动的架构——不同的团队通过 API 作为首选或唯一的数据集成方法进行连接。保持 API 优先的理念可确保组织内部和外部的消费者都可以使用任何关键数据。
数据管理中心——在单独配置的空间或环境中提供一组数据管理功能。这些功能包括元数据管理、主数据和参考数据管理以及数据质量。不必在组织的每个区域内构建这些功能，而是可以从中央数据管理进行部署。
Data Fabric— 提供跨所有系统和应用程序连接的线程称为 Data Fabric。它不是一个可以凭空实例化的魔法层；相反，它由一组支持功能和经过仔细考虑的治理协议组成，这些协议共同使整个企业的数据可发现、编目、分类、标记、质量控制，并可通过通用的互操作性标准和渠道进行访问。
采用数据资产理念管理
什么是数据资产
数据资产是一组准备好的数据（一般不是原始数据），可供更广泛的消费者使用。它受到管理、贴上标签、质量受控且易于访问。它是可发现和描述的，以便为整个企业的消费者启用自助服务。数据资产通常在整个企业中重复使用，并在给定的数据或业务域内拥有。
为什么被高度关注
鉴于数据资产被大量消费者使用，因此这是实施数据质量和治理控制的非常合乎逻辑的位置。在该受管资产中，内容被标记，数据质量受到严格控制，因此不必在整个企业中识别和测量这些数据，这通常会导致不一致的“事实版本”，而是有一个可信的分发点给定的数据集。例如，美国十大银行已经启动了一些计划来识别这些关键数据源并对其进行管理。通常，大约 20 到 100 个数据资产将使组织能够控制其所有关键数据，这比尝试在 1000 个单独系统中定义数据质量要有效得多。
数据资产采用
创建和定义数据资产还不够。一个必要且同样重要的步骤是管理它们的使用，因为如果消费者不使用它们，他们就无法从集中控制的数据质量中受益。因此，许多组织已经启动了各种版本的数据资产采用计划。通常，一方面包括共享流通，加强培育对数据资产及其使用好处的认识，另一方面包括合规标准和机制，要求只能从数据资产而不是任何地方使用别的数据。
业务用户和影响
对于数据组织来说，除了难以衡量的价值（例如避免监管罚款）之外，阐明它们为企业增加的价值一直是一场历史性的斗争。数据资产在这里改变了游戏规则。仅当存在下游关键消耗时，数据源才能成为数据资产，因此建议记录这些消费者及其用例。
构建数据资产和依赖于它们的用例的简单概述可以清楚地阐明这些资产产生的影响。通过收集数据的下游需求并评估如何在受信任的分发点内控制和增强数据，也可以更有效地执行影响评估。例如，一家领先的保险公司能够相对精确地衡量一组增强的客户数据如何使他们能够更轻松地执行和提高销售活动的有效性。
如果没有数据资产的识别和主动管理，结果通常是难以理解的数据流“蜘蛛网”，存在数据重复和不一致的情况。战略性地使用数据资产，可以识别使用独特的可重复使用的精选的数据源用例组。
三、数据资产治理
需要一个治理模型来将数据资产嵌入到 Data Fabric 中，以确保它不会被“坏”数据淹没，其中“数据网格”是如何将此治理嵌入到组织中的主要方法。
数据网格
一个相对较新的术语是“数据网格”，它是一种使业务领域能够在捕获和维护数据的点管理其关键数据的方法，并由中央自助服务数据支持基础设施。这与过去的努力形成鲜明对比，过去的组织试图将其关键数据集中在数据湖和数据仓库中。这种集中化工作通常会受到对中央数据团队的过度期望的困扰，这些团队没有特定于业务的上下文来理解数据，因此无法跟上消费者所需的步伐。“脏”数据湖是一种常见症状。
治理模式
某些业务或功能域可能已准备好立即管理其关键数据资产，但其他域可能还没有。以银行业为例，通常相对成熟的领域包括风险和金融，因为它们在遵守监管数据治理准则方面拥有多年的经验。
允许域所有者生成数据资产供其他人使用有几个要求。首先，支持领域必须在数据管理和工程方面具备最低水平的所需技能和经验。其次，域所有者必须在团队内部或外部拥有所需的资源，或委派部分职责的预算。维护数据资产通常不是一项全职工作，但同时它确实意味着重大责任。
基于这些考虑，企业可以选择适合的治理模式，每种治理模式都有各自的优点和缺点。组织可以先选择一种模式，但随着时间的推移，可以发展到另一种模式。
治理建议
以下建议可以标准化任何模式的实施并降低其风险：
- 将数据资产的概念嵌入到企业变革方法中
- 制定并遵守一系列设计原则，其中包括数据资产的治理
- 坚持数据资产必须直接源自经确认的权威来源的设计原则
- 定义具有清晰描述的领域的权威企业数据模型
- 维护数据资产的中央目录
- 坚持使用最少的所需元数据集，包括分类和其他与安全相关的元数据，以实现基于角色的访问
- 定义并执行可发现性和互操作标准
四、API 驱动的架构和互操作性标准
采用 API 优先的理念以及明确定义的互操作性标准是确保未来数据流的治理和控制以及驱动自动数据沿袭捕获、避免未来大量手动映射工作的关键。
API驱动架构
在 API 优先的基础架构中，不同的团队通过 API 作为首选或唯一的数据集成方法进行连接。保持 API 优先的理念可确保组织内部和外部的消费者都可以使用任何关键数据。如果做得正确，还应该推动对开放银行标准等全球标准的遵守，从而为与战略合作伙伴合作提供机会。
互操作标准
互操作标准由一组规则和协议组成，用于驱动不同系统和应用程序之间的交互和数据交换。如果我们用电来类比，您可以购买任何类型的电器，从冰箱到电灯或手机充电器，并且通常期望您可以将其连接到家中的插座。数据也类似——希望确保数据通过标准插座以商定的质量和数量提供，这些插座可供任何有权访问房屋内不同房间的人使用。对于企业来说，就需要就接口类型以及向其提供数据的渠道达成一致。
没有一套互操作标准适合每个组织，但有几个维度或组件至关重要：
- 遵守数据模型以确保数据的使用和解释的一致性，至少对于最小的一组关键数据而言如此
- 标准消息传递和有效负载格式
- 与系统和应用程序一起以标准化格式识别、维护和提供的最低业务和技术元数据
- 一组已确定的兼容技术
互操作工具集
拥有一套一致的互操作标准应该推动任何类型的兼容技术能够与基础设施交换数据。出于采用目的，建议确定至少 1 种也可能是几种数据工程师可用于各自目的的 API 技术。
选择哪种技术取决于组织、目标业务成果以及现有的技术堆栈和相应的专业知识。比如，一家区域零售组织决定采用 MuleSoft 作为其数字组织构建的首选 API 平台，而一家大型领先制造商则选择创建自己的内部构建的 API 功能。
通过 API 实现数据沿袭工业化
对于组织而言，存在巨大的机会来确保通过采用 API 优先的思维方式将数据管理纳入未来基础设施的设计中：
- 可以定义 API 模式来满足未来对数据和信息流的需求。示例模式包括异步、同步、编排和数据处理以及事件驱动模式。
- 在各种模式中，对齐与 API 一起提供的元数据脚本或文件。这些脚本应该标准化，并包含最少的业务和技术元数据集，例如源、目的地、提要频率、包含的关键数据元素以及一系列指标（例如分类、PII 指标）。最佳实践是，每次更新 API 时，这些元数据文件都会更新（如果可能，自动更新），并在 API 目录中维护。
- 确保将 API 元数据文件推送或拉入元数据管理中。工具到位特别是数据目录，以便可以创建谱系图。
将驱动 API 作为系统间数据交换的主要手段与坚持最低标准相结合，推动“数据沿袭设计”。
注意：不要使元数据文件过于复杂。较小的关键元数据集优于业务价值不明确的详尽集。除了例外之外，默认情况下不需要包含详细的数据元素级采购和转换逻辑。
五、数据管理中心
与实施后手动执行的治理活动相比，集中配置但本地采用的数据管理功能以更低的成本增强了数据的一致定义、治理和保护。
数据管理中心的重要性
为了通过设计推动数据管理，创建并提供一个单独配置的管理中心并使其包含最低限度所需的数据功能至关重要。管理中心包含数据管理，应作为未来任何云原生业务或功能流程构建的一部分来引用和嵌入的功能。他们应该能够从数据中自助服务这些功能，而不是让每个转换计划或业务功能区域在如何确保正确使用主数据、管理元数据和监控数据质量方面重新构建功能和标准。
数据管理需要设计
历史上，绝大多数传统数据管理投资都是在“事后”（即实施后）花费的。发现业务流程，识别数据元素，推断业务需求，并根据现有基础设施实施来衡量数据质量，这需要大量的人工工作和持续的纪律。
在这里的方法中，这些数据管理注意事项嵌入在设计和实施阶段之前和期间。此外，稍后手动执行的治理步骤将作为功能、非功能和技术需求集成为设计的一部分。随着解决方案的实施，数据管理是“按设计”构建的。
“设计”功能示例
数据目录 -正如上面针对 API 所概述的，但应用更广泛，就应用程序及其之间的数据流而言的系统全面的发现、文档和可视化可以自动化。
数据质量——监控和确保数据质量和完整性的控制可以通过两种主要方式嵌入。首先，可以在数据创建、捕获和传输时应用特定的控制和限制。比如对接受或有效值的限制以及数据流中的协调检查。其次，在数据资产等战略位置，可以对静态数据实施质量控制，以衡量完整性、准确性和及时性。
主数据和参考数据——数据资产的非常具体的示例，主数据和参考数据是非常强大的杠杆，可以推动在事务级别重复使用的数据的一致使用。比如MDM以确保在整个企业中，在入职、交易、客户联系、营销和关系管理等流程中使用正确的客户数据元素。同样，提供易于访问的参考数据（例如邮政地址标准）将推动其采用。
六、Data Fabric 作为系统之间的云原生粘合剂
提供跨所有系统和应用程序连接的线程称为数据结构。它不是一个可以凭空实例化的魔法层；相反，它由一组支持功能和经过仔细考虑的治理协议组成，这些协议共同使整个企业的信息可发现、编目、分类、标记、质量控制，并可通过通用的互操作性标准和渠道进行访问。
在很大程度上，该结构是由前面描述的数据资产、API 和数据管理中心组件启用的。如果正确并充分地使用，它们应该形成数据结构的主要架构。但是，即使不是最低要求，也有一些互补的数据功能：
数据管道、摄取、准备、传输、供应和存储——在 API 无法完成工作的情况下，替代或补充的数据交付和集成选项可以确保根据业务或业务来收集、摄取、转换、管理和提供数据。功能要求。需要配置存储来保存数据。
数据编排——根据目标用例和业务流程，可以应用数据编排来从各种来源获取数据，组合和集成数据，并将其提供给数据分析工具。数据编排可以在 IaaS 或 PaaS 级别执行，也可以使用抽象基础设施级别活动的技术（例如 Apache Airflow、Prefect 和 Snowflake）来执行。
数据安全和保护——监控和确保敏感数据不丢失、不被滥用或被未经授权的用户访问的过程，并启用主动保护数据资产的功能。政策和标准应规定如何保护数据以及如何共享数据。身份和访问管理 (IAM) 可以促进基于角色的访问，各种网络和身份验证保护措施可以保护数据免遭未经授权的访问和操纵。
报告、分析和数据科学——可以创建一个或多个数据平台来满足报告或分析用例。具有数据资产、API 和数据管理。数据管理中心到位后，这将成为一项简单的工作，因为数据可用、易于理解且易于获取，并且在云原生环境中，可以按需激活相应的报告或数据科学工具，而无需大量的前期投资。
七、成功因素
让我们以一些关于成功因素的想法来结束本文。取得成功的组织通常首先关注几个选定的领域，从一开始就吸引业务利益相关者，确保将遵守法规和政策方面的好处与业务成果一起考虑，并坚持云优先的设计原则。
- 从小规模开始——从组织相对良好的领域中的 1 或 2 个数据资产开始，其中物料、客户和产品数据通常是强有力的候选者。在较小的规模上取得成功并利用聚集的动力来推动其他领域吸取的经验教训的实施会更容易。
- 业务参与——从一开始就包括业务代表。价值创造取决于它们的采用和消费，这就是为什么确保将相关要求纳入数据资产和数据结构中至关重要，包括需要什么数据以及如何访问数据。
- 效益整合——拥有强大成功案例的组织通常能够将历史数据治理职责与更具前瞻性的数据科学相关用例结合起来，清楚地阐明强大的数据基础将如何为整个企业的利益相关者服务。如果数据管理，投资回报更有说服力。通过设计推动法规遵从性以及以业务为导向、洞察力驱动的用例。
- 云优先——坚持云原生设计可以防止供应商壁垒，并允许进行无风险、无缺失的实验，避免高额前期投资，并能够“快速修复”，在出现问题时进行扩展成功。
