敏捷/精益数据治理最佳实践

数据治理 的目标 是确保组织内的质量，可用性，完整性，安全性和可用性。你对此的看法取决于你。许多传统的数据治理方法似乎在实践中都很困难，我怀疑部分原因是 文化阻抗不匹配，部分原因是传统的IT治理总体上存在争议。传统治理策略中典型的命令和控制方法很像放牧猫，你做了很多工作，但从长远来看，没有什么可以完成的。另一方面，敏捷/精益治理的重点是帮助人们并激励他们做正确的事情。 敏捷/精益数据治理的目标是使开发团队能够在整个IT生态环境中维护和开发高质量的数据资产。精益数据治理方法可促进数据专业人员与 他们支持的团队之间的健康协作 关系。最近Per Kroll和我一直在研究如何采用精益/敏捷的方法来治理软件开发项目，从而产生了 IBM白皮书。本文介绍了一系列实践，其中许多实践适用于一般的IT治理（包括数据治理）。该方法基于以下观察：管理智力工作者行为的最有效方式是通过激励和启用它们，而不是通过命令和控制过程。Dobb博士的Journal of Current State of Data Quality Techniques调查发现，协作方法数据管理比命令和控制方法更有效，后者反过来总比没有方法更好。遗憾的是，传统的IT治理方法通常以命令和控制的方式实现。

1. 传统数据治理策略的潜在挑战

传统的数据治理策略通常会遇到一个或多个常见问题：

1. 数据治理不适合整体IT治理工作。在某种程度上，甚至在整体IT治理策略范围之外考虑数据治理，开发治理，SOA治理或无数其他治理工作也是有问题的。您需要优化整个治理策略，而不仅仅是单个部分。
2. 数据治理工作被忽略。在 2006年DDJ调查到的数据管理实践的现状表明，开发团队的66％会选择“解决”自己组织的数据组，请参阅 图1所示。这显然存在问题，并表明如果您无法找到与开发团队有效协作的方法，那么您的数据治理工作就不可能成功。
3. 数据治理过于繁琐。正如你在看到 图1的开发团队的20％报告说，他们的组织内的数据分组是太困难的工作。在某些组织中，这包括数据管理器。
4. 数据管理器响应太慢。 图1显示，36％的开发团队发现他们的数据组工作太慢，激励开发人员采用他们认为最好的方式（即使他们可能实际上并不知道最佳的行动方案是什么）。
5. 数据管理者不被视为提供价值。  图1显示，19％的开发团队报告说他们认为他们的数据组不会增加太多价值，这通常是因为传统方法涉及额外的官僚作风。

图1。开发团队围绕数据组的原因。

2. 敏捷 /精益数据治理实践

除了支持 敏捷数据库最佳实践之外，您应该考虑为数据治理工作采用的敏捷/精益开发治理实践是：

