What is EA
not?
This page is published under the terms of the licence summarized in the footnote.
Abstract
The term "enterprise architecture" sounds grand and is easily misread.
EA is not some things people suggest it is, could be or should be.
The reach of an EA team into business operations and IT operations is limited.
Business
strategy implementation?
Solution and
enterprise architect roles
Some start by deconstructing the term; asking: What could “"enterprise architecture" be read to mean?
Some answer: “Surely what I (manager, consultant, solution architect, business analyst, software engineer, technologist) do?
And so, every intervention by a management consultant, every implementation of a technology, comes to be called EA.
Every business analyst and solution architect calls themselves an enterprise architect.
This leaves people confused about what an EA team manager is accountable for.
Surely better to begin by understanding the origins of EA and what an EA team is reasonably asked and able to do.
Why was the term EA invented? Over the decades since, what have prominent authorities used the term EA to mean?
And above all: What does a real EA team do? What is an EA team manager accountable for today?
What follows is in line with authoritative EA sources listed in the references below.
On reading the paper below, one EA team member replied immediately "Makes sense to me. Sign me up!"
EA = managing the
execution of business strategy?
EA is not only about managing the execution of business strategy.
And business strategy execution is not only managed by EA.
The management consultant misreading is: EA = business
planning.
The IT architect misreading is: EA = IT system planning = business planning.
But EA = business system planning rather than business planning.
So yes, EA is about ensuring business systems support and enable business
strategy.
But EA is as much or more about improving the efficiency, effectiveness of
business systems for business as usual, especially through cross-organisational
standardisation and integration.
EA is about business roles and processes that create and use information.
Often, that is not the focus of business strategy and usiness
planning.
Even in those peculiar businesses (banks, insurance and government departments)
whose operations are primarily business data processing.
And
where roles and processes have been substantially digitised.
The top level
strategists and planners may be focused on other things.
Where the business
strategy does requires changes to
information-intensive business processes, EA is important to that strategy.
But what if the
business strategy has no impact on information-intensive business processes?
Then EA carries on
striving to improve the effectiveness and efficiency of the current processes,
with a cross-organisational remit.
A further
misreading is: “the EA team addresses all business roles and processes”.
The EA team
addresses business roles and processes that do or should create and use
recorded information and recordable message passing.
Some roles and
processes depend on this, some don’t, and some depend on spoken-only
information.
Of course, humans have to manage where digital systems cannot cope with the
variety of real-world behaviour.
But far beyond
these "exceptions" to formalised, digitised, processes,
much that is human and technological is simply not addressed by EA.
Many business roles and processes are intractably human (intellectual, social
or manual) or electro-mechanical, and better addressed by others.
Also, human hopes,
fears, dreams, motivations and culture are better addressed by others (line
managers, HR, etc).
The best the EA team can is recognise these situations and interface with those others where necessary.
Business strategies present top-level business goals, along with decisions and abstract plans to meet them.
Who directs business strategy?
Who determines the product/service portfolio? steers the marketing strategy? sets HR policies?
Not the EA team, though they may make some proposals at this level.
Who implements business strategy?
Of course an EA team must strive to support top-level goals, decisions and plans.
The EA team will certainly help to implement some particular strategies.
But you can’t define a specific thing (EA) as a more generic thing (strategy implementation)
Other functions (e.g. HR, PMO, FM, OD, ITSM) may be as much or more responsible for strategy implementation.
In fact, almost any department could claim to be responsible for implementing strategies.
Does every business strategy or change need
or benefit from significant EA involvement? No.
Who do you think will implement these strategic decisions?
· Replace the van/truck fleet
· Close the least profitable 10% of current stores.
· Get new top designer to brand clothing range
· Increase the clothing / household goods sales ratio
· Spend £20 million on TV advertising
· Cut the middle management layer by 10%
· Change the culture: send all staff on customer-friendliness training courses.
In these matters, the EA team may be on the side lines or a minor partner.
Does every business strategy need EA
team members to implement it? No.
Many others in an organisation may be called on to implement strategies such as replace van fleet, cut middle management numbers, or increase product prices.
If it ain't related to a repeated business process, then it is probably peripheral to EA.
And some decisions that affect core processes may need little or no EA involvement.
E.g. impacts such as scaling systems up or down may be handled by IT services management.
Does every EA goal register with CxOs as strategic for a business? No.
Some business system standardisation, integration and upgrades are not mentioned in business strategies.
Some may be piggy-backed on work sponsored for a reason more appealing to business managers
Is everything architects do (to implement a
business strategy) rightly called EA? No.
You may use TOGAF to deliver, change or optimise a particular business process or system, perhaps in an "agile" way.
And you may do this
in response to a board-level business strategy or decision.
But suppose you do that without taking a holistic view of the enterprise:
· without reference to enterprise-wide architecture principles, policies and standards
· without attention to the impact on related processes or systems
· creating a process or system that is not standardised, not integrated or overlaps with another process or system
· and without leaving any documentation of the process or system you worked on?
Then you are working as a solution architect, regardless of EA as defined by Zachman, TOGAF and other authorities.
And “If you are not building (and storing, managing and changing) primitive models, you are not doing Architecture. You are doing implementations.” Zachman
The EA team don't lead the design and planning of hardware products, production lines, retail store shelving, vehicles, etc.
They don’t design or manage IT data centres, or manage software development projects.
The EA team is primarily concerned with enabling and supporting business processes.
Architects help to design and change processes that are regular and repeatable
But their reach is limited even here.
Consider the complexity and richness of a business and its real-world behaviour.
· A car manufacturer – assembling a car.
· A gas company – laying a mains pipe, installing a meter.
· A rail infrastructure company – setting points, setting signal to “danger”, delivering replacement track.
· A road gang management company – digging a hole, filling a hole.
· A bus company - driving a bus, collecting a fare.
· A postal service – delivering a letter, requesting a signature for a recorded delivery.
· A TV company - presenting the news, interviewing a celebrity.
· A theatre management company - staging a play, cleaning seats after a performance.
· The thinking/cognitive processes every employee needs to perform their role.
.
These processes may be supported *at some point* by information systems.
And it is an EA role to identify points where IS can improve the efficiency and effectiveness of business processes.
Usually, where the
EA team gets involved is where a business process creates or uses business
data.
In the real world, garbage collection (for example) is primarily a manual and mental activity.
Arresting a criminal is a primarily a manual and mental process.
Driving a bus depends on the mechanical processes of the bus and the mental processes of the driver.
Giving the driver a satnav is a pimple on the backside of the biological processes we take for granted.
Many necessary manual and mental processes are complex and mysterious beyond our understanding - we have no flowcharts for them.
Some are ad-hoc, unrepeatable or unpredictable.
Some are mechanical and/or electrical (say heating and ventilation).
In short, the reach of EA into these processes it limited.
And many business issues - related to mechanical equipment and human nature - are better dealt with by people outside of the EA team.
Why is EA centred
on business processes that use information systems?
Why does the EA team not advise on all the operations of a business?
E.g. driving trucks, digging holes, laying pipes, baking cakes, making cars and running meetings?
Why focus on supporting and enabling business processes that create and use business data in information systems?
Because that is the focus of EA, and it always has been.
In the 20th century, we entered "the information age", and EA emerged from business systems planning methods.
In the 21st century, EA "regards the enterprise as a system" according to TOGAF 9.1.
To understand EA requires understanding what a system is.
In General System Theory (GST), a system is a collection of repeatable processes and information feedback loops.
To describe the enterprise as a system is to describe how its business processes consume and produce information.
The processes maintain the state variables of the enterprise; this state may be distributed, provided it is also coordinated.
If the state is not only distributed but also de-coupled, then you have two more discrete enterprises (or segments as TOGAF might call them).
GST starts from the idea that systems are composed of repeated processes, in which components play roles.
Some social
organisation theorists start from the idea that systems are composed of people
- which is a very different view, and must not be confused with GST.
The EA team’s work on business
processes usually influences the roles people play.
But the team does not take the lead in organisation design or cultural change.
The table below paints a picture of a spectrum from behaviour-oriented EA to people and structure-oriented organisation design.
|
Enterprise architecture
Organisation
design |
|
Processes involve
roles which are
instantiated in assignments performed by human actors who report to organisation units |
The EA team are not responsible for selecting the people a business employs, or defining their general role definitions.
They don’t manage human resources, or assign people to roles, or design organisation management structures.
Who does look after the people who are assigned to play roles in processes?
Mostly, line/team/project managers, Human Resources and Business Change teams.
I am told, for example, that two parallel teams
worked on an enterprise-wide transformation of the Australian Post Office:
·
the EA team focused on systemisation of roles and processes.
·
the Business Change team
focused on the human actors and organisation design.
Business system planning not = business planning.
System architects are concerned with the systemisation of business processes.
The solution architect role is concerned with the design and change of:
· processes that are “regular, repeatable or determinate” as a system theorist like Ashby would say
· processes that can be “digitized” as Ross etc. say, meaning monitored and/or directed by digital information systems
· roles played by human and computer actors in those processes (or business scenarios as TOGAF calls them).
· information systems that support and enable the above roles and processes.
The enterprise architect role involves:
· taking a more holistic view, working at a higher, wider level
· tidying up the mess of business systems, standardising, integrating and improving them
· planning and optimising the whole business system portfolio.
Thus, EA takes a holistic view of business systems, rather than everybody and everything in a business.
A primary aim is to optimise business behaviour through rationalisation, standardisation or integration of processes and systems.
If the work is on a local, non-standard, non-integrated process, then it is more solution architecture than enterprise architecture.
It is common to divide architecture into four domains or views and three or four levels.
The four primary architecture domains have appeared in (surely all) popular architecture frameworks since the PRISM paper of 1986.
Three levels are shown below, though TOGAF inserts fourth level (segment) between enterprise and solution.
|
Architecture Work Space |
||||
|
Domain/view Level |
Business |
Information Data |
Applications |
Infrastructure Platform |
|
Enterprise |
|
|
|
|
|
Solution |
|
|
|
|
|
Software/technology |
|
|
|
|
|
Operations |
|
|
|
|
(Read the EA generalities page for discussion of roles in this work space.)
On planet earth, EA teams are not accountable
for making business decisions or implementing all business strategies.
They produce high-level
designs and plans for the effective and optimal systemisation and
digitisation of core business processes.
They work to implement those
strategies that depend making changes to the business systems portfolio.
And work to improve how the
business exploits information that has been gathered by systems during business
processes.
The EA team are interested in but not accountable for:
· business goals and strategy definition
· business case development
· requirements management (arguable?)
· project management
· software development and the SDLC
· IT services management
· organisation design
· cultural change.
“Yes, I agree on your whole list; to an extent,
even the organisation design.
However, architects are interested in and may influence these things.
These domains generate contexts and constraints for architecture definitions.
So, those darn pesky meddling EAs might have something to say about any one of
them, from time to time.” Nic Havard
Some argue that EA is or should be about organisation design and cultural change.
In practice, the design of organisation/management structures rarely falls in the remit of the EA team.
What if cultural and other human factors are important in an EA-designed change?
Typically, these factors are addressed by a "Business Change" team working parallel with the EA team.
This Business Change team may be transient, formed for a specific business change to address HR and related concerns.
The two teams follow different processes, deliver different products, and need different skills.
Read EA history references for a list of prominent EA sources from
1980 onwards.
Read How does TOGAF define EA? for how EA is defined today.
The architecture of an enterprise
may be defined as the form and functions of a business.
Does this mean the EA
team's remit encompasses every aspect of a business?
This stretches EA beyond the
bounds of credibility and practicality.
Through history, and
in current EA team practice, the reach of the EA team is narrower and more
specific.
In short, the EA team takes a holistic view of business systems planning:
· produces high-level designs and plans for the effective and optimal systemisation and digitisation of core business processes
· helps to implements those strategies that depend making changes to the business systems portfolio
· improves and extends how the business exploits information gathered by systems during business processes
· tidies up the messy business system portfolio and improves it.
There is much that EA is not responsible for, including much that concerns the employees of a business.
An EA framework can happily point to the need for a parallel Business Change team.
It seems unwise to try to turn an EA framework into a treatise on human factors in management hierarchies.
Copyright conditions
Creative Commons Attribution-No
Derivative Works Licence 2.0 04/07/2015 15:02
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