As we have just seen, enterprise architecture transformation is at the heart of the subject matter dealt with by TOGAF, which discusses the following questions in detail:

• Which routes to follow?

• How to organize oneself?

• How to communicate?

• What are the main risks and how can they be reduced?

In this way, TOGAF distinguishes itself from other Zachman⁹-type frameworks, which primarily propose a typical architecture structure, and concentrate far less on the actual transformation approach. However, TOGAF provides its own content framework, with its specific terminology and structure (Figure 1.3).

But let’s get back to the heart of the matter: Which approach should be adopted to make our enterprise architecture evolve? This can be summed up in four points:

• Knowing where we are coming from

• Determining where we want to go

• Choosing the best path to get there

• Successfully completing the transformation

Knowledge of the baseline architecture is not always clearly established. Consequently, a more or less detailed “reappraisal” of what already exists is often necessary. All the more so when we consider that the transformation roadmap depends on the gap analysis between these two states, and on the impact that this transformation has within the enterprise.

Determining the destination, that is to say the target architecture, depends above all on business goals, but also on a series of technical, organizational, and budgetary factors.

Finally, the means used to conduct the transformation must be chosen. What is the timeframe? How can we guarantee that certain critical parts will continue to function? How can we best prepare participants confronted with changes in their activities?

Transforming architecture

Any person who has been confronted with the exercise will say the same thing: making enterprise architecture evolve is a delicate and complex activity. Successfully completing transformation means fully understanding all the constraints that apply to this type of operation.

First off, any evolution of enterprise architecture requires that a large number of highly dependent elements be coordinated. Consequently, the involvement of the different stakeholders is a determining factor in the success of the operation, especially when we consider that this evolution often has significant consequences on the enterprise itself, its activities, and its employees.

Furthermore, the conditions that start an architecture project are diverse, ranging from the introduction of new services or products or the renovation of a part of the system, to internal restructuring or company mergers or buyouts and acquisitions, and so on. This means that the reference framework must have a certain degree of flexibility, since too much rigidity would run the risk of “jamming” the machine.

The scope covered by the transformation also has an influence on the variety of situations encountered. In most cases, we are not building a complete system “from scratch.” On the contrary, developments generally concern specific parts of the system, linked to business goals.

Enterprises behave like living organisms, constantly reacting to external requests. Like a shop that advertises “business as usual during renovation,” the enterprise never suspends its activities, since continuity of service must be guaranteed.

To sum up, the road to follow is not “preordained.” However, the framework can help accelerate and guide change initiative, although the combination of parameters that must be taken into account means that it will always need to be adapted to a particular context.

Transition architectures and increments (states)

How do you move from existing (baseline) architecture to target architecture? The answer to this question, provided in the form of a path (or migration architecture), is a key element of TOGAF, founded on the following principles:

• If it is to succeed, this path must take into account all the facets of the enterprise, and the effects resulting from all changes.

• The path includes intermediate states, described by the transition architecture.

• These intermediate states must bring real, measurable added value.

• Gap analysis between the target architecture and the baseline architecture is a determining element in the choice of path.

Operationally speaking, this path results in a series of implementation projects of various different types: software development or evolution, data migration, training, and business reorganization. The successful coordination of these different projects goes a long way to determining the success or failure of the operation (Figure 1.4).

The number of states varies according to the domain, scope, time horizon, and level of details as well as the difficulties encountered. A direct transition (with no intermediate states) to the target architecture is possible where the gap between the baseline architecture and the target architecture is limited. Progress through states reduces resistance to change, and reduces risk by making adjustments easier.

The description of this migration path is one of the major TOGAF¹⁰ deliverables, notably for developing the operational project schedule.

Gap analysis

In order to choose the appropriate path between two states, the gap between these two states must be analyzed. The same is true when transitioning from a baseline architecture to a target architecture.

The principles of gap analysis are relatively simple. The comparison of baseline architecture and target architecture results in answers to the following questions:

• Which elements are new (organizations, applications, infrastructures)?

• Which elements have been deleted?

• Which elements have been modified?

• Which elements remain unchanged?

However, these results must be considered alongside the business goals of the transformation, in order to check their pertinence. Is the deletion of such and such an element appropriate? Have we forgotten to add such and such an element?

