Things to know about TOGAFTM

This page is published under the terms of the licence summarized in the footnote.

All free-to-read materials on the Avancier web site are paid for out of income from Avancier’s training courses and methods licences.

If you find the web site helpful, please spread the word and link to the avancier.website in whichever social media you use.

 

TOGAF is the most popular public domain enterprise architecture framework; it is also voluminous, multi-authored and not an easy read.

This is one of more than 200 papers on http://avancier.website that TOGAF readers and users might find helpful.

 

Contents

TOGAF is centred on an Architecture Project Management Method. 1

The spectrum of change. 3

The 7 parts of TOGAF. 4

The 10 phases of the ADM... 5

The Content Framework. 6

TOGAF strengths and weaknesses. 8

Ten things to know about TOGAF. 10

Motivations for using TOGAF. 11

On the ambiguity of terms. 14

Some historical background. 14

Some FAQS (more in other papers) 17

 

TOGAF is centred on an Architecture Project Management Method

The first thing to know about TOGAF

TOGAF promotes the importance of work to define and govern major changes to an enterprise at an architectural level.

It promotes the idea that architects (rather than managers) design and govern such architectural changes to an enterprise.

It achieves this by giving architects a management framework for business system change called the architecture development method (ADM).

 

The ADM is a management framework for what TOGAF calls “architecture projects”.

In other words, it is an architecture project management method.

As such, it fully incorporates techniques and deliverables found also in project management and business change methods.
It incorporates stakeholder identification, transformation readiness assessment, risk management and consequent actions.
It produces a project initiation document that defines a business case for change, along with roles, responsibilities and deliverables for the work to follow.
It defines whatever product or work breakdown structure is needed for architecture development.
It includes requirements traceability and cost/value/risk analysis, and it completes programme/project plans.
It then embeds governance by architects within whatever methods are used to manage subsequent migration and/or implementation projects.


Beyond this, "Execution of ADM cycles should be conducted within the project management framework of the enterprise."

Meaning, your enterprise must complete the integration of the ADM with any project management method your enterprise wants to use.

E.g. extend the central Requirements Management phase with ongoing management activities related to stakeholders, business cases and risks.

To explain at greater length

TOGAF uses the word "architecture project" 50 times.

"The Open Group wants TOGAF to be taken up and used in practical architecture projects"

The ADM is an architecture project management framework that draws attention to stakeholders, the business case, risks etc.

There is (through phases A to F) no parallel or competing management of stakeholders, the business case, risks etc.

 

Phase A: Vision

"Establish the Project: This step should focus on defining the stakeholders."

ADM users are expected to identify all stakeholders in every conceivable domain related to the business systems to be changed.

There is no parallel or competing stakeholder identification, done separately by project manager.

 

TOGAF says "risk management is a technique used to mitigate risk when implementing an architecture project.”

Not only “architectural risk” but all risks.

"Risks are normally classified as time (schedule), cost (budget), and scope; but they could also include client transformation relationship risks, contractual risks, technological risks, scope and complexity risks, environmental (corporate) risks, personnel risks, and client acceptance risks."

It directs you to identify and manage risks associated with

"Vision. Desire , Willingness, and Resolve - to achieve the results. Need to execute the endeavor. Business Case, benefits and costs. Funding, fiscal resources. Sponsorship and Leadership. Governance (the ability to engage all parties). Accountability. Workable Approach and Execution Model. IT Capacity to Execute. Enterprise Capacity to Execute. Enterprise Ability to Implement and Operate."

There is no parallel or competing risk management, done separately by project manager.

 

The principal output of phase A is a project initiation document (PID) called the “Statement of Architecture Work” including in particular:

"Architecture project description and scope, Overview of Architecture Vision, Architecture project plan and schedule, Refined statements of business principles, business goals, and business drivers".

Also: "Specific change of scope procedures. Roles, responsibilities, and deliverables. Acceptance criteria and procedures. Approvals"

There is no parallel or competing PID, or other definition of roles, responsibilities and deliverables, produced separately by a project manager.

 

Phases B, C and D: Architecture Development

These phases provide a management framework for architecture development.

This framework for what architects do is mostly written on the basis that you understand architecture development.

