Socio-cultural EA (A deconstruction of
mainstream EA)
One of more than 200 papers at http://avancier.website. Copyright Graham Berrisford. Last updated 01/01/2017 12:43
And a postscript to one of several
papers on the home page about the terms and concepts used in architecture
frameworks.
·
Enterprise & Solution Architecture EA and the Digital Enterprise EA and Strategy
·
Building Blocks, Interfaces and Services Architecture and
Design Architecture and System TOGAF-ArchiMate alignment
Contents
“Enterprise
IT architecting” – focused on technologies
“Enterprise
integrating” – focused on socio-cultural systems thinking
“Enterprise
ecological adaptation” - focused on fostering continual evolution
EA and
agile development as cybernetics
Today’s “information age” started with the digitisation of business information.
Yet the term “enterprise architecture” did not come of out of thinking about information technologies.
The history in “50 years of digital
transformation and EA” includes references from 1970 to
date.
There is a common theme – a focus on business processes and data:
· 1970s Walker's business data-process matrix.
· 1980s Zachman’s framework’s six columns: the first for data, the second for processes.
· 1990s Spewaks “EA Planning” aim to “improve data quality, access to data…”
· US legislation dictats:
- Improve business processes through using data better and reducing data entry effort.
- Share data processing projects and resources to accomplish shared missions.
· 2000s FEAF said EA “establishes… roadmap to achieve… mission through optimal performance of core business processes.”
· "EA as Strategy" said "companies excel because they've [decided] which processes they must execute well, and have [digitised them].”
· 2010s: TOGAF places business processes and data analysis before IT.
Business processes are integrated through the exchange of information in messages and sharing of memories.
EA is about the why, when, where and how of business processes that create, store and use information.
It is about the design and planning of changes to those business activities, and/or to the capture and provision of that information.
In the last decade or so, people have appropriated the term “EA” for other things they wanted to talk about or do.
In 2012, Lapalme proposed a "novel taxonomy” which radically deconstructed EA.
By not mentioning business data or processes at all, Lapalme skipped over 50 years of EA history.
His taxonomy was not based on a review of
what EA teams actually do in businesses.
It was an academic exercise, a review of selected literature that divided authors into three schools below.
“In this school of
thought, enterprise architecture is about aligning an enterprise’s IT assets
(through strategy, design, and management) to effectively execute
the business strategy and various operations using the proper IT capabilities.
This school is
techno-economic in that it aims to reduce IT costs through technology reuse and
eliminating duplicate functionality.
IT strategic planning
and business enablement are also top priorities.”
Defining EA in terms of information technologies without reference to business processes and data is misguided.
US OBM Memoranda 97-16 says this:
“The Enterprise Architecture is the explicit description of the current and desired relationships among business and management process and information technology.
It describes the "target" situation which the agency wishes to create and maintain by managing its IT portfolio.
The documentation of the Enterprise Architecture should include a discussion of principles and goals.
For example… the balance between centralization and decentralization and the pace of change within the agency, should be clearly understood.”
In other words, the US government says manage the IT portfolio to provide the business processes (defined in the target EA) with the information they need.
Yet Lapalme makes no reference to business roles, processes, data, information, or to digitisation of them.
So his characterisation of E(IT)A (shown in italics below) just doesn’t fit mainstream EA.
Motto: “EA is the glue
between business & IT.”
Yes but EA is also about business system improvement and integration through data capture, use and sharing.
Aims: “Effectively
enable the enterprise strategy. Support IT planning and reduce costs.”
Yes but EA aims also to support/enable roles/processes that create/use business data; improve data quality; exploit data captured.
Principle: “Apply a
reductionist (mechanistic) stance.”
Rather, EA applies a holistic (service-oriented) approach based on general system theory principles.
Principle: “Don’t
question business strategies.”
Rather, EAs contribute to business strategies.
Principle: “Design
organizational dimensions independently.”
Rather, EAs design cross-organisationally; others design organisation structures.
However, the organisation structure and roles must be relatable to the processes and data defined in the EA.
Principle: “Don’t
worry about non-IT dimensions; they’re not your concerns.”
Rather, EA must start from the human context - that is a primary concern.
Skills: “Technical competence & engineering knowledge.”
Also communication skills, leadership, holistic business understanding.
“For this school,
enterprise architecture is about designing all facets of the enterprise.
The goal is to
execute the enterprise’s strategy by maximizing the overall coherency between
all of its facets—including IT.
This school … aims to
eliminate contradictions between various enterprise polices and structures and
is often viewed as “the link between strategy and execution.”
All aspects of the
organization form a complex fabric of reinforcing and attenuating dynamics, so
they must be globally optimized and designed.”
“Within this school
of thought, the enterprise architect’s main role is to be an inquiring
facilitator.”
Mainstream EA looks
to integrate business systems, but does not set out to change all aspects
a business, its policies and structures.
The culture of a business is important to the sponsorship, roles and processes of an EA team.
It influences EA; it may be changed as a side effect of business system changes.
But enterprise architects are not tasked with changing culture per se.
Business systems and organisation management structures are separable concerns.
Mainstream EA is concerned with the roles people play in regular business systems, to which actors must be deployed
It is not tasked with managing or motivating the individual people who act in those roles.
And it is not about organisation design.
Who does design the organisation’s management structure and
"softer" human aspects of business system?
They are normally the responsibility of business managers, supported by HR and
perhaps a “business change” team.
To call organisation design “EA” leads to confusion, and sometimes antagonism
between parties.
“For this school,
enterprise architecture is about fostering organizational learning by designing
all facets of the enterprise—
including its relationship to
its environment—to enable innovation and system-in-environment adaptation.
Creating the
enterprise strategy and designing the organization are top priorities.”
“Within this school
of thought, the enterprise architect is a nurturer.
[This] requires a
great deal of sensemaking— a collaborative
process by which people give meaning to experience, creating shared awareness
and understanding out of their different perspectives and interest.”
Mainstream EA starts from considering the business environment, and transactions with customers and suppliers.
However, “ecological adaptation” here means continual evolution of roles and processes.
And if business operations are continually evolving they cannot be described as a system – there is no definable architecture.
See discussion of agile development below.
EA is difficult, political, and not always
successful, but that doesn’t change what it is.
If Lapalme’s first school is meant to be mainstream
EA, then it misses the mark.
Since, remarkably, it makes no reference to
business roles, processes, data, information, or to digitisation of them.
His second and third schools embrace various
socio-cultural systems thinker’s ideas.
Socio-cultural systems thinkers often steal
terms from one domain and confuse people by using them in another.
Lapalme’s essay proposes a radical
reinterpretation of EA.
He proposes the Enterprise Architect is a
"facilitator" or "nurturer" of organisation design or
"organisational learning".
He surely aims to stimulate interest in these
subjects.
Does this help mainstream EA teams out there?
Does it have a better track record?
The EA roles he proposes might more clearly
be called an organisation designer or business management consultant.
EA cannot have unlimited meanings or scope.
A coherent and consistent explanation of EA must be desirable.
EAs aren’t business managers, IT managers or sociologists.
Mainstream EA has its own focus - on information creation and use in business roles and processes.
It is concerned with who does it, why, when, where and how.
This does require attention to the capabilities of information technologies, but is not a technology specialism.
Appropriating “EA” for organisation design or business management consulting is more confusing than helpful.
“Enterprise architecture structures the business planning [and] regards the enterprise as a system or system of systems.” TOGAF 9.1
Mainstream EA is not sociology; yet it is about business systems that can be seen as formalised social systems.
Any discussion of system theory needs to distinguish:
· Descriptions from realities.
· Discrete entities from systems
· Natural systems from designed systems
Natural systems
A natural system runs in reality as phenomena instances before it is described.
The Krebs cycle was a system in operation before it was described.
The solar system was in operation before it was described.
A natural system follows a description made from observation of its repeatable behaviors.
|
Orbiting planets as a
system |
|
“The solar system” <define> <abstracts features of> Astronomers <observe and
envisage> Planets in orbits |
The solar system can be called a discrete entity – meaning it is separable from the rest of the universe.
Telling you that the orbiting planets form a solar system conveys an additional meaning.
It tells you that the system’s behavior
can – at least conceivably - be tested against a description.
The correspondence of the real solar system to its description need not be perfect.
It only needs to be near enough to help those who know the system description to predict its behavior – well enough.
We
readily understand the solar system is a discrete entity, composed of a few
planets that display regular behaviors.
Moreover,
if/when those regular behaviors cease, we know that
entity will stop being the system we understood it to be.
Designed systems
A designed system is described as a set of phenomena types before it exists in reality.
Microsoft Word had to be described in coded types before it could be used to write a document.
A professional tennis match was described in laws before any matches of that type were played.
A designed system, in operation, follows a prior description made of its repeatable behaviors.
|
Tennis match as a
system |
|
Laws of tennis <write> <abstract features of> LTA <observe and
envisage> Tennis matches |
A tennis match can be called a discrete entity – meaning it is separable from the rest of the universe.
Telling you that it is a system conveys an additional meaning.
It tells you that the system’s behavior
can – at least conceivably - be tested against a description.
The correspondence of a real tennis match to its description need not be perfect.
It only needs to be near enough to help those who know the system description to predict and direct its behavior – well enough.
We
readily understand that a tennis match is a discrete entity composed of players
and officials that display regular behaviors.
Without
those regular behaviors, there is no longer anything
describable as tennis match.
Business systems
IBM can be called a discrete entity – meaning it is separable from the rest of the universe.
What would it mean to call IBM a system?
Some argue that every discrete entity could be described as a system.
Trouble is: many entities of interest are describable as an infinity of different systems.
IBM contains infinite phenomena types; so to say IBM is a system conveys no meaning.
Further, IBM as a whole is a somewhat disorderly collection of actors and activities.
They compete with each other, contradict each other and work to different goals.
In what sense is that a system?
IBM in reality is infinite systems in description.
You might well include (among those infinite systems) a description of IBM as a whole as a one system.
But that description might contain little more than a profit/loss variable, and the contribution of each division to it.
“The principal heuristic innovation of the systems approach is what may be called ‘reduction to dynamics’ as contrasted with ‘reduction to components’ ” Laszlo and Krippner.
To define a business system, it is not enough to enumerate the actors, or typify them, say {people employed by IBM}.
General system theory is concerned with dynamics - with repeatable behaviors.
A sociologist may presume a social group does what it does (activities) to satisfy what the social group is (actors).
By contrast, in a business system, the requirement is for
actors to perform roles in processes that provide services required by
system sponsors/stakeholders.
Business system behaviors are defined in terms of services provided by value streams/scenarios/processes/activities.
Mainstream EA
Mainstream EA is about business systems describable in abstract models of repeatable behaviors and the actors/components that perform them.
It is important to acknowledge that enterprise and solution architects cannot describe or design all that matters in an enterprise.
A huge amount of the behavior in an enterprise is very human indeed.
Much if not most of what people do in a business is beyond any generalised description of roles and rules.
Enterprises depend on intellectual, intuitive and creative abilities, social skills and empathetic behavior, and on manual labouring skills.
Of course, architects may also take an actor-centric view of a business, and be sensitive to the interests of human actors.
They can see a business as an endeavour that engages people with differing aims, skills and states of mind.
The human actors have intelligence, knowledge, skills, hopes and fears beyond any possible system description.
The actors choose how they respond to direction, they act in ad hoc ways and break the rules now and then.
Still, mainstream EA is about identifying and changing definable roles and rules, not about the individual human actors.
“Cybernetics deals with all forms of behavior in so far as they are
regular, or determinate, or reproducible.” Introduction
to Cybernetics Ashby
1956
It is also much concerned
with feedback loops between control systems and controlled systems.
A business as an
application of first order cybernetics
In a business system, people play interacting roles in regular, or determinate, or reproducible behaviors.
Every business is connected by “cybernetic” feedback loops to entities that it monitors and directs (suppliers, customers, employees).
E.g. the business receives orders, sends invoices, receives payments or time-out notifications, and so on.
As Conant declared
"every Good Regulator of a System Must be a
Model of that System".
This principle of cybernetics says that
a control system must hold a description or model of the variables it controls.
A brain observes its environment, holds a model of it, then uses that model to predict the future and direct bodily actions accordingly.
A business captures information about external entities and events, records that information in a database and uses that to guide future actions.
EA as an application
of first order cybernetics
EA is a meta system, connected in a monitor-change feedback loop to operational business information systems.
It monitors baseline systems and direct changes to them; then plans their evolution under change control.
Mainstream EA is about designing and planning changes to business systems in which it is presumed that:
· A collection of actors (structures) will perform roles in activities (behaviors) to provide required services.
· The system changes externally when service types are changed.
· The system changes internally when activity types or actors’ roles are changed.
· The system does not change when individual actors are replaced.
· An abstract description of the system should be accepted by its sponsors/key stakeholders
· The description will be revised and approved before the operational system is changed.
Agile development an application of
second order cybernetics
Sociologically-inclined gurus found 1st order cybernetics too limiting for what they wanted to say about social groups.
The gurus decided to include the control system inside the controlled system (or include the meta system in the system).
They included systems observers and describers in “systems” that are observed and described.
They introduced self-aware actors, able to change their own roles and rules, into the “system”.
This was called second order cybernetics to distinguish it from what had preceded it.
Agile development methods embody socio-cultural thinking ideas.
“Continual evolution”
Agile development methods favour short-cycle incremental system development by small multi-skilled team.
Agile developers favour face-to-face description over documentation.
Every day, they code and test a new system version; if it doesn’t work, the previous version is restored.
“Organisational learning”
Agile developers apply organisational leaning to the meta system that is their agile development methodology.
In a meeting each morning, the developers may change the roles and processes they follow.
Enterprise architects may apply these ideas in their own EA processes.
However, EA products describe business systems using the principles of first order cybernetics.
And EA is more about strategic and cross-organisational changes than incremental and local changes.