Preserving the Model

Scott Francis
Next Post
Previous Post
A long-standing debate in the BPM world has centered around whether or not to preserve the model.  It sounds like an esoteric topic, and Keith Swenson’s post: Model Strategy: Preserving vs. Transforming, takes a pretty clinical angle on this debate, and I think lays out the two camps and their respective arguments pretty well. I like his definition of the common ground components:
  • business process enactment: the business process itself has a dynamic component as it moves from the beginning to the end of handling a single case. The process definition does not normally change here, only the process instance or context that records the state of a particular case changes.
  • business process lifecycle: these are the changes that a business process goes through from initial concept, to modeling, to integration, and finally to deployment into an enactment environment.
  • business process improvement: this is the change to a business process that occurs over time through repeated use of the business process lifecycle followed by analysis of how well that version of the business process worked. This is the TQM or continual improvement aspect of BPM.
The two camps then divide themselves into Model Transformers, and Model Preservers.  The Transformer camp, as Keith argues, has roots in long traditions and proven success in software engineering (and related engineering tasks).  For example, 4G tools, UML, and even VLSI chip design applications are good examples – where the picture translates into code through transformation to a new form.  However, the analogy to these prior tools and content areas isn’t perfect.  For one thing, the author of the “picture” was likely the same person who was the consumer of the picture – the engineer (or developer).  It might not literally be the same person, but the same kind of audience. Keith gives a good example of how transformation might apply to a Business Process model:
Coming back to a BPM example: the business analyst might put an activity describing a document review in the business view. This would be transformed to: a activity which sends email informing the person; an activity to check the document out of a repository; an activity to send a reminder message if the response is getting late, and an activity to wait for the response to come back. The programmer might extend this to include notation to handle exceptions and other timeouts that the business person did not include. Later this might be transformed again in order to get the executable code.
This is a pretty good example, though in my experience the business usually thinks of things like email, repository checkout, and reminder messages… However, the programmer very well might have exceptions to handle and other technical details that don’t direclty concern the business person creating the original document.  I think the key thing to note here though, is that to the model transformers, it is okay, and even expected, that by the time the technical folks are done adding their fit-and-finish and details to the model, that it will be unrecognizable to the business (Keith has a great image of simple model transformed to complicated model transformed to XML… surely a format the business won’t relish).  There is great discussion in this camp about something that is a hard problem – the “roundtripping” problem.  Because people can model things that are hard to round-trip.  And they can edit the transformed content, which is not guaranteed to have exactly the same freedoms and restrictions as the modeling environment.  So you have what I would call a “lossy” transformation.  It is not the same as compiling to bytecode and executing, because the expectations is that a developer or engineer will EDIT the “bytecode”… Anyone who has decompiled optimized java bytecode has seen that the compiler makes changes, and it no longer looks like the original code.  If you also edited that bytecode, the resemblance to the original would be even more tenuous. Suffice to say, Round-Tripping is a really-hard-problem for the folks in the Transformation camp.  The best argument I’ve heard from this camp is that you should *not* round-trip, but instead, treat the transformation as a one-way journey.  I think that would be fine, so long as the developer cannot make further changes to the result of the transform. (this is, by the way, what Ismael Ghalimi recommends) The second camp, the Model Preservers, believe the model is the model is the model.  While developers or engineers can ADD to the model, they must do so in a way that preserves the model.  So, integrations, exceptions, etc. can be layered onto that model, but they are layered in context- and without losing the original context of the model.  The concept of Round-Tripping is trivial – the visual and storage and execution are expected to be 100% in-synch, and any difference would be treated as a defect to be fixed, and all three are designed with BPMN as the starting and ending point… So why is preserving the model important?  Because if you embark on the transformation approach, the model that the business creates eventually becomes a piece of paper or image on the screen that isn’t truly relevant to what is running in production.  In traditional software development there might be a very important phase where the business validates that the software developed meets “the spec” as represented in a generally large Word document… But this step can be eliminated if you do model preservation – instead, the business is testing whether the BUSINESS captured the process effectively and correctly, and whether the technical bells and whistles adequately support the process, and no longer testing adherence to a 6-month old specification of requirements. The power of being able to execute the model the business understands is huge.  The power of being able to tie back the analytics to that model (trivially even) is also huge. However, software vendors in either camp still have to execute well on their designs and software development to get good results… And neither approach is easy.  But then, that’s why we buy the software! (or the support contract)
  • johnreynolds

    I’ve thought about this a lot, and will most likely blog about it further… but what’s generally missing in Software Engineering are the mechanisms necessary to “lock down” functional business requirements in a way that prevents developers from (hopefully unintentionally) modifying them.

    In the specific case of BPMN – I think we need to explore “Aspects”… the business “owns” the functional business requirements, including process flow and rules. Developers clearly “own” other aspects, but they should be locked out of changing that which they should not.

    If these aspects can be clearly delineated, then the business guys can look at the business aspects without the developers crud, and perhaps visa versa.

    -John

  • johnreynolds

    I’ve thought about this a lot, and will most likely blog about it further… but what’s generally missing in Software Engineering are the mechanisms necessary to “lock down” functional business requirements in a way that prevents developers from (hopefully unintentionally) modifying them.

    In the specific case of BPMN – I think we need to explore “Aspects”… the business “owns” the functional business requirements, including process flow and rules. Developers clearly “own” other aspects, but they should be locked out of changing that which they should not.

    If these aspects can be clearly delineated, then the business guys can look at the business aspects without the developers crud, and perhaps visa versa.

    -John

  • John –
    The notion of different “aspects” I’ve thought of as “layers” – ie, why can’t we look at the same model, but see different levels of detail or different types of information overlayed on the same basic bones of process….?

    The example I would give is the basic anatomy book with the transparent overlays over the skeleton… you can see the skin, then peel that back and see the muscles, the peel that back and see the organs… etc… And though each layer adheres to the model, it informs the model further, and to the right audience is super-useful… And to the wrong audience the user can either delve deeper to the level they need, or higher to the level of comfort….

  • John –
    The notion of different “aspects” I’ve thought of as “layers” – ie, why can’t we look at the same model, but see different levels of detail or different types of information overlayed on the same basic bones of process….?

    The example I would give is the basic anatomy book with the transparent overlays over the skeleton… you can see the skin, then peel that back and see the muscles, the peel that back and see the organs… etc… And though each layer adheres to the model, it informs the model further, and to the right audience is super-useful… And to the wrong audience the user can either delve deeper to the level they need, or higher to the level of comfort….