Yes, yes, yes! David Loshin explains quite nicely (Data Steward Role Needs Some shepherding Itself) the need for a formal, business centric role of data steward. More importantly, his explanation happens to align with our research: Stewardship is mostly about “policy enforcement” of the “policies setting” that is part of governance. Technically, there is a little snag here: Governance comprises governance (policy setting) and stewardship (policy enforcement). But maybe the duplicate use of the word is not too bad. Our more complete description goes like this:
“The fifth building block (of 7) for Enterprise Information Management is Information Governance. We include in that block two structures that span: – governance (policy setting) and stewardship (policy enforcement). There are other structures and roles also, including the emergence of the Chief Data Officer.”
I read Loshin’s book, Master Data Management, 2009, MK/OMG. It’s pretty good – one of the better books out there (there is, alas, already too many fluffy books in this space). Much of his material is similar to what we have researched, with a few differences. For one thing, stewardship is mentioned once in the index, and represents less than 1 page in a book that is 274 pages long. That tells you the extent of the thinking of Stewardship in 2009.
We had a number of notes published on the role and scope of the work of stewardship in 2009. More interestingly, at our third annual MDM Summit of that year, the keynote deck had a whole slide dedicated to the work of Stewardship. That’s one slide out of a total of 18. That tells you how important we felt stewardship was in 2009. It remains one of the newer, exciting aspects of MDM. And more importantly, it is MDM that is pushing the envelope in terms of defining this new role in the organization.
Other information domains also have the same challenge – how and where, in the business (as opposed to IT) to get “information policy enforcement” actioned. This question has been thrown at records management, content management, e-Discovery, Information Lifecycle Management (storage/archiving, not actual life cycle governance), and yet none of these areas have really punched through the glass organizational ceiling to establish an operational, day-to-day, “in the business” stewardship function. One reason is the nature of these efforts. MDM is focused on business data for business (day-to-day) use by business people. The other programs tend not to be so enterprise wide, and tend to operate (even if called enterprise class) more at a departmental level. These other programs don’t seek to align semantics (or manage the differences) across core business processes; they are generally narrower. Some industries do adopt some of these other programs enterprise wide, but not perhaps for operational data. In each and every case, MDM was designed from the ground up to do just that.
Shhhhh – Master Data Management Doesn’t Really Exist!
This explains in part why MDM is so exciting. It also highlights a major risk that is very “2013”. MDM is a great place to start a modern/new information management strategy, but it is not the end state. In fact, and this is a kind of hushed secret, any organization that launches an MDM program actually moves beyond MDM very quickly – and they may not know it or call it. If you:
- Add some content to the data repository
- Add some business rules controlling application specific data outside of the system of record
- Add some content or other structured data from social data source to enrich master data
- Add some analytics that report on the business use of master data
…then you are governing (presumably) much more than master data. Yet the program may still be called MDM. And this is a problem. This helps explain why one MDM programs looks quite different to the next. It also helps explain why a growing number of MDM programs are failing – we are asking too much of them. We need to learn where MDM stops, and create supporting and additional programs (new names???) to explain and show how the work changes, how the priority from the business has changed, and how the business outcome will changes. After all, ERP is not “all the business applications we use in our organization”.