EA and SA roles in TOGAF
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 them helpful, please spread the word and link to the site in whichever social media you use.
Contents
EA in TOGAF ............................................................................................................................ 1
The importance of abstract documentation ............................................................................ 2
EA and BA in TOGAF .............................................................................................................. 4
Solution Architecture in TOGAF............................................................................................... 4
TOGAF is strongly service-oriented .......................................................................................... 5
EA in TOGAF
Enterprise architecture is about architecting the enterprise, not architecting a tactical solution.
It is a strategic approach to cross-departmental integration and interoperability, with focus on
“holistic enterprise change”, as the quotes from TOGAF 9 below indicate.
Chapter 1: the [enterprise] architecture crosses multiple systems, and multiple functional
groups within the enterprise.
Chapter 1: 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.
Chapter 1: An enterprise architecture [provides] a strategic context for the evolution of the
IT system in response to the constantly changing needs of the business environment.
Chapter 2: [an advantage is] process, concept, and component re-use across all
organizational business units
Chapter 6: The enterprise architecture provides a strategic, top-down view of an
organization to enable executives, planners, architects, and engineers to coherently coordinate, integrate, and conduct their activities.
Chapter 16: The main purpose for the development of the enterprise architecture has been
strategic direction and top-down architecture and project generation to achieve corporate
capabilities.
Chapter 32: Enterprise architecture is … a horizontal function that looks at enterprise-level
(as well as line of business-level) optimization and service delivery.
Chapter 42: [TOGAF’s] purpose … is to ensure that the various architecture descriptions…
support the comparison and integration of architectures within and across architecture
domains (business, data, application, technology), and relating to different business area
scopes within the enterprise.
However, TOGAF blurs the distinction by hitching EA to use of its process for shorter-term
business-driven work, so many of its readers now use the term EA for SA.
To this end, TOGAF borrows the operating model concept from Ross, Weill and Robertson.
Their book "EA as Strategy" prompts EAs to position an enterprise’s “operating model” in a
quadrant of this grid.
An “operating model” for business processes and systems
Low standardisation
High standardisation
Coordinated processes and
High
Unified processes and systems
systems
integration
Replicated processes and
Low integration Diversified processes and systems
systems
TOGAF says that conducting EA means
 “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 all four architecture domains: business, IS (data +
applications) and IT infrastructure.
TOGAF proposes a hierarchical, recursive approach to architecture development, suggesting
two levels of decomposition.
 "Strategic Architecture: A summary formal description of the enterprise, providing
an organizing framework for operational and change activity, and an executive-level,
long-term view…."
 "Segment Architecture: A detailed, formal description of areas within an enterprise,
used at the program or portfolio level to organize and align change activity."
 "Capability Architecture: A highly detailed description of the architectural approach
to realize a particular solution or solution aspect..."
The importance of abstract documentation
When EA gurus speak of “architecture”, they mean abstract architecture description, to be
used in the management of enterprise systems.
Software systems are already documented in the form of executable program code, but this is
unusable at an enterprise management level
John Zachman says: “If you are not building models, you are not doing Architecture. You are
doing implementations.”
TOGAF says: “the EA is permanent and manages the EA artefacts delivered by projects.”
TOGAF includes many definitions that align architecture with system description, including
these:
 "Enterprise: The highest level (typically) of description of an organization and
typically covers all missions and functions."
 "Architecture: 1. A formal description of a system, or a detailed plan of the system at
component level to guide its implementation..."
 "Solution Architecture: A description of a discrete and focused business operation or
activity and how IS/IT supports that operation, typically applies to a single project or
project release..."
 "Application Architecture: A description of the structure and interaction of the
