At the 2. of august, I presented my study plan for my supervisor Kjeld Schmidt and for two other senior staff members of ITU, Kasper Østerbye and Yvonne Dittrich. Anther PhD student, Lene Pries-Heje, also presented her study plan.

My plan was accepted by the seniors and the next step is now to submit it to the PhD study board at ITU, which will approve or reject it in the beginning of october. 

You can find the plan under the download section under the Diverse category and the presentation of the plan under the presentation category, or you can read it directly here.

Introduction

This study plan describes how the Industrial PhD study for Steen Brahe will elapse. The study was initiated at the 1. of April 2005 with an expected end date at the 1. of April 2008. The project is carried out between Danske Bank and the IT University of Copenhagen under the Danish Industrial PhD programme.

Project description

Objective

The main objective of this work is to describe requirements and make prototype tools to heighten the level of abstraction at which business processes are developed as executable workflows. It follows the new software development paradigm, Model Driven Engineering (MDE), which focuses on heightening the level of abstract for IT implementation from the code centric level to focus on models. The focus will be on tool enabling customisation of Domain Specific Languages for modelling the business processes, customisation of the transformation of the model to code, and customisation of implementation patterns used under the transformation.

Heightening the level of abstraction for the IT development of business processes from the platform specific level or code level to a level where the solution is modelled should make it simpler, faster, and less error prone to implement a business process. For a company this will result in a faster adaptation to a changing market and cut in expenses.

The vision is that the transformation from business process model to IT implementation is complete, i.e. no changes have to be made to the generated code. This vision may hold in some cases, but in the complex real world where the MDE approach or paradigm is quite new, changes often have to be made in generated code. These changes must survive future transformations when the model is changed. It is the secondary objective of the project to describe how changes in generated code can survive transformations of a changed model.

Background

Our world is becoming more and more dynamic. National borders disappear and markets are growing worldwide. It is now more necessary than ever that companies focus on expenses and how to adapt quickly to a changing market. The companies that are first to recognise a change in the marked and to change its business towards it will be able to get a larger share of the market. Others will disappear.

One way a company is able to decrease expenses, get higher productivity and be able to change its businesses fast to a changing market is by defining and implementing its business processes as executable workflows. This is why one of the strongest driving factors in the Information Technology industry today is business process integration and automation.

But defining and implementing business processes as workflows is complex and challenging in many ways. One of the challenges is that it involves different kind of people with different kind of skills and is a discipline that is not researched extensively. A business analyst defines the high-level logical business process, which a process developer implements and enriches at the platform specific level. When the business analyst makes a change in the model, the process developer has to make the similar change at the platform specific level.

At Danske Bank, the founder of this project, we have over a three year period been implementing a large workflow management system. During the implementation of this system and implementation of business processes we have experienced the challenges that exist in defining workflows based on business process models. This project is an outcome of the experienced challenges.

A new software development paradigm, Model Driven Engineering (MDE), is beginning to emerge. MDE focuses on models as the primary development artefact in contrast to most development practice today, where the code is the primary development artefact. The key idea behind MDE is separation of business/application logic from the technology. When a solution to a problem is developed as a model, it is independent of technology. If the technology changes, which can often happen, transformers can be developed, which transform models to a specific technology. In this way, the solution does not have to be reimplemented manually in a new technology because the models describe the solution in a precise way separated from the technology.

Using MDE for developing business process models and the corresponding implementations enables the business analyst and the process developer to work on the same model or several related models. Instead of writing code, the process developer inserts the required information in a model. This model can then be transformed to code. There are several advances;

1. The solution is expressed in direct terms in the modelling language instead of being hidden in the code.
2. Repeating implementation patterns can be generated from the model.
3. Faster development because code is generated
4. Less error prone because repeating implementation patterns are generated and not hand coded.
5. The model documents how the business process is executed.

