I fully concur with the article, having been working at the intersection of SOA, BPM and MDM for the last 4+ years building a Business Operations Platform (completely services-based).

I want to share my opinion on the point you make about using BPEL (together with Rules) to handle the “processes” around managing master data. I think you are talking about a general “process-based” approach and so I would take that you would also include BPML also as something that can be used for this. Any executable process instance (that is represented at runtime as either a BPEL or a BPML document) needs to be modeled (design time) using the standard BPMN notation. I guess you agree on this aspect. Here is where I have a difference of opinion.

In our analysis of the types of processes that characterize master data governance (data stewardship for handling duplicates, exceptions, data merge decisions etc) and data integration (events, change data capture, ETL etc), we found that conventional BPM-based models are not sufficient to capture the largely collaborative and knowledge-worker-driven nature of these MDM jobs. In our view, BPM models can be very nicely used to depict well-defined, sequence-based activities with clear definition of steps and process participants, all known up-front. But BPMN, as the notation, is highly unweildy in terms of representing “case handling” process types – which are what most of the data governance tasks are – high degree of collaboration between knowledge workers (data stewards, business SMEs etc), multiple iterations, events occurring randomly (and not in a known sequence and at pre-defined times), actions to be taken being decided at the moment (on the fly, based on the case data context)….all of these variations cannot be modeled in BPMN. So, OMG is also pushing a new modeling notation to capture “Case-like” processes.

In our product, we advocate a State Management-based approach for handling Master Data Management activities – which means, users depict the complete lifecycle of the Hub master data object as a series of States and State Transitions (State Transition models) – transitions, that are triggered by relevant events (which can occur randomly). And, in the State of an object (either while entering or exiting the state or even when the object is in that state) or during state transitions, we can hook in any kind of activity (human worker-driven UI task, a synchronous web service call, invoking a regular BPM process, calling a java class that generates a sequence number, calling a business rule that governs data, anything short-lived, long-lived, human task, system work – almost anything). Thus, end-to-end lifecycle management can be modeled and executed (with a state engine).

However, I agree that if the data management process is fairly well-defined with a few activities and not likely to change often (dynamic) and not be too concerned with human involvement in these tasks, then you might be able to model these within BPMN and have them executed (after generating the BPEL or BPML) by a SOA-based Services Bus.

Can you share your experiences using modeled processes for data management (governance, really) and what typically are the modeling approaches adopted by your customers? Have you collaborated with MDM vendors that advocate a state-based modeling approach for building model-driven trusted data hubs?

Thanks

@Dan thanks for the link- the rest of my drafts folder is pretty murky but I have a few ideas for future posts.

@Bob – A very interesting use case. It sounds like a registry-style MDM, offering data matching services might be the best architecture for you.

@James – I second Dan’s input. As I noted on your blog,
I believe it depends on level of architecture. In a stand-alone application, a SOA is a design framework that allows the encapsulation of business functionality that can be reused. As long as the services inter-operate on a common data store, or pass static data for presentation, then the need for an MDM is minimal. However, as you add additional applications, data about a particular subject area becomes distributed. Whether services are then developed to support composite apps, the integration of data, or retrieval for presentation, then an MDM strategy is critical.

@NM – Your feedback is definitely appreciated.

Joan

@Bob Good point about the difficulties that fraud prevention introduces. Met with Matthew West today and really enjoyed the update on what Infoglide’s Identity Resolution Engine can do.

@James Well written piece at http://jtlog.wordpress.com – keep digging these nuggets out of your “blog drafts” folder!

@NM Thanks for the kind words – we’ll try to keep focusing on great MDM content. Please let us know if there are other topics you’re interested in.

Joan Lawson may drop by to check out and respond to your comments as well.

This also means that these search features may be deployed on the hub as well as on the different data sources and destinations.

Advanced search features may include among other things functionality as:
• Speed, which is a lean factor
• Error tolerance, so you don’t have to spell exactly as in the database and not puzzle with wildcards
• Cross field search – typical party search is provided as “who and where”
• After search navigation, that fulfils the process in one straight forward operation.