TOGAF in the Enterprise

Introduction The Wider Architecture Process Approaches to Enterprise Integration Tailoring the ADM

Introduction

TOGAF originated as a framework and method for technical architecture, but over the years has evolved to the stage where it is eminently suitable for adaptation as an enterprise architecture framework and method. It can also be adapted to the specific circumstances of an organization.

Each organization coming to TOGAF will do so from its own unique context in terms of the practices it currently has in place (if any) for architecture development, business planning, and enterprise integration, and the current status of these activities within the enterprise concerned.

This subsection is intended to place TOGAF and its Architecture Development Methodology (ADM) in the context of the wider processes that enterprises contemplating architecture development typically already have in place, or are considering putting in place. The aim of is to help readers relate TOGAF and the description of the ADM to their own specific situations.

TOGAF and its ADM are a generic framework and method for architecture development, and one of the tasks before applying them to a specific situation will be to review them and tailor them if necessary to the circumstances of the enterprise concerned. This activity would produce an organization-specific framework and ADM.

The Wider Architecture Process

The TOGAF FAQ explains that there are four kinds of "architecture" within the world of Information Technology that are commonly accepted as subsets of an overall Enterprise Architecture:

business architecture;
data/information architecture;
application (systems) architecture; and
Infrastructure architecture.

TOGAF is primarily designed to support the last of these - the infrastructure architecture. However, it also aims to provide sufficient background on other related processes for the reader to be able relate the use of TOGAF and its ADM to these other processes.

Any organization seeking to use TOGAF and its ADM needs to understand, not only how these different "architectures" relate to each other (as explained in the TOGAF FAQ), but also how they and the ADM fit into the wider enterprise planning and integration process.

Approaches to Enterprise Integration

Enterprise Architecture Frameworks

Several frameworks and methodologies exist that relate to this wider context. The following two are widely recognized, and discussed in Part IV, Other Architectures and Frameworks:

Before considering enterprise frameworks, however, it is worth considering...

What is An "Enterprise"?

The term "enterprise architecture" is used in many contexts. It can be used to denote both the architecture of an entire enterprise, encompassing all of its information systems, and the architecture of a specific domain within the enterprise. In both cases, the architecture crosses multiple systems, and multiple functional groups with the enterprise.

A good definition of "enterprise" is any collection of organizations that has a common set of goals and/or a single bottom line. In that sense, an enterprise can be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership.

Confusion also arises from the evolving nature of the term "enterprise". An "extended enterprise" nowadays frequently includes partners, suppliers and customers. If the goal is to integrate an "extended enterprise", then the enterprise comprises the partners, suppliers and customers, as well as internal business units.

Large corporations and government agencies may comprise multiple "enterprises," and hence there may well be separate enterprise architecture projects. However, there is often much in common about the information systems in each "enterprise", and there is usually great potential for gain in the use of a common architecture framework. For example, a common framework can provide a basis for the development of an architecture repository for the integration and re-use of models, designs, and baseline data.

Enterprise Architecture Frameworks

Several frameworks and methodologies exist that relate to this wider enterprise context. All have their advantages and disadvantages. The following two are widely recognized, and discussed in Part IV, Other Architectures and Frameworks:

Although a number of enterprise frameworks exist, there is no accepted industry standard method for enterprise architecture that is in the public domain. TOGAF's ADM provides an industry consensus method, in the public domain, that is sufficient for an organization to adapt as the basis of an enterprise architecture method, and considerations in doing this are explored below. Besides an integrated method, TOGAF also provides a Technical Reference Model, taxonomy of viewpoints, Standards Information Base, and other resources (in Part IV).

Tailoring the ADM to the Enterprise Context

Particularly if an organization is using an enterprise framework such as described above, and seeking to integrate TOGAF and its ADM into such a framework, it may well be necessary to tailor the TOGAF ADM to the specific environment.

A Generic Process for Enterprise Architecture

Whatever enterprise wide approach is taken, there are certain conclusions that can be drawn about the order in which the main architectural activities are undertaken. The process outlined below is consistent with and supportable by the TOGAF ADM, with appropriate tailoring to the circumstances of the enterprise concerned:

An understanding of the business architecture is generally accepted as a prerequisite for any IT architecture or enterprise integration activity, and is therefore normally the first architecture activity that needs to be undertaken, if it is not catered for already in other organizational processes (enterprise planning, strategic business planning, business process re-engineering, etc.).
The development of the business architecture may be done in a variety of ways; for example:
- The enterprise mission, vision, strategy and goals may be documented as part of some wider business or enterprise planning activity that has its own life-cycle within the enterprise.
  - In such cases, there may be a need to verify and update the currently documented business strategy and plans, and/or to bridge between high-level business strategy and goals on the one hand, and the specific business drivers and business process requirements that indicate the technical requirements for IT architecture.
- In other cases, little or no business architecture work may have been done to date.
  - In such cases, there will be a need for the IT architecture team to research, verify and gain buy-in to, the key business objectives and processes that the IT architecture is to support. This may be done as a free-standing exercise, either preceding technical architecture development, or as part of the ADM Initiation Phase.
In both of these cases, the Business Scenario technique of the TOGAF ADM, or any other method that illuminates the key business requirements and indicates the implied technical requirements for IT architecture, may be used.
Some combination of data and applications architecture typically comes next, in either order (advocates exist for both sequences). For example, Spewak’s EAP above recommends a data-driven approach. Increasingly, applications systems such as those for Enterprise Resource Planning, Customer Relationship Management, etc. provide a combination of infrastructure and business application logic, and some organizations take an application-driven approach, in that they recognize certain key applications as forming the core underpinning of the mission-critical business processes, and they take the implementation and integration of those core applications as the primary focus of architecture effort - the integration issues often constituting a major challenge.
Technical architecture is typically undertaken once the business, data and applications architecture is understood.
Implementation of these architectures may not necessarily follow the same order. For example, one common implementation approach is top-down design and bottom-up implementation:

business architecture design

data (or applications) architecture design

applications (or data) architecture design

technical architecture design

technical architecture implementation

applications (or data) architecture implementation

data (or applications) architecture implementation

business architecture implementation

It is important to recognize that the above sequence represents an idealized situation. In practice, this type of work is rarely if ever undertaken in a ”green field” situation, and each of the above stages will be undertaken only if strictly necessary. For example, a change to the business architecture should not impact the technical infrastructure in all cases. Also, if new applications require new data, then the data architecture may well need to be considered, but if they use existing data, then it may not be necessary to visit the data architecture.

The preceding subsection outlines one of the main reasons for wanting to tailor the ADM (its use in a wider enterprise context). Part II, Introduction to the ADM, reviews some of the other reasons why enterprises may want to tailor the ADM.