1. 有价值的公司资产。如果认为向开发人员增加价值，将采用指导（如数据库设计约定， 建模风格指南，数据命名约定和报告设计指南），元数据定义以及可重用资产（如框架和组件）。您希望让开发人员尽可能轻松地遵守，更重要的是利用您的企业IT基础架构。当数据标准合理，易于理解且易于访问时，人们在实践中实际遵循标准的可能性就大大增加。当你强迫人们遵守标准时，当他们这样做是繁重的时候，那么 你就减少他们实际这样做的可能性。
2. 场景驱动的开发。如果不了解零件就无法定义整体，如果不了解整体，就无法对零件进行详细定义。通过采用场景驱动（也称为使用驱动的方法），您可以了解人们将如何实际使用您的系统，从而使您能够构建满足其实际需求的内容。传统数据方法的一个常见错误是它们采用数据驱动的方法（可以理解，因为它们的偏差）使它们陷入困境，因为数据过于狭隘地驱动事物并且它不能反映整体治理工作的需要。
3. 将数据专业人员作为开发团队的积极参与者。当您的DM小组在项目团队外部时，如果您不是非常小心，它可以在您的IT组织内培养“他们与我们”的心态。您不需要有外部组来运行数据治理活动，而是个人数据专业人员可以通过协作和及时的方式将其作为开发团队职责的一部分。这是敏捷数据方法的基本概念之一 。
4. 教育开发人员。开发人员需要了解为什么您的MDM工作很重要，有什么好处，以及如何与您的DM团队合作。当他们知道为什么需要做某些事情，以及如何有效地做到这一点时，他们实际上会做得更好。
5. 适应过程。由于团队在规模，分布，目的，关键性，监督需求和成员技能方面各不相同，因此一个流程规模并不适合所有流程。这意味着您支持面向数据的活动（包括治理）的方法因团队而异。
6. 使团队结构与架构保持一致。数据团队的组织应反映 企业架构结构。例如，集中式数据团队将难以支持具有分散式架构的环境。 
7. 对齐HR政策，IT价值。您需要为技术人员的思维方式制定适当的激励/奖励，以确保他们遵循您的数据治理策略。
8. 协调利益相关者政策和IT价值观。您的开发工作受到利益相关者的驱动和约束。您的利益相关者必须切合实际地了解他们对IT的要求，并了解他们决策的含义（您需要对他们进行教育）。
9. 业务驱动的项目管道。您应该投资于与业务方向完全一致的IT活动，返回可定义的价值，并与企业的优先级相匹配。这也包括面向数据的活动。不幸的是，许多传统的数据治理策略似乎往往反映了我们中间数据官僚的优先级，而不是业务的优先级，导致数据仓库等正在建设中未被充分利用
10. 嵌入式合规性。最好将合规性构建到您的日常流程中，而不是单独的合规流程，这通常会导致不必要的开销。自动化至关重要。例如，不是为了确保开发团队遵循公司数据约定而进行审查，这 是一项耗时且昂贵的工作，为什么不定期针对数据库模式运行静态代码分析工具，以确保遵循数据命名约定？
11. 灵活的架构。面向服务，基于组件或面向对象的架构以及实现通用架构和设计模式有助于实现更高级别的一致性，重用性和适应性。
12. 务实的治理机构。有效的治理机构侧重于以具有成本效益和及时的方式促进发展团队。他们通常拥有一个小型核心员工，其中大多数成员是受治理组织的代表。
13. 促进自组织团队。规划工作的最佳人选是那些要去做的人。IT专业人员应该被尊重为聪明人，他们可以决定自己的合作策略。当给予一些指导和指导时，他们可以在已建立的参数（例如迭代边界）内规划他们的工作。自组织并不意味着团队失控，任何特定团队都必须遵守您的整体治理策略，企业架构等。
14. 基于风险的里程碑。您希望在生命周期的早期降低项目的风险，特别是业务和技术风险。您可以在整个项目中使用团队工作的几个里程碑。每个里程碑的目标是解决一个或多个风险。例如，Disciplined Agile Delivery（DAD） 在其生命周期中明确包含几个轻量级里程碑（它支持多个），其中一个是“经验证的架构”，需要在构建开始之前通过工作代码验证您的架构，从而降低整体技术风险。

3.数据治理成功因素

我发现以下因素对数据治理工作的成功至关重要：

1. 认识到IT治理是真正的目标。数据治理只是IT治理计划的一部分，并且与开发治理，安全治理等其他方面高度耦合。仅关注数据治理会使您面临优化数据治理的风险，使其无法与其他治理工作一起使用，从而使整个治理计划面临风险。请记住第一个 敏捷数据哲学，即数据只是整体情况的一部分。
2. 治理工作必须归属。如果某人不负责IT治理工作，很可能会在您的组织中快速死亡。我的经验是，最适合成为IT治理所有者的人是执行业务的利益相关者。在数据治理方面，最不适合治理的人是数据管理专业人员，因为他们是受治理者（等等）。简而言之，不要让您的数据治理工作转移到您的数据管理组的另一个政治策略，以试图获得额外的权力。
3. 有明确的，可量化的目标。你想要达到什么目的？提高质量？提高生产力？改善价值的时间？提高利益相关者满意度 它的组合？ 
4. 衡量并诚实地报告结果。谈论可量化的目标很容易，但要兑现你的承诺需要相当多的诚信（我会让围绕数据治理工作价值的严重缺乏数据说明一切）。管理直接成本（例如参与治理工作的人员的工资）相当容易，但是更难以衡量间接成本，例如由于治理增加而可能延长决策和开发生命周期的机会成本（此问题是对传统治理策略尤其严重）。衡量收益也可能具有挑战性，尽管Doug Hubbard在如何衡量任何事情中指出 ：在商业中寻找无形资产的价值如果你在盒子外思考一下就有可能。自动化指标收集是精益治理的一个重要方面。
5. 少即是多。与支持治理人员所认为的相比，您需要的治理要少得多，尽管可能比反治理人员的想法更多一些治理。如果您发现需要更多的治理，那么添加它会比删除不必要的治理活动更容易。
6. 教育受影响的人。如果涉及的人员，包括那些受治理的人，不理解你想要实现的目标，并且相信他们的任何额外努力都是值得的，那么你的治理工作将很快崩溃。此外，这种教育正在进行中。