Focus on process rather than organisation
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
The
primacy of processes in enterprise architecture
“Structural
change” wrt enterprise architecture
EA focuses on business processes rather than management structures.
TOGAF-style EA
focuses on business processes, especially ones that create and use business
data.
It distances the
architect from the management structure by mapping processes and data to a
logical business function/capability hierarchy.
John Zachman refers to being inspired by Walker who: "believed
systems should be designed to automate the process, not to encode the
organizational responsibilities.
Because the process and the organization
changed independently from one another.
By separating these two independent variables, management could change organizational responsibilities without affecting or changing existing systems or the organization.”
Walker is right in the sense illustrated by the following example.
There is a process that starts with you putting your credit card into a vendor's card reader and finishes with the transfer of money from your account to the vendor's account.
That process requires various actors/components to perform various process steps.
The management structure that employs or pays for those actors/components can and does change with no effect that process.
Correspondent: However, in my particular branch of the finance industry, organisational structure trumps the process.
The concept of ‘process’ is only understood in the context of controls and compliance.
Reply: Do
you mean each organisation unit sees only their part of an end-to-end process?
Line managers and operational staff don't need to understand that complete process.
However, the Principle of Suboptimization suggests controls applied only at the process step level may be suboptimal.
And
if the EA team understands the cross-organisational process, they may help to
ensure it is not damaged by hapless reorganisation.
Correspondent: In my business, processes disappear as soon as the organisation changes.
Reply: Do
you mean that each line manager is responsible for their own customers, P&L
and processes?
In
that case, the wider legal enterprise is divided into “segments” that could
each have its own EA team.
But
if these independent segments are continually created and destroyed, then it is
difficult, probably impossible, to establish an EA team.
Correspondent: In my business environment, there seems no hope for an EA team.
There is little incentive to invest in improving or optimising the process, but merely to ensure that one’s own contribution to the process is obvious.
Reply: I am not trying to sell you EA, only trying to describe it.
The role of an EA team is to optimise core processes and systems with a strategic and cross-organisational perspective.
If there is no sponsorship for that, you are left with iterative Solution Architecture.
The EA team may (this is not uncommon) turn into a pool of Solution Architects who report to an EA team manager.
Again, that is OK if you accept the “Principle of Suboptimization” and are satisfied with “Guerilla EA”.
EA is not
sociology. EA is about systems that are very complex in the system theory
sense.
It is not about
the so-called "complex adaptive systems" of sociology, in which the
concept of a system well-nigh evaporates.
It is not about
designing the management structure of an enterprise.
When human
resource issues need to be addressed, EA works in partnership with HR and/or
"business change" team or consultants.
What is "structural change", what is the motivation for it, and how is it relevant to EA?
Reader: I take ‘structural change’ to mean organisational changes to formalise roles, responsibilities or activities.
Graham: The term "structure" is used ambiguously in systems thinking and system theory.
A business has a human authority/communication structure (usually a hierarchy).
Business processes are performed by actors connected in a network structure.
The two structures may change independently of each other.
Surely it would be better to distinguish sociology from system theory?
A systems thinker has to choose their viewpoint: actor-oriented or activity-oriented?
Social hiearchology and EA are different things; EA teams do not define human management structures.
And surely it would better to distinguish structure from behaviour?
Holistically, it doesn't matter how the structure or roles of a system change, provided the overall behaviour is the same.
Always, the operation of a system costs money; and changing the structure or behaviour of a system consumes time and money.
"Refactoring" - changing a structure without changing behaviour - is relatively cheap kinds of change.
And shuffling the management deck chairs is peripheral to EA.
The universe or a business is a continuum, with no separation, until separations are observed or envisaged by actors.
Separations appear only descriptions or models that carve the continuum up into discrete things.
Separations are only realised in so far as working actors follow the rules in those system descriptions.
Given that divisions have been drawn and established between systems, EA is concerned to address cross-system impacts.
Reader: It is the interaction of structures in the operation of the business that determine the architecture.
Graham: That is true at every level of granularity.
Within a system, its subsystems cooperate in the system's architecture.
More widely, systems cooperate (now as subsystems) in a wider system's architecture.
Reader: EA should be managing the communication boundaries of structures.
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 19/05/2016 20:56
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