Coherent modelling landscapes

The role of models in enterprise transformation
My previous blog was concerned with securing modelling effort. A specific aspect in this regard is the coherence of models. As promised, I will now elaborate on the coherence of models. Before reading this blog, it therefore makes sense to first read the previous one, where I also argue how enterprise transformation is a model-intensive activity, and why it therefore makes sense to secure modelling efforts.

The set of models produced during an enterprise transformation cover the entire chain of a transformation, ranging from models used for problem analysis, via architecture models, to specific designs. While these models clearly deal with different aspects of the enterprise, and are concerned with different stages during the transformation, they still deal with the same domain. Therefore, it is only natural to expect these models to have a strong coherence. Such an increased coherence would, for example, enable the re-use of investments made in models earlier on in a transformation process (or previous transformation processes!).

Coherence between models
Currently, models produced during one stage of the transformation process (such as an ArchiMate model) quite often have to be re-drawn, or even re-modelled, in some other language in a later stage of the process (such as a BPMN or a UML model). This leads to unnecessary delays and costs during a transformation process, and basicially constitutes a major disinvestment.

The coherence (and automatic transformations) between different models is hampered due to the inherent disconnectedness of the modelling languages used, such as BPMN, UML, ArchiMate, et cetera. With "inherent disconnectedness" I refer to the fact that the meta-models underlying these languages have (from their designs) no formal connections. At the same, time an actor used in e.g. an ArchiMate model will re-appear as an actor in a BPMN model, while this latter model may also provide more details of the business process used in the original ArchiMate model. Of course it is possible to provide a mapping from (relavant parts of) an ArchiMate model to a BPMN model. However:

1. A better integration of the meta-models would make such transformations more easy. A BPMN model provides a detailed view of the actual process and the roles of the actors involved, than what an ArchiMate model would. Therefore, one would expect the BPMN meta-model to be a specialisation of (part of) the ArchiMate meta-model as well. Regretfully, this is not the case at present, but might be strived for by the standardisation bodies.
   
   
2. Even more, the needed transformations between e.g. (a relevant part of) an ArchiMate model towards/backwards a BPMN model could we standardised and become part of the body of standards (e.g. supporting boundaryless information flow at the level of models). This would ensure the portability of these transformations between different modelling tools in use by organisations.

Both of these require an active role of the standardisation organisations such as the OMG and The Open Group, as well as their core members to take their responsibility in this.

An even more universal modelling language?
You might argue that the problem of coherence between models can be solved easily by creating one integrated modelling language.

Essentially UML already provides such a language focusing at the level of software applications and their direct usage environment, while ArchiMate provides such a language focussed at the representation of enterprise architectures over different levels of abstraction (from technology via applications to the business level). The operative word here is "focussed". When designing a modelling language, one selects different modelling constructs to express the models. As argued in two earlier papers (1, 2), the modelling concepts included in a modelling language should really provide a real utility in relation to the purpose/focus of the language.

Depending on the stage of an enterprise transformation, the aspects of the enterprise one focusses on, etc, different sets of modelling concepts are necessary. Therefore, a single unified modelling language will be hard to create, and even harder to use. In that sense we are likely to end up with several more focussed languages, with their own added value

At the same time, this does not have to mean that we cannot have coherence between the different models. For example, within a single enterprise transformation, one may use:

• e3Value to model the position of the enterprise in a value web,
• DEMO to elaborate the essential transactions between the enterprise and its environment as well as the essential internal workings of the enterprise,
• ArchiMate to elaborate the enterprise architecture towards IT support for the enterprise's activities and
  
• BPMN and UML to refine things even further to the level of specific applications and business processes.

These are all valid reasons for using the distinctive modelling languages. At the same time, it is only fair to expect to be able to trace the relations between:

1. value exchanges between the enterprise and other actors in a value web (e3Value),
   
2. the transactions between these actors operationalising these value exchanges and the essential processed needed to realise them (DEMO),
   
3. the implementation of these essentual transactions and processes in terms of tangible actors, applications and IT, in terms of an enterprise architecture (ArchiMate),
4. the actual realisation of these artefacts in applications and business processes (BPMN and UML).

In other words, a coherent modelling landscape is called for. To really be able to do so, requires these models to be interrelated, and eventually, the meta-models of the underlying modelling languages. The most basic way of realising this is to at least use persistant naming of actors, processes, etc, accross the different models. However, to explicitly express the fact that a specific value exchange (e3Value) is implemented using a number of transactions (DEMO), requires additional relations matching the two meta-models.

Realising a modelling landscape
The most practical way to proceed at the moment would be to apply a disciplined naming convention for the concepts used. A practical way of doing this would be the use of a domain model of the different domain concepts used accross the specific e3Value, DEMO, ArchiMate, etc, models, and a consequent use of the (names of these) concepts accross the models. Actually, creating such a domain model may also help modellers in the creation of more specific models such as value models and process models, since they can then start from a thorough understanding of the domain. Some of these basic ideas are discussed in two earlier papers (3
and 4).

A more ambitious approach would also require more advanced modelling tools, in which meta-models of different modelling languages are positioned in a hierarchy in such a way that models can also be mutually related and essentially be re-interpreted in terms of more specific meta-models. In the past, dome some initial work has been done in this regard (see 5 and 6). Such a more ambituous approach would also require a more active role of the standardisation organisations such as the OMG and The Open Group.