Relevance of
the above to 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.
Contents
What
is enterprise architecture about?
A system architect is an actor who describes a reality – an organised collection of inter-related actors and activities - as “a system”.
The triangle below marries the idealist philosophy (in the paper in philosophy) to general system theory (in the paper on system theory).
|
The philosophy underpinning system theory |
|
System descriptions <create and use> <idealise> Architects
<observe and envisage> Operational
systems |
EA applies general systems theory by defining a human activity system as roles performing activities in processes.
The processes maintain system state and/or deliver business services (each definable in terms of inputs and outputs, pre and post conditions).
Actors play roles in processes.
Roles are defined in terms of activities an actor is able to play.
Processes are defined in terms of activities in sequences.
Activities are related to data created and used.
Business data represents the state of entities and events that the business wants to monitor or direct.
Enterprise architecture (EA) is about enterprise-wide business system planning (or capability planning if you prefer).
It treats the enterprise as a collection of operational business systems.
It is a meta system that observes and envisages business systems, and plans changes to them.
It looks to optimise business processes by standardising and integrating business systems, and looks for innovations to improve them.
If EA is about business system/capability planning, it seems a good idea to start by defining system and capability, before defining architecture.
A system is a collection of interrelated elements.
An activity system is a network of actors/components playing roles in processes to produce desired effects by maintaining system state and/or transforming inputs into outputs.
It can be encapsulated behind an interface; it is open, meaning it interacts with entities and events in its environment.
A capability is a system, component or business function, given goals to achieve and resources to achieve them.
It is a collection of actors and activities that deliver desired effects.
It is a combination of people, processes and technologies that deliver required products or services to required measures or standards.
For 30 years, EA deliberately defines business systems/capabilities as independently of the management structure as possible.
To avoid dependence on that fragile structure, a purely logical function hierarchy is often used in its place.
TOGAF suggests using “structured analysis” in which nodes in the logical business function structure are mapped to organisation units.
(For an illustration of structured analysis, see the slide show “TOGAF business architecture - functions and capabilities” at avancier.website).
Enterprise architects traditionally go on to map business to systems to technologies.
They map human activities and data to software applications (or to the use cases they support and enable).
They map applications to computing technologies (or to the platform services they provide).
The resulting composite is a “human and computer activity system” that spans the four primary architecture domains (business, data, apps and infrastructure).
The term “socio-technical system” is sometimes used to mean the same thing, and sometimes to mean something different, as below.
The paper on system theory explored a deep schism in thinking about activity systems.
This paper considers enterprise architecture (EA) in the light of that schism.
The paper “The philosophy of system architecture definition” made some general points about businesses and systems.
A business is an activity system; it employs actors to perform activities.
It operates inside an environment, and interacts with entities and events in that environment.
A business is a bounded set of processes that consume inputs from suppliers and provide outputs to customers.
Process improvement methods like Six Sigma describe a business in terms of suppliers, inputs, processes, outputs, and customers (SIPOC).
However, the boundary of the business (what is inside and outside) depends on the perspective taken.
A business needs to remember discretely identifiable things.
A business creates and uses records of discrete entities and events it wants to monitor or direct.
Business processes proceed on the presumption those records are accurate, and where they are not, the processes may fail.
Business processes depend on data that flows between actors, and data that has been stored for future use.
Particular data items must conform to general data types whose meaning is known to both data creators and data consumers.
So, a business typifies the entities and events it wants to monitor or direct.
E.g. a business use the concept called “payment” to typify money amounts that it receives.
Suggestions made by enterprise architects have included:
A. The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.
B. A formal description of a system, or a detailed plan of the system at a component level to guide its implementation or the structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.
C. A rigorous description of the structure of an enterprise, which comprises enterprise components (business entities), the externally visible properties of those components, and the relationships (e.g. the behavior) between them.
D. An architecture is the most important, pervasive, top-level, strategic inventions, decisions, and their associated rationales about the overall structure (i.e., essential elements and their relationships) and associated characteristics and behavior.
E. Architecture is the use of abstractions and models to simplify and communicate complex structures and processes to improve understanding and forecasting.
Definitions A and B, using the word "component", have misled some to conclude architects define only a structure of building blocks.
Definition A was refined in ISO 40210 (2011) thus:
“Architecture <system> fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.”
The word "element" is intended to embrace both structural and behavioural elements, both components and processes.
The phrase "in its environment" suggests a system is encapsulated behind inputs received and outputs produced (or services if you like).
(In EA, the "principles governing [a system’s] design and evolution" are part of the general context for architecture definition, precursors to it, rather than specific to the system or architecture in question.)
Definitions C, D and E reflect general system theory in promoting the importance of taking a behavioural view.
EA regards the enterprise as a system of systems (or capabilities if you prefer).
A system or capability can be described in structural views (focused on how actors and component subsystems connect) and behavioural views (focused on repeatable services and processes).
Architects start by understanding or defining the behavioural elements (services, value streams, scenarios, use cases or processes) required of human and computer activity systems.
An architecture is the product of designing and planning systems at a high (abstract) level.
It is work product that describes a system, presented in views to address the concerns of stakeholders about that system.
It may map elements of the system to elements of the wider environment or context.
It may inform planning of the work to implement the system.
One architectural system description can define one or more system instances, or operational systems.
The EA team is responsible for business systems that are deterministic.
There are non-deterministic systems.
Agile development methods like SCRUM apply the idea that actors are empowered to change their processes to achieve agreed goals, or even to change the goals.
EA frameworks assume architects define their own architecture processes and products.
But EA is the meta system, not an operational business system.
EA is about governing operational business systems, with a mind to standardisation and integration.
The EA team is accountable for constraining the development of operational systems in some ways, not allowing unconstrained silo system development.
Taking a socio-cultural view of a business can be the opposite of taking a systemisation view
Should the EA team constrain the ambition of business managers to organise its employees and standardise business rules and processes?
You may take the view that some modern business systems are over-engineered; they are too rule-bound.
Should the EA team recommend some business processes would work better if humans were empowered to make up the rules as they went along?
The term EA has never meant designing everything in an enterprise.
The success of a business is not down to EA alone.
There are many parts of a business (technological, intellectual, manual and social) that EA cannot and does not reach.
The EA team is accountable for the effective and efficient behaviour of business systems that are deterministic.
It is not accountable for defining human management structures, for inspiring and motivating employees, and for much else.
The EA team works with people in other functions who are responsible for such things.
If EA meant everything that consultants and authors wanted it to mean, it would meaning nothing in particular.
You may use EA to mean whatever you would rather it mean, but that is not helpful, just confusing.
To change the focus of what EA means, by putting socio-cultural systems thinking at its heart, would not be to advance EA.
Leaving aside the questionable value of some socio-cultural thinkers’ ideas, it would confuse the hell out of people.
Of course there are senses in which people are at the centre of things.
An ATM is designed to help a person withdraw cash from their account.
A business system (say, directing the process from purchase order to invoice to payment) can be seen as a formalised social system.
Business systems involve and serve human actors.
Socio-cultural factors will always be important in the success of a business.
A business works best when its formal systems and culture are in harmony.
And an EA team should be aware of socio-cultural factors in a business.
It is one thing to know all that, and another to shift EA from focusing on processes (deterministic activities) to focusing on people (self-directing actors).
Enterprise architects may benefit from some socio-cultural ideas and agile development principles.
But they are not biologists, psychologists or sociologists.
EA has always been about systems in which actors are employed to perform activities, rather than about the actors themselves.
The primary responsibility of the EA team is the deterministic behaviour of human and computer activity systems, rather than the recruitment, organisation and motivation of people.
Architects work for and with people (sponsors and stakeholders) who have concerns about deterministic business systems.
Architects may record the organisation's management structure, but rarely design it.
Architects may define human roles, but rarely define individual human actors.
Architects may take "culture" into account, but do not design it.
Architects work with people in other functions (such as HR, business change, line managers and even bio-mechanical engineers) who are responsible for addressing human and socio-cultural concerns.
Automation of business processes, data storage and retrieval has required businesses to specify their processes more formally, and to tighten their business rules.
Connection of distributed business processes through digital networks has enabled us take a holistic view of business systems.
EA developed to view an enterprise as a network of human and computer activity systems that enable the delivery of required products and services.
It focuses on business activities that are partly or wholly digitisable, and the communication and exploitation of information captured from those activities.
There are many parts of a business (technological, intellectual, manual and social) that EA cannot and does not reach.
The limited role of the EA team, governing deterministic business systems, is difficult and politically challenging.
The business case for it is usually unquantifiable; but that doesn’t mean it isn’t worth doing.
The sponsorship of an EA team is a judgement call made by senior business managers, hopefully including a CIO and CFO or COO.
Some say EA is or should be about transformational change to systems, as may be requested by business directors.
In practice, top-down business transformations are not common, and the EA team need not wait for such a request before looking at business systems with an enterprise-wide perspective.
The CIO may pursue what I call Guerilla EA, which approaches the aims of EA in a bottom-up and incremental way, by forming solution architects into a community with shared EA aims.
Footnote: Creative Commons Attribution-No Derivative Works
Licence 2.0 08/10/2015
22:49
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.
For more information about the licence, see http://creativecommons.org