Past and present
views of EA
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.
Abstract
TOGAF says: “Enterprise Architecture and Enterprise Architect are widely used but poorly defined terms in industry today.”
Agreed: EA is defined poorly, also variously; the same might be said of Business Architecture (BA) and Solution Architecture (SA)
Contents
Integration
of systems in the Information Age
Appendix:
quotes from popular EA sources that support this paper
For more information about the licence, see
http://creativecommons.org
People argue the future of EA lies in a direction they favour.
Yet these directions diverge, because people hold different views of where EA came from and is today.
Since the industrial revolution, enterprises have
striven to systematise their business processes.
They do this to reduce the duration of processes, reduce
the cost of resources needed, or increase the volume of cases handled.
Also to improve, standardise or
integrate processes, along with the products or information produced by
processes.
Systemisation involves defining core
business processes and the resources needed to perform
them.
Resources include
the people, technologies and information a business needs to enable and
support, monitor and direct, the processes.
During the 1970s, we entered the “Information Age”, described in Wikipedia thus:
“a period in history characterized by the shift from traditional industry to an economy based on information computerization.
… the onset of the Information Age is associated with the Digital Revolution.”
At the start of the information age, a few core business systems were digitised using mainframe computers.
· “Business Systems Planning” see the Wikipedia entry, and the web site of Robinson College of Business, Georgia State University.
· "Business Systems Planning and Business Information Control Study: A comparison" (1982) John Zachman, in IBM Systems Journal 21(1). p32.
In the 1980s, business system planning methods were supported by information system architecture frameworks.
The famous PRISM report was written at a time of growing concerns about.
·
The description and management of
increasingly complex and distributed systems,
·
Increasing disintegration and
non-standardisation of the systems used within a single business.
Concepts in the report (4 architecture domains, enterprise-wide principles and standards) have been used ever since.
Towards the end of the 1980s.
· "A Framework for Information Systems Architecture". (1987) John A. Zachman in IBM Systems Journal, vol 26, no 3. IBM Publication G321-5298.
· “Enterprise Architecture Model” (1989) National Institute of Standards and Technology
In the 1990s, planning methods and architecture frameworks evolved into EA frameworks.
· “Extending and formalising the information systems architecture framework”. Sowa and Zachman in IBM Systems Journal, Vol 31, No 3
· “EA Planning” (1993) See entry in Wikipedia for references.
· “IT Management Reform Act” (Clinger Cohen Act) 1996
Development continued after the turn of the century.
· “Federal EA Framework” Federal CIO Council 1999/2001
· “The Zachman Framework For Enterprise Architecture: Primer for Enterprise Engineering and Manufacturing.” By John A. Zachman. Copyright 2003 Zachman International
· “Integrated Architecture Framework (IAF) CapGemini
In the 2000s, the popular “EA as Strategy” book addressed the same concerns using similar concepts.
· “EA as Strategy” (2006) Ross, Weill and Robertson / MIT CISR
· “TOGAF 9.1” (2009) free to read at opengroup.org
In the 2010s, TOGAF addresses the same concerns using similar concepts.
These concerns and concepts are not expected to disappear soon.
· “The British Computer Society’s reference model for enterprise and solution architecture” (2013) downloadable from www.BCS.org.
·
“The
Skills Framework for the Information Age (SFIA)” the UK's standard reference
for IT-related roles.
A feature of the information age has been increasing digitisation of core business processes.
"companies
excel because they've [decided] which processes they must execute well, and
have implemented the IT systems to digitise those processes." (“EA as
Strategy” 2006)
On top of this, the analysis of stored business information, and “big data” has opened up new business possibilities.
Of course, we still need what to do “operational research” people did before the information age.
We need analysts to study humans at work, analyse business roles and processes, and recommend improvements.
We need to talk to people about their systems, manage stakeholders, draw diagrams to understand and design things.
These older analysis techniques underpin EA, but they are not definitive of what EA is about.
Enterprise
architecture frameworks were developed to help architects work in future that
can be characterised as:
·
The information age
·
Increasingly complex and distributed systems
·
Increasing integration and standardisation of
systems.
An aim is to enable and support business roles and processes that are repetitive and deterministic enough to be typified and systematised.
But EA has wider objectives than the incremental systemisation of processes that has been happening since the industrial revolution.
Our several sources emphasise the strategic nature of EA development in this “Information Age”.
A silo system (or point solution) is an organisation unit, application or other system that:
· is not standardised - does not follow the same rules or processes as another doing the same thing
· is not integrated - does not share information with another doing something different
· does not share/reuse common services – at the business or technology level.
Integration and reuse of systems are popular themes in the world of EA.
Zachman lists alignment, integration, reusability, interoperability, flexibility, and reduced time-to-market as EA objectives.
Clive Finklestein is the “father of Information Engineering” (the Aussie branch, which preceded the USA branch).
The titles of his EA training courses are Business Integration and Technology Integration.
TOGAF says “EA regards the enterprise as a system of systems”.
TOGAF and SFIA both encourage enterprise architects to define an “operating model”.
The operating model is a device introduced in the book “EA as Strategy”.
It is used to explore how far the enterprise (or a division thereof) wants to integrate and/or standardise its core business processes.
|
“Operating model” for core business processes |
||
|
High integration |
Coordinated |
Unified |
|
Low integration |
Diversified |
Replicated |
|
|
Low standardisation |
High
standardisation |
Note that to standardise or integrate business processes requires attention to the information created and used by those processes.
Enterprise architects develop and champion strategic and cross-organisational targets for enterprise systems, and sharing of resources.
The motivation and ability of an enterprise to follow standard processes, share data and share services will probably be
· lower if solution architects are given only narrow project or silo-based objectives
· higher if enterprise architects are employed to optimise the enterprise system estate.
Despite the consistent historical thread above, the term EA is now widely interpreted to mean other things.
Some in-house EA teams focus only on IT infrastructure.
Some management consultants and universities have positioned EA closer to MBA than IT.
Consider the various architecture stakeholders and actors below.
Do you think everything they do is reasonably called “enterprise architecture”?
System designers may consider EA to be drawing diagrams using languages such as UML and ArchiMate.
After all, ArchiMate introduces itself as a language for documenting enterprise architecture.
And some use a tool called “Enterprise Architect” to draw the diagrams.
Technical architects may consider the EA to be the enterprise-wide technology estate.
And produce strategic plans that set out road maps for technology retirements and replacements.
Solution architects may consider EA to be the act of architecting any solution for any line of business.
Though the solution may be contrary to one or more EA road maps.
Business analysts and management consultants may assume EA = BA, meaning business architecture.
This may cover advising on a departmental business process, a management restructuring, or many other things.
TOGAF-certified people may
consider EA to be defined by TOGAF.
TOGAF is a change management framework for “transforming the enterprise from a baseline architecture to a target architecture.”
TOGAF defines EA as “managing the spectrum of change required to transform an enterprise towards a target operating model”
Primary products include architecture definition documents and an enterprise-wide architecture repository.
The resulting uncertainty and confusion is enough to give any EA team manager a headache.
Is the team expected to solve every business problem? Or design every role, process, structure and machine used in a business?
Should the team lead the design of a marketing strategy, an IT data centre, a management hierarchy, a car production line, a software architecture?
How to scope the
role of the EA team today, in a way that is compatible with its history and
with a variety of popular modern sources?
What follows is
based on discussions with more than a thousand architects over nearly two
decades.
Answers emerging from discussions have been refined and illuminated with references to popular EA sources.
Those sources
include Stephen Spewak, John Zachman, Clive Finklestein and TOGAF.
The concept of
the “operating model” is drawn from “EA
as Strategy” by Ross, Weill and
Robertson.
Another source is
the Skills Framework for the Information Age (SFIA), the UK's national standard
reference for IT-related roles.
What follows is
not exactly in accord with one particular source above; it represents a
compromise between them.
Who defines the scope of EA? How can its scope
ever be defined or agreed?
TOGAF, though presented as an EA method, is often
interpreted and used as a solution architecture method.
Some authors have taken the term EA and run with
it in directions they find interesting and valuable, e.g. towards IT or towards
BA.
A message that emerges from EA history is one of cross-organisational integration and reuse.
In most modern sources, the EA team is expected to view the enterprise as a system.
Optimising the enterprise (rather than optimising individual business processes, roles or components) is the overarching aim.
EA takes a strategic and cross-organisational view of business processes, roles and components.
It looks to cross-organisational standardisation or integration of those business processes, roles and components.
The EA team is concerned with the enterprise-wide optimisation of business systems.
· To improve business system integrity - improve business data quality, relevance and use
· To help management understanding and impact analysis - maintain an abstract description of business roles and processes and the systems they use
· To minimise business risks and maximise opportunities - keep an eye on system & technology evolution, and produce road maps where needed
· To reduce TCO and complexity through reuse - tidy up the mess of systems by standardisation and integration.
· To increase agility and reduce time to market.
With the above aims in mind, EA values:
· Taking a cross-organisational view - over many local views
· Taking a strategic view – over tactical-only views
· Enabling business via IS and IT (alignment of the domains) – over single-domain thinking
· Focusing on the services systems deliver – over their internal organisation
· Abstract system descriptions - over very detailed or no documentation
The next section of this paper illustrates the points above with quotes from sources.
Many kinds of “architect” can contribute to the aims of EA; but are they all enterprise architects?
Are all business analysts, process modellers, software architects, database designers and technical architects fairly called enterprise architects?
Is all their architecting activity fairly called EA? No matter how short-lived, parochial or fine-grained?
Surely, calling all EA tends to obscure the aims of enterprise-level, enterprise-wide design and planning?
EA, BA, SA all
aim to enable and support, monitor and direct, core business roles and
processes.
All are likely to
start with definitions of business processes and the data they need.
So what differentiates the role of the EA team from local
business architecture, tactical solution architecture, technical architecture
etc?
From the outset, the idea of EA has been to establish enterprise-level/wide analysis over and above local/tactical solutions.
And to create abstract system EA documentation for use in impact analysis when changes are needed.
Today’s most popular EA frameworks mostly share aims and premises that have been clarified over a 30 year period.
The points below are distilled from the popular EA sources
quoted above.
EA aims
The EA team is concerned with the enterprise-wide optimisation of business systems.
· To improve business system integrity - improve business data quality, relevance and use
· To help management understanding and impact analysis - maintain an abstract description of business roles and processes and the systems they use
· To minimise business risks and maximise opportunities - keep an eye on system & technology evolution, and produce road maps where needed
· To reduce TCO and complexity through reuse - tidy up the mess of systems by standardisation and integration.
· To increase agility and reduce time to market.
An EA manifesto (cf.
the “Agile Manifesto”)
With these aims in mind, EA values:
· Taking a cross-organisational view - over many local views
· Taking a strategic view – over tactical-only views
· Enabling business via IS and IT (alignment of the domains) – over single-domain thinking
· Focusing on the services systems deliver – over their internal organisation
· Abstract system descriptions - over very detailed or no documentation
That is, while there can be value in the items on the right, EA values the items on the left more.
EA always leans to the left, though not always strongly on every point.
An implication is that an approach that tends to the right on several points is probably not best-called “EA”.
In other words, EA
is not the best label for:
·
IT
architecture alone - without reference to business processes, roles and
systems.
·
Solution
architecture alone - without reference to other solutions in the same
enterprise.
·
Business
processes alone - undocumented and/or without reference to business information
systems.
If an enterprise is viewed as a system of systems, then EA can be viewed as a meta system.
EA analyses the structure and behaviour of an enterprise’s operational systems and guides changes to them.
Like any business system, the EA system involves people, processes and products.
If your architecture descriptions each relate only to one system, then there is no EA description.
Quotes below are
from Zachman, TOGAF, and “EA as Strategy” by the MIT-related authors (Ross, Weill and
Robertson), and some other sources.
EA favours taking a cross-organisational view - over many local views – aiming to reduce TCO and complexity.
EAs focus on core business processes, and cross-organisational optimisation of systems.
Today, Finklestein, TOGAF and MIT authors define EA with reference to cross-organisational integration and reuse.
They speak of integration and reuse in every layer of the enterprise system from business to information system to platform technology.
The first six quotes
below are from the enterprise edition of TOGAF, though the operating model
concept comes from the MIT research.
·
“Why do I need an EA?...
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.”
·
“a good enterprise
architecture … ensures the needs of the organization for an integrated IT
strategy are met, permitting the closest possible synergy across the extended enterprise.”
·
“The
focus of the Enterprise Architect is on enterprise-level
business functions required.”
·
“Conducting
EA [can be defined 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.”
·
“Enterprise
architecture is… a horizontal function that looks at enterprise-level (as well as line of business-level) optimization and service delivery.”
·
“TOGAF
is intended … to establish the EA team as having board-level, strategic and cross-organisational authority... needed
for cross-organisational EA to be successful.”
·
“Commonly,
solution architects in the design division are driven to meet the immediate
requirements of individual business units, with the result that only tactical
stand-alone solutions are developed and implemented.” IT Business Edge.
·
“Organizations
can use enterprise architecture and portfolio management approaches [to]
streamline and rationalize the apps
portfolio reduce redundancy, consolidate IT capabilities define sound IT
governance policies.” IT Toolbox.
EA favours taking a strategic view – over tactical-only views.
The quotes below are
from the enterprise edition of TOGAF.
·
“Why do I need an EA?...
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.
·
“An
enterprise architect… has professional relationships with executives of the
enterprise to gather and articulate the technical vision, and to produce the strategic plan for realizing it.”
·
“The strategic
plan of the enterprise architect is tied to the architecture governance
process for the enterprise, so design decisions are not circumvented for
tactical convenience.”
·
“The
Enterprise Architect has the responsibility for architectural design and
documentation at a landscape and
technical reference model level.”
·
“The Enterprise Architect often leads a group
of the Segment Architects and/or Solution Architects related to a given
program.”
·
“elements in an enterprise architecture may still be considerably abstracted from Solution
Architecture, design, or implementation views.”
Zachman, SFIA and others refer to this being the “Information Age”.
EA favours enabling business via IS and IT – over single-domain thinking (to maximise opportunities and minimise wasteful IT spend).
The “alignment objective” means EA joins up business, IS and IT domains – rather than addresses one domain in isolation.
In 1993, Stephen Spewak defined the scope of EA Planning.
“[EA planning is] the process of defining architectures for the use of information in support of the business and the plan for implementing those architectures”.
· The business mission is the primary driver.
· Then the data required to satisfy the mission,
· Then the applications built to store and provide that data
· Finally the technology to implement the applications.
to improve data quality, access to data, adaptability to changing requirements, data interoperability and sharing, and cost containment.”
The book “EA as Strategy” tell us:
·
“EA produces “a road map for the CIO and IT
organisation to follow”.
·
"companies excel because they've [decided] which processes
they must execute well, and have implemented the IT systems to digitise those
processes."
And TOGAF says.
·
“Enterprise Architecture…can be considered as
a superset of Business, Data,
Application, and Technology Architecture.”
·
“Why do I need an EA?...
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.”
Copyright conditions
Creative Commons Attribution-No
Derivative Works Licence 2.0 02/12/2015 00:24
Attribution: You may copy, distribute and display this copyrighted work
only if you clearly credit “Avancier Limited: http://avancier.co.uk” 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.