The Enterprise Operating Model

The Enterprise Operating Model is a technique that is used in phases A through to E in the TOGAF Architecture Development Method.

The main ingredient to establishing interoperability is to determine the Corporate Operating Model.

The Corporate Operating Model will determine what type of interoperability approach will be appropriate.

The Operating Model is the necessary level of business process integration and standardisation for delivering services and goods to customers. The Operating Model will describe how a company wants to grow by providing a more actionable and stable view of the company.

There are four operating models each based on the level of business process, standardisation and integration. It is using these models that architects are able to decide the level of detail and complexity of solution and architecture building blocks.

The four operating models are:

  1. Coordination
  2. Unification
  3. Diversification
  4. Replication


In the context of TOGAF the term Interoperability is defined as:

“The ability to share information and services”

The key element is being able to define the degree to which crucial services and information are to be shared. Within the TOGAF Architecture Development Method interoperability occurs in phases A through to F (From the Architecture Vision Phase through to the Migration Planning Phase).

Phase A – The Architecture Vision Phase

In Phase A Business Scenarios are used to discover the nature and security considerations of any information and security exchanges.

Phase B – Business Architecture Phase

During Phase B Business Terms are used to define information and service exchanges.

Phase C – Information Systems Architecture Phase

During Phase C The Information Exchange Model sometimes in association with Corporate Data is used to detail the content of information exchanges. It is during this phase that the way applications are to share information is specified.

Phase D – Technology Architecture Phase

In Phase D the appropriate technical mechanisms to allow information and service exchanges are detailed.

Phase E – Opportunities and Solutions Phase

In Phase E the actual solutions that will be implemented are chosen.

Phase F – Migration and Planning Phase

During Phase F interoperability is logically implemented.

Capability Based Planning

The objective of Capability Based Planning to focus on the planning, engineering and delivery of strategic business capabilities to the enterprise.

Capability Based Planning is both business-led and business-driven and combines the efforts if all lines of the business or organisation to achieve the required capability. Most corporate business models are catered for with Capability Based Planning.

Capability Based Planning links the IT Vision, architectures and the Implementation and Migration plans with the corporate business, strategic and line of business plans.

Capabilities are parallel and go against the grain of normal vertical corporate governance. Oftentimes, the management direction and also the corporate management accountability framework are based on the line of business metrics and not the enterprise metrics.

Risk Management

With any business transformation or architecture there will always be a degree of risk involved. The key is to determine, classify and reduce any risks as much as possible before starting. This is so that any risks identified are able to be tracked for the duration of the transformation process.

Levels of risk

TOGAF identifies two levels of risk:

  1. Initial Level of Risk
  2. Residual Level of Risk

Initial Level of Risk

The Initial Level of Risk is where any risks are categorised prior to determining and implementing mitigating actions

Residual Level of Risk

The Residual Level of Risk is where any risks are categorised after the implementation of mitigating actions.

The Risk Management Process

The Risk Management Process is comprised of the following steps:

  1. Risk classification
  2. Risk identification
  3. Initial risk assessment
  4. Risk mitigation and residual risk assessment
  5. Risk monitoring

Risk Identification

During Phase A or the Architecture Vision Phase any risks are identified a part of the initial Business Transformation Readiness Assessment.

