Securing modelling effort

The role of models in enterprise transformations
When enterprises aim to meet new challenges, or optimise themselves in terms of increased flexibility, effectiveness, or efficiency, they will transform themselves. In other words, they will engage themselves in a deliberate change. This may involve changes to several aspects, including organisational structures, their processes, their culture, as well as their IT systems.

In my view, such transformations will become increasingly model intensive in the sense that the driving process of (continuously!) assessing what to change, selecting the desired direction of a change, and consequently acting out the change, involves models in different roles (see one of my earlier blogs). On the one hand, the increase of the use of models is driven by the increasing role of IT as an integral part of business operations, bringing the model-intensive nature of IT development to enterprise transformation. On the other hand, the transformation of "the business" itself becomes model-intensive as well, due to business process management, compliance regulations, etc. Even more, within the organisational sciences, models play an (increasingly) important role as well in terms of problem structuring, system dynamics, et cetera.

Within fields such as enterprise architecture, a distinction is made between models and views. Within the context of this blog, however, I will not necessarily make such a distinction, since both can be regarded as models in a broader sense. Furthermore, sets of business rules and sets of architecture principles can be regarded as models as well, so we are not just talking about models of a diagramatic or graphical nature.

The models used during enterprise transformations range from high level architectural models, which have normative role towards lower levels of architectures, to the more detailed models used within change projects, which may involve business rules, business process models, and even highly formalised models that can be executed, interpreted, or compiled directly by computers. In other words, the models may range from informal sketches to models with a more explicit and formal syntax, to models with a mathematically well defined semantics.

Return on modelling effort
A lot of time and effort is put in the creation of these models. In other words, these models represent a large investment to enterprises. In making these investments, it is sensible to guard a proper return on modelling effort. As discussed in an older blog on return on modelling effort, some potential returns on investments for example are:

1. Models may provide insight. Either directly or indirectly by deriving views from the models that answer specific questions. This insight might be needed towards an informing purpose, a decision making purpose, analytical purpose, etc.
   
2. Models may provide guidance towards the execution of work. This could be design activities, the operational execution of work, etc.
   
3. Models can act as a formal a steering/regulation instrument.
   
4. They can act as a common frame of reference, i.e. an ontology.
   
5. They can be directly executable or at least formally interpretable (MDS and MDA!).

Securing modelling effort
The possible returns of modelling effort will not always (need to) yield their returns immediately after the modelling effort. In general, the returns may (also) follow at a later stage. This does stress the importance to secure the investments made in terms of these models, in order to guard their potential returns. In practice, however, these investments are treated rather badly. For example:

1. models are not kept up-to-date without making conscious decision to disinvest in the actuality of the model,
2. 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 model or UML model).

Securing modelling efforts will involve several aspects. Some of them could include:

1. Guard the actuality of models - The actuality of models can be validated by using mining techniques. For example, logs from work flow systems and ERP systems can be used to continuously (and automatically!) evaluate the validity of business process models (see e.g. process mining). Another example would be the use of logs from an enterprise service bus to monitor which software components depent on each other and see if reality complies to the "theoretical" perspective at the architecture level.
   
   
2. Model management - Models with a remaining return on modelling effort should be well managed. This can be done using repositories. However, this should not just pertain to the models themselves, but also involve a report on the context and intent for wich the models were created. At the same, time we should be aware that there are several models that can be discarded because they have served their purpose, e.g. because they were only intended to align people's focus, or to express an intermediate idea.
   
   
3. Coherence of models - Separate from the fact that it is necessary to remain a strong focus on a return on modelling effort, there is also a lot to be gained from a better integration between the different models produced during modelling. These models range cover the entire chain of transformations, 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 would only be natural for these models to have a stronger coherence. Such an increased coherence would, for example, enable the re-use of investments made in models earlier on in a transformation process. Currently this is hampered by the disconnectedness of the modelling languages used, such as BPMN, UML, ArchiMate, et cetera.
   

In a future blog I intend to elaborate more on the latter issue of coherence of models.