Resurgence of the CIM?

So, what’s the really hard bit about building automated business systems or services? Picking the right programming language and understanding how to exploit all its options? Hardly; you only need about a dozen basic concepts to make a programming language, it can’t be all that hard.

No, the hard bit, I think, is understanding what the business process really is, in all its complex and ambiguous detail, complete with special cases at month- or year-end (when perhaps it just gets passed over to Fred, “who understands that stuff”) and so on. And then building this understanding into a logically complete and consistent model. And if you think the individual business practitioners each have a clear, consistent and complete picture of the greater business process they’re involved in, you probably haven’t been involved in a serious business automation project. However, you can’t deliver automation safely until you have effectively achieved completeness and consistency in your understanding of the process (automation lets you get things wrong very fast and very expensively).

Normally, automating a business process involves synthesising (formally or informally) a complete and consistent model or set of models of the process, representing the partial viewpoints of all the practitioners with duplications and ambiguities removed. Models allow you to manage the complexity of the real world and resolve apparent inconsistencies and can be validated by actual practitioners. But, unless you model the manual processes, any automated processes are embedded in how can you validate the automation (you don’t know how it will be used)—or its completeness (perhaps some business-critical special cases are handled manually)?

These models can be described formally (on paper, in a drawing tool) or in someone’s head or as a set of pieces of prototype code. Remember that program code is just another model of part of the business process, albeit one that can be “executed” in order to perform a subset of the process. People who think they don’t use models are probably modelling the real world inside their heads or don’t recognise a program as just a model of the real world.

All of which means that I like a model-driven approach to systems development—perhaps the OMG’s MDA is the best example—and the idea of transforming models into more specific models, adding man-machine boundaries, removing ambiguities and adding constraints, until you arrive at a set of manual procedures and program applications that together perform the business process. And since there are a range of stakeholders in this process, I like the idea of having a central model (or perhaps an interconnected set of models) and giving all stakeholders their own particular view, using the terminology and level of detail that they’re used to, into this one model.

So, this makes me an MDA fanatic, right? Well, only up to a point, Lord Copper. To my mind the most interesting part of the MDA picture is the CIM—the Computation Independent Model—since this represents what the business actually does or wants to do in future. Then, from this you can derive software-oriented models which describe the areas of the business system that will be automated—the PIM (Platform Independent Model) and PSM (Platform Specific Model). The PIM is a technology-neutral description of the model in, say, UML; the PSM adds implementation details necessary for targeting, say, DB2 on an IBM mainframe or MySQL on a desktop PC. This sounds good, although the transformation from CIM to PIM won’t be trivial—quite a lot of the CIM won’t end up in the PIM, but will be implemented as manual procedures, governance rules etc.—but the principle seems to work well. So, I look up the CIM in a fairly authoritative book: “MDA Explained” by Kleppe, Warmer and Bast, with a foreword by Andrew Watson, technical Director of the OMG. I’m looking forward to getting into the meat of how the CIM works and the issues around transformation of CIM into PIM. And what do I find? One reference in the Index, to Page 19 on which there are 3 high-level paragraphs and a diagram. And that is all there is about the CIM in “MDA Explained”. Am I too cynical when I suspect that this is because none of the vendors supporting the OMG have tools to sell that do a lot with the CIM? Well, possibly not, according to Phil Webb, Technology Director at Aptero Solutions: “I don’t think that MDA has explored the CIM level in sufficient detail,” he says, “and certainly most vendors treat it in a very light-weight fashion, diving quickly to the PIM. I suspect that this has a significant amount to do with the technical, UML background to MDA (and the vendors for that matter)”. Has MDA been sufficiently driven by those with a business stakeholding, we wonder, or too much by software modelling tools vendors and IT specialists?

OK, I realise that this isn’t the end of the road for the CIM—the OMG now supports BPMN for business modelling. “Transformation” from CIM to PIM has rather fallen by the wayside, as being “too hard”, which I think is a pity—but perhaps that is a another article (as is the possible confusion with the DMTF CIM—Common Information Model—which is a valuable but somewhat different concept, now supported by the OMG). For now, we have BPMN, we can model the business in BPMN and develop, in this context, the PIM, PSM and possibly execute the PSM using MDA transformations. This may be good enough and BPMN is, it seems to me, a richer way of describing process than the alternative OASIS BPEL which is just a process description language.

But now there’s another issue—whether BPMN is suitable for working on business process with business people (and if business people aren’t involved in the CIM, it has little chance of being much use). Webb’s blog (entry posted on December 23, 2010 by Phil Webb) on this subject gives a good summary of the issues.

I think the issue reminds me of similar issues with Data Flow Diagrams when they were proposed as a way of communicating with business people. After the CASE technologists got hold of them, business people were turned off in droves but, used in the way Tom DeMarco and the Atlantic Systems Guild originally used them (with a bit of flexibility over the rules), business people found them pretty usable.

One real issue, I suspect. is that business people have to come some way towards meeting the technologists as well as vice versa. It’s too easy to say that IT simply has to understand the business—business users often don’t really understand their own processes in detail and the business process actually in use may have real defects—inconsistencies, incompletenesses. Someone has to translate business ambiguity into coded un-ambiguity and if the business leaves this entirely to the programmers it often gets just what is easiest to code—and misses the opportunity to correct its own business process.

On the other hand, if the programmers leave this entirely to the business, they risk building systems that leave out significant use cases that the business just didn’t think of at the time. MDA needs to be able to work with ambiguities and special cases without losing them—even if they may not make it into code (a manual exception process might suffice, for example). So, BPMN needs to be able to bridge the gap between business thinking and technology thinking and, in MDA terms, surely that implies different views into a single underlying model?

Webb agrees that: “multiple views on the same model is certainly one approach; one which can be achieved in a number of ways”.

“One could consider a formal MDA approach where automated transformations can be applied to a formal CIM model,” he continues, “but, as you suggest, the detail required in the CIM to achieve any significant gain here may not be cost-effective, and certainly risks alienating the business user. The other approach is to transform where possible, and to link/trace where not. So even if PIM artefacts cannot be directly derived through automated transformations from the less-detailed CIM, items in the PIM can still be traced back to their CIM forebears”.

Webb goes on to explain: “This provides a looser link between CIM and PIM which allows the CIM (in BMM, BPMN, textual requirements etc.) to be more loosely defined (and therefore more accessible) while still allowing the technical artefacts to be traceable from the business artefacts and vice versa. Is this MDA? Maybe not to the same degree as the technical transformations one can apply between PIM and PSM, but the model still holds everything about the architecture (business & technical) and enables the navigation through the levels”.

I’ll be speaking at an Aptero business breakfast meeting entitled “Analysing Processes with BPMN” in London in early February which will explore this topic further, from a computationally independent (CIM) viewpoint—there is a draft agenda here, but this is still very much up for discussion.

I am convinced that the CIM does merit discussion—largely because it is the first point at which you can start to remove defects. Defects to do with the understanding of what the business really does are the most serious (and expensive) defects in any automation initiative—and they are most cheaply removed before they affect the code or the automated system design. Besides, working on the CIM is a good opportunity for IT and the business to attain mutual trust.