The GRAAL Architecture Framework

 

© Roel Wieringa (http://www.cs.utwente.nl/~roelw)

The GRAAL project (http://is.cs.utwente.nl/GRAAL) 

University of Twente, the Netherlands

15 November 2004

 

This text in pdf format

 

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.

  • System aspects: Externally observable properties of a system
  • System aggregation: The composition of complex systems from simpler systems
  • System life: The life of a system from conception to disposal
  • Description levels: Abstract (few details) to refined (many details).

 

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.

System aspects

 

 

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.

  • Behavior consists of  the ordering of services over time.
  • Communication consists of  the interactions with other entities (people, devices, businesses, software)  during the delivery of the service.
  • Each service is offered by exchanging  data with the environment..

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.

The aggregation hierarchy

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:

  • The physical world is the world of computers, cables, printers, wireless access points, and in general anything that can be described using the basic measuring units of physics, Meters, Kilograms, Seconds, and Amperes.
  • The social world consists of roles people play, organizations, departmenrs, money, responsibilities, rights, delegation, business processes, and in general the processes and structures defined by human institutions.
  • The software world consists of software applications, information systems, office software, ERP systems, workflow management systems,  database management systems, middleware, operating systems, assembly language programs and even microprograms running on computers.

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 life of a system

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. 

Refinement levels

 

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.

Summary

The GRAAL framework consists of four abstraction mechanisms

  • System aspects: Externally observable properties of a system.
    • Services
      • Behavior
      • Communication
      • Data
    • Quality
      • For the user
        • Usability
        • Efficiency
        • Security
        • ...
      • For the developer
        • Maintainability
        • Portability
        • ...
  • System aggregation: The composition of complex systems from simpler systems
  • System life: The life of a system from conception to disposal
  • Description levels: Abstract (few details) to refined (many details).

 

 

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.

References

The first version of our framework was published in [6]. It was further elaborated in [7] and combined with systems engineering in [8]. In [9], the framework was further simplified and in [10], 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 [11].

 

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.

 

  1. B. S. Blanchard and W. J. Fabrycky. Systems Engineering and Analysis. Prentice-Hall, 1990.
  2. A.D. Hall. A Methodology for Systems Engineering. Van Nostrand, 1962.
  3. A.D. Hall. ``Three-dimensional morphology of systems engineering''. IEEE Transactions on System Science and Cybernetics, SSC-5(2):156–160, 1969.
  4. G. Pahl and W. Beitz. Konstruktionslehre. Handbuch f¨ur Studium und Praxis. Springer, 1986.
  5. N.F.M. Roozenburg and J. Eekels. Product design: Fundamentals and Methods. Wiley, 1995.
  6. R.J. Wieringa. Requirements Engineering: Frameworks for Understanding. Wiley, 1996.
  7. R.J. Wieringa. ``A survey of structured and object-oriented software specification methods and techniques'' , ACM Computing Surveys, 30(4):459–527, December 1998.
  8. R.J. Wieringa. ``Postmodern software design with NYAM: Not yet another method'', In M. Broy and B. Rumpe, editors, Requirements Targeting Software and Systems Engineering, pages 69–94. Springer, 1998. Lecture Notes in Computer Science 1526.
  9. R.J. Wieringa. Design Methods for Reactive Systems: Yourdon, Statemate and the UML. Morgan Kaufmann, 2003.
  10. R.J. Wieringa, H.M. Blanken, M.M. Fokkinga, and P.W.P.J. Grefen. ``Aligning application architecture to the business context.'' In Conference on Advanced Information System Engineering (CAiSE 03), pages 209–225. Springer, 2003. LNCS 2681.
  11. R.J. Wieringa, P.A.T. van Eck, D. Krukkert. ``Architecture Alignment''. To be published, ArchiMate.