Business System Architecture

Roel Wieringa ( and Pascal van Eck (

The GRAAL project (

University of Twente, the Netherlands

14 November 2004

This text in pdf format


A business system is a software system used in some, but not all business processes. It is developed or bought to provide certain services in certain business processes, and therefore has particular user groups. Infrastructure software can be found in all businesses, but business systems are often local to one business. A government organization might have business systems to compute subsidies, income tax or other legal obligations, and a financial organization might have business systems to compute risk, mortgage interest, or an insurance premium.

Landscape maps

It is customary to distinguish two types of business systems: Information systems, which store data, and applications, which use data. Because of their close relationship with business processes, organizations can maintain a landscape map of business systems in

tabular format.


Each business process is represented by a column that contains the business systems used by that process. A system used in more than one process spans several columns. (If these columns are not adjacent, the business system must be represented by a rectangle scattered over several columns.)

CRUD Tables

If an application and an information system are in the same column, then the application has some interface to this information system. This interface can be made explicit in a CRUD table such as shown below, which gives more information about the interfaces between business systems in one column of the landscape map.



Application 1

Application 2

Application 3

Application 4


Information system 1






Information system 2






Information system 3






Information system 4






Information system 5







CRUD tables were introduced by James Martin in the 1970s in Information Engineering and related methods.

Communication Diagrams

In terms of the GRAAL framework, landscape maps and CRUD tables are communication models.They represent communication interfaces among systems. These can be represented in yet another way, conveying yet other information, in a communication diagram.


This communication diagram represents possible communications among the systems already listed in the landscape map. It shows that information systems do not communicate directly but only through applications. This information is not visible in the landscape map or in the CRUD table. The communication diagram can be used to trace possible impacts of changes. If a system is changed, then we must trace communication links to neighboring systems to see if those systems are impacted by the change.

Application areas

Applications can be grouped into application areas, which are coherent groups of business activities, that require the same business knowledge. For example, an insurance business might distinguish application areas such as claims handling, mortgages, life insurance, health insurance, etc. Each of these application areas requires certain expertise to handle, and for each there are certain groups of applications that may be used in various business processes. In the example landscape map shown above, two application areas are represented: The first area contains applications 1 and 3, and the second one contains applications 2 and 4.

Subject areas

Information systems can be grouped into subject areas, which are coherent parts of the world about which data are stored in information systems. Example subject areas in an insurance business are customers and insurance contracts. Our example landscape map shows two subject areas, one containing information systems 1, 2 and 4, and the other containing information system 3.


If an information system is used by many different business processes, it spans many columns. This means that all these processes use the same data with the same definition, which is good for the coherence among these processes. On the other hand, the more business processes an information system spans, the more difficult the system is to manage. Different processes usually have different data needs and different data definitions, and the more processes a system is to support, the more complex requirements negotiations become and the more complex data definitions result. A similar observation can be made of applications spanning more than one column. This leads us to the following generalization.


  • Proposition. The manageability of a business system is inversely proportional to the number of business processes supported by the system.


The reason for this is that the semantics, behavior and interfaces needed to support different business processes is usually different.


Another generalization we can make from our observations is the following:


  • Proposition. Business systems tend to gravitate to infrastructure.


As also observed by Weil and Vitale, a business system becomes standardized, more users start using it until it is so generally available that it has become part of the infrastructure. Many components of ERP systems started out as special purpose business systems and, by the time they have become part of an ERP system, they are part of the infrastructure.


  1. J. Martin. Strategic Data-Planning Methodologies. Prentice-Hall, 1982.
  2. J. Martin. Information Engineering. Prentice-Hall, 1989. Three volumes
  3. P. Weill and M. Vitale. ``What IT infrastructure capabilities are needed to implement e-business models?'' MIS Quarterly Executive, 1(1):1734, March 2002.