Courtesy of Lorraine Lawson of IT Business Edge

Jignesh Shah (@jshah0209 ),  Software AG's vice president of business infrastructure products and solutions, discusses with IT Business Edge's Loraine Lawson the benefits of taking a process-driven approach to master data management, as opposed to a data-driven approach. (In the interest of disclosure, this month Loraine Lawson began writing for  B2B.com , a business-to-business site owned by Software AG and overseen by Shah's division. However, this interview was scheduled in response to an ITBE blog post Lawson wrote on  marrying BPM with MDM.)

Lawson: I know that in 2010, towards the end of the year, Software AG - which is known for its BPM tool - bought Data Foundations, an MDM company. How do you see BPM and MDM coming together?

Shah: What's interesting is that the process-driven MDM story at Software AG precedes Data Foundations, and not a lot of people know this because it actually stems from the IDS Scheer side of the house. Definitely we put process-driven MDM messages on the forefront for the Data Foundation acquisition, but IDS Scheer, which became a part of Software AG in 2009 and has been around for about 20 years, has been doing process-driven MDM for about 15 years.

IDS Scheer started out as a process improvement company and a lot of their practice around process improvement was around SAP implementations. So they took a very process-driven approach to implementing SAP.  They would document customers' processes, how they could be changed, modified, automated, and then use all that information to then guide the implementation of SAP systems and modules.

Even with SAP, the databases and the data models are not homogenous, so frequently they would implement master data management within SAP modules or between SAP modules and other systems that clients may have. And guess what? Being a process company, they adopted a process model to do MDM as well. Initially, it started out as an extension of just process thinking, but very soon they actually had developed a whole methodology and discipline around how MDM can be implemented and tied to process improvement initiatives. It's a six-point methodology starting from strategy, organization, process, data, applications and governance.

The article that you wrote and some of the things that Andrew White of Gartner writes, they often kind of equate process with BPM, which maybe it's true these days, but you know processes have been around as long as we've had the human race, right?

So, BPM and processes are not one and the same, is the point I'm trying to make. And IDS Scheer was doing process improvement before BPM became fashionable and they've been doing process-driven MDM before people started talking about marrying BPM and MDM, shotgun or otherwise. So that's the backgrounds. So we've been doing this part of the initiative for about 15 years, and then when we acquired in 2010 OneData, it just made natural sense to say, "Hey, we're going to go to market with this tool and with the methodology that we have developed over the last 15 years as a combined, unified offering," and that's how we came about the process-driven MDM message, the process-driven MDM dummies book and that's how we go to market these days.

Lawson: So if you're not doing BPM, how are you managing processes? Is that just a methodology approach?

Shah: People often equate BPM with automation of processes. There are processes that do lend themselves to automation, but there are many things that you can do to a process that have nothing to do with automation - redesigning a process, making specific pieces of the process more efficient by having the right people, the right training, the right governance and so on. There are many aspects of process improvement that fall outside of scope of a classic BPMS.

When we look at MDM, we don't assume you are using a BPMS or you have a formal BPM program in place. Regardless of whether a company has a formal BPM program or not, every company is interested in process improvement.

Lawson: Can you give me an example of what you would use a BPA tool for versus a BPM tool, which I know can do some of the integration and automating, acting as a sort of middleware. I assume you mean that BPA does not do that.

Shah: To be clear, BPA is considered part of BPM, a very key part of BPM. A BPA tool like Software AG's ARIS is a process-modeling and design tool. The other part of BPM is the automation of these processes often using a BPMS like Software AG's webMethods BPMS. Both aspects of BPM have important touch points with MDM.

Lawson: How does MDM fit in with your BPA tool?

Shah: To start with, our BPA tool, ARIS, has the ability to identify the data elements that these processes need to operate. So in addition to defining the process logic and the process flows and the decisions and so on, we also are able to define what we data entities and business entities use by process steps. Typically they tend to be things like customers, products, orders and so on. So the analysis helps you identify these entities and develop attributes of these entities that are needed to operate the processes correctly.

That data model then flows into our MDM tool, which becomes the starting point for deciding what data will you master, what attributes will you master, and what policies do you need to put in place to govern the changes to the master data. So all the work that you do up front in terms of identifying these processes that create, consume and change master data, that then flows into MDM in the forms of data models and policies that have to be implemented.

The other thing that happens is, as these data elements are identified, the BPA tool also helps you link them back to the source systems that supply information. That information, again, becomes very useful on the MDM side because you'll decide: How am I going to consolidate information from the sources, how am I going to cleanse it? How am I going to put it back into these systems?

Lawson: Why the focus on the BPA portion?

Shah: I guess the greater point that I was trying to make is that BPM has two components, right? It has a process analysis and redesign component and then it has a process automation and integration component.

People often talk about the automation and integration portion more than they talk about the analysis and process-design component. What I'm here to tell you is that from an MDM point of view, it is the analysis and design component that is much more relevant and valuable in driving MDM than the automation and integration component.

The classical MDM approach is to do this boil-the-ocean approach of studying all the systems that have customer information and the hundreds of attributes associated with the customer entity and how they differ and so on. If you do this in a vacuum, as an academic exercise, it's just never ending. And often, MDM has been accused of not delivering results fast enough, because people go through that academic exercise.

When you look at it from a process point of view, then you quickly can separate the wheat from the chaff and say, look, if the business goal is to improve customer service and new subscriber on-boarding processes, then here is the section of the customer data model that is the most relevant that we need to worry about, in terms of making it pristine and error-free and complete.

Lawson: So, it sounds like the BPA tool is the more strategic part of this?

Shah: Exactly. A lot of the discussion often tends to relate the automation and integration component of BPM to MDM, and of course there is linkage there and we support it. But when you look at it that way, it almost says, "Hey, it's only relevant to people who are doing process automation and process integration." What about all other companies or departments or projects that don't necessarily have a separate process-automation tool? Are they not interested in improving their processes with better master data?"