Conceptual Models

A conceptual model is a high-level view of an IT system in its context. It's purpose is:

To aid understanding of the system by all stakeholders.
To help decide where to make changes to existing IT systems.
To provide a firm basis from which to initiate application development projects.

Conceptual models is a term that has been used for a long time in database design. We have extended the notion to cover all aspects of IT systems. We illustrate the conceptual model using three types of diagram:

Overview diagrams, to show the hierarchical relationship between activities.
Box bag diagrams, to show how the organization's activities use information.
Activity diagrams, to show the control flow between activities.

It has long been the practice in IT to describe a large system in terms of a set of interacting modules. If you can describe what each module does and describe how they interest with each other, you have a high level description of the system. Furthermore if you describe each module in terms of sub-modules each interacting with each area, you have now a more detailed description of the system. Thus arises the concept of having being able to zoom into parts of the system in more and more detail and being able to zoom out to see a wider and wider part of the system.

So why is it so rare to find an IT system described this way? The catch lies in the word "interact". IT practitioners are typically taught only one way modules can interact - the programmatic interface, a set of procedure/operation/method calls with parameters and return values. In a conceptual model, activities (the conceptual level modules) rarely interact using programmatic interfaces. Instead the two most common forms of interaction are:

Sharing data, one activity provides data, others use it.
Through the action of external entities. For instance in an airline system a crucial factor in the interaction between the check-in and departure gate activities is the passengers moving from the check-in desk to the departure gate.

What is distinctive about our approach to conceptual modelling is the use of the box bag model which is designed to show how activities interact in terms of sharing data or passing data, and to show how activities and data depend on, or are related to, external activities, things or people.

Information boxes and bags are a simple metaphor for representing how activities use data. Activities place information into bags - we don't specify in the conceptual model how the information is structured - and other activities take the information out of bags. Thus we can map who uses which chunks of data. If there is a requirement to make a bag persistent it can be placed in an information box. Other activities can then find the box, read the bags in them and/or add their own bags to the box. Boxes are, of course, usually implemented by rows in database tables but one box can translate to may rows, or be moved from database to database. The box bag diagram shows the shape of the system without becoming lost in implementation detail.

Conceptual models are easy to develop and would normally be done before embarking on application development projects because they are an important tool in developing the scope of the application development projects.

For more information, there are a series of papers available here.

The Conceptual Model in Context

The next level of detail beyond the conceptual model is the logical model which annotates the box bag model with the structural detail. The logical model describes the data structures of all activity input and output and itemizes the business rules implemented by the activity. The implementation level then turns the logical model into code. This gives us the three layers as show on the diagram below.

Alongside the logical model are two more boxes - the application architecture and the technical architecture. Together these provide a high level overview of the implementation. The application architecture enumerates the applications, places the applications into layers, enumerates the databases and shows which applications use which databases and the which applications invoke other applications. The technical architecture chooses the technolgy, outlines of the physical distribution of hardware resources, and provides an outline network, security and systems management design. Linkages between the logical model and the application architecture tell you which activity uses which application. Linkages between the application architecture and the technical architecture tell you what technology will be used to implement the applications. Together they provide a specification sufficient for the programmers, database administrators and human interface experts to create the application.

This is not to say that this four model view implies a waterfall development. It describes the desired end result of development not the order the work is done. We would recommend finishing a conceptual model before embarking on any implementation because a conceptual model is such a useful tool when scoping a development project. Even if you are doing an agile development and believe in minimal documentation, the thought processes in building a logical model and application architecture are useful, especially the verification techniques.

[back]