Phase F – Migration Planning

The main objective of Phase F or the Migration Planning Phase is to place the varying implementation projects into order based on their priority.

The main activities of Phase F are to assess the costs, benefits and dependencies of the varying migration projects.

All of the projects in the priority list will then become the basis for the Migration Plan and the implementation Plan. It is at this point that an Architecture Evolution Cycle is established which will ensure the architecture remains relevant. Any lessons learnt or feedback should be documented for future reference to enable a more streamlined approach moving forward.

Phase E – Opportunities and Solutions

The objective of Phase E or the Opportunities and Solutions Phase is to:

  • Identify the important phases of change
  • Any known parameters
  • High-level projects / Work packages
  • Any new business opportunities that arise from architecture work during previous phases

That will need to be undertaken when moving from the current environment to the new environment. Any outputs from the Opportunities and Solutions phase will be the initial step in modelling the implementation plan for the target architecture.

Other objectives during the Opportunities and Solutions phase are to perform a gap analysis between phase B (Business Architecture Phase) through to phase D (Technology Phase). In addition, during this phase it is important for the architect to review the capabilities and objectives of the business.

A full review (And confirmation) of the organisation or enterprises current parameters should be taken in order to see the effect of any proposed changes.

The definition of the solution building blocks should also be done and a set of transition architectures should also be derived.

Finally, an overall strategy outlining the Migration and Implementation should be generated and agreed upon with the relevant stakeholders.

When implementing Phase E or the Opportunities and Solutions Phase it is important to understand that this phase is the first phase which is directly concerned with the actual implementation.

On occasion, when identifying any new implementation opportunities a new application may be identified. If and when this occurs, it may be necessary for an architect to revisit and iterate over the previous phases.

Phase D – Technology Architecture

The objective of Phase D or the Technology Architecture Phase is to define and develop the Technology Architecture that will:

  • Identify any candidate Architecture Road-map components using a gap analysis based on differences between Baseline and Target technology architectures.
  • Enable any physical and logical data and application components as well as the Architecture Vision
  • Address any stakeholder concerns and requests for architecture work

Specifically, the Technology Architecture should be able to describe the current and target views of the technology portfolio. These views should identify the key work components and build a road-map toward the proposed Target Architecture.

When implementing Phase D or the Technology Architecture Phase the architecture team will need to acknowledge any Technology Architecture Resources that are available via the Architecture repository and most importantly, are these resources relevant?

There are a vast array of existing Information Technology Services resources already available – these resources include:

Finally, it is important to understand that new emerging technologies can be a major catalyst for organisations or enterprises seeking to improve their business operations.

Any Technology Architecture should be able to understand and implement any new opportunities that may arise via the adoption of new technology.

Phase C – Information Systems Architecture

The main objective of Phase C or the Information Systems Architecture is to develop the target architecture for any Information Systems.

The Information Systems Architecture can be broken down into two separate architectures:

  1. Data Architecture
  2. Application Architecture

The Information Systems Architecture should be able to describe in detail how the enterprise or organisations Information Systems Architecture will facilitate:

  • The Identification of any Architecture Road-map Components based on a gap analysis
  • The Business Architecture
  • The Architecture Vision

Data Architecutre

The main objective of the Data Architecture is to determine the sources and types of data that will be required to support the organisation or business. It is imperative that the Data Architecture should be able to be easily understood by any stakeholders.

Application Architecture

The main objective of the Application Architecture is to determine the specific types of systems that will be required to process any data and to support the organisation or business.

Phase B – Business Architecture

The main objective of Phase B or the Business Architecture Phase is to develop the business architecture that will describe how the enterprise or organisation will need to function in order to reach the business goals that have been specified.

In addition, another objective is to identify the candidate architecture road-map components which are based on any gaps between the target business architectures and the baseline business architectures.

Other key objectives pertaining to Phase B or the Business Architecture Phase are:

  • Elicit any business requirements and identify any existing material that may be able to be reused.
  • To demonstrate to stakeholders the business value of any subsequent work and what return on investment they should expect to see.
  • Describe the baseline Business Architecture
  • Analyse any gaps between the Target Business Architecture and the Baseline Business Architecture.
  • Identify and develop the architecture viewpoints that are relevant.
  • Demonstrate how end stakeholder requirements and concerns are addressed in the Business Architecture
  • Identify and select any techniques and tools that are relevant and can be utilised within the selected viewpoints
  • Identify any existing architecture definitions that may be able to be used as a starting point when creating the architecture

The key aspects when approaching the Business Architecture Phase are:

Approach one -The most common approach

  • An architect must understand that the extent of work in the Business Architecture Phase will directly depend on the the enterprise environment. It is important to be aware that in some instances important elements pertaining to the Business Architecture may be completed within other activities
  • Where the key element may be completed in other activities the architect may be required to verify and update any current or ongoing business plans and strategies. In addition there may be the requirement for the architect to connect between business strategies, business drivers (At a high level) and goals on one-hand and the specific requirements of the business on the other.
  • Where none or a small amount of Business Architecture work has been completed the architect must analyse and research, verify and achieve buy-in to the main business objectives and processes that the architecture must support.

A secondary approach

Establishing the Baseline Description

Where the business has existing descriptions of the architecture. In this scenario, then these descriptions should form the basis for the Baseline Description. Where no architecture descriptions exists, then information should be obtained and the relevant Business Architecture Models developed.

Implementing Business Capabilities

Use the the business capability map that was either found or developed during the Architecture Vision phase. The business capability map should provide a self contained overview of the current business or enterprise organisational structure, IT systems, applications and any other business processes.

A third approach

Using the organisation map – An organisation map displays any key organisational partners, units and stakeholder groups the form the ecosystem of the enterprise or organisation. The organisation map should also display any working relationships between these entities.

Mapping and modelling techniques which may be provided are extensions that will implement the business capabilities, organisational maps and any value streams into actual business practice.

In addition to any value streams, business capabilities and organisational maps a assortment of other techniques may be employed. These techniques may be Class Models, Use-Case Models and Business Process Models (Commonly referred to as Activity Models).

Phase A – The Architecture Vision

The main objective of the Architecture Vision Phase is to develop a high-level vision of capabilities and the business value that will be delivered to organisation as a result of the proposed architecture. In addition, there needs to be approval for a Statement of Architecture Work which will define the program of works to be developed.

Other objectives within the Architecture Vision Phase are:

  • Creation of a comprehensive work plan
  • Obtain commitment of management and obtain formal approval and go-ahead.
  • Validation of the business drivers, goals and principles
  • Identify stakeholders their concerns and objectives
  • Define any business constraints and business requirements
  • Define the scope of and priortise architectural tasks
  • Describe any appropriate solutions
  • Organise and define an architecture development life cycle
  • Provide and describe an Architecture Vision

The key aspects when approaching the Architecture Vision Phase are:

  • Provide a formal definition of what falls both inside and outside the scope of the architecture effort and any constraints. It is important to understand that constrains are informed by business goals, strategic drivers and principles.
  • Create an Architecture Vision document and clarify and agree on the purpose of the Architecture.
  • Provide a high-level description of the Target and Baseline architectures.
  • Determine which Business Scenario Technique will be utilised in order to develop the Architecture Vision.

The Preliminary Phase

The main objective of the preliminary phase is to provide the definition of how an organisation will develop its architecture. A key objective within the Preliminary Phase is to get the buy-in of all the relevant stakeholders.

Other objectives within the Preliminary Phase are:

  • Developing an “Architecture Footprint” which consists of the people who will be performing the architectural work, their specific responsibilities and their location.
  • Defining and understanding the scope and any assumptions that are being made
  • Define the method and any frameworks that will be utilised throughout the ADM
  • Confirmation of any support framework that will be used and also to confirm a governance
  • Selection and implementation of any supporting tools that may be used
  • Define any architecture principles that may limit the architecture work.

The Preliminary Phase should be thought of in terms of defining the following in the enterprise:

  • Where
  • What
  • Why
  • Who
  • How

The key aspects when approaching the Preliminary Phase are:

  • Evaluating the architecture maturity of the enterprise
  • Defining any relationships that exist between management frameworks
  • Defining the framework that will be utilised
  • Defining architecture principles that will drive the architecture work
  • Define the actual requirements for the architecture work
  • Defining the Enterprise
  • Identifying key elements and drivers in the context of the organisation.

Overview of the TOGAF Architecture Development Method

The TOGAF ADM Framework is a method for developing an Enterprise Architecture and consists of the following phases. Each phase below is listed in the order that it should be followed through each iteration of the ADM.

Preliminary Phase

The Preliminary Phase is used to describe the initiation and preparation activities that will be required to meet the specific business directives for a new enterprise architecture. The preliminary phase should include the definition of principles as well as the organisation specific architecture framework.

In summary the preliminary phase is used to prepare the organisation for undertaking successful enterprise architecture projects which includes:

  • Understanding the business environment
  • Engaging high-level management commitment
  • Agreeing on the scope of the proposed architecture
  • Establishing principles
  • Establishing a governance structure
  • Agreeing upon the method(s) that will be adopted.

Phase A – Architecture Vision

It is during the Architecture Vision or Phase A where the first iteration of the architecture process is initiated. It is also during Phase A where the scope, expectations and constrains of the project are set.