In Phase G or the Implementation Governance Phase a risk identification worksheet is maintained as a governance artifact; an example of a Risk Identification Worksheet is shown below (Courtesy of the

Risk Identification Worksheet

When maintaining the Risk Identification Worksheet Table ensure that ‘Unlikely’ and ‘Likely’ pertain to the probability or risk and not the frequency of risk.

Risk Mitigation Assessment

In Phase G (The Implementation Governance Phase) a Risk Mitigation Assessment worksheet is maintained as an governance artifact. It is in Phase G where risk monitoring is conducted. The purpose of Risk Mitigation is to identify, plan and conduct specific actions which will limit any risks to an acceptable level.

Developing Architecture Principles

An Architecture Principle is a method for providing support during the decision making process. In addition they provide guidance on using and deploying assets and resources pertaining to the architecture work.

When developing an Architecture Principle the following should be taken into account:

  • What are the characteristics of the enterprise or organisation? i.e. Perform a SWOT analysis (Strengths, Weaknesses, Opportunities and Threats)
  • What are the goals of the enterprise or organisation?
  • How is the enterprise or organisation structured?
  • What external constraints might come into play? i.e. Customer expectations, current or proposed legislation etc.
  • Technology and Systems across the enterprise or organisation which includes policies and procedures, documentation and Information Systems.
  • Trends (Technical, Economic, Political) which may be emerging within the enterprise or organisations industry which may impact the enterprise or organisation.

Principles should be linked to Standards, Policies, Guidelines and Procedures. The reason for linking principles is so that they are able to be supported inside the repository and can be shared with architects providing a full understanding pertaining to the structure.

Architecture Principles are usually established during the Preliminary Phase and can be thought of as a general set of guidelines and rules. Architecture Principles apply directly to the Architecture which is being developed and are usually a subset of the broader Enterprise Principles.

Architecture Principles should be created in such as way that each Principle is:

  • Robust
  • Understandable
  • Consistent
  • Stable
  • Complete

Why the need for Architecture Principles?

An Architecture Principle provides support and information in the way that an enterprise or organisation fulfills its objective. They should be specified as statements of intent which can be quantified and can be carried out by the architecture.

Requirements Management Process

The Requirements Management Process is used throughout the entire Architecture Development Methodology life-cycle in all phases.

It’s key objective is to address the requirements of the enterprise or organisation, store the requirements and then pass the requirements to and from each ADM phase when required.

The Requirements Management Process is what drives the ADM and this is why the Requirements Management Process is at the center of the ADM life-cycle as shown below.

It is imperative that an architecture is able to handle changes in requirements as by its very nature an architecture is subject to changes such as:

  • Stakeholder uncertainty regarding requirements and solutions
  • What was proposed and what can actually be delivered (e.g. Constraints may force a change in deliverables)
  • Drivers and constraints outside of the control of the ADM or enterprise, such as changes in technology, new legislation for example

Phase H – Architecture Change Management

The main objectives of Phase H or the Architecture Change Management Phase are:

  • To appraise the efficiency and performance of the architecture and provide proposals for when the architecture may need to be altered.
  • To ensure that the proposed architecture is able to achieve the specified business values.
  • To ensure that any baseline architectures can continue to evolve e.g. Changes in the business or technology may force baseline architecture(s) to be altered.
  • Determine the circumstances and provide a process which will allow the architecture to be modified after the deployment.
  • Assess any changes to the principles and framework which have been created in the previous phases of the Architecture Development Method.
  • To use and administer the Governance Framework.

It is worth understanding that Phase H or the Architecture Change Management Phase is extremely pertinent to the processes pertaining to architecture governance and management of the Architecture Contract.

Phase G – Implementation Governance

The main objective of Phase G or the Implementation Governance Phase is to bring together all of the relevant information pertaining to the various implementation projects – specifically:

  • Ensure that the deployed architecture conforms with the implementation projects
  • Ensure that the actual solution is deployed successfully
  • Generate suggestions for each of the implementation projects
  • Manage and govern an Architecture Contract for the actual implementation and deployment
  • Implement the appropriate governance functions pertaining to the system while it is being deployed and implemented
  • Ensure that any future supporting operations are started.

Phase G or the Implementation Governance Phase is where the association between the architecture and the implementation organisation occurs; this connection is via the Architecture Contract.

To make certain that the Architecture Contract is both competent and effective there are five main aspects of the Governance Framework which should be introduced during Phase G; they are:

  1. Communication
  2. Ensuring processes are as straight forward as necessary
  3. Authority is centered around people
  4. Any responses should be timely with an effective and efficient escalation process.
  5. Aspects should support the organisation structures

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.