The context: I spent the day with an end user organization that was trying to determine their MDM strategy – that is to say, trying to plan out how they should go about putting together their MDM program.  The user, a consumer goods manufacturer and distributor, has a good general idea that “customer” and “product” and “hierarchy” master data needs to be addressed across a heterogeneous ERP oriented environment; and over the next 3 years they are going to migrate from 4 legacy ERP systems to one ERP set of applications.  They have some tenuous sponsorship from the business for “better information management”, but not outright explicit support for MDM – since they don’t yet have an explicit MDM program to propose.

We were exploring how business and IT could create an understanding of the “as is” and “to be” states for critical business processes that were of concern to the business. If they could document the important business level description of such business processes, IT could extrapolate to the logical and physical models to determine exactly what data is needed to support the processes, where it is needed, and how best to store it.  Such an understanding of these most important processes (and supporting data lifecycles) would highlight which users/roles, and which applications should participate, overall. 

In talking about this we realized that this organization, like many others, do not document current processes, and do not maintain any living documented record of such processes.  We explored this issue.  Why is it that there are no documents describing the important – even master processes – that define how a business operates?  It turns out that the organizations did maintain a single view of these master processes when they were small enough; but as they grew, processes became departmentalized and so no end to end view, explaining the dependencies, was maintained. 

We know that for a minority of organizations this is not the case.  Unless your organization is into Six Sigma or some other continuous or sporadic business process improvement program, it is likely that your organization does not maintain a living master process model.  Given this situation, how could this specific user determine what master data was needed?  If you don’t know your master processes, how can you know or determine your master data?

One of the users piped up, and said, “People do, because they always have done”.  And this simple phrase said it all.  Most organizations follow tasks and departmental processes, and in so doing, lose visibility of end to end master processes, and the impact of their actions on each other.  I realized that this phrase, this condition, is not unique to this manufacturer.  It is everywhere I go – or almost everywhere I go. 

The take-away: Business Process Management and supporting technology, BPMS, is hot stuff.  But is the focus right?  Are organizations defining master processes that drive their business success, and if they are, why are they not linking mater process management with master data and MDM?  How can you talk about “order to cash” and not define a business concept of “customer” and “produce” or “service”?  Can we please start talking about Master Process Management, as a sister to MDM?  I would offer up the idea that Master Process Management as a discipline to define, document, and maintain a living, up to date library of the critical business processes that define the innovative and differentiating/key processes that the business is most interested in.  With this living model, determining what master data is needed to support “single version” would be relatively easy.

Individually 2 of the 3 product groups gave me the answer I was looking for, and expecting.  The third product group – the newest, didn’t provide the same answer.

1. Composite Application Platform (CAP).  This interesting technology supports the notion of development of a business application.  The process modeled or designed is primarily targeted at system to system interaction.  The platform takes a process design all they down to the deployment of an instantiated, executable business application.  The answer to my question was “well, we would hope that MDM is established”.  The reason being that the BPM model has its own generic data model (of sorts) and so any service orchestration that is “executed” against real world systems has to be mapped to those systems, and would (unless MDM was operational) have to concern itself with semantic consistency.
2.  TIBCO iProcess.  This BPM toolset focuses less on system to system process design, and more on people to system process interaction and design.  Clearly this seemed to intersect nicely with CAP.  I surmised that some users would and could actually use both toolsets.  Again, as with CAP, this toolset can take a process so designed all the way through to instantiated executable application.  And again, given the condition I offered, “MDM” was the preferred answer given. 
3.  TIBCO ActiveMatrix BPM.  This is the newer product that was announced today.  The focus of this product was presented to me as spanning the domains of the other two products.  As such this BPM model spans people to system and system to system process design and specification.  This looks like a good move for TIBCO; not sure about users that have invested in one or other of the “legacy” products.  Maybe they share common services (?)  However, when I asked my question, the answer I received back was that ActiveMatrix BPM was able to maintain the mappings of semantic (via metadata maps) between systems.  As such, this BPM tool would take unto itself the responsibility (and cost) to maintain the semantic map that represents a virtual enterprise data model. 

On the one hand this was a reasonable answer – until you realize that this approach is basically the same approach IT has been following for years, albeit not always with one toolset.  The problem is that this approach works only for the purpose intended; and incurs a huge overheard if applications change since the maps have to be re-drawn and implementations of deployed applications re-composed and tested.  How else could all the intricate nuances of semantic differences be avoided?   Of course, if MDM were part of the same strategy it would here, within MDM, that these issues are handled, once, and maintained naturally. 

This is the thing I just don’t get with MDM.  And I saw this again later in the day on Wednesday at a case study presentation on MDM.  It was a good case study, presented by a consultant and end user, concerning multi-domain MDM (mastery of product, customer, and location).  To a pretty busy room the consultants advised us that MDM remains consuming to many folks, since they just don’t “get it”.  I have to ask myself, do they “get” BPM?  MDM is a huge departure in “how we manage information” compared to what we have done for the last 20 years.  From vertical silos we are moving to horizontal services, spanning the legacy silos.  Yet still so few folks “get this” or even understand what it means. 

I had another wry smile on my face.  During the keynote session on Wednesday an external consultant suggested, in his closing remarks, that “we all used to say that you [the organization] need to be ‘process’ focused.  Well no we are telling you to be ‘event’ focused”.  As if these two concepts did not already or even interconnect.  Is it the case now that processes don’t matter?  Does instrumenting the world’s events suddenly change everything?  If we measure and track every event, is there no need to see these events in context, with an outcome?  Doesn’t a desired outcome assume a process of some kind takes place?  I came away with an idea for a good science fiction book J

The rest of the day was very good – starting off with a couple of good 1-1’s with MDM users, and some good content from the TIBCO team.  The 1.300 or so folks at TUCON 2010 certainly seemed to be keen to learn and share.  The keynotes focused on some technical stuff, and some hints at new releases in 2011.  The best part of the keynote for me was the Secretary General of Interpol: he communicated effectively (with good anecdotal stories) how they work around the globe fighting crime, and wove in how TIBCO technology helps support a very demanding IT environment.  All in all a good couple of days.  I learned a lot from what I saw and heard, and learned some more from what wasn’t said.

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.