Developing an Architecture Method Library

The design, realization, and implementation of information systems provides employment to millions of professionals worldwide. When attempting to clearly identify their profession, one discovers that there does not exist a well established and clearly identified body of knowledge.

The Software Engineering Body of Knowledge (SWEBOK) project [SWE01] started from a similar observation for the field of software engineering. The following motivation of the SWEBOK project is provided:

In other engineering disciplines, the accreditation of university curricula and the licensing and certification of practicing professionals are taken very seriously. These activities are seen as critical to the constant upgrading of professionals and, hence, the improvement of the level of professional practice. Recognizing a core body of knowledge is pivotal to the development and accreditation of university curricula and the licensing and certification of professionals.

This inspired us to develop an architecture method library, containing project experiences, reference architectures, literature, proven methods, tools, etc.

Using various kinds of access mechanisms the professional is able to use this library. By giving it an open nature, it can be filled by professionals from different fields and with different backgrounds. Feedback mechanisms can be used to improve the contents of the library by e.g. giving feedback on the method components present based on the actual use of the library.

This article describes the design of such an architecture method library, what it contains, the way it is filled and how it can be used. Some future directions are given. In section 7 an extended example is given to illustrate the results from the other sections.

Given the unclear boundaries of the information systems engineering field (what is part of this domain and what is not?), we use the following definition of information system:

An information system is a sub-system of an organizational system, comprising the communication- and information-oriented aspects of the organization system [FVV⁺98].

In this article, the term information systems engineering is used to refer to all activities involved in the design, realization and implementation of information systems (including non-IT or non-automated aspects). This essentially ranges from the high level design of a portfolio of information systems (an information architecture) to the design and realization of a specific information system.

We use an organic approach to the development of the architecture method library. This essentially means that no strong restrictions are set on the scope of the library beforehand. It will emerge from the content as more is added. This fits with the fact that most of the knowledge available on information systems engineering is in case-based form, tied to experiences learned from specific cases from industrial practice.

For this moment, the demarcation lies in the group of professionals responsible for providing the content: those people who consider themselves to be architects or information systems engineers.

We realize that we cannot aim to develop a fully integrated and completely consistent architecture method library. Reasons for this are (among others) the huge amount of literature in the information systems field, the ‘vagueness’ of the field (and, subsequently, the various backgrounds of the professionals involved), and the case based nature. Therefore, we aim to compile and structure a library filled with a collection of significant, loosely coupled ‘knowledge items’ or ‘method components’, considered useful to project members of an information systems engineering project. These method components consist of focused denotations of knowledge pertaining to information systems engineering.

Related work can be found in e.g. [DGC⁺97] and [FVV⁺98]. In [DGC⁺97], a model curriculum is described for undergraduate degree programs in information systems and it also contains a definition of a body of knowledge for information systems engineering. The Framework for Information Systems Concepts (FRISCO) as reported in [FVV⁺98] aims to give the field of information systems a conceptual underpinning by introducing a unified framework of concepts. What both of these approaches lack is the practical side in terms of concrete work practices, techniques and tools to be used, etc.

Another field that is of relevance is the field of method engineering [BLW96, Har97]. The approach taken there tends to dissect methods to the level of distinct concepts and their relationships. For the moment, it involves too much detail to be applied to the gathering and structuring of a library of knowledge items. However, the theories provided by method engineering are useful in dissecting method knowledge into more elementary items and will also be useful for developing a consistent body of method knowledge once a significant collection of knowledge items has been gathered into our architecture method library.

The architecture method library should contain information about various architecture and information systems subjects, such as:

• •

  project strategies,

• •

  case studies (both successes and failures),

• •

  descriptions of methods, techniques and tools,

• •

  reference models and frameworks,

• •

  heuristics on the use of project strategies, methods, techniques, etc.,

• •

  knowledge to aid in planning and execution of projects,

• •

  heuristics and guidelines with regard to design decisions, the use of reference models, architecture principles, etc.

The intended audience of the library includes managers, architects, designers, engineers, etc. In the next sections it is shown how we intend to dissect this knowledge into focused ‘knowledge items’ or ‘method components’ as we will call them below.

First, method components and a characterization of them are introduced. This is followed by situational factors and heuristics. Finally, the complete structure of the library is given.

Project members can use the architecture method library to find the answers to questions such as:

• •

  Which activities, techniques and tools are most appropriate given a specific project situation and task?

• •

  What reference models are relevant for my project?

• •

  What reference models are relevant in a situation where the business has selected “customer intimacy” as in [TW97] as their strategic focus?

• •

  What are relevant architecture principles?

• •

  Which reference models represent a front/mid/back office architecture?

• •

  Which guidelines are useful for designing a data model?

• •

  What methods can be used for designing an application architecture in a process intensive environment?

Just like a regular (physical) library, the architecture method library is meant to assist professionals. That means that the content in the library may help users in deciding, for example, which activities are appropriate in a certain project situation. The library will then present several possibilities, but only judgment of the professional will make this usable in a project context. As always, the expert is responsible for decisions made.

