Tuesday, 11 December 2012

Model Driven Organisations

My recent work has been investigating approaches to model aspects of an organisation. This was motivated a while back by a presentation on Enterprise Architecture (EA) that I attended and being frustrated with the lack of precision offered by current approaches and the large number of different concepts involved. Work has evolved in two directions.

Firstly, we developed the language LEAP as an executable component-based modelling language based on the hypothesis that many of the features found in current EA modelling languages and analysis processes can be reduced to a small collection of concepts. Current LEAP work aims to integrate intentional aspects of goal-based languages such as KAOS and i* into components.

The second direction addresses the problems that are faced by a modern organisation in terms of its complexity. It is rare for any single individual to have a clear understanding of its information, IT systems, business context and processes. This makes an organisation difficult to manage and maintain. Issues such as regulatory compliance, mergers and acquisitions, outsourcing, etc., can easily get bogged down in detail. Colleagues Balbir BarnRobert France, Ulrich FrankVinay Kulkarni and I have proposed the idea of the Model Driven Organization (MDO) to help address these issues. The idea is that aspects of a business can be modelled and the models can be used to support key EA issues. Models are good at abstracting from implementation detail which makes it easier to perform key analyses and to replace specific implementation platforms. Models can be sliced and presented to different stakeholders in domain-specific ways making it easier for them to understand how an organisation operates without being a technology specialist.

Taking this idea to its limit, all aspects of an organisation could be modelled and the organisation could be run directly from the models; changing the model will directly affect the organisation. What would need to be modelled? The diagram below presents some of the features that a language for MDO would need to offer:

The MDO provides a challenging application domain for model-based engineering research. 


  1. To communicate these ideas to a wider audience, my experience is that they need to be packaged into a concrete example such as this one http://s23m.com/logistics/index.html. The value of formal models is not obvious to anyone outside the small formal modelling community.

    It is also worthwhile noting that many Enterprise Architects are unfamiliar with the use of formal models, and prefer the use of informal models that are unsuitable for automated processing. The somewhat esoteric jargons used by the formal modelling community stand in the way of wider adoption. Additional barriers are created by over-hyped industry standards that offer very little in the way of semantic interoperability.

    In most organisations, including larger corporations, there is no one with extensive experience in formal modelling. This effectively limits the idea of a Model Driven Organisation to a small set of organisations.

    Formal models can be used effectively when presented in the form of concrete instances, and when implemented in software solutions that are described as "business configuration software" (or similar), without mentioning the "M" word.

    It remains to be seen whether the hype around big data will lead to a greater awareness of formal models or various kinds and to a greater awareness of the automation potential inherent in high quality metadata.

  2. I agree that (sadly) formal modelling is not well understood or adopted within the EA community and that the current batch of informal notations are unsuitable for automated processing.

    One motivation for our work is to raise the profile of organisational modelling within the modelling community. MDA has been very popular, but it really just addresses a systems-view. There is a need for the "formal" modelling community to develop integrated techniques that address much broader problems.

    I also agree that meta-data is the key. For me, modelling is simply the realisation that information that would otherwise be hidden because it is implicit, or available during a different development phase, or operational should be made explicit in terms of structured data. The form of the data can occur in a variety of ways, for example using standards such as UML, data structures in a programming language or as configuration tables.