Things to know about TOGAFTM
Copyright Graham Berrisford. One of several hundred papers at http://avancier.website. Last updated 23/12/2018 17:32
This paper was written with reference to TOGAF version 9.1 and updated a little to reflect some changes in version 9.2.
TOGAF is the most well-known public domain architecture framework.
It is also voluminous, multi-authored, not an easy read and widely criticised.
First, a few things to know about TOGAF.
1- It assumes you are an architect already. It is a management framework that positions and promotes the of architects role in business system change.
2- It is not prescriptive. You pick from it what you want, and do that alongside or within your PMO processes.
3- It is not written by gurus. It is written by The Open Group’s Architecture Forum members for their own use.
4- It has weaknesses. A good course will discuss those.
5- It is not entirely consistent, being written by many people over many years; each keen to make their own contribution.
6- It is not TOGEAF. It is a general framework for architecting at any level from project upwards, which urges you to take a cross-organisational and strategic perspective.
7- It has scores of rivals, but was the first free-to-read framework, and courses wouldn’t get repeat business from companies and individuals if they didn’t find it relevant.
Critics of
TOGAF tend to fall into these categories.
1-
People with their
own ideas or approaches to sell who are envious of TOGAF’s success in the
market place.
2-
Software
developers and others who mistakenly assume TOGAF is designed to teach them to
be architects.
3-
Agile development
extremists who are opposed to any strategic or big-up-front design.
Those who value TOGAF are often experienced architects.
They see it is designed to help them address the political and management obstacles to getting any architecture work done at all!
Contents
Part II: The Architecture Development Method (ADM)
Part IV: The Content Framework
TOGAF strengths and weaknesses
More things to know about TOGAF
Some FAQS (more in other papers)
The term "architecture" appears thousands of times in TOGAF.
In many cases, the word is best read as meaning the documentation of an "architecture definition".
EA frameworks (DoDAF, MoDAF, FEAF and TOGAF) presume architects maintain abstract definitions of an enterprise’s systems.
The six parts of TOGAF outline architecture definition processes and products, and the roles of people involved.
|
|
I Introduction |
|
Process guidance |
II Architecture
Development Method a step-by-step approach to developing an Architecture
Definition and using it. |
|
III ADM guidelines
and techniques guidelines for adapting the ADM, and techniques to be used
in the process. |
|
|
Product guidance |
IV Content
framework describes the content of Architecture Definition in terms of
architectural entities and artifacts. |
|
V Enterprise
continuum and tools discusses taxonomies and tools to categorize and
store Architecture Definition elements. |
|
|
People role guidance |
VI Capability
framework guidance the roles and functions of the organisation that
develops and maintains Architecture Definitions |
Click here for a longer overview of the TOGAF standard’s parts
The following sections contain “things to know” about
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 ADM is a management framework for what TOGAF calls “architecture projects”.
It uses the word "architecture project" scores of times.
You can read it is an architecture
project management method.
"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."
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).
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.
“Enterprise architects approach their job through the consistent use of recognized design methods such as the TOGAF Architecture Development Method.”
The Architecture 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. |
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.
Preliminary phase
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"
In a large organisation adopting TOGAF, the first 6 months might be consumed with the work outlined in the ADM's Preliminary Phase.
Once a capability has been established, requests for architecture work can be accepted
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.
Phase A is a kind of feasibility study, it addresses the business case, risks etc.
There is no parallel or competing
management of the business case, risks etc.
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 develop the Architecture Definition Documents.
"Operating a mature Architecture Capability within a large enterprise creates a huge volume of architectural output. ...
It mostly presumes you already 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.
Phase F starts: "Ensure that the Implementation and Migration Plan is coordinated with the enterprise’s approach to managing and implementing change."
There is no parallel or competing
RoI analysis, or other plans produced separately by a project manager.
Phase G:
Implementation Governance
Phase G starts: "in parallel with Phase G, there is the execution of an organizational-specific development process, where the actual development happens."
The “architecture project” leads to what TOGAF calls "migration projects" or "implementation projects".
These are run in parallel with phase G by a PMO.
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.
Still, architecture governance must
be embedded within whatever methods
are used to manage migration and/or implementation projects.
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.”
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.)
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 |
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 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.
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).
|
Things to know |
|
|
TOGAF is not at all
prescriptive |
You pick from it what you want, and do that alongside or within your PMO processes. Nobody does everything in TOGAF. |
|
There is no Mr
TOGAF |
It is not written by gurus but by TOG Architecture Forum members for their own use. It is a compendium - a framework for contributions made by 300 member organisation. |
|
TOGAF has
weaknesses |
A good course will discuss those. |
|
TOGAF is not
entirely consistent |
Being written by many people over many years; each keen to make their own contribution |
|
TOGAF is not
TOGEAF. |
It is a general framework for architecting at any level from project upwards, which urges you to take a cross-organisational and strategic perspective |
|
TOGAF has scores of
rivals |
But it was the first free-to-read framework and wouldn’t get repeat business from companies and individuals if they didn’t find it relevant |
|
TOGAF is
conventional |
It 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 architecting |
It assumes you are an architect already. It is a management framework that positions and promotes your role in business system change. It addresses political issues ahead of technical issues. It borrows from various management and requirements engineering techniques It joins up business process change, project management and service management. |
|
TOGAF architecture description is abstract |
It 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 |
It is written for planning strategic and cross-organisational “enterprise transformations”. |
|
TOGAF requires sponsors
and stakeholders at Chief Officer level. |
It 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 |
It 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 |
It 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. |
It 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) |
TOGAF is written to help you improve the way information systems enable and support business roles and processes
To help you:
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:
Who would benefit from TOGAF? Any organization
The Open Group operates as a not-for-profit consortium committed to
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
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:
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.
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.
For a more general history of EA, go to the Enterprise Architecture page at avancier.website.
This section focuses on TOGAF in particular.
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:
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:
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:
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.
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
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.
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:
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 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 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, 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 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 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
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)
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 23/12/2018 17:32
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