The area of MDE is still young and very much in evolution. The Object Management Group (OMG) has proposed an initiative for interoperability called Model Driven Architecture (MDA). This initiate is a realisation of the MDE vision around a set of other OMG standards like UML, MOF, XMI, OCL and CWM. Because of the young age of MDE the principles and the goals are not well understood. Therefore the OMG standards are still evolving.

The OMG MDA initiative operates with two models; a Platform Independent Model (PIM), which represents the business/application logic, and a Platform Specific Model (PSM), which represents the business/application logic mapped to a specific technology platform. A key concept of MDA is transformation between models. A business analyst can specify the business logic in one model (PIM), which can be transformed to model (PSM) containing information about a specific technology. This model can either be generated completely or partially. If it is only generated partially, an IT developer must further enrich the model with technology and enterprise specific information. The goal of MDA is to make the transformation complete so no further work has to be done at the PSM. A lot of challenges have to be solved to reach this point.

Software vendors are beginning to make tools to support Model Driven Software Development (MDSD), but are using different standards and terminologies. Not all vendors agree on the OMG standards which make interoperability between different tools difficult. Tool support for MDSD regarding business process modelling and implementation are available, but because of the relatively young age of the MDE paradigm, no agreed upon standards and no complete understanding of the principles in MDE, this tool support is only very limited.

Challenges

Several challenges exist for modelling a business process and implementing it as an executable workflow. The challenges can be grouped in four categories:

1. Modelling the business process (PIM)

Each enterprise does business on its own ways. It describes its processes in specific terms and has specific requirements for how to describe the process and tasks and how it should be executed. Tool vendors on the other hand make general modelling tools and general languages, which all enterprises have to use. It can be difficult, and often impossible to use the general modelling tool to model the business processes for an enterprise, if the enterprise does not model their processes using the same methodologies and terms as the tool vendors. It requires a large degree of flexibility and customization possibilities in the modelling tool. The enterprises may need their own Domain Specific Languages to model their business logic in a precise and direct way.

1. Transformation of the business process model to platform specific implementation(PSM)

After a business process has been modelled, it may be implemented as an executable workflow. This requires the model to be transformed / translated into the programming language used as implementation (PSM). Enterprises will often have reoccurring implementation patterns for certain artefacts in the business model. No methods or tools support the enterprise to define these patterns and how they should be combined and customised with the business model, when it is transformed into a PSM. The consequence is that the transformation only produces a PSM shell, and afterward a lot of repeatedly manual implementation work has to be done, which is time consuming, expensive and error prone. The enterprises need to be able to attach custom transformations and custom implementation patterns to the elements in their own Domain Specific Language as suggested above.

1. Consistency between the PSM and the PIM

After transforming the business process model (PIM) to a PSM, two or more models exist. As described above, a lot of manual implementation work may have to be done after the transformation by the process developer. If the business analyst changes the business process model, there is no more consistency between the PIM and the PSM. A transformation of the PIM to a PSM will override the implementation details made earlier by the process developer. If it is not possible to keep the two models synchronised, changes have to be made in two different models in the rest of the lifetime of the PIM and the PSM and the transformation from the PIM to the PSM can only be made the first time, where the PSM does not yet exist. The inconsistency of the two models results in that the abstraction level of the development process has not been lifted; each change in the PIM has to be manually implemented at the PSM.

1. Model driven development process

There are several people involved in describing a business process and implement it as an executable workflow. A business analyst describes the high level business process. An IT architect ensures that the business process conforms to the business process management system used in the organisation, and an IT developer makes the implementation details for the executable workflow. The development process is complex because two worlds meet; the intuitive and not strictly described business world must be mapped to the strictly described IT world, where rules and models must be described semantically correct and not only by words. It is neither understood how many layers of models are required to describe a business problem and at what level of abstraction they should be at.

Modelling and developing tools must be able to address these challenges in order to provide an agile software development environment and in order to make the MDE vision a success, where the primary development artefacts are the models.

