For the last couple of days I had the pleasure of sitting down with numerous attendees at our North American BPM summit here in Maryland, DC. Even though the weather and the cherry tree blossom was wooing us away, we stayed in the hotel to talk about ‘data’ and ‘process’ and – predictably – which came first.
I took a couple of 1-1’s with users who ranged a numer of questions along the lines of:
- How should we look at aligning our EA, BPM and MDM efforts?
- How can I quantify the impact of bad data (quality) on poor process (integrity)?
- Which vendors have a good BPM/MDM vision?
- How to document and understand the flow (ie process?) across my business (application landscape)?
Interestingly these questions were then highlighted nd explored more deeply in an hour long “ask the analyst” session where end users from a wide range of industries pondered the question – how should they align BPM, MDM and application strategy?
One end user actually reported that they had Chief Process Officers “sitting next to” Chief Data Officers, in order for the two practices to align and ensure dependencies are managed effectively. This indeed was a great “best practice” that, unfortunately for the rest of the attendees, remains far off. Most organizations did not have a Chief Data Officer; not all even had Chief Process Officers.
The fun part for me was when I took a leaf out of BPM land and turned process and data upside down. We all know that a process-view leads us to think about a conceptual process (e.g. customer places order for products that we fulfill). This conceptual model is translated into specific activities (logical model) and then down through a physical model were specific data in a specific table in a data store is defined. IT then “simply integrates” the data and away we go. The problem is, as any heterogeneous-application-landscape-aware person knows the data can be a major pain. If it is inconsistent (ie.. un governed), that ‘perfect process’ just won’t work once it is instantiated in a physical application!
Many successful MDM programs have taken their lead by looking at this problem by turning it on its head. Instead of taking the view of a process, and what data it needs, take data (the object, such as product, or customer) and follow it through the processes and applications that use it. In other words, “document and understand the flow of data across the organization”. This ‘data lifecycle’ is what is needed to identify:
- What data?
- Who touches it?
- What happens to the data next?
- Who approves and who should approve data (or policy)?
- What policies are identified (or should be)?
- What metrics drive behavior, and what should?
This is the essence of MDM. Turns out it’s the essence of BPM too!
I also had the pleasure of presenting on, “BPM and MDM: A Powerful Force in Business Performance Improvement”. The session was well attended, and I had some good questions at the end:
- How do you see SOA/ESB/Service layer play a role between/with BPM/MDM?
- How do you see big data’s impact on how MDM is evolving?
- How do you see MDM relate to semantic reconciliation efforts?
The one worrying item for me was this: As I do in every session on this topic (of BPM and MDM), I asked for a show of hands “How many of you have a distinct connection between an MDM and a BPM program?” Oddly only 5% of the hands went up!. In Europe the response was, a month ago, 20%. In the US last year, the result was 15% or so, up from about 10% the year before. Europe has been steadily increasing too. Why was this audience so low? Interest is not waning – its increasing! While some vendors on the show floor don’t report a lot of work or activity in this “convergence” space, some are reporting a surge in interest. And inquiry levels relating MDM and BPM are up. So it is interesting that this is an important but single data point. We will need to keep a wary eye on this.
So a busy couple of days, lots of end user interaction (the best part of what we do), and some food for thought. On to the next show.