Enterprise Architecture Master Data Process Content Relationship Management ?

The subject of linking Enterprise Architecture efforts and Master Data Management with Business Process Management is now frequently recurring. Let me just say that the direction is an absolute necessity. One approach is the theoretical top-down modeling as employed by for example DoDAF concepts, the US Department of Defense standards efforts, and the other using the free market forces of SW vendors acquiring various other vendors to integrate functionality. There is a kind of fuzziness in definitions of Enterprise and Business Architecture, but the EA is usually more IT oriented and contains details on applications and infrastructure. Because I am concerned with a real-time link to Business Architecture as the input to  process goals, I prefer a third, consolidated approach, where the business (capability) model entities are defined as structures of the IT execution environment.

The first approach is for example well defined by the efforts of Michael zur Mühlen (MzM) in his work to integrate architectures and business processes around the DoDAF models and BPMN. I recognize much of it in the work he did for SAP and the ASAP 7 methodology. It is an all-encompassing and very theoretical approach that will fit slowly planning and operating government organizations. I am not sure if a large dynamic enterprise could survive the rigid structure. I would like to hear your opinion on this. Please comment.

Sandra Kemsley has given a great overview on MzM’s approach on her blog and it was there where I easily found the strong similarities and subtle differences to my approach. The differences can also be seen as substantial depending on your viewpoint. In short, while we model the same things I don’t work top-down, but open all definitions up to the business hierarchy and the customers in real-time for transparency.

The common approach is to place the Business Architecture or Model design on the strategic planning level and have the Master Data Management as design-time tool the IT execution side. That produces the very disconnect that is the problem. It also disconnects the process from strategy and targets. To make the planning capabilities available to business, I propose a business goal-driven approach with the same capabilities, activities, resources and performers (CARP for MzM) as the architectural base for process management. This is clearly visible in the FIVE ELEMENTS of ACM that are available to the business for interaction and not just to business and process designers. I propose to also design and adapt the business model in the executable IT environment.

Like Michael zur Mühlen, I came to the conclusion that the modeling requires more a business (organizational) perspective than a BPMN perspective. Which is why he decided to disallow a number of BPMN features and focus on milestones, handoffs, decisions and procedures. I propose the same and took it one step further. Rather than just using milestones as a structuring of process phases, I decided to use GOALS as the main structuring concept of a process or a case. It does not only structure the process, but it also directly defines the rationale and WHY and there is no need for later process monitoring. It is right there in the process, visible for everyone. Rather than handoffs, we use SUBGOALS to keep the process paths asynchronous. The big advantage is that these are event driven and can also be simply used across process/case boundaries. There is no longer a happy path, but simply fulfilled or unfulfilled goals, with the opportunity of alternative goals defining the happy path on the fly. All real world processes are event-driven and not flows and therefore an event should never throw an exception, but be simply dealt with through a new subgoal. At decision points users input path relevant data or decide to add a new goal to the process or cancel one that is there. When decision points are linked to customer outcome relevant processes then this point becomes in my diction a leverage point that directly influences business results.

Business Architecture (Capabilities) for Objectives, Targets and Goals

In terms of the product-merging approach, Forrester’s Clay Richardson highlights the relationship between MDM and BPM by referencing Software AG buying Data Foundations. Clay is absolutely right too about this requirement, but I wonder about the suggested strength of the combination. Clay references a few more vendors who have BPM products and acquired MDM capability to strengthen his reasoning. No need. The benefits if it works are compelling. But does it work? Can a vendor simply plug an MDM tool into another product? I know from experience that there is no easy way to simply merge two products that were built by different labs and have their own distinctive customer base. OneData MDM has its own Model, Acquisition/Import, Create, Maintain, Distribute, Data Quality, Process Flow, Survivorship, Security, Governance, Workflow, Change Management, Collaboration, Business Rules, Messaging, SOA, Reporting, and Auditing. Will be interesting to see the integration. I prefer consolidation around a common executable model.

While it is great for the developer to have access to a MDM during development, what happens when someone changes anything in the MDM? How are changes migrated to all the products and applications that use compiled code? So a ‘design-time-only’ MDM is only part of the story. The business architecture and processes may be in ARIS with a link to OneData MDM and there goes your promised agility. Any change has to go through the ARIS toolkit and run the complete BPM bureaucracy plus the MDM, because ARIS doesn’t execute, but just manage and measure definitions and process resources. Development, deployment and execution has to be all done someplace else and controlled.

Even if you have a central MDM piece serving multiple SILOS, I haven’t seen one yet that allows for a change in the MDM definition that will automatically translate to changes in all the ECM, CRM and BPM fragments, to their DB tables, content definitions, program calls, business rules, processes and GUIs. Maybe once you will rewrite everything such a solution might be ready by then. Only a consolidated solution can do such a focused deployment by dynamically reading and interpreting the MDM repository at runtime. Let me reiterate that the MDM should also hold the data (object) definitions for the business architecture and enable their link to process management!

