Andrew WhiteWatch out – the hype meter is running high on this one.
It is not often that I disagree with Information Management, and I am not sure that I really am, but I have to diverge from the views in this article, Process Data Management: Like Your Brain And Your Heart, BPM and MDM Can’t Survive Independently. The article explores the link between BPM and MDM and concludes that the two (disciplines, technologies?) need to merge. Pardon me, but this looks and smells like an old “ERP” argument, dressed up for a new time, a new market, using the predictable cycle of innovation/assimilation.
The article started off on the right foot: What came first, data or process? Correctly the writers suggest that there should be more interaction between BPM and MDM. Last year I reported that, for an MDM Magic Quadrant in 2008, 2 out of 50+ user references described an active and strategic connection between BPM and MDM. No users had said as much before hand; though through inquiry we knew that there were a few – a very few. And that is after covering the space (MDM) for 6 years!
Within the discipline of MDM there are workflows and business processes that any MDM users would understand and recognize. These processes need to be benchmarked and improved over time. That is standard stuff for any business process (so BPM seems to make a good connection). Likewise, any process designed by a BPMS tool references some notion of data. The process so modeled is then used by an application developer to create an application. That application then consumes and uses data. So the link is clear. Is there a need for merger?
The article highlights something called Process Data Management – which is the joining of MDM and BPM. After less than 5 years with each having their own life cycle, it would seem the demise of MDM and BPM is imminent, even sought, and a new amalgamation is required. I disagree. We all just spent the last 20 years building vertical stacks of application and data; and we are all now about to spend 20 years building horizontal layers of services of stuff (like BPM, MDM), but to say that the two need to be merged?
Yes, the processes are linked or should be more explicitly linked. You cannot build an application from a process designed without recourse to the quality of the data being consumed by it. However, master data is not the only data used in an application.
No, the BPMS technology and MDM technology do not need to be merged, or built or offered by one vendor. It could help some users, since integration between the two should (not necessarily) be more integrated, but the issue is not technology. The issue for both is governance, process, and organization.
We have too many registries and repositories; we have too many standards; we have too many methods and styles. We have MDM applications that are built with a SOA design style that leverage BPEL that can be “called” by a service. So any application, designed by BPM, can call the MDM service. But wait, does BPM “talk” directly to MDM? No – a process, modeled and improved in BPM, is used to build a business applications and it is the business application that does the actual data consumption. So the only legitimate, direct connection between BPM and MDM is at the data and process model definition level. BPM assumes that there is a consistent data model; MDM assumes that services calling it use consistent contextual requests.
Now, the article does say: process improvement and data improvement should be consolidated. The benefits should be leveraged. The synergy in the technology design and deployment should be sought. And of course, there are common governance/process/organization considerations.
But BPM and MDM need to survive, will survive, for along time yet, as separate and independent disciplines with ever increasing “interoperability” in terms of services. That is a practical conversation – not a market hyped conversation about how BPM and MDM need to collapse into a fictitious market called process data management. The vast majority of users have yet to master MDM, or BPM, for that matter. It will take time.
The technology may get acquired but that does not mean the same thing as “merged” or “aligned”. ERP never made it. Today we spend our time arguing over what you mean by “ERP” and what I mean by “ERP”. Is it a suite of applications with a single data/process model? Or is it a strategy for sourcing applications and solutions from one vendor?
The article ends, “Most importantly, senior management must foster collaboration and provide cross-training between these two siloed disciplines to begin this long overdue paradigm shift.” This is reasonable advice – but I do not subscribe to the conclusion that MDM and BPM will “go away” and some new technology, or aggregated discipline, will emerge.
One last thought – a larger number of users are asking – how to expand a successful MDM program to reference data? In other words, once a firm has mastered it’s mater data, how does it go about mastering other, reference data? Is this the same governance organization? Is it the same technology? Many more users would like to see MDM “merge” with other areas such as reference data management, content management, and so on. So MDM has lots of courting opportunities to consider. I am not convinced that BPM will be the main or even primary marriage partner.
1 response so far ↓
1 JB October 17, 2009 at 8:29 am
You are right on…..we have not yet been able to measure the temparature and count the wins from strides in MDM over the last 5 years. As articulated (soundly) during the recent summit, business cases and adoption into mainstream is taking longer than usual, perhaps due to the recession.
In the absence of a clamor for these services from the business side, MDM soundbytes remain IT babble and that is a clear problem to the value proposition.
In my own situation, I am dumbing down the vocab so it sounds more humane and can relate to my business partners.
Process Data Management (surprised no TLA!) appears several dreams distant.
Cheers!