© Roel Wieringa (http://www.cs.utwente.nl/~roelw)
The GRAAL project (http://is.cs.utwente.nl/GRAAL)
15 November 2004
To describe ICT architectures in a business, we need a conceptual framework that provides us with the words in which to describe the architecture. The framework used in the GRAAL project is a result of 10 years of research in the design of information systems. It was inspired by similar frameworks used in systems engineering and industrial product engineering, but was adapted to suit the needs of information systems architects. In the course of 10 years it has been simplified continuously. At the same time, it was validated in many different projhects, large and small, in different organizations.
The word ``system'' in the following refers to any coherent collection of elements. Examples are an information system, the entire enterprise system layer of a business, the business itself, or a value network of businesses. All of these are examples of systems, and they all have an architecture.
Our framework consists of four orthogonal dimensions.
The first three dimensions cover three possible ways of considering a system: by its externally observable properties, by its internal structure, and by the stages in its life.
The fourth dimension concerns the level of detail we include in our system descriptions. Note that each of these dimensions is an abstraction mechanism. We can simplify a description of the system if we concentrate on only one aspect (such as its behavior or its usability), or if we concentrate on one subsystem, or if we consider it only at one snapshot of its life, or if we omit irrelevant details—and we can choose to apply all these absractions at the same time. In the next sections, we look at these abstraction mechanisms in more detail.
Each system offers certain services at a certain quality level. For example, an information system provides information to its users (a service) with a certain reliability, currency and accuracy (quality attributes); and an application system offers certain user-specific services at a certain quality levwel. Well-known quality attributes are usability, efficiency and reliability for users, and maintainability for developers.
All system services are characterized by three functional properties.
All software development methods offer various notations to deal with these aspects. For example, event lists and state transition diagrams (statecharts) can be used to represent behavior. Data flow diagrams and use case diagrams can be used to represent communication between processes and actors. Entity-relationship diagrams can be used to represent the semantics of data. These are just examples; there are many other notations available.
Next to focusing on one system aspect, we can abstract from complexity by focussing on one subsystem. This is possible because systems are part of an aggregation hierarchy, as shown in the following diagram.
For example, a complex software system may be decomposed into individual software systems, which have subsystems, which consist of modules, which can be decomposed into software objects. At each level in this hierarchy, systems have the GRAAL aspects. For examples, software objects offer services with a certain quality of service, and each service has behavior, communicates with other objects, and exchanges data. The same can be said of modules, of suvbsystems, of entire systems, and of systems of software systems.
In the GRAAL framework, we distinguish three worlds:
Aggregation in each of these worlds is different. For example, a physical computer is composed of many components, and an organization is composed of many departments, and these two aggregation relationships are totally independent. And both are independent of the aggregation relationship in the software world. A software system may be composed of subsystems, which are composed of modules, which are composed of objects, and this aggregation relationship is completely separate from any aggregation relationship in the physical or social worlds. Aligning these three worlds is a difficult problem.
The third way we can abstract from a system is to consider only one stage in its life. Any system goes from conception through acquisition, use and maintenance to disposal.
An important part of the problem of aligning software to the business is coordination of future development of software systems. Of every system, several versions may exist. Many systems are supplied by third parties, each with their own release frequency. Coordinating all of this is a major problem in practice.
The fourth and last way in GRAAL to absgract from a system is to omit details. We can do this at any layer in our framework. Here are some illustrative refinement relations.
Not only can we describe entities at each service layer at any level of detail, we can do the same with entities at different levels in the aggregation hierarchy. For example we can describe one software system very abstractly by describing its mission and responsibilities, or very detailed by describing all its transactions and the structure of the data input and output by the system. Lower down in the software aggregation hierarchy we can do the same: We can describe one software object by describing its mission and responsibilitiers, or in a very detailed manner by describing the syntax and semantics of its operation calls, and the communication protocol to be used when calling an operation. Therefore, decompositing a system intyo components is not the same thing as moving to a more detailed desxcription level. We can describe its components just as abstractly as the system itself, and we can describe the system just as detailed as any of its components.
The GRAAL framework consists of four abstraction mechanisms
We use this framework in GRAAL to analyze architectures that we find in businesses. The framework allows us to structure our descriptions of these architectures in such a way that we can compare the descriptions in a meaninghful way.
The framework can also be used by an architect as a means to structure his ir her thinking about the architecture, and as a means to structure architecture documentation.
The first version of our framework was published in . It was further elaborated in  and combined with systems engineering in . In , the framework was further simplified and in , it was applied to the problem of architecture alignment. The version described in this white paper is the result of several years of studying the architecture alignment problem in different organizations .
The GRAAL framework borrows heavily from systems engineering [1, 2, 3] and from industrial product development [4, 5]. It is compared with other architecture frameworks in another white paper.