The Architecture Vision is used as the guide during the beginning of every architecture iteration to assist with the creation of the Architecture Statement of Work Document and Architecture Vision. The Statement of Architecture Work Documents are used to validate the context of the business.

Phase B – Business Architecture

When undertaking architecture work in any domain (Data, Application, Technology) it is prerequisite that there is knowledge pertaining to the Business Architecture. Therefore the first architecture activity that needs to be undertaken is gaining the knowledge of the business architecture.

On occasion, information pertaining to the Business Architecture may already be available in other business / organisational processes such as:

  • Strategic Business Planning
  • Enterprise Planning
  • Business Process re-engineering

Phase C – Information System Architectures

Phase C is associated with two main architectures:

  1. Data Architecture
  2. Applications Architecture

When developing the architecture an architect must decide on which architecture to begin first; Application or Data?

In most instances it is usual to address both the data and applications architectures at the same time; however this may not always hold true depending on the scope of the project and any constraints.

If an architect had to choose which architecture to begin with, based on existing theory it would be wise to begin with the Data Architecture. However(!), due to practical considerations, it may mean that starting with the Application Architecture is more efficient.

Remember, that Phase C encapsulates two separate architecture domains (Data and Application). Therefore there are actually two areas / phases inside Phase C – Data and Application so there will need to be an iteration for both of these.

Phase D – Technology Architecture

The Technology Architecture Phase or Phase D is used to map any application components defined during the Application Architecture phase into a set of technology based components.

These technology components should be able to represent the hardware and software components which are already available on the market or components that are already configured within the organisation into technology platforms.

Phase E – Opportunities and Solutions

The Opportunities and Solutions Phase or Phase E is the first phase in the Architecture Development Methodology which is directly concerned with design and structure of how the target architecture will be achieved.

Phase F – Migration and Planning

During Phase F or the Migration Planning phase of the ADM the main focus is the development of a viable implementation and migration plan. The migration plan should be developed in conjunction with the project and portfolio managers.

Phase G – Implementation and Governance

The Implementation and Governance phase or Phase G is concerned with providing an architectural overview of the proposed implementation activities.

Providing an overview of the proposed implementation activities is to ensure that the activities are compliant with the target architectures.

Phase H – Architecture Change Management

During Phase H or the Architecture Change Management Phase the main goal is to ensure that the proposed architecture is able to achieve the original target as specified by the business.

The Architecture Change Management Phase should:

  • Manage changes to the architecture in an orchestrated and cohesive manner
  • Provide for continual monitoring of any changes in governance requests, new technology developments and any changes in the business environment
  • If any changes do occur then the Change Management Phase should be used to determine if a new formal iteration of the architecture evolution cycle should be initiated.

Requirements Management

Requirements management whilst not technically a phase within the ADM is vitally important. The Requirements Management is a process for the management of requirements throughout all phases of the ADM.

The four dimensions of scope

There are four main dimensions that are typically used to limit and define the scope of an Architecture.

  1. Breadth
  2. Depth
  3. Time Period
  4. Architecture Domains

Breadth

Determine the extent of the enterprise or organisation and how much of that extent should the architecture effort focus on. It is important to understand that many organisations are large and are comprised of separate business units. These separate business units can be thought of as enterprises in their own right. Modern businesses further blur this distinction as many businesses embrace a combination of traditional business enterprise as well as partners, customers and suppliers.

Depth

Depth describes to what level of detail an architect should go to when creating an architecture. The challenge here is deciding on how much architecture is enough and when to stop and the delineation between other related activities or systems.

Time Period

Specifies the time period for the initial phase – Architectural Vision and is the specified amount of time realistic based on resources available.

Architecture Domains

Typically when creating an Architecture Description the description should contain information pertaining to all four domains:

  1. Business
  2. Data
  3. Application
  4. Technology

Sometimes, due to constraints such as time and resources there often not enough resources available to create an all inclusive architecture description that covers all four domains.

Typically when creating the scope of an Architecture the scope is expressed in:

  • Breadth
  • Depth
  • Time

Once the scope of the organisation is understood then a suitable combination of architectural domains is selected based on the problem being addressed.

Architectural Activities – Restraining the Scope

For various reasons it may be necessary to restrain the scope of an architectural activity which usually pertains to:

  • The stakeholder concerns and objectives that need to be addressed within the architecture
  • The availability of resources such as people or money
  • The authority within the organisation of the people producing the architecture.

It is important to understand that the proposed scope should allow the work of all the architects within the organisation or enterprise to be integrated and effectively governed. Doing this will require that a set of aligned “Architecture Partitions” are created which will ensure that different architects are not all working on conflicting or the same activities. It will also require that any definitions of compliance relationships are established between the architecture partitions as well as how they may be re-used.