Chapter 27 of TOGAF (Gap Analysis) proposes the use of a baseline/target matrix, which highlights differences and makes them easier to analyze.

One advantage of this tool is that it proposes a systematic approach, which helps avoid “flaws.” During the different phases of the ADM, the aim is to identify elements that have potentially been overlooked, but that play an important role in measuring the gap between baseline and target architectures, and that will be significant to the change operations that are to be carried out. Beyond aspects linked to IT systems, this gap measures the distance that must be covered if the enterprise is to be capable of meeting new business goals: for example, employee skills, modifications to organizational structures, or the availability of technical means.

Impact evaluation

An enterprise is often a complex organization with multiple branches. Consequently, the modification of one part of its architecture may potentially affect other components situated outside the scope of the implemented changes.

First, the impact can be technical: any modification of a software component can potentially have repercussions on all the components that use it.

Second, the changes made can also indirectly affect certain business aspects. For example, increasing the number of products available will probably have an impact on how other products are presented.

Finally, the restructuring of an enterprise’s organization, even partial, can have repercussions on the way the enterprise functions, through the relationships that exist between different departments and their members.

We will see that during architecture development phases, gap analysis and impact assessment go hand in hand, each influencing the other in terms of architecture choices and transition management. Even though this development initially focuses on its scope, it must take into account the enterprise in its entirety.

The concept of capability

Capability designates the ability of an organization to provide a given product or service. Capability manifests itself through a series of factors that contribute to the realization of these products or services at the required level of quality. These factors can vary widely in type: for example, personnel training, availability of an expert in a field, surface area of premises, power of IT servers, and so on.

The notion of capability is also widely used in other frameworks. ITIL defines it as being “The ability of an organization, person, process, application, IT service or other configuration item to carry out an activity.”¹¹ It is also naturally found in the acronym CMMI (capability maturity model).

The fact that this term appears nearly 500 times in the TOGAF document is testament to just how essential it is to consider a business function as a whole, far beyond a strictly “IT system” view. The enterprise must be able to satisfy its clients, and in order to do this, it must be fully operational. Even the most perfect application can only function in an environment that is able to use it. A badly informed user, a badly adapted procedure, or unmotivated management will inevitably prevent the realization of the defined goal.

More generally, the goal of an ADM cycle is to improve or put in place new business capabilities. This goal is present during each phase, so as to coordinate the different dimensions of the architecture (business, system, and technology) in order to converge on the final solution. This goal also applies to each step of the path, as we saw earlier.

In TOGAF, two chapters are specifically dedicated to this:

• Chapter 32, “Capability-Based Planning,” a technique for planning the transition from baseline architecture to target architecture based on capabilities.

• Part VII of the TOGAF document, “Architecture Capability Framework,” deals with the organization and governance of enterprise architecture. We discuss this point further in Chapter 4.2. Here, the term “capability” designates all the organization elements that have to be implemented in order to guarantee efficient management of enterprise architecture.

We have already spoken at length about architecture and transformation, but it is useful at this point to refresh our memories regarding the term “architecture” and its content. In its introduction,¹² TOGAF gives two definitions of the term “architecture”:

1. “A formal description of a system, or a detailed plan of the system at component level, to guide its implementation.”

2. “The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.”

The first definition considers the term “architecture” as a synonym of “system description.” For the second, “architecture” designates the structure and principles of the system, independent of its description.

This double definition may seem surprising, but it does reflect a very real situation. Software systems are, by nature, opaque, so much so that their structure is only visible through representations. Factories, ships, or engines all have a physical structure, which is more or less visible. However, it is impossible to “lift the hood” of an IT system, whose architecture only exists through its representation. This is also the case for business elements such as processes, organization, or strategy, which can only be communicated through descriptions or models. The proliferation of schemas, diagrams, and tables within enterprises is testament to this reality.

In this context, communication on architecture plays a determining role. Just like the blueprints of a building, communication is a vital tool for those working on the different tasks involved: development, evaluation, exchange, and construction. In this book, we have chosen to focus particularly on this point, through the use of concrete examples (Chapters 6–11).

Domains and phases

What are some of the main subject areas in enterprise architecture? TOGAF proposes a high-level breakdown into four large domains:

• Business architecture, which covers strategy, goals, business processes, functions, and organization.

