How does TOGAF relate to EA, BA and security?
(Observations on TOGAF)
Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 17/07/2017 14:27
Enterprise Architecture (EA) and TOGAF can reasonably be criticised from several angles.
However, some criticise them unfairly, because they misunderstand them or misapply them.
Do your customers misinterpret TOGAF? Think it teaches them to be architects? Think EA is “doing TOGAF”?
Then you might find this paper helpful.
The “Information Age” started with the shift from manual to digital data processing.
To begin with, an enterprise (aka business, company or organisation) computerised formal systems, like accounting.
Today, a very wide variety of business operations capture digital data and store it for use and analysis at a later date.
Even informal social human activities are supported and enabled by digital data processing.
The Information Age brought new opportunities, but also new difficulties.
Incrementally, enterprises acquired and then relied on ever more information systems.
Projects involving IT became notorious for overrunning time and budget, and not delivering systems of the quality desired.
Some systems stored different version of the same data, some did not interoperate, and many were tied to particular technologies.
This led to problems in coordinating the business roles and processes that relied on these information systems.
For example, sales and billing systems, or social and health care systems, might be inconsistent and uncoordinated.
EA grew in the 1980s out of the requirement to reduce cost and quality issues caused by “silo systems” (not standardised, not integrated, and not sharing common services).
· “EA is concerned with “system implementations, extending in scope and complexity to encompass an entire enterprise.” (Zachman).
As ever more business processes were digitised, models for EA were established; significant references include:
· Business information systems analysis should be raised to the “Enterprise-level” (Zachman, 1982 reference).
· Architecture is divisible into four domains: business, data, application and technology (PRISM report, 1986 reference).
· The focus is on business and information before technology (NIST EA model, 1989 reference).
For decades, authors have put the quality and use of business information at the heart of EA.
· “Architecture planning is the process… to improve data quality, access to data, adaptability…, data interoperability and sharing, and cost containment.” (Spewak, 1993 reference)
· “The domain of information-intensive organisations…is the main focus of the [EA modelling] language” (ArchiMate standard v2.1)
· "Today’s CEOs know that the effective management and exploitation of information… is a key factor to business success.” (TOGAF 9.1, 2009 reference)
· The Open Group’s vision: “to achieve Boundaryless Information Flow™ through global interoperability in a secure, reliable and timely manner.”
· The Open Group’s mission: “enabling access to integrated information within and between enterprises, based on open standards and global interoperability.”
The higher purpose has always been to optimise and improve business processes.
· “An EA establishes the Agency-wide roadmap to achieve an Agency’s mission through optimal performance of its core business processes within an efficient IT environment.” (FEAF, 1999 reference)
· "Companies excel because they've [decided] which processes they must execute well, and have implemented the IT systems to digitise those processes." (Ross, Weill and Robertson, 2006 reference).
The solution architecture vision is to support/enable, speed/scale up, optimise/extend roles and processes in a narrow scope.
The EA vision is broader, to standardise, integrate and coordinate business information and processes across an enterprise.
This vision is challenging politically as well as technically.
Enterprise architects work as enterprise-wide as possible; regarding the business as one large system of systems.
They are expected to document the architectures of business and information systems – at least at an abstract level.
They respond to business plans, align system changes with those plans, and may influence them.
They take a cross-organisational and strategic perspective of the architecture domains in the table below.
Business mission, vision, drivers, strategies, goals and top-level business plans.
Mergers, acquisitions, divestments, internal organisation restructurings and rationalisations.
(Business Systems Planning)
Business functions/capabilities, roles, processes/value streams and their interrelationships.
The services they provide to each other and to entities in the business environment.
Applications and their interrelationships
The services applications provide to each other and to business activities.
Data stores and data flows, the data structures they contain and the qualities of that data.
Platform technologies and their interrelationships
The services technologies provide to each other and to business applications.
An EA practice typically acts also as a central design authority and risk management function.
Enterprise architects guide and govern lower level solution and technical architects working on specific programmes and projects.
The practice is challenging and political: architects need not only appropriate knowledge, skills and resources, but also cross-organisational authority.
Some enterprises have never set up an EA practice; some have done so and struggled to make an impact.
Latterly, people have used the term EA for other activities ranging from business planning to software engineering.
Read 50 years of digital transformation and EA for a more extensive EA history and many references.
EA had been discussed for about 20 years before The Open Group Architecture Framework (TOGAF) was published.
Yet to begin with, TOGAF owed little or nothing to that EA history.
The vision of the Open Group (TOG) was a world in which information flows are “boundaryless”.
TOG looked to realise that vision through the development of IT standards that make information systems portable and interoperable.
At the same time, the US “IT Management Reform Act” demanded that federal government CIOs maintain a “sound and integrated IT architecture repository”.
From 1996 to 2001, TOG members developed TOGAF versions 1 to 7 as a framework for IT architecture.
When it finally joined the EA party in 2002, TOGAF 8 (the "Enterprise Edition") borrowed a great deal from FEAF v1.1 (1999).
The US government’s Federal EA Framework drew from three mainstream EA sources: Zachman, Spewak and the NIST EA standard.
It declared its aims as: “common data and business processes”, “information sharing”, “new and improved processes”
TOGAF 8 also extended the service-oriented specification approach used in TOGAF 1 to 7.
"TOGAF Version 8… uses the same underlying method for developing IT architectures that was evolved [in] TOGAF up to and including Version 7.
That method was to define a system or component, an architecture domain or layer, logically, by the services it provides.
Version 8 applies that… method to the other domains of an overall Enterprise Architecture - the Business Architecture, Data Architecture, and Application Architecture, as well”
EA defines system behaviors in the form of interfaces and service contracts.
The Open Group promotes service-orientation – defining standards and systems in terms of service portfolios.
TOGAF 9 introduced a content framework and meta model based on this service-oriented approach.
The table below shows the terms TOGAF uses when abstracting Services from Building Blocks.
Generic meta model
Functions & Roles
TOGAF versions 1 to 7 were enterprise-wide, but infrastructure technology-oriented.
Versions 8 and 9 became more business-oriented, but also more akin to a project management method, with side bar references to EA.
The latest version can be used in a way that supports and enables the work of enterprise architects.
But the use of TOGAF is not limited to EA, and using it does not make you an enterprise architect.
This first part of TOGAF 9 introduces the context for TOGAF, and defines core concepts.
TOGAF 9 is a management framework for architecture-intensive projects.
It is a general purpose architecture framework – which can be decoupled from EA
Today, it is probably more often used for solution architecture work than for EA.
It does not teach you how to do architecture.
It is a menu of things TOG architecture forum members have done on different projects.
It assumes you know how to do these things (though some TOGAF tutors may explain some of them).
Read TOGAF core concepts for general architecture concepts and principles used in TOGAF.
The ADM is the core of TOGAF; it is a process for architecture-intensive work to design, plan and govern business systems.
It presents a menu of phases and activities in a rational sequence – outlined below.
You are expected to tailor the ADM process and meld it into your PMO processes.
You might reasonably read as a project management framework thus
Establish the capability to follow the ADM from A to H (when a request for work arrives).
A: Architecture vision
Feasibility study, and stakeholder approval of work to be done.
B,C,D: Business, IS and Technology architectures
Logical design of business processes and roles, and supporting data, applications and infrastructure.
E: Opportunities and solutions
Supplier/technology selection and transition state planning.
F: Migration planning
Planning of projects to develop and deploy new/changed systems.
G: Implementation governance
Governance of development and deployment projects.
H: Architecture change management
Governance of system changes after deployment.
A cycle of ADM starts with a "request for architecture work" (say, to improve our care-in-the-home business operation).
If stakeholders don’t approve the initial “architecture vision” at the end of phase A, then it is not taken forward.
If they do approve it, then the next step is to study the human activity system in more detail.
And then, how IT can best be used to support and enable that by regularising behaviors, store and transmit information.
Architects must tailor TOGAF to the needs of those who request architecture work.
You don’t set out to eat everything on the TOGAF menu in one cycle.
You select items that will help you address a sponsor's particular "request for architecture work".
This part contains techniques used during the ADM, and guidelines for adapting the ADM.
Several of the 10 techniques are management-oriented (e.g. stakeholder management, risk management) rather than architecture-oriented.
Below are a few observations on the 4 guidelines for adapting the ADM.
You are not expected to follow the ADM process in a strictly sequential fashion.
You tailor it, in concert with other methods your organisation uses.
You can iterate between phases and within each phase, activities may done iteratively and/or in parallel.
The whole process is also as fractal as you choose it to be
The ADM may be applied at any of up to 5 levels (Enterprise, Segment, Solution, Capability, Capability Increment).
TOGAF has always recommended service-oriented specification of systems at all levels.
This chapter adds little value.
TOGAF is not a security architecture framework.
However, the security chapter maps security considerations (copied from a NIST standard) to ADM phases.
The aim is to help you position security considerations in the ADM process.
Again, TOGAF is only a management framework for architects.
It does not teach professional architects how to do architecting.
UK architects would more likely map the ISO 27001 standard to ADM phases.
This part is an extensive menu of products that may be produced by architects during the phases of the ADM.
There is also a meta model indicating how the elements of these products are related.
Read TOGAF core concepts for the principles used in how TOGAF describes architectures.
Observations on business architecture
TOGAF catalogues more artifacts for documenting a business architecture than any other architecture domain.
It starts with analysis of required business goals, business services and the business scenarios required to deliver them.
The business architecture approach is based on universal system modelling principles.
The universal presumption is that activities can be modelled in:
· sequences (called processes, scenarios)
· cohesive clusters (called nodes, functions, roles)
· collaborations (networks of nodes with flows between them).
Flows between nodes may be of energy, materials and/or information.
Flows may be interpreted as of value to senders and/or receivers.
TOGAF’s business architecture artifacts might be renamed in the current fashion.
· Scenarios and processes might be called value streams.
· Functional decomposition hierarchies might be called capability maps.
· Node connectivity diagrams might be called value networks.
Renaming them doesn’t change the general principles.
Activities can be modelled at several levels of abstraction.
The granularity of the atomic activity is up to you.
The enterprise continuum is a structure for classifying architecture definition products.
The enterprise repository is a data store that contains architecture definition products (and other things).
Read TOGAF core concepts for a graphic of the enterprise continuum.
Implicit in TOGAF is a rejection of how the Zachman Framework was used in the 1990s.
You never “do TOGAF”, or attempt to fill the architecture repository for its own sake.
You use TOGAF as checklist for architecture work to be done in response to a sponsor’s request for work.
You populate the repository as a side effect of sponsored work.
It is questionable how many TOGAF users maintain a coherent enterprise repository.
A reference model is a general structure or pattern for use in different situations.
Today, the two reference models in TOGAF are inherited from earlier versions.
Technical Reference Model (TRM)
TOGAF versions 1 to 7 were designed help IT service managers deduplicate (rationalise) their enterprise’s infrastructure technology estate.
The TRM is used in this process, to classify and analyse the platform services provided by platform technologies.
(TOGAF 7 was squeezed into one of ten phases in TOGAF 8, and later compressed to only a few paragraphs in TOGAF 9).
Information Infrastructure Reference Model (III-RM)
TOGAF version 8 (called “the enterprise edition”) shifted focus towards higher level business and applications architectures.
The III-RM was introducced with a view to supporting the TOG vision of Boundaryless Information Flow.
The III-RM is a design pattern for application integration (but only one of many design patterns that may be used for this purpose).
This last part is about the roles of architects in an enterprise, especially in governance.
Effective EA implies and requires governance of architects and by architects.
TOGAF refers to governance of architects by an architecture board.
The architecture board publish generic principles, standards, road maps etc. to which architects are expected to conform.
Principles, standards etc.
<publish> <used by>
Architecture board <monitor and guide> Architects
<create and use> <realised by>
Architects <observe and envisage> Systems
Architects create architecture definitions in response to requests for work that meet some aim(s) of the business.
TOGAF assumes governance by architects of system development/implementation and system change (in TOGAF phases G and H).
It is presumed that architecture and management roles are performed by different people.
Project managers manage projects to implement systems designed by architects.
A change advisory board governs work to change live systems.
Architects ensure projects and changes accord with architecture principles, standards and whatever architecture definition has been developed.
It is difficult to get to grips with TOGAF just by reading it.
Or by attending a course presented by a tutor who qualified by passed the TOGAF exams.
Passing the exams is the least of what you need to know.
It helps to understand the context for TOGAF and its evolution to date:
· US legislation that directed CIOs to maintain an IT architecture repository.
· US federal government guidance on what EA means.
· The broad methodology history that TOGAF draws from.
· Various systems analysis and design methods and other EA frameworks.
· The Open Group, its mission, vision and service-oriented specification principles.
· The processes by which TOGAF content is developed.
Nobody is employed to write TOGAF; you might say it is crowd-sourced.
Any architecture forum member can request a change or draft a contribution.
From that point to publication in TOGAF is a long and democratic process.
There is no director or editor you can press to address your special concern.
TOGAF’s scope is determined by what forum members choose to write about.
If you want to contribute, then join the forum.
TOGAF tends to lag behind the times; it does not anticipate trends or publish speculative practices.
It contains only what has been approved by enough forum members
As things stand, the refresh cycle takes several years (remember training courses and examinations have to be updated).
TOGAF is free to read!
The astonishing thing is not that TOGAF is flawed; it is that it is reasonably coherent and consistent.
Read TOGAF core concepts for more about principles applied in TOGAF.
A system contains or employs actors that play describable roles in processes.
E.g. consider an orchestra’s performance of a symphony.
A social entity is a group of actors who may chose their own behaviors, and may interact to reach aims they agree.
E.g. the group of actors hired to play in the orchestra.
If management is about the actors in the orchestra (the social entity), then EA is about the roles in the symphony (the social system).
System theory concepts and principles help us to understand what EA is and is not - what it can and cannot do.
Taking an aim-oriented view
Managers may decompose business goals and assign them to individual actors.
Managers can encourage actors to share the goals of the business, e.g. through team building.
They can also help actors reach their own goals, most obviously by paying them.
But if how the actors work is ad hoc, continually changing, then there is no describable system in the EA sense.
Taking a process-oriented view
EA regards a large enterprise as a system of systems.
These systems may be uncoordinated, overlap, duplicate, conflict and fail to share information.
The ultimate vision of EA is to unscramble this mess of systems.
To coordinate, de-duplicate and integrate distinct systems into one system, without duplication or disintegrity.
All free-to-read materials at http://avancier.website 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 avancier.website in whichever social media you use.