When the architecture method library is used, the general steps for answering questions like those above are the following:

1. 1.

   Analysis of the situation at hand.

2. 2.

   Selection of base method components for the question(s) at hand.

3. 3.

   Selection of other useful method components. This step can be repeated as desired.

4. 4.

   Use of all the method components selected helps to complete the analysis.

All this can be done by accessing the library. Adding these steps to the structure of the library as given in figure 2, the subsequent figure 3 results.

There are three different ways to access components of the library. The first method is to formulate an exact query. One formulates a question based on logical expressions with values for various properties. This is used as a query to the library. Examples of these kinds of queries are given at the beginning of this section.

Often, it is not easy to formulate an exact query like this. In such situations, browsing and selecting relevant method components may be more appropriate. This is often called: query by navigation.

The third method of accessing the library is the use of a more-or-less predefined decision tree. Using such a tree as a guideline helps to investigate the situation with which the user is confronted. The base for this are situation factors and heuristics which are used to select the applicable method components.

Of course all three access methods can be combined. After an initial selection has been made, more can be added at will. This results in a more refined analysis, as is indicated by the curved arrows in figure 3. Method components selected may (left open arrow) or may not (right open arrow) lead to additional or revised analysis. In section 7, the different access mechanisms are illustrated.

Filling the library is an iterative process. That means that adding new documents to the library is an ever continuing process.

Examples of new, not yet analyzed documents are project deliverables, project archives, textual descriptions of methods, techniques and tools, case descriptions, etc. From the perspective of the library, this material is not likely to be very homogeneous with respect to the method components which are already present. For example, a book on some modeling method could discuss this technique in a way that is highly intertwined with a specific tool that can be used to produce the models which is already present in a method component in the library. This relation can only be added after (extensive) analysis of each source document.

After addition of these new documents, in the following step this analysis is performed. From the source document, the method components are extracted and described in a framework as described in the previous section. During this step, the relations with other method components already in the library are determined. This is often a time consuming task. The resulting material is homogeneous in nature.

In principle, anything can be added to the library. However, when quality criteria are used for “screening” new raw material, the time necessary for adding extracted method components can be reduced drastically. Criteria can be:

• •

  Is the new source document in some way structured (the structure may lead to easier identification of method components)?

• •

  Is the knowledge present in the new source document an addition to knowledge already present in the library (preventing double occurrences of the same method component)?

• •

  Does the material fit in the domain of the library (preventing the addition of irrelevant material)?

• •

  Is the knowledge expected to be interesting for more than one specific customer or situation (preventing the addition of material which is too specific to be used elsewhere)?

As can be seen, adding material to the library is a non-trivial task which has to be done by an experienced architect. Guidelines are important to prevent differences in interpretation of the raw material and to prevent different phrasings. In the next section the importance of this is illustrated. However, one should realize that such differences cannot be prevented completely.

Other, general maintenance tasks for the library can be done by a qualified “librarian”.

An additional step may be the rewriting of method components to some form of “standard terminology”. In this phase aggregation can be executed, as well as normalization of terminology and concepts used. However, this will take a substantial amount of time and the usefulness of such an exercise is not clear at this moment.

In this section an extended example is discussed. We have taken [SS97] as raw material.

Eventually, once the library has been filled with a reasonable number of method components, a core body of knowledge for information systems engineering may be identified. Such an explicit and accepted body of knowledge would, for example:

• •

  Allow universities and training institutes to tune their curricula to a well defined body of knowledge accepted by both industry and academia.

• •

  Allow for the identification of distinct roles in the information system engineering process and related forms of certification.

• •

  Allow managers of information systems engineering projects to constitute project teams with professionals who share a common terminology and understanding of the profession.

• •

  Allow client organizations to organize second opinion reviews among providers of information system engineering.

• •

  Allow for re-use of experiences and materials between practitioners from different backgrounds.

Ideally, the library should make use of a common and unified conceptual framework. This will require several iterations of analysis of the library.

Once the library becomes filled with some critical mass of assets, it may become part of a “learning cycle”. The actors in an information systems engineering project who use the knowledge in the library for their project activities will be able to give feedback on the contents of the library based on their experiences in a project.

Of course, these experiences should be added to the library, resulting in an open library where professionals submit method components or refinements of existing ones to the library.

In this paper we have presented an architecture method library which eventually may evolve to some kind of information systems engineering body of knowledge. Discussed are the restrictions on the scope of the library, the contents of the library, how the library can be used and how it can be filled, and finally future directions. Also, an extended example has been provided.

This project is a collaboration between the Dutch Ordina group and the University of Nijmegen. We are currently in the process of gathering information systems engineering knowledge within the context of the Ordina group. We appreciate contributions of other companies, research groups and universities and invite them to join our effort in gathering and structuring the architecture method library.