The Model Driven Engineering paradigm is still very much in evolution. The industry demands solutions, the software vendors cannot agree upon standards, and the research community is still far from having defined a sound set of foundation principles. Because of the early stage of this new paradigm, it is in general a large challenge to enable an MDE approach to software development. We must gain a better understanding of how MDE can be applied in the industry before the method and principles of MDE can be defined and understood.

Goals

This work will apply the MDE approach to the domain of Business Process Management by focusing at challenge no. 1, 2 and 3 above with the vision to lift the abstraction level of the development process from focus on code to focus on models. It will be based on real industrial experiences where the challenges described above are faced.

The goal is to make a prototype tool which faces the challenges and gives a possible solution to them. To meet the challenges, the prototype tool must be able to be customised to:

• Define custom DSL’s for modelling business processes for a specific enterprise.
• Define custom transformations to custom elements in DSL’s.
• Define custom technology specific implementation patterns to each custom transformation.

Further it must allow models to be transformed several times without loosing manually entered changes in generated models.

The prototype tool has several purposes; it will illustrate a possible solution to the described challenges, it will give a better understanding of these challenges, it will give direct value to the process developers in Danske Bank, and it will inspire tool vendors to implement similar solutions in their products. The prototype tool is therefore a concrete goal and outcome of the project.

The following milestones are expected:

1. Description of requirements for a business process modelling tool to support the vision of MDE based on industrial experiences. The tool must be able to be customised to the enterprises modelling terms, i.e. it must be able to define Domain Specific Languages, and it must be able to let the user define custom transformations and custom implementation patterns for each element in the DSL.
2. Description of how changes in the generated PSM can survive a second transformation from the PIM.
3. Description of the architecture of a prototype tool based on the Eclipse framework which supports the requirements above.
4. A prototype tool implementation based on the Eclipse framework and if possible the IBM WBI modeller extension. It requires an agreement with IBM to get access to their source code.
5. Empirical test of the prototype tool on a real world business process.

Research questions

Several questions arise about how to define a business process model in specific terms for an enterprise, i.e. let the enterprise define its own Domain Specific Language, and how to transform a business process model to a specific implementation, which contains enterprise specific information and implementation patterns:

• Definition of Domain Specific Languages

Enterprises must be able to define their own modelling elements, i.e. they must be able to define their own Domain Specific Language. How can they define their own language, and how should the meta model of the language be stored. Should it be defined in an UML profile, as a model based on MOF, or as a proprietary meta model.

• Pattern definition

A specific element in the business process model can be transformed into a pattern in the PSM. The pattern is itself a PSM described in the same technology as the PSM to which the business process model is transformed. A pattern developer must be able to define and save patterns to be inserted under transformation. How can this be done in the most flexible way? Together with a defined pattern, a metadata description and some transformation rules must be defined. How can these elements be defined and made as an extension to a modelling tool, which other developers can use?

• Pattern transformation

When transforming an element in the business process model to a predefined implementation pattern, this pattern must be customised to reflect the meta-data describing the element. The transformation rules can be described declarative or imperative. There are pros and cons by both methods. Both methods should be tried and pros/cons listed. What kind of transformations are required?

• Persistency of data

A specific element in the business process model (PIM) must be transformed to a specific artefact in the implementation model (PSM). To make such a transformation requires data to describe the properties of the element in the business process. Where can these data be described and persisted? Should they be kept in a separate model, or should they be part of the PIM?

• Collection of data

When a business analyst defines the business process model, data describing each element in the process must be entered. If an element is enterprise specific, i.e. the analyst uses a DSL, data specific for the element must be present when the model is transformed to the PSM. Some parts of the required data can be defined by the business analyst, while other parts can be retrieved from the organisations IT infrastructure. Only the essential data for describing the element should be defined by the analyst/developer. The rest of the data should be obtained automatically. What are the requirements for a modelling tool to support this kind of flexibility?