In my last article I suggested that many organizations have approached Data Governance incorrectly using only centralize data governance teams and that approach is not working for many. Large organizations generally need a decentralized approach, to engage resources in all functional units (my definition of “a village”) to Operationalize data governance across many functional business units.
What I may not have been clear with in that article is that data governance processes and compliance can be started with a small dedicated team and leveraged to educate the organization about governance processes and compliance practices. Over time many functional business units can have their operations include data governance processes. All but the largest of organizations can succeed in Data Governance with small central teams but expectations have to be set appropriately.
It is true that in 2014-2015 the popular Data Governance practice was to start a CDO organization and put the responsibility for Governance in a centralized CDO team. There were a few reasons for this. Such as the following:
- Training and education was easier when it was just a core central team.
- New resources could be hired faster. It takes more time and executive effort than integrated in an existing business unit.
- It could be made more visible to external regulators that something was being done to address governance and compliance gaps.
- For many, the need to show progress in the immediate “defensive” use cases was in respond to regulators and not to Operationalize governance to improve data outcomes directly.
Sustaining Governance in operations was not high on the objectives for most organizations at the time. The prime objective at the time was to be able to demonstrate to regulators that some action was being taken. The industry had moved beyond those limited use cases, I hope.
Data Governance should begin with a limited number of use cases that add significant value to the business quickly. Broad Use Cases such as ”create a Business Glossary” are not specific enough to add short-term value. A Use Case such as “define the processes, roles and differences between a Customer and a Vendor” is specific. This may be a Use Case that has been an organizational challenge for a long time. I recommend that teams don’t shy away from a hard problem, but set expectations that they will make incremental improvements over time. The big problems generally need to be organized in smaller increments to break the problem into manageable actions. For example, rather than tackling “Customer and Vendor differences for the full enterprise, look at tackling it for 1 or 2 business units first. Shall we day, eat the elephant one byte at a time approach.
A general practice is to break the problem down in scope either functionally or by extent of deliverables. Using the Customer and Vendor you can reduce the scope by possibly limiting the type of Customers or Vendors before tackling the Vendors that are also Customers. In architecture terms, you may limit the scope to address the individual separate object types before the concentric circle complexity. Or define and document Customers that are not Vendors before the complexity of those that are.
One can also consider limiting the scope of deliverables to reduce the resources and time needed. For example, you may set expectation that you will be completing a business glossary only in a first phase, then other data governance deliverables in later phases.
Leverage what exists
Once you have your Use Case scope beginning documenting what resources exist that you can leverage this can include the following:
- Existing dictionaries or glossaries that exist in the business unit, technology teams, or from industry standards groups.
- Existing BI/analytics reports and resources. The Analytics/BI team may have the best knowledge on how data is being used. Ensure to include them as sources of information.
- Existing data analysts, data experts or data modelers/architects will also be great existing resources for information.
Build a Basic Business Glossary
While, the problem for the Use Case may not be originally stated as a problem with definitions, it is likely that creating basic definitions and domains in a business glossary will clear up some of the confusion and help get to solutions faster. Definitions are critical for data governance and the solutions to your Use Cases. Don’t get hung up on technology, just get clear definitions. Use what you have even if it is Word or Excel. You are likely not ready for large enterprise tools yet, let another team conduct that analysis. It is OK, stay calm and allow your Business Glossary to prosper.