Some architectural techniques and artefacts are explained little or not at all.

There is no parallel or competing product or work breakdown structure, produced separately by a project manager.

 

Phases E and F: Planning

These phases are completed in very close engagement with a PMO.

Migration planning must address all costs, value and risks in cost/value/risk analysis. Resourcing is also addressed.

There is no parallel or competing RoI analysis, or other plans produced separately by a project manager.

 

Phase G: Implementation Governance

The “architecture project” leads to what TOGAF calls "migration projects" or "implementation projects".

These are run in parallel with phase G by a PMO.

Still, architecture governance must be embedded within whatever methods are used to manage migration and/or implementation projects.

 

The spectrum of change

TOGAF is a management framework for conducting EA, for “transforming the enterprise from a baseline architecture to a target architecture.”

It defines EA as: “managing the spectrum of change required to transform an enterprise towards a target operating model [defined by] the necessary level of business process integration and standardization.”

 

The spectrum of change covers the primary architecture domains: business, IS (data + applications) and IT infrastructure.

These domains can be represented as hierarchical layers in which the components/roles in a lower layer provide services to the components/roles in the layer above. 

Architecture domain or layer

Generic elements

Specific elements

Business

Services

Business services

Components

Business functions & roles

Information systems

Services

Information system services

Components

Application components

Infrastructure technology

Services

Platform services

Components

Technology components

 

The operating model concept comes from the famous “EA as Strategy” book.

Business process - operating model

High Standardisation

Coordination

Unification

Low Standardisation

Diversification

Replication

 

Low Integration

High Integration

 

TOGAF presumes that standardisation and integration are goals of EA.

“The purpose of EA is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment.”

 

TOGAF says EA “regards the enterprise as a system, or system of systems.”

The enterprise is a business organisation with agreed goals and budget, one that enterprise architects are sponsored to address.

An architecture describes the structure and behaviour of a system.

So, an EA describes the structure and behaviour of a business organisation as a system.

 

