Architecture Methods

Roel Wieringa (www.cs.utwente.nl/~roelw) and Pascal van Eck (www.cs.utwente.nl/~patveck)

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

University of Twente, the Netherlands

15 November 2004

 

This text in pdf format

 

 

The architecture design methods in the organizations studied by us are all based on Information Engineering (IE), itself a method developed in the 1970s by James Martin. In the Netherlands, the Panfox method is a well-known successor to IE.

 

Deliverables

The following entity-relationship diagram shows the products delivered by an Information Engineering-like method.

 

In order to get a list of applications and information systems, a business process model is built.

Whatever the case, the business process model yields a list of business activities to be supported, and for each of these an application may be acquired to support executing the activity. Applications use data, and these are stored in information systems. In order to find the relevant information systems, the subject domain of the business processes is modeled, usually in an entity model. The subject domain of a business process is the part of the world about which the process needs data. Each information system has exactly one subject domain.

Abstractions

Because all of these models must show a lot of information, usually abstractions are made in the form of process area models, application area models, and subject area models. Each process belongs to one process area, each application belongs to one application area, and each subject domain is part of exactly one subject area.

Consistency

Consistency between applications and information systems is maintained by means of CRUD tables or similar techniques. For each application and for each information system there must be such a consistency check.Our observation is that mutual consistency among all these models is never obtained.

 

  • Proposition. Consistency among process models, application models and subject domain models is never achieved completely.

 

The reason for this is that these models represent a large amount of information that is managed and owned by different organizational actors who do not coordinate all their activities among each other. There are just too many organizational change processes going on concurrently to keep all models mutually consistent.

Notations

Notations like the UML are at most used very fragmentarily, and architecture methods, if used at all, are used very opportunistically. For example a process may be modeled by a simple bulleted list of activities, or it may be represented by a complex UML activity diagram of activities and objects passed around among activities. Our observation about business process modeling is this:

 

  • Proposition. The more complex a process modeling notation, the more decisions must be made to build the model, and the more errors are made in the model.

 

While some complex and mission-critical business processes may require a complex notation, we think that many business processes are not that complex and can do with a more simple notation. Process notations such as the ones used in the area of process management may be suitable.

 

We generalize this to the following observation.

 

  • Proposition. Current architecture methods and notations are too complex and inflexible to be used in the current dynamic business environment.

 

There is a need for light-weight methods and techniques for architecture design. Furthermore none of the organizations we studied incorporated techniques to deal with cross-organizational IT. Nevertheless, cross-organizational IT has been important since the rise of EDI in the early 1980s and the current trends in networked business, value networks, value chain automation and outsourcing create an urgent need for incorporating network aspects in IT architecture alignment. Finally, the rapid rise of mobile and ubiquitous technology such as RFID, cell phones and wireless PDA's create an additional need to come to grips with the alignment between software infrastructure and physical infrastructure. With mobile technology, the physical location of software is important and this has consequences for the services offered by mobile technology, as well as for the management of this technology.

Place in the GRAAL framework

Information Engineering-like architecture design methods restrict themselves to business systems. They incorporate the distinction between applications and information systems. Different methods focus on different aspects of applicagtions and information systems. Usually, at leasst the following aspects are specified:

  • applications are specified by specifying their services,
  • information systems by specifying a subject domain model, and
  • for each application and infdormation system a context diagram is used to specfify its communication with other systems.

The context diagram of a system must then be consistent with the landscape map of the business system layer.

1

 
 


References

o        T. W. Hardjono and R. J. M. Bakker. Management van processen: Identificeren, besturen, beheersen en vernieuwen. Kluwer, 2001.

  • J. Martin. Strategic Data-Planning Methodologies. Prentice-Hall, 1982.
  • J. Martin. Information Engineering. Prentice-Hall, 1989.
  • W. van der Sanden and B. Sturm. Informatiearchitectuur: De infrastructurele benadering. Panfox Holding, 1997.
  • R. C. G. van Velzen, J. N. A. van Oosten, Th. Snijders, and T. W. Hardjono. Procesmanagement en de SqEME-benadering. Kluwer, 2002.