Complementing TOGAF with the EAM Pattern Catalog

Today’s enterprises are more than ever forced both to react to environmental changes resulting from a staggering globalized economy and to proactively seek new business opportunities. These aspects demand that an enterprise not only has its business—and IT—functions aligned, but also has incorporated management policies that increase overall flexibility and agility. To enable this enterprise agility, managers must know what their company is good at and which areas retain potential for improvement.

However, this question cannot be answered by thinking in terms of “business-only” or “IT-only.” Instead, it has to account for the complex web of interdependencies between business and IT aspects, which together form the enterprise architecture (EA). This architecture constantly evolves over time, as various business and IT projects keep changing the structure of the enterprise and hence tune the interplay of business and IT.

It is necessary to manage this evolution holistically to avoid growing dissonances and to increase the alignment of business and IT. This is why many enterprises are introducing integrated EA management (EAM).

The design of an EAM function for an enterprise is no easy task. Various frameworks exist, as well as EA management tools, which promise to deliver guidance for performing EA management. Still, the presented approaches are either too abstract to provide realization support or far too generic. Hence, they neglect enterprise-specific EA concerns. In this article, we discuss The Open Group Architecture Framework (TOGAF) and its promising but nevertheless highly generic Architecture Development Method (ADM). Complementing the method, we introduce a pattern-based approach to EA management providing guidance for addressing specific EA-related concerns with step-by-step methodologies as well as with corresponding viewpoints and information models.

Two Promising Approaches to Start an EA Management Endeavor

Being confronted with the task to establish an EA management in an enterprise, the responsible architect typically seeks for standards or best practices available in this field. Probably, the most prominent framework for EA management today is TOGAF1, which was released in its version 9 in February 2009. The core contribution of TOGAF is the ADM, which describes a reference method containing 10 generic phases of EA development (see figure 1). Each phase of the ADM is described by objectives, inputs, steps, and outputs. Thereby, the descriptions stay on an abstract and generic level.

The information objects to be documented, maintained, and visualized are described in the content framework of TOGAF. The content framework provides a conceptual information model for describing architectural artifacts, i.e., for storing information to support EA management. This model is designed in a highly general way and, consequently, covers a broad variety of EA-relevant concepts on a fairly abstract level. Nevertheless, TOGAF 9 does not regard the information model to be compulsory and explicitly accounts for the combined usage with other conceptual information models.

The Enterprise Architecture Management Pattern Catalog (EAMPC) is another prominent approach, which aims at supporting enterprises in the design of an enterprise-specific EA management function. Patterns have a long history as a means to document proven practice-based, general, and reusable solutions to recurring problems. Their initial exposition dates back to 1977, when C. Alexander proposed the concept in his famous book A Pattern Language: Towns, Buildings, Construction. In this book, he introduced the general notion of patterns in the field of architecture, but the concept was quickly adopted by various other disciplines, such as software engineering. The EAMPC builds on the success story of patterns and applies them to the field of EA management. It introduces four different types of patterns:

• Methodology Patterns (M-Pattern) define processes and roles to be taken in order to address a given concern.

• Viewpoint Patterns (V-Pattern) provide a language used by one or more M-Patterns and propose ways to present data (graphical, tabular, text based, etc.) stored according to one or more Information Model Patterns.

• Information Model Patterns (I-Pattern) supply an underlying model and a glossary of the used concepts for the data visualized in one or more V-Patterns.

• Anti Patterns document recurring solutions, which have proven not to work in practice in order to prevent typical mistakes in EA management

In addition, EAM patterns explicate potentially conflicting forces influencing the solution for a concern. They further denote known usages in practice as well as implementations of the pattern in EAM tools. Finally, applying a specific solution to a given problem commonly does not come without cost. The EAM patterns account for this fact by giving indications on consequences, which may arise from the usage of the pattern, such as the effort related to data collection. On the level of detail as accommodated by the patterns, an overall process description for performing EA management is not that easy to establish. At this point, TOGAF’s ADM provides a valuable complement.

Using the Pattern Catalog to Detail the TOGAF ADM

Let’s look at the single phases of the ADM cycle, the steps conducted in each phase, and how the EAMPC can be used to complement the generic method of TOGAF based on best practice solutions gathered from practitioners and academia.

The TOGAF ADM cycle starts with the Preliminary Phase, which prepares and initializes the EA management approach. Typical tasks executed in this phase include the definition and establishment of the EA team, the selection and implementation of supporting tools, as well as the definition of architecture guidelines and principles.