• Data architecture, dedicated to the organization and management of information.

• Application architecture, which presents applications, software components, and their interactions.

• Technology architecture, which describes the techniques and components deployed, as well as networks and the physical infrastructure upon which the applications and data sources run.

This breakdown is unsurprising and fairly similar to other proposals on the same subject, although each has its own particularities and vocabulary.¹³ Chapter 3 takes a more detailed look at the contents and structure of TOGAF architecture.

The first part of the ADM approach is structured using the same typology, with one main difference: only three phases are dedicated to the elaboration of the architecture: business (phase B), IS (phase C), and technology (phase D). The IS architecture phase has two subphases (data and application), which correspond to the two aforementioned domains. From here on, we either use the term “IS architecture” or else directly refer to “data architecture” and “application architecture.” Figure 1.5 summarizes the two structures (by domain and by phase) used in TOGAF.

We see in Chapter 3.2.4 that this equivalence between architecture domains and ADM phases, while pertinent at first glance, is not strictly valid in detail.

Architecture repository

Naturally, enterprises need to conserve, diffuse, and reuse the EA information that constitutes one of their key assets. This is the role of the architecture repository, which includes descriptions from each of the four domains, as well as a whole host of knowledge, guiding principles, and techniques linked to enterprise architecture. Far from being a static source of information, the repository is constantly evolving throughout architecture transformations, thereby participating in know-how capitalization. It also provides an overview of the architecture, which facilitates decision making at a strategic level.

Architecture and solution

For TOGAF readers, one item of vocabulary still has to be explained. TOGAF often refers to solution architecture. Here, the term “architecture” designates a description, and more precisely a logical view, as opposed to the “solution,” which represents a technical reality. This distinction can be clearly seen in the terms “Architecture Building Block” and “Solution Building Block” (respectively ABB and SBB). The logical specification of an element is an ABB, while its physical equivalent is a SBB. These two types of element are present in the architecture repository, which enables either the documentation or the physical component to be reused, according to the context.

Managing stakeholders

First, it is essential to clearly define each stakeholder as early as possible during the ADM cycle. This identification mainly uses a pragmatic approach in order to avoid simply reusing existing organizational structures, which only partially represent the reality of the activities and responsibilities that will be put in motion. Leaving a key participant by the wayside would significantly affect the quality of the results. Consequently, in order to determine with whom and in what form work will be carried out, a series of key questions must be answered on the subject:

• Who defines goals?

• Who gains and who loses from this change?

• Who controls the transformation process?

• Who designs new systems?

• Who will make the decisions?

• Who procures IT systems and who decides what to buy?

• Who controls resources?

• Who has or controls the necessary specialist skills?

• Who influences the project?

From these questions, TOGAF recommends that the position of each stakeholder be clarified, notably his or her degree of involvement. Figure 1.6 presents these different degrees.

Each stakeholder will be positioned using these degrees of involvement, which determine the relationships to develop and the level of involvement in architecture project steering committees. Naturally, key players play a determining role and must be on the front line in all areas of decision making.

This qualification is cross-referenced with the role played in the context of the current project:

• The executive management, who defines strategic goals

• The client, who is responsible for the allocated budget, with regard to the expected goals

• The user, who directly interacts with the system in the course of his or her activities

• The provider, who delivers the component elements of the architecture, notably its software components

• The sponsor, who drives and guides the work

• The enterprise architect, who turns business goals into reality within the structure of the system

Transformation Readiness Assessment

Is the organization ready for the envisaged change? This question may seem incongruous, but how many projects have finished unsuccessfully because this dimension was not taken into account? In just a few years, “change management” has become a discipline in its own right, producing a large number of articles and seminars.

Chapter 30 of TOGAF¹⁴ is entirely dedicated to this question, which is widely discussed in the description of the ADM phases. The identification of change resistance risks and the definition of actions to take to limit these risks are essential tasks that must be carried out before embarking upon a transformation project. This is particularly important for an operation covering a broad scope and resulting in significant restructuring.

While it is not possible to provide turnkey solutions on such a subject, it is possible to use certain techniques that will help reduce this type of risk:

• A clear presentation of the impacts of changes made, notably on an organizational level

• A concrete view of the expected business benefits, in the form of “business cases”

