Picked up an interesting white paper this week authored by SAP. ‘Governance from the ground up - launching your information governance initiative’. In it our friends from Walldorf spell out how data governance should be organised, key roles, lessons to be learned etc.
Now, as you know I’m a data migration guy so my role is either tangential to data governance where it is well established or, as I shall argue, a really good starting point for data governance, so maybe I’m not all that qualified to comment. But what the heck I shall anyway, at least for those areas of overlap between my sphere and my DG colleagues.
Let me be clear at the outset that I welcome data governance oversight on any project I’m working on even where I occasionally butt heads against it. It’s always a bit like traffic lights - we know they are essential but hate them when show red to us and we’re in a hurry.
Let us make a start with that bug bear of mine - the data steward. In my book Practical Data Migration, I take issue with the term data steward. This is mostly because the ones I have met do not seem to conform to a single well defined role. Some are business based with a part time responsibility for data quality in their area, others are technology based with a more global reach across the organisation. All too often they are lonely, isolated figures continually frustrated by being ignored by the very folk they are trying to help.
The SAP white paper acknowledges this. Its section on information governance challenges paints a picture of a group of well intentioned even passionate and well skilled individuals tasked with the responsibility of ‘monetising enterprise-class information governance’. Then there is the business that is just too busy to implement change. Even with executive sponsorship the initiative is dissipated and data governance ‘collapses under its own weight and becomes a euphemism for (yet another) intellectual exercise that went nowhere’.
The suggestion by SAP is to start small and to create a data steward role (amongst other things).
So perhaps here we will find the answer to my question what is a data steward?
There is a list of activities they may be involved in - data correction, reducing data errors, metadata management, maintain a glossary of business terms, creating mapping, cleansing and validation rules. All of which seem very technology focussed as indeed do the skills - ‘understanding of workflows...delivery methodologies...data architecture...database administration functions...data quality tool’ as well more generic skill like facilitation. They are also expected to engage with the business domain experts and lead the council (a body not fully defined but one I’m guessing is analogous to the DQR board in PDM).
So the role of data steward, in terms of basic skills, it is not unlike our wish list for the perfect data migration analyst.
Someone who can talk to the business in business terms but backed up by a solid core of technical skills that are needed for the job and will make them credible with their technical colleagues.
The difference, of course, is that we expect our data migration analysts to understand the special needs of our project based, short term, data migration requirements. We therefore concentrate more on prioritising and fixing current data quality issues, less (or not at all) on fixing upstream issues that cause data quality problems. We are also deadline driven. We can’t iterate through a series of projects to develop best practice. Data migration is a one way, one off trip to get our target system up and running. Our processes have to work out of the box.
A second key recommendation from SAP is that you spring board your data governance capability by initially working within a well bounded, small project of fixed duration - they case study the establishment of a data governance competency as part of a CRM implementation. The objective is to deliver on two levels. Add immediate value by being of use to the under pressure programme manager but also consciously use the project ‘to establish some new information governance processes’. You are looking to develop processes that are ‘solid and repeatable’. This includes ‘establishing data ownership and procuring tools - so they can scale to the next project or set of projects’.
If the idea of using a concrete programme with political weight behind it (like maybe an SAP data migration) to get a structured approach to data governance seems familiar to readers of this blog, then that is maybe because it has been one of the consistent themes I’ve been banging on about for the last 15 years. Nice to see that SAP is catching up. For those of you familiar with PDMv2, using a data migration as the starting point for a data quality or data governance competency is all covered in the legacy decommissioning module.
Here it has to be said that most of my writing to date has been of a less optimistic tone than I’m getting from SAP or from other recent commentators on the subject. If you use PDMv2 properly you will have a bunch of real data owners familiar with their responsibilities (they have signed the de-commissioning certificates after all); a network of engaged and enthused business domain experts (the PDM terminology for subject matter experts); a fully socialised process for bringing data issues to the table and getting them prioritised and actioned with full business ownership (the DQR process); a metadata understanding of the target and legacy domain (much of which persists in many post migration settings); a list of data issues that could not be resolved in the timescales of your migration.
As we pack our bags to go on to our next project all too often we leave this behind on the table where it withers away. One of my persistent big moans has been about this waste, but it seems that the tide may be turning. Data governance, like most good ideas in IT, has gone through its braggadocios adolescence where it failed to live up to its promise. It is now beginning to be recognised that although we want to re-plumb the entire enterprise we may be better off with small beginnings. Ones that show quick added value.
So being tactical about which projects you get involved with and having an eye to the long game whilst still delivering in the short term, will pay dividends. This way you may win your case to get the funding you need for the necessary tools and training because of the immediate benefits they bring, whilst looking to their longer term use.
And you should, of course, use PDMv2 as your methodology, at least outside of the DMZ because only PDM has the mechanisms, out of the box, to deliver robust processes in the kind of time frames that a pressurised data migration project demands. Don’t try to make them up on the fly. Rely on the fact that we have made all the common mistakes that everyone else makes and put remediation in for them over the last 15 years.
By the way if anyone is bewildered by some of the terminology in this blog and their copy of Practical Data Migration has yet to arrive, drop me a line to the email address below and I will send you a full colour A1 sized poster of PDMv2 which includes module and sub-module definitions.
I have of course only snatched a few morsels out of the feast that is Governance From The Ground Up. You really need to reads the original to understand the structure they are suggesting and benefit from the insights they give into the commercial and political realities of getting a data governance initiative up and running. I picked mine up from the Tech Republic site - although I guess it must be on the SAP site somewhere. Both are free but will ask that you give away contact information, which I recon is a very fair quid pro quo.
Johny Morris
jmorris@iergo.com
