Computer based information systems have become a very important factor in modern economy. They are so well accepted, that there is almost no business area which is not supported by such a computer application. But computer based information processing is still a relatively young science. This becomes obvious in a rather painful way if we look more closely at the currently used applications in small as well as in large enterprises. This includes even very famous and well introduced so called "Enterprise Standard Application Programs".
The characteristics of almost all of the actually exploited commercial IT applications used to control and administrate companies is a relatively low level of integration and a relatively high overlap in provided functions and used data. This is due to the fact, that the basic design of most of the applications was done in those times, where the power of computers in terms of number of processed instructions per time unit and storage capacity was limited and batch processing was the technique programmers were familiar with. As computer capabilities grew, those applications were combined using bridges (interfaces between application systems for data exchange) and more user friendly end user interfaces were built, but nevertheless the basic design was and is still somehow batch oriented.
Now computers have become very powerful and relatively cheap and therefore decentralized but co-operative processing using distributed databases became affordable. Clients, very often in the role of customized front end personal applications with fancy user interfaces and with a high degree of own intelligence using offered services of servers in networks or peer to peer distributed processing are techniques which can now economically be used for modern business supporting IT application systems. Parallel processing is available to process big amounts of data within an acceptable time frame. The Internet can be used to offer web-based applications which are available allover the world.
On the other hand real on-line decission support based on the most actual and consolidated information available in an enterprise is a matter of survival in a lot of industries. Most of the current applications cannot satisfy this demand and it is in most cases impossible to migrate these applications to the new state of the art techniques with a justifiable effort (time and money). I personally believe, that most (probably all) re-engineering attempts do not fulfill expectations with respect to integration, stability, adaptability, serviceability and maintainability and the spent effort (if measured honestly) cannot be justified.
This lays a heavy burdon on all IT application developers. The problem they face is to provide modern, highly integrated applications free of redundancy, and this in a very short time frame in order to cut maintenance costs of legacy applications which are no longer state of the art. The new applications should be designed in such a way, that they - compared with existing application systems - are superior and long-lasting from a business point of view, but can - if needed - easily be adapted to new business situations as well as to new technical possibilities coming up in the future.
This goal only can be achieved if application development is performed in a very disciplined manner using techniques which allow precise definition of the envisaged results. Therefore
this document proposes Model Driven Application Development as a very effective method for the development of modern, highly integrated commercial IT business applications.
The purpose of the document is to explain, what I mean when I talk about development, models, and modelling. The document will show what models should contain, how they should be structured, and how the information contained in a model should be collected.
The document will also show, that projects consequently exploiting model driven application development generate results which are much better with respect to durability and consistency than any other development method I am currently aware of.
It is good practise to precisely explain what is meant if specific terms are used in a certain context. A lot of confusion can be created if persons talk to each other, believing that the other parties are familiar with the terms used, but in reality each party has something totally different in mind (e.g a German talks about a "handy" as a "cellular phone" whereas an American thinks about something useful or something which can be reached easily). There have already been mentioned some terms like "model" and "development". And there will be even more terms! Therefore lets first make some definitions.
If I talk about development in this document I talk about development of IS Business Application Software - that is computer software intended to be used to support the performance of activities in a business environment. Of course other software must also be developed, but developing computer games, or computer tools (like editors), or even so called "middle ware", or "operating systems" can be (within certain phases) pretty different from developing business applications. This does not mean, that I want persons involved in those kinds of developments to stop reading here.
The term "development" here covers the whole process of computer software creation starting with the documentation of the first idea of a new software product until to the undertaking of a software product which will be no longer used.
There are mainly two approaches used to develop IT business applications, the
The development process - as I have defined it above - is pretty complex because it comprises a lot of activities which have to be performed in a certain sequence. The process therefore has to be structured in order to do the development efficiently. Again there are mainly two structuring methods,
There have been fought religious wars about which approach may be the better one. Some arguments for the kind of structuring I prefer and therefore recommend I will discuss later.
The term model is very wide, and there are many types of models around. Before I start to talk more detailed about models and modelling I first have to explain, what I mean, when I use the term "model".
In general a model is a replica (or image) of something real but as it is only an image it presents only a certain selection of properties of the real thing.
When I talk about a model I do this always from the perspective of an IS application developer. Therefore in the context of this document
a model is the description of a specific view of a real world "problem domain" showing those aspects which are considered to be important to the observer of the problem domain.
In the definition I have used the term "problem domain", so I have to explain this term as well.
A "problem domain" is an area of interest with clearly defined boundaries with respect to this interest. It can be anything which can be described by properties and activities but it should form an autonomous unit.
In this document we call a specific business environment a "problem domain". Such an environment can be a generic domain like "a retail environment", or it can be a very specific domain like "the enterprise XYZ". Both types of domains may have sub-domains. The enterprise domain e.g may have the sub-domains "administration", "production", and "distribution". The retail domain may have sub-domains like "procurement" and "marketing".
The boundaries drawn for business problem domains can be very wide. That means that many business problem domains we have to deal with are very complex just because of their size.
Models as descriptions of something real (in our context a "business problem domain") of course are generated for a specific purpose. Main purpose is to have a well structured documentation of the business problem domain which can be easily understood by the persons which are somehow related to this business problem domain. Such a model than can further be used to develop the business problem domain into a certain direction and to derive support for this business problem domain in an effective and economical way.
To be more concrete a model of a "business problem domain" once created can be used as
The following list shows concrete what can be achieved by using a model:
Models are in general categorized according to their subject or content. This is what the following list intends to provide, but there exists also a "potential usage aspect". Therefore most of these models can also be an "as is" or a "to be" model.
Note: Because I talk in this document in general about business application development for one or more enterprises when I use the term model I normally mean "business model" (or also "industry model" as a model covering several business models).
What should a busines model contain in order to function as the basis of a business application development. In principle it should contain a detailed description of
Model elements should be:
A complete set of content elements (also known as model properties) is very important for the value of a business problem domain model. Equally important for its usability is how these properties are recorded and structured. This will be the topic of a detaild discussion later in this document.A model of a problem domain can never cover all aspects which appear in the real world. Very important is therefore the viewpoint of the observer(s) of the real world business domain who created the model. In general I can say: the more complete a model is in terms of number of aspects covered as well as levels of details recorded, the more accurate the results will be which are derived from the model.