The Open Group Architecture Framework

The Open Group Architecture Framework (TOGAF), opposed to the Zachman Framework, is a recipe, that is, a process for creating an organisational architecture (The Open Group, 2012). As an architecture framework, TOGAF provides methods and tools which can be used create, maintain and use enterprise architecture. The foundation of TOGAF is an iterative process model. It is accompanied by a set of best practices and re-usable architecture assets. TOGAF provides for four architecture domains, namely, the business, data, application and technology architectures (The Open Group, 2012).

The TOGAF Architecture Development Method (ADM) provides the process for the creation of enterprise architecture. The ADM can be used for the creation of an architecture framework, developing of architecture content, transitioning to new architecture as well as governing the implementation of an enterprise architecture. This is done repeatedly using the ADM to define and implement architecture. The architecture repository is used with the ADM. The architecture repository contains examples of architectures, models, and patterns that can be used as templates when creating architecture. As architecture is developed over time, the architecture repository will grow, since newly developed artefacts are constantly added.

34

Figure 2.6: The ADM process (The Open Group, 2012)

The ADM consists of nine cyclical phases:

Preliminary

A. Architecture vision B. Business architectures

C. Information systems architectures D. Technology architectures

35 F. Migration planning

G. Implementation governance H. Architecture change management

The objectives of each phase are illustrated in Table 2.2 below.

Table 2.2 Objectives per phase of the ADM

Phase Objective

Preliminary Determine where the organisation wants

to be in terms of architecture capability Establish the required architecture

capability

A. Architecture vision Develop a vision of capabilities and value to be created by means of the new architecture

Acquire approval for statement of architecture work

B. Business architectures Develop the target business architecture Develop proposed architecture roadmap C. Information systems architectures Develop the target application

architecture

Develop proposed architecture roadmap D. Technology architectures Develop the target technology

architecture

Develop proposed architecture roadmap E. Opportunities and solutions Produce initial complete version of the

architecture roadmap

Develop transition architectures if needed F. Migration planning Finalise the architecture roadmap and

the supporting Implementation and migration plan

Align implementation and migration plans with organisational change management strategies

36

Facilitate understanding of business value and cost-of-work packages and transition architectures

G. Implementation governance Govern the implementation to ensure alignment with target architectures Govern changes to target architectures if

needed

H. Architecture change management Maintain the architecture life-cycle Execute the architecture governance

framework

Ensure the EA capability meets requirements

To illustrate the involvement of the human component in implementing EA by means of TOGAF, the following section will elaborate on what the enterprise architect needs to do practically to achieve the objectives per phase as presented above.

In the preliminary phase, the enterprise architect needs to collaborate with the business executives as well as the CIO to introduce TOGAF and agree on any changes needed to suit the organisational culture. In collaboration with business executives, the enterprise architect needs to understand the business philosophy and business models, as well as strategic goals and drivers. Additionally, among the business executives, the CIO, as well as the enterprise architect, they have to agree on the architectural principles relevant to the organisation. This process involves close collaboration, communication and trusting relationships to share information between business and IT role players and achieve common understanding and consensus.

In phase A, the CIO needs to work closely with the business executive and supporting business team members to define the scope of the architecture project, identify constraints, as well as document the high-level baseline architecture and future target architectures. This includes the business, technology, data and application architectures.

Phase B involves the compilation of a detailed baseline and future target architectures using the deliverables from phase A. Following this is a detailed gap analysis between baseline and target architectures.

37

As part of phase A and phase B, IT role players such as the enterprise architect, CIO, and the project manager, as well as business analysts, need to facilitate approval and buy-in from business representatives for the future target architectures. Close collaboration and sharing of knowledge will be needed between business representatives, the project manager, and business analysts in order to compile and agree on the detailed baseline and future target architectures.

Phase C involves formulating the target information and application architectures. The participants in this phase are primarily IT role players. It involves a collaborative team effort involving, amongst others, the enterprise architect, CIO, business analysts, system analysts, application portfolio managers and data analysts.

The activities of phase D involve documenting the existing technology architecture as a baseline. It also requires the development of the technology architecture needed to support the proposed future architecture. Once this has been done, a gap analysis has to be done between the current and proposed technology architecture. The role players in this phase are primarily the technical architects as part of the CIO‟s team. Close collaboration is needed between the role players to achieve buy-in and consensus on the proposed future architecture. The project manager plays a key role in this phase to facilitate the team working together towards delivering the future target technology architecture.

Phase E focuses on evaluating the various implementation alternatives in terms of implementing the target architecture. Members of the CIO‟s team, as well as representatives from the business side, are involved in determining the most suitable way to implement the proposed target architecture. Business and strategic plans need to be reviewed to determine potential constraints, and gaps identified in steps B, C and D need to be reviewed and consolidated. Implementation dependencies need to be defined and potential risks involved in transforming to the target architecture should be assessed, documented and mitigation strategies formulated. An overall implementation and migration strategy is the next step as part of phase E. This needs to be facilitated by the project manager, after which the next focus is the identification of work packages needed to implement the target architectures. The next step is the creation of an architectural road map and detailed implementation and migration plans. The project managers and supporting staff from the project office are key role players in these activities. Business representatives, including project owners and project sponsors, are key players as part of this collaborative effort, together with IT role players such as the CIO and the enterprise architecture team.

38

Phase F encompasses the compilation of detailed implementation and migration plans. Business role players responsible for business planning and staffing of implementation efforts, the CIO and the enterprise architecture team, business and IT project and portfolio management teams as well as operations management are involved in this planning phase. The business value for each work package needs to be determined and business and IT cost and resource estimates need to be compiled for each work package. This is followed by the prioritisation of each project, and succeeded by the compilation of detailed implementation plans for business and IT activities.

Phase G focuses on governing the implementation projects. Scope and priorities are confirmed between the project manager and the development team as well as business representatives on each project. Resources and skills required on both the IT and business sides are identified. This phase also includes conducting post-implementation reviews and the compilation of service-level agreements between business and IT.

Phase H involves establishing and managing relevant change management processes as well as change governance structures. This is a collaborative effort between business and IT management requiring discipline and close collaboration between business owners and IT professionals in the SDLC.

Figure 2.7 illustrates a sample of typical stakeholders involved during the ADM cycle (The Open Group, 2012). In this example, provided by The Open Group, there are 22 different stakeholder types during a typical EA implementation. Depending on the size of the organisation and industry involved, the number of stakeholders can be greater or smaller. The illustration is, however, comparable to stakeholder complements I have observed as part of my corporate IT experience. Successful implementation of EA projects is highly dependent on close collaboration and teamwork between the above mentioned typical stakeholders.

39

Figure 2.7: Stakeholder analyses (The Open Group, 2012)

As in the case of the Zachman Framework, TOGAF does not refer to EI or any skills or competencies required by the different stakeholder types involved in a typical EA implementation. As stated above, the ADM provides the process for the creation of enterprise architecture. TOGAF requires intense collaboration between the different stakeholder types during execution of each phase of the ADM. The human is, however, absent from the guidelines per phase. The absence of skills and competency guidelines for IT professionals utilising the ADM, especially the EI of EA professionals, could lead to unsuitable decisions, negatively impacting business – IT alignment and organisational success.