The Science of Model-Driven SOA

What do organizations need to be successful in good times and to survive in bad times? According to Richard Veryard what matters is how people and systems collaborate effectively to address emerging business opportunities and threats, in an agile and innovative manner. He calls this Organizational Intelligence.

I think for reaching Organizational Intelligence we need Model-Driven SOA. The point of Model-Driven SOA is to create technology (Service-Oriented Business Applications – SOBA) that truly supports an organization. We have to specify the business with declarative models, these models should directly lead to working software, either by direct execution (e.g. process engine, rule engine) or by transformations to executable models. Even if these transformations are manual, good tools support tracing between business requirements and implementation, thereby enabling methods to assure business-IT alignment.

However, to do Model-Driven SOA in practice we’ll need some kind of framework or process describing what models and transformations we need. Although I have some ideas about this subject, let’s first look at some scientific research in this field.

In the remainder of this post I present two recent (last year) scientific publications researching a framework or methodology providing end-to-end guidance and assistance to refine and transform business models created by business experts into IT models and then to IT implementation:

  • the Business to IT transformation Framework [1], and
  • the Model Driven Service Engineering Process [3].

Business to IT Transformation Framework

Stein, Kühne, and Ivanov [1] have conducted an extensive literature research in the field of model-driven business to IT transformations. They conclude that the reviewed works only cover a subset of the different criteria and present a new framework providing the building blocks of business to IT transformations from a practical point of view.

Mens and Van Gorp [2] distinguish between horizontal and vertical transformations. A horizontal transformation is a transformation where the source and target models reside at the same abstraction level. A vertical transformation is a transformation where the source and target models reside at different abstraction levels. According to Stein, Kühne, and Ivanov [1] most approaches for business to IT transformations follow a horizontal transformation strategy. A horizontal transformation starting with an abstract business process model results in an abstract orchestration model requiring significant refinement efforts to make it executable. An alternative horizontal transformation strategy is to start from a business process model augmented with technical details. However, this forces the business analyst to think in terms of executable business processes.

Due to the previous arguments, Stein, Kühne, and Ivanov [1] formulate the following axiom, which forms the basic assumption for their business to IT transformation framework:

Business process models (e.g. BPMN, EPC) must be platform independent and a platform specific IT implementation (e.g. BPEL) must be derived through a vertical transformation strategy.

Consecutively they come to the following consequences and requirements for their framework:

  • The business process model shall not contain any platform specific details, e. g. references to WSDL artefacts.
  • The business process model should use refineable proxy elements instead.
  • Source models should be restricted to a subset, which can be unambiguously transformed.
  • Full code generation is desirable but not achievable.
  • Target models should be comprehensible for human users.
  • The framework should use iterative development processes through change detection, change visualisation, merge functionalities.

Business to IT transformation framework


Figure 1 – Business to IT transformation framework

Figure 1 exhibits the general business to IT transformation framework [1]. The framework shows three different model perspectives: process, data, and interaction perspective. These perspectives reduce cognitive complexity at design time [1]. The framework also presents two abstraction levels, the business level and the IT level, which are related with vertical transformations.

Model Driven Service Engineering Process

Anaby-Tavor et al. [3] define a model driven service engineering process aimed at providing a methodology giving end-to-end guidance and assistance to refine and transform business models created by business experts into IT models and then to IT implementation.

A service engineering process is a sequence of activities: analysis, strategy design, development, and deployment, done in this order to produce a services system [3].

Model Driven Service Engineering Process

Figure 2 – The Model Driven Service Engineering Process

Figure 2 presents the methodology in three layers. The upper layer shows the service engineering process, the middle layer describes the models supporting each phase of the service engineering process, and the bottom layer describes the aspects of the services system that the models affect. Anaby-Tavor et al. follow the definition of a services system given by Zang et al. [4] which states that a services system is a 6-tuple: <Inputs, Outputs, Goals, Transformation, Components, Sensors>.

In the analysis phase the system requirements are analyzed and modeled. In the next phase a strategy design is conducted to describe the static and dynamic aspects of the services system. Static enterprise models define the components’ black box view. The components collaborate using services, this forms the first step of the dynamic modeling of the enterprise. During the development phase detailed executable data is added leading to execution models describing the control flow of the activities of the services. Finally, sensors use IT management models to oversee the deployment of the services system.

This time I don’t want to give my opinion on these studies, I’m curious what your experiences are with translating organization models into software?

Do you use a framework? If so, what framework?

I’d like to hear your thoughts in the comments.


[1] Sebastian Stein, Stefan Kühne, and Konstantin Ivanov. Business to IT Transformations Revisited. In Cesare Pautasso and Jana Koehler, editors, 1st International Workshop on Model-Driven Engineering for Business Process Management, pages 1-12, Milano, Italy, September 2008.

[2] Tom Mens and Pieter Van Gorp. A taxonomy of model transformation. Electr. Notes Theor. Comput. Sci., 152:125-142, 2006.

[3] A. Anaby-Tavor, D. Amid, A. Sela, A. Fisher, Kuo Zhang, and Ou Tie Jun. Towards a Model Driven Service Engineering Process. Congress on Services – Part I, 2008. SERVICES ’08. IEEE, pages 503-510, July 2008.

[4] L Zhang, J Zhang, and H Cai. Services Computing: Core Enabling Technology of the Modern Services Industry. Tsinghua University Press, 2007.

4 Comments Added

Join Discussion
  1. Richard Veryard April 15, 2009 | Reply

    Thanks for your link to my post on Organizational Intelligence. I can certainly see the value of Model-Driven SOA, but I am not convinced that it is neither necessary or sufficient for Organizational Intelligence.
    As far as I can see, the kind of models you need for Model-Driven SOA are structural ones – models that could be drawn using UML or BPMN or ArchiMate.
    The kind of models I need for organizational intelligence are more like the business notion of business model (as in “The Business Model for Newspapers is Broken”).
    At present, I see SOA and organizational intelligence as separate practices, with different skills and notations, although I’d very much like to bring them together. I shall be talking about this in my workshop in EAC 2009.

  2. Wen Zhu April 20, 2009 | Reply

    I am not sure whether you are aware of the SoaML standard recently adopted by the OMG ( It actually intents to address SOA modeling at all levels:
    – At CIM level (Business modeling), it allows you model service architectures as communities of participants;
    – At PIM level (Abstract IT), it allows specification of service contracts, which can then be mapped to artifacts like WSDL or BPMN
    – At PSM level (Platform level), we can generate executable artifacts for a particular technology, e.g. Java EE.
    We have seen a lot of interests in SoaML, and we have open source provisioning engine available now (

  3. Johan den Haan April 21, 2009 | Reply

    Hi When,
    I’m aware of the SoaML standard and I have covered ModelPro in my microblog –
    However, by now I haven’t taken the time to look in-depth at it. So, if you have any suggestions for a starting point / quick overview I’d like to hear it!

  4. Jukka Tamminen April 27, 2009 | Reply

    The most important thing that OO discovered was the distribution and encapsulation on behavior. That yields 1/10 complexity of models where behavior is teared out of structure.
    See: my site +
    regards Jukka Tamminen

Leave a Reply