Models that matter; Return on Modelling Effort

In the context of enterprise architecture, IT architecture, (software) system development, et cetera, we use several models. Some models have a descriptive nature (e.g. UML, ArchiMate and DEMO models) and some have a prescriptive nature (e.g. sets of business rules and architecture principles).

All of these models are created for many different purposes. At the same time, the creation of these models takes time and effort. In other words, they cost money. This raises the question of how these investments can be put to good use? How to increase the return on investments put into models? In other words, how to achieve return on modelling effort (RoME)?

Since a year or two, my research group at the University of Nijmegen has been using the return on modelling effort question as one of the drivers in its research activities.

Below I'll venture out and explore some potential returns of modelling efforts. Knowing beforehand what the expected return of modelling effort for a given modelling endeavour would be, also provides insight into a stopping criterion for the actual modelling. All modelling effort should be focussed towards the achievement of the planned/expected returns. In the past we did some explorative work on these issues:
  1. Quality of modelling
  2. Modelling strategies
  3. Making modelling strategies explicit
  4. Requirements on modelling
  5. Understanding the act of modelling
Taking a return on modelling effort perspective on modelling may sound as an obvious thing to do. Nevertheless, most modelling/architecture approaches do not require modellers to reflect on the business-case for their modelling activities. As a result, there tends to be no stopping criterion to decide when the model is finished. Even more, some early approaches to the quality of modelling presumed quality of models to be an objective property of the model in isolation independent of the reasons for which the model was created, thus completely ignoring the need for a cost/benefit analysis.

In the context of enterprise architecture, the return on modelling effort is also a driving principle in Capgemini's book on Enterprise Architecture - Creating value by informed governance as well as the book by Johnson and Ekstedt on Enterprise Architecture - Models and Analyses for Information Systems Decision Making.

As promised earlier on in this entry, I would discuss some potential returns of modelling efforts. Of course I cannot list benefits in detail, but hopefully some of these will inspire you:
  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!).
I'm sure I haven't listed all potential benefits, so consider this as an invitation to provide more suggestions. I might gather them in a future blog entry.


  1. Good start!

    Let's take this up and make it an article.



  2. Hi Erik, here are a few more possible benefits:
    Models can be used as an instrument for knowledge sharing or as part of a knowledge retention strategy
    Models can be used as an (intermediate) instrument in creative development processes (e.g. strategy development, architecture design, architecture trade-off etc.)
    Models can be used as an instrument in discussing/solving disputes between conflicting stakeholders
    Models can be used to explain aspects that are too complex for certain stakeholders to envision (aligning to the stakeholder's mental model )

    Greetings, Louis Dietvorst


Post a Comment

Popular posts from this blog

Three perspectives on enterprise architecture

Fundamentally understanding IT? - Why Web 2.0 needs architects. Part II