數據治理 的目標 是確保組織內的質量，可用性，完整性，安全性和可用性。你對此的看法取決于你。許多傳統的數據治理方法似乎在實踐中都很困難，我懷疑部分原因是 文化阻抗不匹配，部分原因是傳統的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. 教育受影響的人。如果涉及的人員，包括那些受治理的人，不理解你想要實現的目標，并且相信他們的任何額外努力都是值得的，那么你的治理工作將很快崩潰。此外，這種教育正在進行中。