EA introduces a level of "enterprise-level analysis" (Zachman's 1982 observation) above project-level processes.

TOGAF-style EA is supposed to:

·        introduce a more a strategic view,

·        define cross-organisational EA collateral (principles, standards, drivers, goals and strategies),

·        ensure compliance of project deliverables with that EA collateral, and

·        record EA-compliant architecture definitions in an abstract architecture repository for change impact analysis and reuse.

 

Note however that the scope defined in phase A of TOGAF’s process is infinitely flexible.

You are expected to tailor it; and many do tailor it for use as a method for conducting solution architecture.

The 7 parts of TOGAF

EA frameworks (such as the Zachman Framework, DoDAF, MoDAF, FEA and TOGAF) are centred on designing and maintaining the Architecture Definitions of enterprise systems.

The term "architecture" appears c5,000 times in TOGAF, and many if those are best read as meaning "Architecture Definition".

 

Clearly, TOGAF is centred on Architecture Definition, and its seven parts address that in different ways.

Phase

Relevance to Architecture Definition

Part I Introduction

introduces methods and tools for accepting, producing, using and maintaining enterprise Architecture Definitions.

Part II Architecture Development Method (ADM)

describes a step-by-step approach to developing an Architecture Definition and using it.

Part III ADM guidelines and techniques

contains a collection of guidelines and techniques for developing an Architecture Definition.

Part IV Content framework

describes the elements of an Architecture Definition in terms of architectural entities and artifacts.

Part V Enterprise continuum

discusses taxonomies and tools (Architecture Repository) to categorize and store Architecture Definition elements

Part VI Reference models

provides two reference models for structuring parts of an Architecture Definition.

Part VII Capability framework

offers guidance the roles and functions of the organisation that develops and maintains Architecture Definitions.

 

In a large organisation adopting TOGAF, the first 6 to 12 months may be consumed with the work outlined in the ADM's Preliminary Phase.

 

Click here for a longer overview of the TOGAF standard’s seven parts

The 10 phases of the ADM

“Enterprise architects approach their job through the consistent use of recognized design methods such as the TOGAF Architecture Development Method.”

The Architecture (note, not System) Development Method is based on the phases below.

Iteration

Phase

Purpose

Capability

Preliminary

establishes the EA team and their authority

Phase A

produces an Architecture Vision - a sketchy Architecture Definition.

 

Requirements management

ensures the Architecture Definition addresses documented requirements, and manage changes to requirements.

Development

Phases B, C, D

develops a logical Architecture Definition.

Planning

Phases E

apportions elements of the Architecture Definition to solutions and to transition states

Phases F

plan projects to implement the Architecture Definition in systems, and so establish the “Architecture Lifecycle”.

Governance

Phase G

While a PMO runs implementation projects, architects govern to ensure implemented systems are Architecture Definition-compliant.

Phase H

While an ITSM organisation manages system changes, architects govern to ensure changed systems remain Architecture Definition-compliant.

 

A TOGAF project develops and maintains Architecture Definitions.

"Operating a mature Architecture Capability within a large enterprise creates a huge volume of architectural output. ...

 

Others develop and maintain solution-level system architectures.

“The implemented system is actually an output of the development process”, meaning, not of the TOGAF process.

 

TOGAF makes it clear that its Architecture Definitions are distinct from system architectures

It often uses the term architecture as a synonym for Architecture Definition.

"After approval, an architecture will begin to decrease in accuracy if not actively maintained", meaning, an Architecture Definition will get out of step with any corresponding system architecture.
The end-goal is an architecture-compliant implemented system”, meaning an Architecture Definition-compliant system architecture.

You must integrate the ADM into your management processes

"The ADM... is complementary to.. standard program management processes, such as those for

·        authorization,

·        risk management,

·        business planning and budgeting,

·        development planning,

·        systems development, and

·        procurement."

 

Preliminary phase: "most organizations have a method for the development of solutions... The Phase therefore involves doing any necessary work to adapt the ADM to define an organization-specific framework"

Phase F starts: "Ensure that the Implementation and Migration Plan is coordinated with the enterprise’s approach to managing and implementing change."

Phase G starts:  "in parallel with Phase G, there is the execution of an organizational-specific development process, where the actual development happens."

The Content Framework

TOGAF proposes an enterprise’s architecture is described and documented in terms of interoperating building blocks.

A “building block” is a component as in any CBD or SOA methodology that emphasises the specification of active components by interfaces.

This table summarises what TOGAF says about building blocks, which corresponds to what CBD says about components.

TOGAF building block

CBD component

“is generally recognizable as "a thing" by domain experts”

is a structural element rather than behavioural.

“may be assembled from other building blocks; may be a subassembly of other building blocks”

is recursively composable and decomposable.

is a package of functionality defined to meet the business needs across an organization.”

groups behaviours performable by an actor or component instance,

that is, groups services requested of it and/or processes performed by it.

“has a defined boundary”

is encapsulatable behind an interface specification.

may interoperate with other, inter-dependent, building blocks.”

is related to other components by requesting or delivering services.

“Ideally, is re-usable and replaceable, and well specified.”

should offer generally useful services via an interface that is free of implementation detail.

considers implementation and usage, and evolves to exploit technology and standards.

can be specified with particular technology-specific components in mind, or reverse-engineered from them.

 

The building blocks are described in artefacts (e.g. a business function decomposition) and in deliverables (e.g. an architecture definition document).

TOGAF proposes architects describe building blocks at several levels of abstraction, depending on what stage of architecture development has been reached.

The content framework proposes these specifications are stored in an enterprise repository that is subdivided into requirements, architecture and solutions repositories.

The four rows of the table below map the phases of TOGAF’s architecture development method to these three levels of abstraction, and to operational systems.

Phase of ADM

Elements

Enterprise

Continuum

Enterprise

Repository

Notable deliverables

Quotes

Preliminary phase

Phase A

Principles, Vision, and Requirements

Context and

requirements

 

Requirements

repository

Principles catalogue

Stakeholder communications plan

Architecture requirements specification

Architecture vision

"Architecture Principles, Vision, and Requirements artifacts are

intended to capture the surrounding context of formal architecture models,

including general architecture principles, strategic context that forms input for architecture modeling,

and requirements generated from the architecture."

Phases B to D

Architecture building blocks:

e.g. Sales function, RM, RDBMS.

Architecture

continuum

Architecture

repository/landscape

Architecture definition document

“Building blocks are defined in relation to a set of contextual factors."

An Architecture Definition is “a collection of artifacts that document an architecture”.

“The Enterprise Architect has the responsibility for

architectural design and documentation at a landscape and technical reference model level.”

Phases E to F

Solution building blocks

e.g. Salesforce.com, Oracle DBMS.

Solution

continuum

Solution

repository

Architecture road map

Implementation and migration plan

 

Phases G and H

Concrete elements

in deployed solutions.

Deployed

solutions

 

Operational systems

“This Architecture repository … provides the capability to link architectural assets to

components of the Detailed Design, Deployment, and Service Management Repositories."

 

For more on how TOGAF describes systems as collections of building blocks, read “TOGAF Building Blocks.”

On the meta model as an EAR model

TOGAF's artefacts are views of an enterprise/system (real or envisaged) that help stakeholders understand it and validate the enterprise/system description.

The TOGAF meta model diagram shows the atomic entities (e.g. actors and roles) that are named and related in TOGAF's artefacts (e.g. actor/role matrix).

For the consistency of TOGAF, its meta model must reflect its artefacts and vice-versa.

 

The meta model diagram is an entity–relationship model; which is to say describes inter-related things of interest in the domain of knowledge that is EA.

It is composed of entity types (which classify the things of interest) and specifies relationships that can exist between instances of those entity types.

For the consistency of TOGAF, relationships in its meta model must reflect relationships in its artefacts; and in v9.1 most of them do correspond.

 

The whole meta model is more than an ER diagram; it also tabulates the attributes of each entity, which is to say it is an EAR model.

Currently, these attributes are poorly specified, perhaps because there is so little by way of artefact specification to validate them against.

For the consistency of TOGAF, attributes of its entities must reflect attributes recorded in catalogue artefacts.

 

The TOGAF meta model primarily specifies the EA-specific ontology that supports TOFAF's techniques and products; it is secondarily a data model or potential repository structure.)

TOGAF strengths and weaknesses

A typical class view

Students in TOGAF classes typically offer this kind of assessment at the end of a training course.

Strengths

Weaknesses

Open: free-to-read framework for common practices contributed by a large community

Loose: contributions not tightly integrated; additions not aligned with existing material and vocabulary

Broad: makes you think about things you might otherwise overlook

Large: essentials clouded by non-essentials

Well known and credible in the market place

No public domain examples of “deliverables”

The ADM process is strong

Some parts outside of ADM are not so well-considered

Flexible and adaptable

Could be slow moving and bureaucratic if not adapted

Structure and guidance for EA decision making and direction setting

EA not distinguished from and linked to SA.

Encourages efforts to assure compliance to cross-organisational principles, standards etc.

In practice, hard to keep business support for strategic cross-organisational efforts

More practical and useful in the real world than the Zachman Framework

Abstract: not as prescriptive, measureable, down to earth and concrete as we would like

My view

TOGAF helps people to propose, document, plan and govern a substantial programme of changes to one or more systems within an enterprise, or even to the enterprise as a whole.

Its strengths include:

  • It is broad ranging
  • It is free to read, and the most popular architecture framework
  • It is developed by a large community (not a guru), and so reflects a consensus
  • It provides a common language about the process followed by architects working in different enterprises
  • It always strives for compatibility with other industry-recognised methods.

 

It promotes effort to increase the cross-organisational standardisation and integration of systems and processes (as per MIT’s “operating model” concept).

It promotes the role of architects and architecture definition in helping people to agree, accept, plan and deliver the changes that are proposed.

It is very broad – brings together various strands of management and activity in a transformation programme.

It coordinates business process improvement, application portfolio management and infrastructure technology change.

It embraces the planning and management of implementation projects, and the subsequent management of change to operational systems.

It is not deep - it identifies relevant architecture techniques and documents, but does not teach them, since it is primarily a management framework for architects who already know what they are doing!

It is not prescriptive – it is very flexible and expects you to adapt it.

It includes brief outlines of related disciplines – business planning, requirements management, risk management, project management.

It assumes a large organisation will have many architecture definitions – at different levels of granularity – and for different endeavours.

It suggests “segmenting” effort by time, by business function (or capability) and/or by architecture domain.

Its process (ADM) is designed as a management framework for architects working on a large enterprise or IT transformation programme.

 

TOGAF has its limitations.

It speaks less to architects who strive to maintain enterprise-wide descriptions, principles, standards and technology road maps and play a design authority role.

It provides little concrete guidance to solution architects.

It assumes that organisations will have their own processes for related disciplines, and will integrate those processes with TOGAF.

It must work for all: public sector and private sector, manufacturing and services industries, enterprises and service providers.

It is wordy.

It is not consistent in its meta models (three different models can be identified) or level of abstraction.

It is not a modelling language, a quality management system, or a substitute for architect skills.

But think of it as a friend who can help you enough that you will learn to live with its imperfections.

Ten things to know about TOGAF

To become an “architect” takes education in specific architecture disciplines and perhaps 7 years related experience.

TOGAF is management framework for architects who already know what they are doing.

 

The conundrum facing many enterprises and management consultancies is: How to grow architects who will wisely shape, steer and superintend changes to business IT systems, without having any software architecture or systems integration capability in which junior solution architects can learn the craft? TOGAF training cannot possibly fill this need on its own (hence Avancier Methods and associated training).

 

Ten things to know

 

There is no Mr TOGAF

TOGAF is a compendium - a framework for contributions made by 300 member organisations – there are inconsistencies.

TOGAF is not at all prescriptive

TOGAF is for you to adapt - a framework from which you choose what is relevant to you, and then adapt. Nobody does everything in TOGAF.

TOGAF is conventional

TOGAF is not inventive or trend setting. It is a framework for practices already done somewhere by somebody – at least in US federal government.

TOGAF is not an education in architecture and design techniques

TOGAF addresses political issues ahead of technical issues. It is a management framework that borrows from various management and requirements engineering techniques, and joins up business process change, project management and service management.

TOGAF architecture description is abstract

TOGAF focuses on logical technology-independent architecture description It shares the Open Group mission statement to improve integrity, interoperability and portability through the use of open standards and vendor-neutral specification.

TOGAF is for strategic rather than tactical work

TOGAF is written for planning strategic and cross-organisational “enterprise transformations”.

TOGAF requires sponsors and stakeholders at Chief Officer level.

TOGAF tends to assume a top-down command and control structure, giving architects the authority to standardise and integrate systems across organisation units.

TOGAF is about replication and/or coordination of systems

TOGAF is written for transformational change rather than for steady-state.

It is about standardisation to reduce duplication and variation, and about integration to reduce separation and interoperability issues.

TOGAF is not about business strategy or business change per se

TOGAF is business-driven but does focus on those business roles and processes that are supported by digital information systems.

It is written for people who report to a CIO or CTO.

TOGAF is modular, not monolithic.

TOGAF offers guidance in three separable areas

·        Processes (parts 2 & 3).

·        Products: documentation of artifacts and deliverables (parts 4, 5 & 6).

·        People: the architecture and governance organisations (part 7).

The core of TOGAF is the process

The process, ADM may be thought of as four phases:

·        Initiate (Preliminary, A and RM)

·        Develop (phases B, C, D and RM)

·        Plan (phases E, F and RM)

·        Govern (phases G, H and RM)

 

Motivations for using TOGAF

TOGAF is written to help you improve the way information systems enable and support business roles and processes

To help you:

  • Standardise and integrate business processes (as in MIT’s operating model)
  • Rationalise and integrate of overlapping IS/IT systems.
  • Maintain vendor-neutral specifications for procurement of IS/IT products and services.
  • Enable business agility: enabling business improvement through innovation and change.
  • Enable technical agility: making IS/IT systems more flexible, and faster to change.

 

TOGAF 9 says: “EA might cover [either] an entire enterprise encompassing its information and technology services, processes, and infrastructure [or] a specific [architecture] domain within the enterprise.”

In other words, an EA effort might focus on any or all of business change, data change, apps change or technology change.

While TOGAF rightly places a huge emphasis on business goals and business architecture, the main focus is how to help a business make effective and efficient use of information systems.

TOGAF embraces business analysis and business change, and concerns about the efficiency and effectiveness of IT support for the business.

 

I’ve copied relevant points from the TOGAF 9 text below.

 

Chapter 1

An effective enterprise architecture is critical to business survival and success and is the indispensable means to achieving competitive advantage through IT.

The architecture crosses multiple systems, and multiple functional groups within the enterprise.

The business operating model [showing degree of standardisation and integration] is useful to determine the nature and scope of the enterprise architecture within an organization.

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.

The purpose of enterprise architecture is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy.

Today’s CEOs know that the effective management and exploitation of information through IT is a key factor to business success, and an indispensable means to achieving competitive advantage.

An enterprise architecture addresses this need, by providing a strategic context for the evolution of the IT system in response to the constantly changing needs of the business environment.

A good enterprise architecture enables the right balance between IT efficiency and business innovation, ensures the needs of the organization for an integrated IT strategy are met, permitting the closest possible synergy across the extended enterprise.

A good enterprise architecture bring business benefits, which are visible in the net profit or loss of a company or organization:

  • A more efficient IT operation:
  • Better return on existing [IT] investment, reduced risk for future investment:
  • Faster, simpler, and cheaper procurement [of IT]

 

Who would benefit from TOGAF? Any organization

  • undertaking, or planning to undertake, the design and implementation of an enterprise architecture for the support of mission-critical business applications.
  • seeking Boundaryless Information Flow - the structures and processes to enable access to integrated information within and between enterprises.
  • [wanting] a design and a procurement specification that can facilitate an open systems implementation.

 

The Open Group operates as a not-for-profit consortium committed to

  • delivering greater business efficiency by
  • bringing together buyers and suppliers of information systems to
  • lower the barriers of integrating new technology across the enterprise.

 

Chapter 5

The ADM is targeted primarily at architects in IT user enterprises.

 

Chapter 6

The enterprise architecture provides a strategic, top-down view of an organization to enable executives, planners, architects, and engineers to coherently co-ordinate, integrate, and conduct their activities. The enterprise architecture framework provides the strategic context for this team to operate within.

 

The term enterprise architecture was first coined by John Zachman as a means of creating a coherent way of modeling an enterprise to enable the efficient and effective deployment of IT.

 

6.2.1 Enterprise

In many organizations enterprise architecture is part of the Chief Information Officer (CIO) responsibilities and accountabilities and is considered a strategic planning asset that is becoming increasingly an integral part of business management.

In other organizations, enterprise architecture has an even broader remit and more generally supports the management of strategic change across all aspects of the enterprise.

In either case, the strategic perspective that enterprise architecture can bring is required from the outset.

 

6.2.5 Management Frameworks

The enterprise architecture can be used to provide a structure for all of the corporate initiatives,

The main frameworks to be co-ordinated with TOGAF are:

  • Business Capability Management: (Business Direction and Planning)
  • Portfolio/Project Management Methods: manages change initiatives, can be used to deliver the components of the architecture, and
  • Operations Management Methods: runs day-to-day operations, including IT, supports incorporation of these new components within the corporate infrastructure.
  • Solution Development Methods

 

The business planners are present throughout the process and are in a position to support and enforce the architecture by retaining approval for resources at the various stages of planning and development.

On the ambiguity of terms

The IT industry continually finds new ways to mangle ordinary language terms and concepts.

You will find TOGAF easier to read if you understand and accept it grows by the accretion of countless authors’ contributions.

It grows rather like an open source operating system, except that there are no test cases for contributions, and no regression test pack.

Inevitably, different authors use words inconsistently; and TOGAF’s own definitions of terms leave a lot to be desired.

You have to read TOGAF with a degree of caution about the wording and be relaxed about that.

·        Business function, service, capability and organisation unit. Avancier Methods sort out the confusion of terms and concepts in this area.

·        Artifact, view and model: These terms are often interchangeable.

·        System: Usually means application (digitised information system), but occasionally means something else.

Some historical background

For a more general history of EA, go to the Enterprise Architecture page at avancier.website.

This section focuses on TOGAF in particular.

TOGAF as an open standard

To understand why TOGAF is the way it is, you have to understand a little of the background out of which it emerged.

In the early 1990s, there was an explosion of diverse technologies, and duplications between systems offering the same services.

Systems integration was necessary, but increasingly difficult.

Also, there were concerns about vendor/technology lock-in.

All these concerns led towards the definition and adoption of open standards.

An open standard has two basic characteristic:

  • it is published for all to read in the public domain
  • it is maintained by a vendor-neutral organization (or consortium of organizations) rather than a specific product vendor.

The Open Group

Today, the Unix operating system is a good example of an open standard.

For many years however, there were competing versions of Unix, promoted by different interest groups.

The Open Group was initially created to put an end to the Unix wars – to certify all versions of the Unix operating system comply with single open standard.

 

The Open Group has since expanded to certify many other products.

It derives its income comes from certification to standards of a wide range of products and services, and from membership fees.

So it encourages its member groups to maintain standards and develop new standards.

 

The mission statement of The Open Group is:

  • “The Open Group is a vendor-neutral and technology-neutral consortium,
  • whose vision of Boundaryless Information Flow™
  • will enable access to integrated information, within and among enterprises,
  • based on open standards and global interoperability.”

Boundaryless Information Flow™

Boundaryless Information Flow is a concept trademarked by the Open Group.

It is to the Open Group what MDA is to the OMG.

It is a vision. It is a banner to follow. It is a buzz phrase rather than a fully worked out scheme.

It is a kin to the vision of BPM + SOA that has become so prominent in recent years.

It means:

  • Any data
  • Available
  • Any time
  • Any where (over any network) to
  • Anybody entitled to see that data.

 

Traditionally, an information system is a silo that sits within the boundaries of the business unit that bought or built it.

But the enterprise wants data to flow from the start to the end of business process (or value chain), across departments and business units.

The enterprise wants an IT architecture that enables a user at any step in a business process to get information from several physically distinct and distributed information provider applications.

Regulation of government procurement processes

Also in the early 1990s, there was widespread disappointment in the costs of IT and the value it delivers to the business.

This led not only to open standards but also to legislation governing procurement of IT services by public sector organisations.

The most famous law in this area is the Clinger-Cohen act of 1996.

This too had an influence on the history of IT architecture and enterprise architecture.

For more details, read our paper “Brief history of EA” at Avancier.co.uk

The Architecture Forum

In 1992, members of the Open Group expressed requirements for an IT architecture framework.

The Open Group does not directly employ gurus in this field, or any other field.

Rather it hosts and enables groups of experts to meet and collaborate on open standards.

So, it created and helps to administer the Architecture Forum.

And Architecture Forum members, under the auspices of the Open Group, have developed and maintained TOGAF ever since.

From TAFIM to TOGAF

In 1994, the Open Group selected TAFIM from the US DoD as a basis for development of an open standard.

TOGAF was first published in 1996.  The motivations were those of the US DoD, The Open Group, and IT architecture in general:

  • Business-IT alignment
  • Rationalisation and integration of overlapping IS/IT systems.
  • Vendor-neutral specifications for procurement of products and services.

 

TOGAF is designed to help an enterprise take a cross-organisational and strategic approach to address all the concerns mentioned in the Open Group mission statement.

Given the background of open standards and legislation, you won’t be surprised to learn that TOGAF encourages architects to maximise interoperability between systems, and specify them in a vendor-neutral and technology-independent way.

Many TOGAF concepts and processes are a consequence of applying these principles.

TOGAF 7 – technical edition

TOGAF didn’t make much impression on the world outside of the Open Group until version 7, which largely still exists within TOGAF  8.

TOGAF 7 authors traced Technology Architecture building blocks directly to Business goals/objectives/requirements.

The target architecture was entirely a Technology Architecture.

There was no Information Systems Architecture sitting between the Business and the Technology.

TOGAF 8 – enterprise edition

TOGAF 8 came out with big changes.

It featured distinct phases for defining business, information system architectures.

It introduced more emphasis on considerations of how information systems (aka enterprise or business applications) support business processes.

It introduced data and applications architecture between business and technology.

 

TOGAF subdivides information systems architecture into data and applications architecture domains,

It is convenient for many purposes to treat the information systems architecture as a single domain, as shown in this table.

TOGAF Phase

Architecture Definition elements

Business Architecture

Business Services

Business Functions, Roles, Actors

Information Systems Architecture

Information System Services

Application Components, Data Entities

Technology Architecture

Platform Services

Technology Components

 

TOGAF 7 largely reappeared as phase D in TOGAF 8, which explains a few peculiarities in TOGAF 8.

However, most of TOGAF 7 disappeared in TOGAF 9, which makes the continued prominence of the Technical Reference Model hard for readers to understand.

TOGAF 9

TOGAF 9, published in 2009, contains most of TOGAF 8 but under a new structure of seven parts and 52 chapters.

 

TOGAF 9 remained centred on its process, called ADM.

TOGAF 9 added more by way of definitions of architecture entities, artifacts and deliverables, and a meta model of those architectural entities.

There are also additional chapters on specific topics.

Some of the new chapters (SOA, Security and Capability-Based Planning) still look more like white papers.

Not all the new material is well integrated with old.

 

TOGAF 9 changed in a less acknowledged way.

In TOGAF 8, ADM was clearly a process for enterprise architecture - about cross-organisational interoperability/integration and strategic standardisation.

In TOGAF 9, ADM might be used as a process for any level of architecture.

This makes the process considerably harder to understand and explain – because the context in which it is used can be so varied.

TOGAF 9.1

TOGAF 9.1 is a largely cosmetic tidying up of TOGAF 9.

Some baffling text relating to phases A and E were removed, along with some sentences that positioned EA as related primarily to changes that involving IT (though TOGAF is still centred on IS)..

Some FAQS (more in other papers)

Some of the questions people ask about TOGAF are answerable through understanding of the history above.

 

Q) What is TOGAF for?

