I sat down with an attendee at our Canadian CIO and IT Leaders’ Summit in Toronto today and between us we came up with a new name for what has been a problematic area for many organizations.
The attendees question was this – and I paraphrase:
- We are an established retailer with a large, complex, legacy application landscape
- We are about to undertake a business transformation program that will result in an overhaul and likely replacement for most of the legacy applications (among other things)
- Are there any best practices related to data and analytics, particularly the data side that we should consider?
I felt at this time that this was going to be a fun and exciting 1-1. I drew on 16 years of inquiries just like this one, and the thousands of firms that had gone through the same question across every industry. Of course, the findings and conclusions are legion and, without any emphasis or priority, I offered up the following:
- Many firms have asked the same question
- Many firms assume that as they “take” on board a new business application from a vendor or vendors, they “acquire” that vendors information architecture
- Most business application implementation user acceptance criteria do not focus on the quality of the data in those applications – most focus on the ability to process a core transaction (which many would assume implies good enough data quality)
- The vast majority of organizations will follow a path through this transformation and change in business applications without their own specific information architecture. The result is as predictable as the sunshine:
- “Successful” go live – vendors get paid – thank you very much
- Reasonable use of business applications
- Inability to quantify the benefits of the replacement of business apps on the new, revised business process outcomes. One reason being tied to data.
- Data quality in those business applications is “acceptable” at the go-live, but over time, about 9 months in fact, that quality erodes to the point at which business users finally see the challenges and those challenges start to impact negatively their business outcomes.
- If you are lucky, those challenges end up doing “death by a thousand cuts”. If you are unlucky you cannot ship orders or process billing transactions and these are the stories you hear in the press. The others, ‘death by a thousand cuts’, is the norm and so you don’t hear or read about these in the press.
- The final curtain call results in the organizations asking, “Should we now implement MDM?”
Thus the smart answer to this gentleman’s question is this:
- Implement MDM before and offset earlier than your apps implementation by about 3 months.
- This will make the applications implementations easier since the core underlying data will already be available and trusted.
That is the “easy” response. But there are some challenges in this response – particularly with MDM. MDM has gotten a bad rap. MDM has gotten a bad rap since so many of us are familiar with “master files” in our business systems and vendors have encouraged us all to assume that “master files” are synonymous with “master data” such that all the data in the “mater file” should be “master data” and so managed by “MDM”. This is wrong.
A few years ago we started to call out the difference between master data and application data. More recently we refined the demarcation of data into three groups:
- Master data – widely reference, widely shared across core business processes, defined initially and only from a business perspective
- Shared application data – less widely but still shared data, between several business systems, that links to master data
- Local application data – not shared at all outside the boundary of the application in mind, that links to shared application and master data
This “three ring” model has been very popular with clients and, being a simple model, it has proven to be most valuable in cracking open the needed dialog about what data is most important. You see we have also noted relatively recently that not all data is equal, so we do not need to govern at the same level of effort nor in the same system (i.e. MDM).
So the practical response I had for this attendee was, as started above, “start MDM ahead of and preceding your applications”. But taking into account the new realities of the “three rings” and the wider uses and value of data, we need perhaps a broader and more accurate response.
The response I came up with during this 1-1 was “business information architecture”. I said that I had never written this down before and that I had not seen that specific phrase before. In fact before writing this blog I searched on Gartner.com and did not see the phrase in the top 10 results of the search. I then went to Google, of course, and noted a number of “hits” but none were what I was focused on. All the hits were close, but tended to focus on a business view of information flow or information architecture overall of ALL data. This was not my focus.
What we talked about was the bare bones, the least amount of master data and shared application data needed a two-tier governance and stewardship model needed to assure trust in the core data flowing through the future state application landscape. Thus the business information architecture model was a minimalist model, not enterprise-wide; it was enterprise-class but not wall to wall. It was focused on the data that needed global governance and agreement and that second tier data that needed regional governance and agreement. All the local data needing local governance was ignored. The resulting program will therefore be small, nimble, and agile and work at the speed of business. Quite the appositive of those pesky MDM programs the vendors are peddling that seem to take forever and cost an arm and a leg.
We honed in on “business” as the first term since this was first and foremost a business and conceptual topic. There is no need for a definitive, perfect or complete data model. We just need some concept that is important to the business, such as product or customer, to get started. We don’t need to model everything. So we don’t need technical architects – we need business users that can think and talk about models and ideas. The technical and data architectures, if they exists, can do the detailed logical and physical modeling later.
Lastly, even though we used the term, “architecture” we meant more than a design pattern. The picture we drew together implies an architecture but also an actual implementation of MDM and Application Data Management that was scaled for speed and agility, with the least amount of data and analytics governance (policy setting) and with effective stewardship (policy enforcement) in the business. So this was a business information program too.
So there you have it. Together we came up with a new name, even an acronym if you like (e.g. BIA) even though you won’t likely see it in any research or any work we publish. At least, not just yet. But I think the idea is spot on. I think it captures the essence of what we mean to say when we say, “Do MDM before ERP” which is easier to say (but as I note above, far harder to do for a number of reasons). I think business information architecture includes an entire program spanning the right/least amount of (business-focused) master data (with central governance) and shared-application data (with regional governance) that will preceded local data governed data in the actual applications stood up over time.
What a great way to bring the Summit to a close!