Extract from a paper presented by Dennis A Stevenson to the Department of Information Systems, University of Cape Town, in partial fulfillment of the requirements of the degree of Master of Commerce in Information Systems, June 1995. Copyright subsists in this material.
[Architecture Frameworks ] [Page Administration ] [IS
World Net Navigation Map ]
Note: References cited here can be found in "references ".
When creating an architecture it is useful to have a framework to identify and categorise the parts of the architecture. One can either create one’s own framework or use an existing one of which there are several available.
"The ‘Framework for Information Systems Architecture’ is a simple, logical structure of descriptive representations for identifying ‘models’ that are the basis for designing the enterprise and for building the enterprise’s systems." (Zachman, 1995)
In his seminal work on architecture Zachman’s (1987) parallel between information systems architecture and classical architecture may be considered as a justification for the use of the metaphor "architecture" in the enterprise modelling and information systems context.
His analogy is mainly concerned with a number of different perspectives on the business. In brief they are, from the top down:
A scope description which is a "ballpark" view and relates to the architect’s bubble charts, It contains or facilitates the following:
- Gross sizing, shape, spatial relationships
- Architect/owner mutual understanding
- Initiate project
- Basic concepts for building
A model of the business which is the owner’s view and relates to the architect’s drawings:
- Final building as seen by the owner
- Floor plans cut - always pictures
- Architect/owner agreement on building
- Establish contract
A model of the information system which is a designer’s view and relates to the architect’s plans:
- Final building as seen by the designer
- Translation of owner’s views into a product (what to build)
- Detailed drawings - 16 categories
- Basis for negotiation with general contractor (builder)
A technology model which is a builder’s view and relates to the contractor’s plans:
- Final building as seen by the builder
- Architect’s plans constrained by laws of nature and available technology
- "How to build it" description
- Direct construction activities
A detailed description which is an "out-of-context" view and relates to shop plans:
- Sub-contractor’s design of a part/section
- Detailed stand-alone model
- Specification of what is to be constructed (components)
- Patterns for components
The actual system which relates to the physical building.
Each perspective contains a complete view of the business and must therefore cover various focus areas, each of which answers a basic question: what = data; how = function; where = network; who = people; when = time and why = rationale. (Sowa and Zachman, 1992)
When mapped against each other the perspectives and the focus areas form a matrix called the Information Systems Architecture Framework, or more commonly the Zachman Framework (see Figure 10).
Figure 10: The Information Systems Architecture Framework - Sowa and Zachman (1994)
Each cell in the matrix represents an artifact such as a data or process model, with its own rules, notations, guidelines and tool support (see Figure 11 which is a representation from the Structure for ISA tool from Framework Software Incorporated).
Figure 11: The ISA Framework in the Structure for ISA tool
Each column or focus in the framework relates to a sub-architecture.
Figure 12: The ISA Columns related to architecture
Many of the other published frameworks are derivatives of the Zachman (ISA) Framework.
In each case the framework has been adapted to work in the practitioner’s environment.
Zachman says that the rows and columns of the framework are universal, but practitioners can adapt cell contents to suit their different circumstances.
However it appears that in practice most serious attempts to apply the framework have resulted in some modification of rows and columns.
The DA/ZE or DataBase Associates/Zachman Extended framework introduced an extra column for Presentation (Loosley, 1992).
The Information FrameWork (IFW) was developed by IBM’s Banking Solution Centre in Dublin in conjunction with input and feedback from many banks worldwide. The project started in 1991, growing out of IBM’s Financial Application Architecture (FAA). The IFW was based on the Zachman Framework, but during development the structure was changed. (Evernden, 1994)
Zachman’s Rule 1 of the Framework is that the columns have no order. This is because order implies priorities which creates a bias toward one aspect at the expense of others. (Sowa and Zachman, 1992)
In contrast, the columns of the IFW are grouped into a logical order (see Figure 13). For example, the three views of information form a progression from the view of a specific ‘organisation’, through a view of the ‘business’ or the industry within which the organisation operates (banking), to the view of the ‘technical’ platforms and structures used to provide computer support for that business. (Evernden, 1994)
Figure 13: The Information Framework - Evernden (1994)
The IFW has five rows and ten columns whereas the ISA has six rows and six columns.
"IBM’s Insurance Application Architecture (IAA) is an architectural framework and set of components to guide the development and maximize the effectiveness of insurance applications and technology solutions." (Nichols, 1994)
Although the Insurance Application Architecture uses a version of the Zachman framework, its creators have chosen to use only three of the six columns and four of the six rows of the ISA.
IAA is both a framework and a populated architecture (see 4.1.1.5.3 above).
Figure 14: Insurance Application Architecture Framework - Nichols (1994)
One of the interesting differences in the ISEM framework (Coleman, 1989), is that it introduces the concept of simultaneous architectural representations for the "as is" and the "to be" states. However as these are reflected as rows in the framework (see Figure 15) they do not provide a complete representation of these states.
Figure 15: The Integrated System Engineering Methodology Framework - Coleman (1989)
This researcher has also reflected on the "as is" and "to be" states of the architecture and how to deal with them. The term coined to represent this is the "Dual Timeframe Problem" (Stevenson, 1991).
In an attempt to reflect the dual timeframe problem in terms of the Zachman Architecture during development of OMIBA, Stevenson’s Interpretation of the Zachman Extended Framework (SIZE) was developed (see Figure 16). The argument here is that a complete representation of the architecture should be held for each of the "as is" and "to be" states and that movement between them must be carefully managed.
Figure 16: Stevenson’s Interpretation of the Zachman Extended Framework (SIZE)
For further clarification of the SIZE framework an entity-relationship model was produced. As the framework itself is a meta-model of the business, the meta-model of the framework could be considered a meta-meta-model (see Figure 17). At the time (1991) the intention was to use this model to create a database for the OMIBA architecture repository.
Figure 17: SIZE Framework Meta-Meta-Model
What Zachman calls a perspective and a focus are called a view and a subject respectively in this model.
The bill-of-materials structure at the bottom of the model shows an entity called association/transformation/transition. This reflects the different types of cell to cell relationships in the framework:
Association = cell to any cell in the same row
Transform = cell to adjacent cell in the same column
Transition = cell to corresponding cell in the other timeframe layer
The ISA provides the ability to record information (e.g. guidelines, notations, tools) about each cell which represents a view of a subject. The SIZE meta-meta-model can record information about a view of a subject, a view of a subject within a timeframe, as well as associations, transforms and transitions as described above.
The Loosley Integration Framework Extension (LIFE) Matrix , (Loosley, 1992) provides a column to column mapping of the ISA framework that is an explicit view equivalent to the association mapping in the SIZE meta-meta-model.
The IFIP Working Group 8.1 Architecture
The working group WG 8.1 "Design and Evaluation of Information Systems", of technical committee TC 8 "Information Systems" of the International Federation for Information Processing (IFIP) has produced an information model for a comprehensive methodology for developing information systems (see Olle, 1983, 1988a, 1988b).
Figure 18: Views of IFIP WG 8.1 Architecture (Olle, et al., 1988a)
The methodology has three views or perspectives (see Figure 18):
It also has three layers or stages:
The framework of Architecture of Integrated Information Systems (ARIS) is similar to the IFIP WG 8.1 model, but has four views and three levels (see Scheer, 1992, 1994a) (seeFigure 19).
The four views are:
The three levels are:
Figure 19: The ARIS framework (Scheer, 1992)
Neither the ARIS architecture, nor the ARIS tool deals effectively with an Object Oriented view. For this reason they are not adequate on their own for OMIBA. However there is a fair amount of commonality between ARIS and OMIBA and OMIB is experimenting with the use of the ARIS tool for representing operational flows and will be evaluating it for a more comprehensive role. A mapping has been done between objects in the OMIBA meta-model and objects in the ARIS meta-model (see section 6.4.1.4).
PERA, TOVE, GERAM, CIM-OSA
Various architectural frameworks and meta-models are current in the Industrial Engineering discipline and the Manufacturing Industry.
Investigating these to extract value for OMIBA is planned for the near future (see Chapter 13.3. Further Research).
The Purdue Enterprise Reference Architecture (PERA).
The Toronto Virtual Enterprise (TOVE). (Fox, et al, 1993)
The Generic Enterprise Reference Architecture and Methodology (GERAM). (Bernus and Nemes, 1994)
The Computer-Integrated Manufacturing - Open-Systems Architecture (CIM-OSA) (see ESPRIT, 1989; and Jorysz and Vernadat, 1990a and 1990b) is a three dimensional framework (see Figure 20). The dimensions are:
stepwise derivation
- requirements definition
- design specification
- implementation description
stepwise instantiation
- generic requirements
- partial requirements
- particular requirements
stepwise generation
- function view
- information view
- resource view
- organisation view
Figure 20: CIM-OSA framework (ESPRIT, 1989)
As can be deduced from the variety of frameworks in the preceding section, there is no single universally correct framework.
It is interesting to note that ISA, IFW and IAA are all IBM initiatives, with the frameworks used by IFW and IAA being derivatives of the ISA framework. IAA and IFW were both developed for the financial services industry, one for banking and one for insurance. However they are significantly different from each other and from their parent ISA. So, if IBM itself is not able to adhere strictly to the architectural framework proposed by it, it is perhaps not surprising that other companies develop their own frameworks or their own interpretation of the ISA framework.
It can be argued that a two-dimensional framework might be simplistic and at the same time restrictive. It may not be desirable or necessary to have the same number of layers of perspective (rows) for each focus (column). For instance while it may be worth the effort and cost to have six layers for data, it may only be worthwhile maintaining three layers for process.
On the other hand, complex multidimensional and multifaceted framework models (e.g. some of the cube models), while intellectually satisfying for architects, often do not lend themselves to effective communication with the business, which is something that must at all times be kept high on the priority list.
The architects of OMIBA had a strong preference for the Zachman framework, however several attempts to promote it as the primary framework for OMIBA failed to gain acceptance from either the systems or business management. As one of the primary purposes of a high-level framework is to help to communicate the architecture to its stakeholders, it would be self-defeating to try to force the use of a framework that has not found favour. The ISA is therefore not currently part of the architecture.
A different set of classifications has been independently developed for OMIBA. OMIBA has two high-level frameworks called the Four Dimensions and the Four Domains, and a detailed meta-model in the form of an entity-relationship model. The Four Dimensions and The Four Domains are known as the "4x4D" framework and have been widely used to good effect with audiences across the business spectrum. Having a name such as 4x4D allows one to draw an analogy to four wheel drive diesel vehicles and the qualities they have in common with architecture:
See also: John
Zachman - "The Challenge is Change: A
Management Paper"
IS World Net Home Page (net map
or text
only )IS
World Research and Scholarship Enterprise
Architecture 
Architecture Frameworks. Where
you are right now!
This page is maintained by Dennis A Stevenson who can be reached at (denniss@iafrica.com).
This page was last updated on 11th November 1997. Although we will attempt to keep this information accurate, we can not guarantee the accuracy of the information provided. Users are advised to look at our disclaimer .
Any feedback will be appreciated.