applications as groups of capabilities that provide key business functions and manage
the data assets."
Enterprise architects are expected typify an enterprise’s roles and processes in
documentation.
EA favours abstract system descriptions - over very detailed documentation - to facilitate
understanding and change management.
TOGAF says: "The Enterprise Architect has the responsibility for architectural design and
documentation at a landscape and technical reference model level…
The primary output is an EA description that is vendor-neutral and “considerably abstracted
from solution architecture”.
Phase B says “Architecture Definition will not be intended to give detailed or comprehensive
requirements for a solution.”
Even in Phase D, Technology Architecture, “Physical elements in an EA may still be
considerably abstracted from Solution architecture”.
John Zachman's big point is this: if it ain’t documented, then the business doesn't know what
it is and can't properly manage it.
You don’t need to be a fan of his framework to recognise John Zachman’s influence on EA
today.
He was probably the first to publish papers on the need for enterprise-level and enterprisewide analysis and documentation.
He set out to distinguish EA from the localised business process design and technical
architecture that preceded EA.
In 1982, he wrote of the need for enterprise-level analysis.
In 1987, he introduced an enterprise-wide information system architecture framework.
In the mid-1990s, he converted his IS architecture framework into an EA framework
In 2003, he spoke of EA as “Enterprise Engineering”; and listed the 10 points he considers
key to EA.
1. “If it gets so complex that you can’t remember everything… you have to write it
down (Architecture).
2. Then, if you want to change it, you start with what you wrote down (Architecture), the
baseline for managing change.
3. … The broader you define the analytical target, the better leverage you are going to
get on integration, reusability, interoperability, etc…
4. If you draw the boundary more narrowly…, you will disintegrate your Enterprise, that
is, you will build a “legacy.”
5. Once you get data … designed and implemented in a database, there is no way to
change the meaning of the data.
6. You don’t have to build [all] models Enterprise-wide… However… whatever
[models] you are not building… you are assuming risk of scrap and rework.
7. … you’d better pay attention to Enterprise-wide models in Columns 1, 3 and 6 [of his
framework].
8. If you are not observing the engineering design principles…, you are not going to
realize the objectives of alignment, integration, reusability, interoperability,
flexibility, reduced time-to-market, etc.,
9. … you are never going to appreciably reduce time-to-market until you have
something in inventory before you get the order.
10. If you are not building (and storing, managing and changing) primitive models, you
are not doing Architecture. You are doing implementations.
From “The Zachman Framework For Enterprise Architecture: Primer for Enterprise
Engineering and Manufacturing.” By John A. Zachman. Copyright 2003 Zachman
International
EA and BA in TOGAF
TOGAF has one phase (B) dedicated to Business Architecture.
It assumes knowledge of business architecture techniques and products.
(Structured analysis, business process models and business data models get less than one
sentence each.)
In phases A to C, TOGAF expects business architects to play a solution-oriented role:
 identify stakeholders and their concerns
 define stakeholder viewpoints and value propositions.
 use business scenario analysis to define key business processes and roles.
 apply structured business analysis
 decompose business functions and business processes to elementary (OPOPOT)
human activities.
 map activities to business roles, and roles to organisation units
 map activities to data entities and application components recorded in the architecture
repository.
TOGAF is concerned more with the effective integration of human and computer activity
systems.
And less with the most human aspects of an organisation: building facilities, management
reporting structures, benefits packages, etc
Responsibility for designing the latter may lie with a parallel “business change" team, HR,
business managers, etc.
Some have suggested a future version of TOGAF should present EA as independent of IT,
even of information systems.
However, with 1,400 references to “application”, TOGAF’s implicit meta model is centred
on the enterprise application portfolio.
Solution Architecture in TOGAF
TOGAF says this.
"Solution Architecture: A description of a discrete and focused business operation or activity
and how IS/IT supports that operation, typically applies to a single project or project
release..."
But says little more about solution architecture.
It says: "The Enterprise Architect .. often leads a group of the Segment Architects and/or
Solution Architects related to a given program."
It indicates solution architecture starts in Phase E and is performed Phase G.
Phase E identifies “Solution Building Blocks which could potentially address one or more
gaps and their associated architecture building blocks.”
Phase F plans the work to design and implement those solution building blocks.
Phase G says “Perform gap analysis on enterprise architecture and solutions framework”
which implies a clear EA/SA distinction
“The specific Solution Building Blocks required to fill these gaps will be the identified by the
solutions architects.”
The EA/SA distinction became muddy in TOGAF version 9.
TOGAF 9 allowed that its process can be used at a project (or “capability”) level, and
associated solution level artefacts with phases B to D.
In practice, many use TOGAF for project-level work, with little or no reference to a wider
EA and leaving little or no EA documentation behind them.
TOGAF is strongly service-oriented
A raison detre of The Open Group is open specification of systems, as in the POSIX and
UNIX standards.
Open system specifications are formed by defining the services a system should offer, leaving
the structural organisation of components to the manufacturers.
A service encapsulates processes needed to deliver the desired result, and is describable using
a service contract.
TOGAF considers the service-oriented view so fundamental that it places business and IS
services in the Requirements Specification - outside of the Architecture Definition Document.
See this slide show for further details.