• An objective assessment of the enterprise’s IT, business, and financial aptitudes, with no overestimation of its real capacities

• An executive management team recognized as being able to defend the project in the long term

• High-quality communication, which aims to promote a common understanding of the stakes and the solutions to implement

Views and viewpoints

If a message is to be successfully understood, the most important aspect to consider is that its content and form must be tailored to the intended recipient.

For this, TOGAF uses the concept of viewpoints. A viewpoint designates the most appropriate perspective for a given participant, and is materialized by a certain number of views of the architecture, in the form of diagrams, documents, or other elements. For example, executive management will be more interested in a high-level description, while communication with operational staff will require much more detailed representations.

This is a critical point, one that will condition the quality of communication and that will be encountered during each phase of the ADM cycle. Consequently, it is imperative that views and viewpoints be defined for each stakeholder before beginning work on the four architecture domains (business, data, application, and technology). We discuss this question in detail in Chapters 7–10, with examples taken from TOGAF views.

We have just seen that implementing transformation constitutes the main theme of TOGAF. We have also seen that architecture transformation is driven according to business goals defined for a specific scope.

However, a wider, more long-term perspective is also necessary. It is clearly up to the enterprise’s executive management to define general goals and develop the strategy. These translate into decisions concerning architecture, notably in terms of evolutions to the IS.

In a framework such as TOGAF, this aspect is found in the form of links between business strategy elements and system components. The formalization of “drivers,” “strategic goals,” or “business requirements” is included in the business architecture part of TOGAF. This formalization of the “why” contributes to a common understanding of business fundamentals, and clarifies the role of each component in a wider perspective.

Moreover, architecture choices will affect the system for years to come. The system must meet today’s requirements, but must also be able to adapt to tomorrow’s needs. Ensuring overall consistency on the functional and technical levels is therefore vitally important for those in charge of enterprise architecture.

Governance

In a complex organization, this strategic view cannot be taken for granted. Consequently, to slow down the centrifugal forces and retain a certain level of overall consistency, it is essential that an appropriate organization be established. This organization, which is centralized by nature, uses a cross-organizational mode of governance that handles architecture in terms of the enterprise, its strategic choices, its principles, and its action plan.

This organization, called the “architecture board,” is responsible for the following goals: to guarantee that common rules are respected, and to ensure that implementation projects are supported. In its capacity as a steering and control committee, the architecture board also takes care of managing the architecture repository. We go into more detail on this point in Chapter 4.

Architecture principles

Architecture principles provide invaluable help in this strategic view of the architecture. They establish a set of rules and recommendations, which encourage the harmonization of choices and practices.

TOGAF recommends that these architecture principles be established as early as possible, as a unifying element for future projects. Architecture principles are a kind of table of statutes, which must respect the following properties:

• Stability: Principles are stable by nature. They are only rarely modified compared with the frequency of developments.

• General scope: A principle applies to the entire enterprise, and does not depend on the transformation carried out.

• Comprehensibility: A principle is interpreted clearly by all stakeholders.

• Coherence: With regard to the set of principles. Two principles cannot be contradictory.

Every time a transformation project is begun, each participant must be able to consider these principles as a guide, and use them as a basis for his or her choices.

TOGAF provides an example of a relatively detailed catalog of architecture principles,¹⁵ which includes around 20 principles organized into four families similar to the four architecture domains: business, data, application, and technology.

Rules on relatively diverse aspects are found in this catalog, such as:

• The systematic involvement of users in architectural choices

• The harmonization of application design

• Continuity of service

• The respect of intellectual property protection rules

• The sharing of information

• Data quality levels

• The harmonization of vocabulary

• Security

• Independence with regard to technical platforms

• Ease of use

• The respect of deadlines

• The respect of standards

The reader can refer to the TOGAF document for a more detailed description. Each principle is described in a standard way: the name of the principle, its statement and rationale, and its implications.

This catalog is a relatively broad basis upon which each enterprise can establish its own set of architecture principles. It goes without saying that the wide range of enterprise histories, businesses, and priorities makes individually adapted formulation essential.

It should also be noted that there is no point in having too big a catalog. It is always preferable to work on a limited number (a few dozen) of widely accepted principles, rather than a multitude of badly assimilated rules.

