Data Governance, top-down or bottom-up?

Our team has broad firsthand experience with various approaches to Data Governance (DG) frameworks. E.g. DAMA DMBOK for master data management, ITIL for change management and operations, Prince2 for project management, Scrum for development, or more vendor-specific systems like Oracle Fast track for DWH development...

On projects, however, we combine a number of practices we have found useful for delivering tangible results and they're not based on any specific approach.

For instance, if you were to take any of the above-mentioned frameworks and were to apply them in a top-down manner on a specific IT environment, you'd typically reduce thousands of pages of guideline documents to hundreds of pages of guideline documents with the customer's logo at the top of each new page.

Intellectually, it would be a great endeavour and you would spend many days in interesting discussions with the customer's architects. HOWEVER, it wouldn't change a single thing in the day-to-day habits of the people actually working with the data or anything else for that matter.

When the exercise was finished, your customer would either:

  • stop the project because it had brought limited or no business value.

  • appreciate your hard work, but not know what to do next and ask you to write a more detailed DG process description and history would repeat itself.

This is my humble opinion on DG applied in a top-down manner.

On the other hand, you could do this from the bottom-up and propose to demonstrate how DG should be exercised in only a single business area - the one which is the most sensitive to data quality in the context of the customer's revenue generation.

Let's be honest, there's a big difference when implementing a new system, between reading how things should be done (PPT delusions) and actually doing it, ie. documenting a table, finding a steward and publishing this information in a format that would be useful to someone OUTSIDE the DG team. Following a Power Point-dictated solution fails for the reasons I've outlined above. Getting your hands dirty with a test project doesn't. It gives you the chance to evaluate a customer's cultural habits and DG maturity and allows you to propose processes that might actually work enterprise wide, because you've proved that they work in a sample area.

It's a completely different story for a CIO to sell and drive a DG initiative internally when s/he has a working prototype of the solution and not just hundreds of PPT slides and Word documents.

I would propose:

The DG vendor should provide

  • a senior architect/analyst

  • a DG mentor/coach

The Client should provide

  • available documentation for one business area (collections, underwriting ...)

  • allocate typical roles related to the data life-cycle (business end user, business analyst, IT developer, IT operations) from a given business-area

Project scope

  • Over a 4-month period the senior architect would map a given business-area with the cooperation of the client's people. S/he would encourage contribution to the documentation from the client's side.

  • The DG coach would provide guidelines, templates, best practices and organise regular workshops on how to analyse, document, operate information assets and preach the DG gospel to anyone willing to listen.


  • DG guidelines which reflect the client's culture and maturity.

  • One business area documented according to the DG guidelines.

  • A team who is trained to deal with data in accordance to the DG guidelines.

Then the customer can decide whether DG should be rolled out and in what manner, enterprise wide.