A) It is a management framework for architects wanting to steer an enterprise transformation programme.

 

Q) Where is TOGAF on a business-to-technology scale?

A) You decide. TOGAF is highly generalised and covers a wide range of problem domains.

You decide and define the scope of the systems you will apply TOGAF to.

If you want to focus on business change, then you do.

If you want to narrow your scope to focus on rationalisation of the technology infrastructure, then you can.

 

Q) Where is TOGAF on a strategic-to-tactical scale?

A) It is mostly written for use at the strategic end of the scale.

TOGAF is written to support cross-organisational and strategic enterprise architecture and IT architecture.

TOGAF’s ADM is presented as a top level process that produces

  • a strategic plan - within which several implementation projects are prioritised and scheduled, and
  • an architecture contract for each implementation project - which defines the architectural collateral (goals, principles, standards, reference models and building blocks) to be followed or used in the project.

 

Q) Who wrote TOGAF?

A) There is no author, or even a “gang of four” authors; rather, hundreds of unpaid contributors over many years.

TOGAF has the strengths and weaknesses of a multi-authored product.

 

Q) Who is supposed to apply TOGAF?

A) TOGAF is not designed for solution architects, for designers working in the SDLC, or for people working in managed operations or IT service management.

It is written for Enterprise Architects who are concerned with cross-organisational integration and standardisation.

 

Q) Why does TOGAF include so many references to vendor-neutrality, technology-neutrality, integratability and interoperability?

A) Because that is the raison detre of the Open Group. See the Open Group mission statement above.

 

Q) Why does TOGAF include so many steps to document the rationale for a decision and trace a solution to requirements?

A) Enterprise architecture grew in response to requirements to improve public sector procurement processes and business-IT alignment.

Every public sector procurement decision should have a documented rationale.

 

Q) Could we use TOGAF for solution architecture?

A) You might. TOGAF does employ some ideas and techniques used also by solution architects. It could be tailored for use by them.

But Avancier Methods are better for solution architecture.

 

Q) Could we use TOGAF as an implementation project life cycle?

A) It would take considerable adaptation.

ADM is not intended as SDLC. Where is Software design? Configuration management? Release management? System testing?

 

Q) How does TOGAF compare with RUP?

A) RUP is an SDLC. You may treat phases A to F of ADM as being the Initiation phase of RUP.

The elaboration, construction and transition phases of RUP are completed in phase G, where software implementation projects are run.

 

 

Footnote: Creative Commons Attribution-No Derivative Works Licence 2.0           24/05/2016 13:02

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.website” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see  http://creativecommons.org