An Enterprise Ontology based approach to Model-Driven Engineering

Today I successfully presented the results of my thesis at the Delft University of Technology. The goal of my research was:

Design an MDEE approach based on a sound theoretical foundation, providing end-to-end guidance to refine and transform an organization model into an IT system supporting that organization.

MDEE is the abbreviation of Model-Driven Enterprise Engineering, which is the name of the Model-Driven Engineering approach resulting from my research. On this blog I mostly call such an approach Model-Driven SOA. See for example my posts: SOA is dead; long live Model-Driven SOA and A Framework for Model-Driven SOA.

In this article I want to give you a short overview of the results of my research. I have also added the slides of my presentation.

Johan den Haan presenting an Enterprise Ontology based approach to Model-Driven Engineering

Why another research on Model-Driven Engineering?

Because of the lack of a significant increase of productivity in the last 20 years we are still in a huge need for increasing the return a company derives from its software development effort. Model-Driven Engineering (MDE) aims to raise the level of abstraction in application modeling and increase automation in application development, thereby increasing the productivity in software development.

The Model-Driven Architecture tries to define an MDE approach, but is mainly focused on technical variability and lacks formalism. Other approaches, using Domain-Specific Languages, do not define a process or framework at all. Research in this area is focused on language engineering and multi-modeling. Literature on formalizing MDE is focused on defining the concepts and assets needed to construct an MDE framework. We only know one attempt on formulating an end-to-end (from business model to IT implementation) MDE approach, but the resulting framework does not have a theoretical foundation (see the science of model-driven SOA).

Concluding we can state that no end-to-end MDE approach exists describing abstraction layers, models, modeling languages, and transformations, based on a formal, theoretical foundation. My thesis presents an MDE approach based on a sound theoretical foundation, providing end-to-end guidance to refine and transform an organization model into an IT system supporting that organization.

The Model-Driven Enterprise Engineering approach

The theory of Enterprise Ontology constitutes the basis of my Model-Driven Enterprise Engineering (MDEE) approach. MDEE is also based on the Generic System Development Process which states that a system development process consists of five steps: reverse engineering, function design, construction design, engineering, and implementation. Figure 1 gives an overview of MDEE.

The Model-Driven Enterprise Engineering (MDEE) approach

 

Figure 1 – The Model-Driven Enterprise Engineering approach

The first step in our MDEE approach starts with interviews and the documentation of an organization and results in an organization model. We call this reverse engineering.
Using service identification a set of services is identified which are needed to support this organization. These services are specified in the service specification step, resulting in a service specification model. Service identification and service specification together form the function design step of our MDEE approach.

The next step in our MDEE approach is construction design. As shown in Figure 1 this steps consists of two parallel tracks. Service orchestrations are derived from the previous models based on a set of derivation rules. Another set of derivation rules defines how to derive BCI3D input tables from the previous models. The component identification step, implemented with BCI3D, identifies a set of components based on these tables. The identified components are specified in the component specification step. The model created in the construction design step is a business component construction model and consists of service orchestrations and a component diagram.

In the engineering step the business component construction model is transformed and refined into a business component implementation model. As exhibited in Figure 1 this is done by defining an implementation for the orchestrations, human services, IT services, and data services. These implementations are combined into SCA composites which form the business component implementation model. This final model can be implemented by executing it on engines, resulting in a working IT system.

Conclusions

As enterprise ontology is a way of thinking, different modelers create the same model for the same organization. This means our MDEE approach has a stable basis. While our MDEE approach is also model-driven and consists of steps which are partly automatable the quality of the resulting IT system can be very high depending on the quality of the MDEE approach itself. In other words: as the IT system is derived automatically (for a big part) from the organization model and the organization model is stable because of the underlying theory, the quality of the IT system can be ensured by improving the quality of the MDEE approach itself.

In our definition of MDE the automation of transformations is an important aspect. Hence, the question is to what extend the steps in our MDEE approach are automatable. The steps in our MDEE approach consist of two parts: a transformation part and a refinement part. The transformation part is defined with derivation rules and specifies what elements of the output model can be directly derived from the input model. This part can be fully automated with model transformations. The refinement part describes what additional elements have to be added to produce the output model. In this part decisions have to be made about what elements to add and how they are modeled. These decisions can be ‘hard-coded’ in transformations, thereby also automating this part of an MDEE step. However, a part of the decisions will always stay human decisions. The more an MDEE approach is tailored to a specific domain (e.g. the approach is only applicable to insurance companies), the more decisions can be taken beforehand and thus ‘hard-coded’ in automated transformations.

Because a significant part of the steps in our MDEE approach can be automated and the implementation model (which is directly executable) is defined in a much higher level language than currently existing programming languages, we can conclude that our approach fully complies to the definition of MDE. Our MDEE approach does raise the level of abstraction in program specification and it increases the automation in program development. Hence, our MDEE approach can finally deliver the increase in productivity we are waiting for quite some years.

Concluding we can state that we succeeded in designing an MDEE approach based on a sound theoretical foundation, providing end-to-end guidance to refine and transform an organization model into an IT system supporting that organization. As we have shown with our running example, starring the Protector case, our MDEE approach is applicable to real-life cases. However, due to the limited scope of our research there are some research limitations.

More information

You can find the slides of the presentation of the research results below. They give some more details about the MDEE approach and the used languages and techniques.

In the near future I will post more information about MDEE. I am currently working on some scientific papers based on my research.

What do you think about MDEE?

Do you think extending model driven approaches with models of the organization does have advantages?

MDEE is quite scientific; do you see parts which can be useful in practice?

3 Comments Added

Join Discussion
  1. Skip Boettger October 22, 2009 | Reply

    I think it is incredible that you pulled off a thesis based on something that Industry practitioners in EA, EBA, and Knowledge Discipline Architecture have been doing for the last three decades. The failures in the results the great majority of the time are because of a lack of ‘commitment and will’ on the clients’ part, not the Practitioner.
    Respectfully.

  2. Johan den Haan October 22, 2009 | Reply

    Hi Skip,
    Thanks for your comment.
    Can you explain this sentence a bit more?
    The failures in the results the great majority of the time are because of a lack of ‘commitment and will’ on the clients’ part, not the Practitioner.
    Thanks in advance!

  3. Marwane March 19, 2010 | Reply

    Lol, I think our friend skip is a typical frustrated practitioner or purist of MDD, the practitioner makes no faults, he is perfect and posseses the ultimate knowledge so no research needed, just these “stupid” clients, they keep you from using your revlutionary techniques…just assuming that these things have been done in the last three decades in industry is as idiocratic as assuming that we need invent no programming languages because people have been programming other people to do stuff since several centuries ago…what an insight and pragmatism mr. Skip! I must say I am impressed by your visionary approach to model driven SOA.

Leave a Reply