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.
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.
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.
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.
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