After the preparation and initialization activities are performed, the scope of the EA management endeavor is defined within the Architecture Vision Phase (Phase A). A core objective of this phase is to identify the relevant stakeholders and their concerns. Whereas TOGAF details on the management of stakeholders and explicates categories of stakeholders, e.g., executives, line manager, and business process experts for the project organization, it does not give a procedure on how to gather the relevant concerns. Based on the identified stakeholders and their concerns, a high-level architecture vision of the enterprise is derived in this phase. The EAMPC can be used to support the identification of relevant concerns; it explicitly lists typical concerns in the context of EA management. These concerns can be used as input to the stakeholders identified according to TOGAF.

Based on the architecture vision developed in the Phase A, the corresponding business, information systems, and technology architecture is developed in the following phases: Business Architecture (Phase B), Information Systems Architectures (Phase C), and Technology Architecture (Phase D). The fundamental makeup of these three phases is similar: Initially, the baseline architecture is described. Based on this architecture, the target architecture is developed taking the architecture vision into account. This vision was formulated in the preceding phase. Furthermore, a gap analysis is performed to evaluate the differences between the baseline and the target architecture. Whereas, TOGAF describes only a generic EA management process, which needs to be adapted to the specific needs of an enterprise, the EAMPC can be used for this adaptation and to solve the following problems:

• Identify concepts to be collected: No information about the exact data to be gathered within the Phases B to D is given. Nevertheless, the importance of gathering only the necessary information to avoid gratuitous effort is referred to by advice given in TOGAF: Gather and analyze only that information that allows informed decisions to be made relevant to the scope of this architecture effort. The EAMPC can be used here to derive the needed information from the concerns identified in the Architecture Vision Phase. In contrast to TOGAF, the EAMPC follows a concern-driven approach and supports the deduction of relevant information model fragments corresponding to the selected concerns.

• Determine overall modeling process: To perform this task, best practice solutions as documented in the M-Patterns of the EAMPC can be used.

• Identify required visualizations: TOGAF details the importance of choosing the appropriate viewpoints to ensure that the concerns of the stakeholders are covered. Furthermore, the viewpoints need to be selected according to their appropriateness for the stakeholders involved. The EAMPC can be used to ensure the suitability of models and viewpoints as it directly links V-Patterns to concerns.

The Opportunities and Solutions Phase (Phase E) is concerned with the derivation of projects and programs, which describe the transformation from the baseline to the target architecture via intermediate transition architectures. The major steps to be performed in this phase are the consolidation of the gap analyses from phases B to D; the identification, refinement, and validation of dependencies between the different architectural layers; and the derivation of transition architectures, which group projects and portfolios. The deduction of transition states can be supported by the EA best practice solutions as documented in the EAMPC. Failure Propagation Specific Proposal Comparison, for example, documents how to automatically generate possible transition architectures in the context of failure propagation.

The aforementioned transition architectures form the input of the Migration Planning Phase (Phase F), which is concerned with formulating an implementation and migration plan that schedules and realizes some or all of the transition architectures. The major steps within this phase are the assignment of a business value to each project, the prioritization of projects, and the generation of a road map and migration plan. Within the context of migration planning, the aspect of time-dependence arises, leading to certain demands regarding an information model and the visualizations used in this phase. These demands are addressed by the EAM patterns Functionality Migration Road Map and Business Support Migration of the EAMPC, which can be used to support this phase.

In the Implementation Governance Phase (Phase G), the projects selected for realization in Phase F are executed. Major tasks of this phase are identifying deployment resources and skills, monitoring the execution, and conducting reviews, e.g., regarding architecture compliance. The implementation aspects of concerns are addressed in the EAMPC as part of the EAM patterns, which give indications on implementation details. An example of an implementation detail originating from the context of architectural standardization is discussed in Standard Conformity Management.

The Architecture Change Management Phase (Phase H) concludes an ADM cycle and prepares the initiation of another cycle. As part of the phase, the changes of the architecture are assessed. Key tasks of this phase are deploying monitoring techniques for the architecture process, developing change requirements to meet performance targets, and managing the governance process. Existing analysis and metrics patterns from the EAMPC, e.g., Verification and Audit, can be used here to assess the achievement of the specified objectives.

Complementing the generic process of TOGAF with patterns from the EAMPC has been proven to facilitate the conduction of EA management projects in practice. In different projects, we have used EAMPC’s concern-driven approach to realize the generic steps of TOGAF’s ADM. Especially, the possibility to derive the information model from the concerns risen by the stakeholders provides a useful extension to the ADM. Furthermore, the best-practice visualizations of the EAMPC have been proven to be used to augment the deliverables defined within TOGAF.

The EAM Pattern Catalog and case studies can be found at http://eampc-wiki.systemcartography.info.

by Sabine Buckl, Alexander M. Ernst, and Christian M. Schweda, research assistants at the chair for Software Engineering for Business Information Systems (sebis) at the Technische Universität München (TUM–Munich University of Technology).