Conclusion: All these really brilliant people got it right. I am in total agreement with Michael zur Mühlen, as well as Sandra Kemsley, and Clay Richardson (I finally did meet both in Washington) and all those others who see process not simply as flowcharts but want to connect it to the business strategy and  architecture efforts. YES, as directly as possible, please. But given the current lack of software consolidation, they still need to propose a large BPM bureaucracy that is supposedly a sign of process maturity. Common sense says that processes are mature when business users can achieve a customer outcome without needing weeks to months of process design and implementation. Humans are mature when they do their own thing and not when they need to be told what to do continuously. Hence, once you can get rid of the BPM bureaucracy then your processes might really be mature.

PS: You will find more as to how Papyrus ACM solves these issues on my architecture blog.

I am the founder and Chief Technology Officer of Papyrus Software, a medium size software company offering solutions in communications and process management around the globe. I am also the owner and CEO of MJP Racing, a motorsports company focused on Rallycross or RX, a form of circuit racing on mixed surfaces that has been around for 40 years. I hold 8 national and international championship titles in RX. My team participates in the World Championship along Petter Solberg, Sebastian Loeb and Ken Block.

Tagged with: , , , , ,
Posted in Adaptive Process, Business Architecture, Business Strategy
10 comments on “Enterprise Architecture Master Data Process Content Relationship Management ?
  1. […] This post was mentioned on Twitter by Mridul K Singh and Fauzan Mohamad, TheBusinessArchitect. TheBusinessArchitect said: #BusArch #News Enterprise Architecture Master Data Process Content Relationship …: The common approach is to pla… http://bit.ly/bSXmr8 […]


  2. […] discussed need & an absolute necessity. This blogpost discusses various approches to this end. Business Architecture (Capabilities) for Objectives, Targets and Goals This entry was posted in Data. Bookmark the permalink. ← Data Analysis- unmasking […]


  3. Dear Max,
    I completely share your vision.
    Im with Politecnico di Milano and Webratio (www.webratio.com) and we also have been doing integrated data modeling and application design (and evolution) for 10 years. I’m quite surprised that now all of a sudden people (especially in the BPM field) wake up and understand that this is big value.
    In our approach we envision an integrated model driven development of processes, data, application structure and user interface. We don’t have a suite of enterprise applications like yours, as we focus on tailored web application development, but I strongly believe that model integration, alignment and continuous cross-validation down to the implementation is the only response to the complex needs of today’s enterprises.
    If you want to have a look, here are some materials on our work:


    MDD response to BPM trends (including MDM integration):

    On a large-scale banking industrial experience:

    I would be glad to get your feedback.


    • Marco, this sounds like a great approach to BPM and process oriented applications. I fully agree with the model oriented approach to creating applications.

      I am already more focused on giving the flexibility to create the process and the user interface to the business user, because as you mention in one of your presentations, there is substantial interest in the industry – not yet in the market – in adding social concepts to BPM. I do not see it as enough to provide the social interaction during the design stage, and simply allowing twittering does not add process value.

      There is the new idea of Activity Streams that collects user interactions from different silos and mines them for process and case work. That has some similarities with my work to bring the silos into one frontend and allow freeflow but managed collaboration towards process goals.

      My next post will be on the relationship of Social Media and Process Management. Thanks, Max


  4. Janet Kuntz says:

    Very interesting article that points out the challenge between theory and practice. We are creating an enterprise information architecture that is based on the enterprise business architecture. The information architecture is activity-based, and the methodology for defining our information outputs and those that are ‘records’ is processed based. Our challenge is integrating our process methodology with the application development metholodogy. We are trying to integrate the two, but it requires significant change management practices. Once that’s overcome – our custom apps will be integrated and support the enterprise information architecture and the organization’s results-based framework, however off-the-shelf software will pose another challenge. Your article raises these issues and more… thanks


    • Janet, thanks for reading and commenting. If you refer to off-the-shelf software as hard.coded applications, or BPM or MDM modelling environment then I totally agree with you.

      That is the reason why we developed a model-preserving technology that allows you to model the architecture and the processes in one environment and execute the processes to meet, objectives, targets and goals.

      EA and MDM and execution in one place. The consolidation solves all the challenges you could encounter by integration process you describe. The change management and deployment is handled by our platform. As everything is OO state/event/rule modeled, there is no programming effort and the processes can be created by the business with or without the help of BPMN.


  5. […] Master Data for Process, Content and Relationships I want to elaborate here on the EA to MDM and BPM, CRM, ECM relationship as discussed in my related Real World post. […]


  6. […] Process Maturity – Max J. Pucher For me process maturity is achieved when the users can immediately execute […]


  7. […] with events, rules and goals. BPMS miss the capability to deal with random events. Therefore, Michael zur Mühlen cuts BPMN back to simple ACM-like task management. Event listeners in BPMN mostly break the flow and it is very […]


  8. […] October, 24th, 2010 – Enterprise Architecture Consolidated […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Max J. Pucher
© 2007-19

by Max J. Pucher. All rights reserved.

Real World Statistics
  • 234,703 readers

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 367 other followers

ISIS Papyrus on Twitter
%d bloggers like this: