TOGAF history and EA observations
This page is published under the
terms of the licence summarized in the footnote.
Abstract
Your prior reading should include:
· EA history a slide show taking you through the history of Enterprise Architecture (EA), quoting the references below
· EA history references lists prominent EA sources from 1980 onwards.
This paper is the first of a pair that supplement the EA history above.
· TOGAF history and EA observations
· EA history from a US government perspective
Contents
TOGAF’s
journey from ITA to EA
Judged by published certification numbers, TOGAF is the most popular EA framework, and some assume it defined EA.
However, TOGAF started life as a technical IT architecture framework.
“TOGAF has a solid history in IT architecture, considering the ways in which IT can support enterprise change.” TOGAF 9.1
TOGAF 1 to 7 (from
1996)
In 1994, the Open Group selected TAFIM from the US DoD as a basis for development of an open IT architecture standard.
(See the companion paper for the background to this.)
TOGAF started out taking a strategic and enterprise-wide view, but also a very technology-oriented view.
It emerged out of the desire to rationalise a messy IT estate.
This and other motivations were shared by the US DoD, The Open Group, and IT architecture:
Right up to version 7, TOGAF was still focused on defining and using a Technical Reference Model (or foundation architecture) to define the platform services required from the technologies that an entire enterprise uses to support business applications.
TOGAF 8 (2002/3)
This “enterprise edition” of TOGAF shifted its focus to the business, data and application layers on top of technology architecture.
“In order to succeed, the EA must reflect the needs of the organization.
Enterprise
architects, if they are not involved in the development of business strategy,
must at least have a fundamental understanding of it and of the prevailing
business issues facing the organization.” TOGAF 8.1.1
TOGAF 8 introduced structured analysis, after Information Engineering, which features, for example, mappings of organisation units to business functions and data entities to business functions.
Today, business functions are often called business capabilities.
And many enterprise architects regard their business function/capability hierarchy/map as the fundamental EA artefact.
They map data entities, use cases, applications and technologies to the functions/capabilities.
“The primary reason for developing an EA is to support the business by providing the fundamental technology and process structure for an IT strategy.
This in turn makes IT a responsive asset for a successful modern business strategy…
An EA provides a strategic context for the evolution of the IT system in response to the constantly changing needs of the business environment.
A good EA… assures the needs of the organization for an integrated IT strategy [and] permits the closest possible synergy across the extended enterprise.” TOGAF 8.1.1
TOGAF 9 (2009)
TOGAF regards EA as indispensable to IT success.
“An effective EA is critical to business survival and success and is the indispensable means to achieving competitive advantage through IT.”
Looking to achieve competitive advantage through IT, TOGAF 9 says that it.
“incorporates a broader perspective of change that allows EA to be used to specify transformation across the business, data, application, and technology domains.”
For analysis of business concerns, TOGAF 9 introduces techniques such as business capability assessment, business transformation readiness and the business operating model.
“The business operating model concept is useful to determine the nature and scope of the EA within an organization.”
Remember, the Center for Information System Research’s operating model shows the enterprise’s ambition for cross-organisational process integration and/or standardisation.
Since these aims depend on digitised information systems, the enterprise needs a strategic approach to business information systems planning.
“as TOGAF has grown in depth and maturity it has become a framework for managing the entire spectrum of change required to transform an enterprise towards a target operating model.”
Again, transforming an enterprise towards a target operating model implies “implementing the IT systems to digitise those processes”.
TOGAF does say “The term [EA] can be used to denote…
an entire enterprise…”
But still, its view of the enterprise is very much from the perspective of information systems.
This is revealed by what it goes on to say … encompassing all of its information and technology services, processes,
and infrastructure.”
Zachman proposed in 1982 that information systems analysis should cover the business context.
Today, TOGAF adds a layer of business architecture on top of IT architecture.
This helps us to understand and define the context and requirement for the business data, applications and platform technology architecture to follow.
“A complete EA should address all four architecture
domains - business, data, application, technology.”
“Why do I need an EA? … the effective management and exploitation of information through IT is a key factor to business success…
An EA [provides] a strategic context for the evolution of the IT system…
A good EA enables you to achieve the right balance between IT efficiency and business innovation…
At the same time, it ensures the needs of the organization for an integrated IT strategy are met.”
Under the heading of “return on existing investment” TOGAF talks specifically about return on information technology investment:
“Reduced complexity in the business and IT -
Maximum return on investment in existing business and IT infrastructure –
The flexibility to make, buy, or out-source business and IT solutions - Reduced risk overall in new investments and their cost of ownership.”
“Who would benefit from using TOGAF? Any organization undertaking, or planning to undertake, the development and implementation of an EA for the support of business transformation will benefit from use of TOGAF… Organizations seeking Boundaryless Information Flow …to enable access to integrated information within and between enterprises.”
The Boundaryless Information Flow is the Open Group's vision of open access to stored (digital) business data.
To this end, TOGAF includes an SOA design pattern for information system architecture called the Integrated Information Infrastructure Reference Model.
“Organizations that design and implement EAs using TOGAF are assured of a design and a procurement specification that can facilitate an open systems implementation.”
Procurement of open information systems and technology is facilitated by logical specification of system services and adoption of open standards.
“Large corporations and government agencies may
comprise multiple enterprises, and may develop and maintain a number of
independent EAs to address each one.
However, 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.”
Common use of business applications has been a core EA principle for many years.
And text analysis reveals that TOGAF is centred on the business application portfolio.
A comparison of EA frameworks shows that TOGAF is a kin to FEAF, which is a kin to EAP, which is akin to BSP.
In short, the focus and concerns of TOGAF today are similar to those of
· IBM’s Business Systems Planning method in 1980
· Stephen Spewak’s EA Planning method in 1993
· MIT’s Center for Information System Research in 2006.
TOGAF supposes that EA starts with business drivers, goals and strategy.
It traces everything back to those.
It includes a light chapter promoting "capability based planning".
It regards business architecture as an essential part of EA.
It is clearly a kind of business change management method.
But at the same time, TOGAF expects that business planning is done outside the EA team, perhaps by business management consultants, who bring their own methods and tools.
It suggests that the baseline business architecture may be documented as a “free-standing exercise”.
It is focused on the design and implementation of changes that have a substantial impact on information systems.
TOGAF makes several references to the operating model concept, introduced in the popular book "EA as Strategy”.
This book provides a high-level process for:
· “C-level executives determined to get IT right”
· delivering “a road map for the CIO and IT organisation to follow”.
· "improving strategy execution and lowering IT costs" and
· "creating a foundation for business execution… an IT infrastructure and digitised processes that implement your company's core capabilities.”
The authors reported the results of work by MIT’s Center for Information System Research.
"companies excel because they've [decided] which processes they must execute well, and have implemented the IT systems to digitise those processes."
They encourage enterprise architects to engage business managers by exploring how far the enterprise (or a division thereof) is interested in integration and/or standardisation of those core processes.
|
Positioning the “Operating
model” for core business processes |
||
|
High integration |
Coordinated |
Unified |
|
Low integration |
Diversified |
Replicated |
|
|
Low standardisation |
High
standardisation |
If improving business roles and processes is the aim, then why emphasise information systems?
Because you can't integrate business processes without attending to the business data that is passed between roles and activities.
And you can't standardise business processes unless the actors in those processes are directed by systems and recorded by systems.
Thus, the book presents EA as a strategic approach to the planning of investment in business information systems and technology.
In much the same spirit as IBM’s Business Systems Planning method - 25 years earlier.
Enterprise
architecture aims to support, enable and improve business roles and processes
that are repetitive and deterministic enough to be systematised and digitised.
It also aims to
standardise and/or integrate business processes.
Accordingly, it
describes enterprises as systems.
It would be difficult to manage the enterprise as a large and complex system, and plan changes to it, if it were not well understood and well described.
So, following the tradition of Stephen Spewak and John Zachman, enterprise architecture frameworks regard “architecture” as collection of descriptive artefacts
It is expected that enterprise architects maintain these descriptions in line with concrete, operational, systems.
The Zachman Framework is not a methodology.
But there is a long tradition of architecture frameworks that do provide methods for planning the implementation of operational systems.
They range from IBM’s Business System Planning (c1980),
through Spewaks’s “EA Planning” (1993) to today’s
architecture frameworks, which go on to govern implemented systems against
their descriptive representations (the architecture).
EA ends and means include:
· To enable and support business processes and roles, EA strives to structure workflows and improve the quality, relevance and use of business data.
· To optimise business systems, EA looks to tidy up the typical mess of duplicated and overlapping systems by standardisation and integration.
· To facilitate understanding and change impact analysis, EA maintains an abstract description of business roles and processes and the information systems they use
· To minimise business risks and maximise opportunities, EA also keeps an eye on information technology evolution.
In the 1980s, attention was given to describing the business context for IS and IT architectures.
The term "enterprise architecture" was introduced to embrace all three architecture layers (business, IS and IT).
Some add an environment layer on top of that.
|
Environment |
Entities and activities
monitored, supported or directed by the business. |
|
Business |
Business functions
offering services to each other and to external entities. |
|
IS |
Business applications
offering information services to each other and to business functions. |
|
IT |
Generic hardware,
network and platform applications offering platform services to each other
and to business applications. |
Nowadays, it is expected that an architecture framework does more than structure the architects' thinking about how to describe a system.
EA has taken a strategic cross-organisational perspective (meaning that discrete local initiatives are often called termed Solution Architecture).
Enterprise architecture frameworks are designed to help enterprise architects handle the scale and complexity of the enterprise-as-a-system, by
· abstracting from the level of detailed design that builders work at,
· producing useful architecture description documentation, and
· managing the task of architecting changes to the enterprise’s systems.
EA has a role in enterprise transformations that involve the information systems that enable and support business roles and processes.
It is to plan and govern those transformations better than they would otherwise be planned and governed.
And to encourage cross-organisational integration, standardisation or reuse where it that will optimise the business.
EA cannot address everything that is important to business managers, or that a business consultant might offer advice on.
EA cannot address everything of concern to IT managers and infrastructure architects.
EA is centred more on IS than on IT.
EA is about enabling and supporting business roles and processes that are repeated and deterministic enough to be systematised and digitised.
EA ends and means include:
· To enable and support business processes and roles, EA strives to structure workflows and improve the quality, relevance and use of business data.
· To optimise business systems, EA looks to tidy up the typical mess of duplicated and overlapping systems by standardisation and integration.
· To facilitate understanding and change impact analysis, EA maintains an abstract description of business roles and processes and the information systems they use
· To minimise business risks and maximise opportunities, EA also keeps an eye on information technology evolution.
EA has a well-understood role in enterprise transformations that involve the information systems that enable and support business roles and processes.
It is to plan and govern those transformations better than they would otherwise be planned and governed
And to encourage cross-organisational integration, standardisation or reuse where it that will optimise the business.
It is about “the effective management and exploitation of information through IT” as TOGAF puts it.
Modern enterprise architecture frameworks typically provide structured guidance that is divided into three main areas.
· Products - architecture descriptions: how to document a system from several viewpoints. Each view describes one slice of the architecture; it includes those entities and relationships that address particular concerns of interest to particular stakeholders; it may take the form of a list, a table, a diagram, or a higher level of composite of such.
· Processes - for architecting: there is usually an overarching architecture process, composed of phases, which may be decomposed into lower level processes composed of finer grained steps/activities. A process is defined by its objectives, inputs, phases/steps/activities and outputs. It may be supported by approaches, techniques, tools, principles, rules and practices.
· People - the architects: guidance on the architect team structure, the governance of the team, the skills, experience and training needed.
Since Stephen Spewak's EAP, and perhaps before then, it has been normal to recognise four architecture domains: business, data , applications and technology.
(Note that the applications architecture is about the application portfolio, not the internal architecture of a single application - which is often called the application architecture.)
“A complete EA should address all four architecture domains - business, data, application, technology.” TOGAF 9.1
The overlaps and relationships between EA, business architecture, information system and technology architecture are often disputed.
And the term “solution architecture” should be added into the mix, since it may well have predated “EA” in common use.
The term solution architecture is well established in systems integrators; for whome a key deliverable is an architecture definition document called the "solution outline".
They see the "enterprise architect" as a kind of design authority role in their customers’ organisations.
The table below offers some simple definitions that align with the history above.
|
Term |
Definition |
|
EA |
An enterprise-wide cohesive architecture that relates business, information system and information technology architectures into a coherent whole |
|
Solution architecture |
Same as above, but for a requirement, problem or project that is narrow or local, and possibly short term. |
|
Business architecture |
Description and design of business products or services, business processes, business functions, human roles and the organisation or management structure. |
|
Information system architecture |
Sum of data and applications architectures. Description and design of what data flows and data stores contain by way of data entities and data items. Description and design of business applications, data or use cases offered to business roles and processes, data stores they maintain and the data flows they exchange. |
|
Information technology architecture |
Description and design of the generic infrastructure technologies and the platform services they provide to enable business applications. |
The BCS reference model for enterprise and solution architecture defines EA thus:
“A strategic approach to architecture that addresses a whole enterprise.
The highest level, widest scope, longest term kind of architecture.
1: Documentation describing the structure and behaviour of an enterprise and its information systems.
Or 2: A process for describing an enterprise and its information systems and planning changes to improve their integrity and flexibility.” Ref. 9.
As will be discussed later, this does not mean enterprise architects design the totality of a business, all its human activities, regardless of information systems.
EA is not a complete business strategy/planning method.
EA teams are rarely well equipped to address sociological factors in business change.
TOGAF, like other sources, regards the architecture domains as layers of the enterprise system.
Each layer contains components that execute processes and offer services to the layer above.
E.g. TOGAF v1 (1996) encapsulated the technology component layer behind the platform services defined in the "Technical Reference Model".
This was and is very much according to the philosophy of TAFIM and POSIX.
The view of
architecture domains as layers can be presented thus:
|
Environment
|
Entities and activities monitored,
supported or directed by the business. |
|
Business |
Business functions offering services to
each other and to external entities. |
|
IS |
Business applications offering
information services to each other and to business functions. |
|
IT |
Generic hardware, network and platform
applications offering platform services to each other and to business
applications. |
Each layer "delegates" work to the layer below.
In each layer, the components, the processes and the services can be defined at a coarse-grained level and decomposed into finer-grained components, processes and services.
An architecture description document can be thought of as the blueprint for the procurement and realization of a system.
But an enterprise architecture includes more than just an abstract description of the system's structure and behavior.
It includes also principles, policies and standards (akin to building codes) designed to ensure that systems will be soundly constructed.
Governance of the enterprise architecture and of its implementation will require organization and processes (akin to city and county inspectors and the processes for checking building improvement projects).
Some business management consultants want their business card to present their role as “enterprise architect”.
Some in EA discussion groups talk about what they think EA should be.
Kite-flying industry analysts predict what EA will be in the future.
· The “EA as Strategy” book showed 94% of EA teams are focused on rationalisation of technology, data and application portfolios.
· Almost all of c. 1,000 architects I have met on EA training courses over the last 6 years, have been based in an IT department.
· Many notionally employed in an EA team are in practice working as solution architects on projects.
· I have been told that Gartner research into “leading EA practitioners” (whatever that means) reported that in western countries “70% of EA” (whatever that means) is within the IT department. Surely, if Gartner included “non-leading” EA practitioners, then the percentage would be higher.
Most EA teams are focus on the “foundation for business execution”, on digitisation of processes and IT infrastructure, on road maps for platform technologies and for business applications, though of course, they map these things to business functions/capabilities/processes.
Here is one more piece of anecdotal evidence.
· “In practice, much real world EA effort is rightly centered on application portfolio management (not be confused with project portfolio management).
· The CIO's attention may be drawn by fashion and shiny new things (social media, mobile devices, big data, analytics, Cloud) by various technical innovations and "modernizations".
· But my analysis of a smallish (10,000 person) company's software estate shows it has over 800 database-centric applications on their mainframe alone.
· And who knows what else on Windows, Unix, iSeries, etc? When the old main-framers retire, who is going to maintain those applications and integrate them with new ones? Knowledge of your business application portfolio and how it's connected up will be at a premium.” David Eddy in correspondence.
In recent years, some have started use the term EA for something other than what most people in EA teams do – as a technique that might be taught in an MBA course.
The something else seems variously to be what might better be called:
· business vision and/or innovation
· business product/service strategy definition
· business planning
· business process reengineering
· business change management.
All are important. All have touch points with EA.
But none are newer or more "advanced" than conventional EA. They are simply something else.
We might hope that
EA would be driven by executive-level business managers.
Yet in practice, the reality is that EA teams usually report to a CIO or to a direct report of the CIO.
And those few EA teams that do sit outside the IT department surely must have a close working relationship with it.
It seems to me there are several natural reasons why EA is rooted in IT.
First, EA has been
envisioned, defined, refined and developed by people concerned to help business
roles and processes make efficient and effective use of IS and IT.
“TOGAF has been developed through the collaborative efforts of 300
Architecture Forum member companies from some of the world’s leading IT
customers and vendors and represents best practice in architecture
development.” TOGAF 9.1
Second, EA appears to be strongest in those businesses (banks and government departments) that are in essence, highly regulated data processing businesses, with a much higher than average IT spend as a proportion of revenue.
Third, the IT department is often the largest cross-organisational function.
IT people see cross-organisational waste that line of business managers and CxOs might never see.
They have to take a longer term view than business directors who are focused on the next quarter's report to shareholders.
So, the need for EA springs from issues the CIO may be the first executive officer to see, or to envisage solutions to.
Fourth, executives and business managers usually see the planning and development of business information systems as the responsibility of the CIO.
“Typically, an EA is developed because key people have concerns that need to be addressed by the IT systems within the organization…” TOGAF 9
Fifth, since business managers are busy running their business, they need people with the vision, will and ability to see any EA initiative through.
Designing, building and delivering the digitisation, standardisation and integration of business processes requires both abstract and painstakingly detailed intellectual effort.
Business managers need those nerdy, systematic, completer thinkers who gravitate into the IT department – rather than into business management.
An EA team should maintain a cross-organisational
business function/capability hierarchy/map, and look to address the breadth of the business.
But EA can never address the totality
of a business? That is unrealistic.
Matters beyond the scope of EA include:
·
the human cognition needed to make business
decisions and deal with people
· human roles that are little or not at all helped by information systems
· machinery that makes no use of information technology
Much of what goes on in a human activity system cannot be documented in a
conventional EA model.
Humans act in informal, ad hoc, flexible, creative and unpredictable ways.
They work toward business goals as they perceive them, and may disregard
given roles, rules or processes if they get in the way.
Indeed, humans (rather than machines) are employed for having the ability
to behave in those ways.
A business employs people because humans are extremely clever and extremely
adaptable.
They can anticipate what their manager would, or should, want them to do in
novel situations.
They can change the business rules and improvise processes as they go
along.
The result is that much of the activity in human activity systems is not formalised in role or process definitions.
Enterprise architects do not even try to model the processes of human
cognition, communication and creativity that are critical to much business.
So if any architects claim to have completed a model of an enterprise, then
they have probably missed a lot of what goes on in the real world.
Enterprise architects do not design the totality of a business, all its human activities, regardless of information systems.
EA is not a complete business strategy/planning method.
EA teams are rarely well equipped to address sociological factors in business change.
The normal practice is for a business change team to be formed to work alongside the EA team.
Very
different kinds of designer apply the term EA to the work they do.
An IT
technician might use EA to mean the design of an enterprise’s IT network.
A management
consultant might use EA to mean defining a business product/service strategy.
However,
classic EA treats the enterprise as a system in which all is related via
information systems.
EA has always been inseparable from information system architecture.
That is natural, since business people need information not only to carry out their daily business processes but also to make decisions.
Clearly, business managers need information systems if they are to monitor
and control a business.
And managers make decisions based on the information they receive.
Governors are
supposed to monitor managers - check that they are following defined principles
and policies, and making wise decisions.
This too implies the collection of data about decisions made, directions
given and compliance with those.
So, EA has always been about efforts to enable or improve business roles and processes that use business information systems.
EA can also be about describing a business (or enterprise) and planning work (or endeavour) to transform that business towards a better integrated and more standardised state.
Today, enterprise architects strive to take a strategic and cross organisational view of business information systems, and the technology platform they depend on.
They steer those systems in directions that enable or enhance business roles and processes in accord with business drivers, goals and strategy.
Avancier
Methods provide some of the most extensive and practical
resources available, and are compatible with most other architecture frameworks
and schemes.
Published
under the Creative Commons Attribution-No Derivative Works Licence 2.0 06/02/2015
00:54
Attribution: You
may copy, distribute and display this copyrighted work only if you clearly
credit “Avancier Limited: http://avancier.co.uk” at the start and
include this footnote on each page.
No Derivative
Works: You may copy, distribute, display only complete and verbatim copies of
this paper, not derivative works based upon it – unless you have permission from the author.
For more about
the licence, see http://creativecommons.org.