previousnext


Models to Solve Current Application Development Problems?

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.

What I am Talking About - Some Definitions

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.

Development - what it is and how it is done

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,

  1. the "waterfall" model which defines certain milestones along the development progress
  2. and

  3. the "spiral" model or the "fountain" model, which follows the philosophy of an iterative development approach.

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.

Models and problem domains

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.

The Purpose of Models

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 - Categorization and Content

Model Types

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.

Analysis Model
A model holding essential information coming from the analysis process of an existing problem domain. It describes for instance what is the concept of the solution for one or more of the systems we need.
Business Model
A model showing the manner in which the business (e.g. distribution, retail, production, administration, ...) responds to its customers, suppliers and other partners. It gives a view of the business itself and not how it is handeled by an individual enterprise. It may comprise: use cases, business objects, process descriptions, and business rules.
Design Model
A model holding the description of the details and arrangement of the elements of a system for a specific purpose. It describes exactly the usage of the selected elements. It is normally derived from an analysis model.
Enterprise Model
A business model showing, how a specific enterprise handles a certain business. The relationships between agents outside the business are clearly denoted and related to the organizations within the enterprise described. Also referred to as an enterprise domain model. It may be derived from an industry model describing the industry the enterprise belongs to.
Industry model
A business model describing a whole industry domain. It may be the synthesis of an enriched specialization of a problem domain model covering an all industries view with one ore more business models.
Information Model
A model just structuring (business) information.
Problem Domain Model
Not a specific model but just a generic term for any kind of model.
System Model
A model describing the characteristics of an existing or envisaged system of any kind.
Workflow Model
A model dealing just with the structuring of the procedural aspects and their automation within a business domain. Therefore also called Procedure 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).

Important Model Content

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.
The little example bellow illustrates how different the content of a model can be if seen through the eyes of observers with different interest. The example also makes clear, that a model created from the wrong viewpoint may be useless for the intended purpose. On the other hand it seems also obvious, that a model not necessarily has to cover all properties of a real world thing in order to be useful.

Let us model "A street". Let us further asume we have two observers, the first be a constructor, and the second be a postman.
A constructor most likely will put in his model of a street properties like: width of street, length of street, kind of pavement, material of shoulder, ....; whereas a postman will be interested in the name of the street, the used numbering system to identify the buildings along the street, the kind of owners of the buildings - e.g. companies, private persons, ....
Both models are incomplete with respect to the properties of a street in the real world, but both models will show the essentials needed in the relevant problem domain.

Top of page
Table of Content

previousnext