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.

My 1997 system design used a business repository as the design-end of the application platform. Any change made to the data definitions in the repository will translate to changes in all parts of the applications for CRM, CRM, BPM and SOA interfaces as soon as they are tested and deployed. We actually execute the models! I proposed the combination of inbound and outbound document management ECM with BPM in 2001. We proposed the merging of CRM and BPM in 2005.

When we change a CLASS definition (which is not C++ or Java code, but a OO model description in the repository) because for example the data definition of an SOA interface changes, then this change will be effective through all applications that use that CLASS. Therefore the integration of silos by means of SOA and Eclipse/Java to map the SOA to internal programs creates the huge ‘investments’ that stop products from being OPEN. Linking best-of-breed software with SOA will not produce a best-of-breed system. Clearly integration – and why not by means of SOA – is an essential capability for any product. We joined OASIS to be able to influence the direction of CMIS, for example. We typically install and integrate with ECM, CRM and BPM products, but SOA integration does not yet give you a common user interface and end-to-end processes.

One argument against the consolidated solution that I propose is that ‘we have a substantial investment in XXX’. So what? I am told that businesses do not want to be dependent on a single vendor and prefer OPEN and STANDARD products, when there is no such thing. People have ‘invested’ substantial amounts of gas into their cars and still go out and buy a new one. Enterprises have invested substantial amounts in ECM and still go out and buy Sharepoint, despite all its incredible limitations. Now they ‘invest’ in Sharepoint custom coding … and there is nothing OPEN about Sharepoint at all. That is the reason why we are also offering Sharepoint integration and all processes/cases defined in Papyrus can be accessed through a Sharepoint WebParts GUI.

Businesses have bought ECM, CRM, BPM and ‘you name it’ and they are always ‘locked-in’ because none of these products are OPEN in the sense that you can replace them with another OPEN solution for a reasonable effort and retain all the capabilities. Especially those products with substantial investments, because that means a lot of customizations. OPEN does never happen. Not in my pragmatic ‘real world’.

While the market is slowly waking up to the possibilities, we started to develop a consolidated solution in 1997 and installed the first large healthcare application (3500 users!) on the Papyrus Platform in the US in 2001. My tries to convince US analysts at the time that merging ECM inbound and outbound content (which are the most essential process resources not mentioned by any of the above) with BPM and CRM processes was met with blank eyes. Until we added the BPMN process view in 2009 to our state/event/rule driven processes no one was willing to even consider us BPM. And having functionality across-market fragments is too difficult to grasp for analysts, so they still don’t know where to put us …

Attaching BPMN Flows to Goals in ACM

In fact the modeling power of the Papyrus Repository is so great that anything that any DoDAF specs can be modeled. If there is graphical representation, then a view/edit frontend can be added as we did for UML, RAD Role-Acitivity Diagrams and finally BPMN. Yes, BPMN was not encoded into Papyrus, but modeled (mostly using XPDL attributes) and is executed as such. Therefore it was easy to expand it with the artifacts that represent the resources, activities, capabilities and performers of for example the high-level concepts in  DoDAF proposed by Michael zur Mühlen. We also added Balanced Scorecard strategic objectives and operational targets and linked them to the process goals.  Our customers can use the adaptive process capability to manage business innnovation programs or IT projects. I know that the business planning side can be TOP-DOWN graphically modeled in for example ARIS and you need a huge project bureaucracy to get there because of it.

With Papyrus you can MODEL AND EXECUTE inside a fairly simple adaptive process framework. The main difference is that I see the transparency for strategy coming TOP-DOWN, the customer outcomes OUTSIDE-IN, management targets INSIDE-OUT, and how to execute from the BOTTOM-UP. That substantially reduces bureuacracy and makes the business REAL-TIME ADAPTIVE.

As Craig LeClair of Forrester said to me once: ‘Max, Papyrus can’t be everything.’ My answer was: ‘Yes it can, you just can’t imagine it.’