Who values the enterprise as a system?
This 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
On valuing
the enterprise as a system
Some businesses, especially in the finance industry, are suffering a system complexity problem that is recognised at board level.
This report nails a bank’s complexity problem very well:
Arguably,
such a business needs an over-arching complexity management initiative that
tackles all five sources of complexity:
1 Regulation, 2 Multi-channel customer interactions, 3 Fragmented
systems, 4 Product proliferation and 5 Geographic
expansion.
EA can address such problems, especially fragmented systems.
An EA vision is to move from “fragmentation” to “unification” in the grid below.
|
Business
process “Operating
model” |
Low standardisation |
High standardisation |
|
|
High integration |
Coordination |
Unification |
|
|
Low integration |
Fragmentation |
Replication |
EA emerged out of Business Systems Planning in the 1980s.
A business system being processes, performed by a mix of human and/or computer actors, that deliver output products or services to human and perhaps also computer users.
Today, TOGAF says “Enterprise architecture regards the enterprise as a system, or
system of systems.” (Ref. 1)
Senior
managers may envision their enterprise as being one coherent business system.
But
where, aside from bottom line financial numbers, is
this system defined?
We
are dealing with such complex systems that establishing a useful cross-organisational view of them is difficult.
And
establishing and maintaining the value and sponsorship of cross-organisational endeavours is
challenging.
It
seems reasonable to propose system architects focus on the "value" that
a "system" delivers to "customers".
However,
value is a fluffy, soft concept, and the architect’s customer is rarely the
system’s customer.
And
systems are nested such that the customer of one system is an actor inside a
wider system.
So
the proposal is somewhere between an aphorism and a platitude.
Who is the customer of a business?
In
a competitive commercial business, the answer may seem clear.
The
customers of a bank are savers and borrowers.
The
customers of a cinema are people who buy tickets.
But what about shareholders?
Who
are the customers of a charity – say Cancer Research, Oxfam or the RSPCA?
Who
are the customers of government department – say tax collection?
What
about a department that makes it possible for farmers to claim EU grants?
Are
the customers the UK government? The European Commission?
The citizens or taxpayers of the UK? of the EU?
Farmers? The biosphere,
and so all life forms on the planet?
Focusing
on the customer who pays for business services doesn’t always help a system
architect.
The
job is rarely to design a whole business, and enterprise architecture is not
web site design.
Architects
have to design systems that interact little or not at all with business
customers.
The
system users might be suppliers or employees rather than business customers.
The
job may be to standardise or integrate systems and so
improve internal business efficiency.
Or to generate better business intelligence for
senior managers.
Who is the customer of a system architect?
System users? System operators?
Surely,
the architect’s customers are sponsors who pays for systems?
And sponsors don’t always want systems to
please system users!
A payment system may be designed to delay
the outflow of payments, rather than please suppliers.
A
budget airline may want a cheap system that does the minimum a customer needs
to book a flight.
The
system may be designed to charge excessively for changing flight details.
What is the value of a business or a
system?
Suppose
you run a cinema. Do you care what values your customers get from buying
tickets?
If
tickets sales are good and profitable, you may not worry what values customers
obtain.
If
ticket sales take a down turn, you might try to find out what they want.
It
may be a simple as cheaper tickets, or better films.
In
the final analysis, your primary concern is the value you get from ticket sales.
Value is a fluffy concept; a system architect is taught to start with the desired effects of a system.
And then consider the outputs or services the
system can deliver to produce those desired effects.
That basic system theory is assumed in every architecture framework I know of.
It
applies at any level from the smallest and simplest system to the largest and
most complex.
The "zoom out, zoom in" principle
tells a system architect
First study the wider business context and
the demands it places on a system, looking at input/output flows and
measurements of them.
Then study the role subsystems plays in the system, looking always at input/output flows between them.
However,
there are many stakeholders in the development or change of a system.
Architects
are supposed to identify and articulate value propositions for each stakeholder
group, and manage discrepancies between them.
System
size and complexity
The huge size and complexity of a large enterprise makes a detailed description of the enterprise-as-a-system too huge to maintain
And summary descriptions are usually too vacuous for those solution architects who are employed to deliver working subsystems.
Hierarchology
Lower-level managers have a budget for their subsystem, are reluctant to fund shared services or resources.
Higher-level managers are more remote from the subsystems that must be bought, built or changed.
The higher their level, the bigger the decisions (e.g. ERP system purchase) the more the decisions approach random.
If higher-level managers focus on the next report to shareholders or government politicians, or their next career step, they probably won’t be motivated to look to the long term.
If they don't feel the pain caused by non-standardisation and non-integration of subsystems, they probably won’t be motivated to sponsor cross-organisation efforts.
EA may do well to interest higher-level managers in the need for better cross-organisational “business intelligence”.
However, somebody who gets to be a senior manager is often not an analyst by nature.
It
is naturally difficult to get sponsors for cross-organisational
systems and endeavours.
Who pays for a system? How is the value of a system defined?
The same questions can be asked of integrating systems into an enterprise-wide system.
Correspondent: “Value” is a personal thing; there are many ways to define it.
A thing or activity has the value you pay for it, or you can sell it for, or the value you feel it to have.
Reply: The value of standardising and integrating systems is to increase the efficiency and coherence of enterprise-wide system outputs.
But this is only of value if somebody actually values it.
Correspondent: That somebody is surely the accountable executive who decides whether or not he/she is getting enough value the work?
That executive, be it the CEO or a lower level executive, is usually responsible for P&L of some form.
Reply: Accounting for shared services or resources is always problematic.
Who pays for the integration of line-of-business systems by information exchange or overarching process control?
Typically, the higher the executive who pays for a system (or work to operate, maintain or change it) the further they are from system actors and users.
On the other hand, the more they might gain from management information gleaned from one system, or garnered from several systems.
Correspondent: That budget holder should make their values explicit, along with principles for what is considered valuable.
Everybody else’s definition of value should stem from that budget holder.
Reply: A hierarchical cascade of aims and values might help, but is crude management science.
System sponsors, users and actors have different aims and values.
Sponsors see the costs of systems they pay for, yet not feel the operational-level benefit or pain of systems.
So they can be insensitive to what system actors and users value.
Yes, you can short-circuit any debate about what “value” means.
Get the sponsors of your endeavour to tell you what measurable value they expect to obtain, before you start.
And then stick to that, come hell or high water.
Trouble is – when it comes to work on systems, especially what might be called common good work - sponsors may ask you to define the value and quantify it.
Correspondent: In my experience, those who best understand the value of EA are the least able to convince decision makers of the value.
Reply: Their natures likely differ: the analytical, tidy-up-the-mess nature needed for some EA team roles isn’t what gets you promotion up the business management hierarchy.
Correspondent: The ‘pull’ for EA should come from those who decide where and how money will be spent.
If the spenders feel no need for information or advice from their EA team, then it is not likely to retain sponsorship.
Reply: That is one reason why EA is as much or more a political game than a numbers game, as discussed below.
Read the following short papers for discussion of each point.
· Effective implementation of business goals
· Simplification and cross-organisational integrity
· Return on investment in systems
· Reduction of operational or change risk
· Increased business and IT agility
· Focus on process rather than organisation
· Where EA sits in the business
References
Ref. 1: TOGAF 9.1, The Open Group.
Ref. 2: Oxford Dictionary of Proverbs. Cf. 1942 G. Ciano Diary 9 Sept. (1946) II.
Ref. 3: Heylighen F. (1992): "Evolution, Selfishness and Cooperation", Journal of Ideas, Vol 2, # 4, pp 70-76.
Ref. 4: “EA as Strategy” Ross, Weill and Robertson.
Ref. 5: ArchiMate v2 standard, The Open Group.
The papers on the “Enterprise Architecture” page at http://avancier.website contain much advice relating to EA.
Footnote:
Creative Commons Attribution-No Derivative Works Licence 2.0 18/02/2015 18:38
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
work, not derivative works based upon it.
For more information about the licence, see http://creativecommons.org