Just read a brilliant post by Dylan Jones called “A Framework is not a Strategy.” It was in response to a comman Data Quality Pro community member question: “we’re launching a data quality/ migration project, whic
Just read a brilliant post by Dylan Jones called “A Framework is not a Strategy.” It was in response to a comman Data Quality Pro community member question: “we’re launching a data quality/ migration project, which frameworks do you recommend?”
Dylan goes on to note that problems occur when program planners confuse the terms framework and strategy. He offers the following definitions:
Framework:
- a skeletal structure designed to support or enclose something.
- a frame or structure composed of parts fitted and joined together.
Strategy:
- A method or plan chosen to bring about a desired future, such as achievement of a goal or solution to a problem.
- The art and science of planning and marshaling resources for their most efficient and effective use. The term is derived from the Greek word for generalship or leading an army.
Dylan then notes something that I, too, have seen a lot of: program planners who “focus far too much on the ’skeleton’ at the expense of the ‘desired future.’”
When DGI introduced the DGI Data Governance Framework over 7 years ago, our goal was to help people understand what components should be considered as they put together a program and infrastructure that could support the work needed to bring about a desired future. We felt that a new framework was needed because some components (stakeholders, decision rights, controls) were often overlooked.
We recognized that a strategy for Data Governance in support of Data Quality might look very different for one in support of Data Integration or Compliance. But all of these would involve the coordination of the same components.
Over the years, I have heard from hundreds of people who have said that they’ve used our framework to develop their own strategies int their organizations. (Quite rewarding, I must say.) In 5 continents, it would seem, are organizations who are implementing formal Data Governance and/or Data Quality, and who wanted a framework to help them get organized, get started, and to clearly communicate complicated ideas.
At first, it was tempting to assume that every one of these hundreds of framework users was going to have a happy, productive program. But after a few dozen exchanges over the phone or at conferences, it got so I could tell (usually just a few minutes into the conversation) which ones were actually making a difference in their organizations. They were the ones who emphasized HOW components of their strategy, and not just the WHATs of their framework.
- How they were identifying and engaging their program participants: Stakeholders, Stewards, DGO members, and authorities such as council members.
- How they were bringing clarity and transparency to complicated data situations by focusing and framing stakeholder needs.
- How they were helping to define data-related objectives and meaningful targets.
- How they were identifying gaps in their data-related rule-making and filling those gaps so they could develop the rules (policies, standards, priorities, directives, mandates, agreements, and others) needed to specify what should be done or not done.
- How they were providing alignment-level support to managers and architects charged with translating policy into enforceable controls and practices.
- How they were helping to embed rules and controls into programs, processes, systems, lifecycles, and professional practices.
- How they were providing support to managers and others involved with assigning accountabilities, enforcing compliance to rules and controls, identifying conflicts, and resolving conflicts.
- How they were helping define approaches and metrics for assessing results, through monitoring, assessments, profiling, auditing, attestations, and other activities.
- How they were helping drive action in systems affected by inertia, lethargy, and blockages.
- How they were providing ongoing Stakeholder Care in the form of communications, access to peers and participants, recording of data-related decision rights and other governance decisions, and education/support.
Unfortunately, some conversations only focused on WHAT needed to be in place, as if their organizations would magically achieve the value they were looking for merely by having a program equipped with a mission, focus, value proposition, participants, processes, decision rights, rules, accountabilities, and controls.
To these people, I would try to explain that having such a framework in place is no more useful than merely erecting the metal framework of a high-rise building. Both are there to support the rest of it! In the case of a high-rise, the rest of the building needs to be layered onto the framework, so that people can get into, reside in, work in, and leave the completed space.
In the data world, it’s the job of Business + EIM + IT to build out and maintain the structures in which our data lives and works. Data Governance helps these blended teams to agree on the rules they must all follow (”Big G” Governance) and then embed and enforce and monitor the rules (”little g” governance) and – when needed – address and align conflicts (alignment-level governance).
The contents of a Data Governance strategy will depend upon where Biz+EIM+IT need help! The idea of a Data Governance (or quality, or migration, or MDM…) framework is to standardize thinking about the components involved in delivering Big G, little g, and alignment-level governance activities.
If you want to join the ranks of successful programs, remember that defining and building out a framework is just the first step. You need to keep layering on strategy, plans, and deliverables unless you want all your participants holding onto wind-swept girders as they work.