In practice, the catalog of architecture principles is often built based on existing elements, from several sources or spread across different organizations. Where this is the case, the main task is to compile and consolidate information based on the aforementioned characteristics.

TOGAF and DODAF

DODAF (Department of Defense Architecture Framework)¹⁸ provides an architecture management and representation framework. The concept of the viewpoint, also found in TOGAF, plays a central role, linked to governance and stakeholder management.

DODAF viewpoints are structured as follows:

• All Viewpoint (AV)

• Capability Viewpoint (CV)

• Data and Information Viewpoint (DIV)

• Operational Viewpoint (OV)

• Project Viewpoint (PV)

• Services Viewpoint (SvcV)

• Standards Viewpoint (StdV)

• Systems Viewpoint (SV)

As in TOGAF, each viewpoint is broken down into a collection of views, each designed to represent a part of the architecture. For example, the operational viewpoint includes the following views:

• OV-1 High Level Operational Concept Graphic

• OV-2 Operational Node Connectivity Description

• OV-3 Operational Information Exchange Matrix

• OV-4 Organizational Relationships Chart

• OV-5 Operational Activity Model

• OV-6a Operational Rules Model

• OV-6b Operational State Transition Description

• OV-6c Operational Event-Trace Description

• OV-7 Logical Data Model

A fairly similar approach can be found in the MODAF¹⁹ framework, notably with regard to the use of viewpoints and views.

Despite the fact that these frameworks (DODAF and MODAF) are established in a governmental context, and more specifically in the field of defense, they can be used in other contexts. Where necessary, the definition of viewpoints and views can be used to adapt them to the TOGAF framework.

TOGAF and ITIL

ITIL is a framework dedicated to managing ISs. ITIL has been popular since the mid-2000s, notably after the release of version 3 in 2007.²⁰

The main ITIL concept, the service center, clarifies the position of the IS within the enterprise as a provider at the service of its clients, be they internal or external. It establishes a set of recommendations and best practices that aim to control system quality, in terms of reliability, response to needs, and risk reduction.

ITIL deals with all aspects linked to the management of the IT system infrastructure through the description of its processes: service deployment, operation, support, security, and lifecycle.

• Incident Management

• Problem Management

• Change Management

• Release Management

• Configuration Management

Highly quality oriented, ITIL greatly inspired the ISO 20000 norm, as well as the enterprise certification program. For readers wishing to learn more, there are a number of works on the subject.²¹

What is the relationship between ITIL and TOGAF? Since version V3, ITIL has been structured into five “volumes,” focused on the notion of service:

• Service strategy

• Service design

• Service transition

• Service operation

• Continual service improvement

This structure makes certain overlaps with TOGAF²² appear: service strategy with the preliminary phase and phase A; service design with phases C and D; service transition with phases E and F; service operation and improvement with phases G and H.

At first glance, this correspondence can be interpreted as a similarity between the two frameworks. In this case, should we choose between the two approaches and forbid their simultaneous use?

Beyond these formal similarities, the fundamental difference between the two frameworks is first and foremost a question of perspective. ITIL has been developed as a tool dedicated to IT services used to manage IT systems. TOGAF is clearly oriented toward a business view of architecture and the transformation method.

It is clear what the subjects dealt with during phases G and H of TOGAF, which concern the use and maintenance of IT system components, are also widely present in the ITIL community. However, the development of architecture and its impact on the business and the organization, subjects at the very heart of the TOGAF project, are less prevalent in ITIL “culture.”

It should be noted that neither ITIL nor TOGAF is presented as “turnkey” solutions, but rather as reference frameworks. Consequently, the right attitude for enterprises must probably include a healthy dose of pragmatism, taking the best from both approaches.

TOGAF and CMMI

The CMMI²³ is a repository of best practices organized into levels of maturity. It is both a certification framework and a set of processes destined to improve the quality of development projects.

Dissemination of the maturity-level structure is real, and CMMI certification is a guarantee of quality often requested of enterprises. Moreover, this method of evaluating an organization or a system has been used in several different contexts. TOGAF dedicates an entire chapter to this (Chapter 51), and proposes an enterprise architecture maturity evaluation model, which uses the CMMI’s five maturity levels. This model is a result of the “Enterprise Architecture Capability Maturity Model” from the DoC (US Department of Commerce), and is presented below.