PAPER Enterprise transformation
Transcript of PAPER Enterprise transformation
www.leonardo.com.au Page - 2
If it were like a house renovation project What if we tried to illustrate enterprise transformation using the classic before/after
advertising photos, like the ones used to present the achievements of a builder?
While there are many different types of house renovation projects, we can group them into
two types: one for those that do not require a lot of owner engagement; and another for that
do involve extensive owner engagement.
Group 1 – minimal owner engagement.
In this group we might find things like an upgrade to the electrical wiring and components to
ensure compliance with security standards, the replacement or enhancement of the heating
system, and fitting new gutters, etc.
Group 1 projects can be seen as relatively simple endeavours, at least from the owner’s
perspective. If the heating system is broken, then it needs to be replaced. There are
questions to be answered by the owners, but they come more as options among a selection
of available technologies, proven practices, and associated costs.
Group 2 – extensive owner engagement.
In this group we would find things like extensions to the house, adding a floor, or major
additions, like a swimming pool, etc.
Group 2 projects require a bigger involvement by the owner in the outlining of the initial
requirements, and throughout the project. In these projects, owners need to answer
questions like: How many more rooms? What size? The floor map could include spare space
to allow the future fitting of a lift – do you opt for smaller rooms to allow the possibility of
adding future equipment? Things become even more complicated when the owners are a
couple that do not agree on the requirements. Owners’ choices reflect their tastes, their
goals, and their identities.
Group 2 projects require owners to contemplate fundamental questions about the nature of
the house: What do I want to do with it now? How long do I intend staying here? What will
www.leonardo.com.au Page - 3
change in my life during that time? Of course, Group 2 projects are often the opportunity to
tackle Group 1 projects, or are the accumulation of many unattended Group 1 projects.
Thought experiment
As enterprise transformers working on advertising our business, we need a picture of the
enterprise taken before the transformation, and another of the enterprise after the
transformation. What would this picture look like?
www.leonardo.com.au Page - 4
What is an enterprise? To try to picture an enterprise in our little before/after thought experiment, let’s look at what
The Open Group Architecture Framework (TOGAF), the most popular enterprise architecture
framework, has to say about it:
• “TOGAF defines ‘enterprise’ as any collection of organizations that has a common set of goals” (TOGAF® 9.1 web> Part I: Introduction > Introduction > 1.2 Executive Overview).
• “TOGAF considers the enterprise as a system” (TOGAF® 9.1 web> Part I: Introduction > Core Concepts > 2.2 What is Architecture in the Context of TOGAF?).
At a very high level, an ideal enterprise could be sketched as a primary system delivering
business outcomes within its environment and being constituted of:
• smiling people with clearly defined responsibilities, conducting
• well-aligned activities, supported by
• efficient, smoothly running technology.
While operating, that enterprise exchanges goods, services and resources with its
environment. We might represent it with a picture like this:
But that picture is not static. The enterprise environment is ever changing and the enterprise
operating model can only deliver its expected products and services within certain conditions
of viability. Unexpected or expected changes in the environment require changes to the
enterprise operating model.
www.leonardo.com.au Page - 5
The need for transformation Here is what TOGAF says about itself: TOGAF is “a framework for managing the spectrum of
change required to transform an enterprise towards a target operating model” (in the
TOGAF® Version 9.1 Book – Chapter 4.2 The Benefits of TOGAF).
Often, the enterprise’s capacity to deliver its expected outcomes is stressed in the face of
both expected and unexpected changes in its environment.
The gap keeps widening between the strategic intents and the actual outcomes. The
enterprise viability deteriorates, and its operating model no longer fits its environment.
Our enterprise in need of transformation could be pictured with people’s faces showing how
much they appreciate being submitted to unclear or conflicting directives on broken or
misaligned activities, and supported by less-than-smoothly operating pieces of technology.
However, this picture might not be detailed enough to show which parts of the enterprise
operating model require work.
If, like TOGAF 9, we consider our enterprise as a system of systems (“Enterprise architecture
structures the business planning into an integrated framework that regards the enterprise as
a system or system of systems” TOGAF® 9.1 web > Part II: Architecture Development Method
(ADM) > Preliminary Phase> Relating the management frameworks), then it would be
interesting to try to represent that extra dimension of systems.
www.leonardo.com.au Page - 6
Enterprise as a system of systems So, we are looking for a model to represent an enterprise as a system of systems, and we are
interested in how these various systems contribute to the enterprise viability. It does not take
much online research to discover that operations research theorist Stafford Beer’s Viable
System Model attempts to do just that. The VSM is not new – Beer introduced it in his book
Brain of the Firm in 1972.
This system model was recently re-introduced by Patrick Hoverstadt in his book The Fractal
Organisation.
The following illustration is like a zoom into the ‘fried egg’ we presented earlier. It is inspired
by the VSM because it contains each of the subsystems originally identified by Beer and re-
introduced by Hoverstadt; however, for simplicity, it does not show the complex network of
structural relations between the systems.
It is important to remember that even if the structural relations between the sub-systems are
not shown here, they are the most important concept of the VSM. These relations should not
only be understood as information flows between systems, but also as necessary structural
couplings that ensure the cohesion and sustainability of the whole.
Here is an example of such structural relation between two sub-systems found in the above
illustration: the sub-system called delivery is structurally coupled with the sub-systems called
operational units. This structural coupling is made of performance measurement flows (i.e.
descending instructions, ascending accountabilities, and all the related responsibilities,
processes and supporting applications).
www.leonardo.com.au Page - 7
Defects in the quality of this relationship (also called structural couplings) often account for
imbalances and resulting operating model structural defects.
It is also important to bear in mind that, even if each of these sub-systems is constituted by
people responsible for processes delivered by technology, they might not be mapped exactly
onto our official enterprise organisational chart. For example, you may be working in an
enterprise with no marketing department, but that doesn’t mean no market intelligence is
gathered and understood (a typical function of the sub system called intelligence in our
model). It probably occurs, for instance, in the CEO’s brain – and that can, potentially, become
a viability concern.
The different sub-systems of the VSM can be listed as follows:
Core value-adding functions group
This contains the operational units organised in structures dedicated to the production of value
by delivering goods and services, either to be consumed internally by other operational units,
or externally by parties external to the enterprise.
Meta functions group
This contains the following sub systems:
• Policy system – normally the responsibility of the board, it has to do with the enterprise identity and strategic intent.
• Delivery system – responsible for the continuity of the delivery at a tactical level in accordance to the strategic intent (C-level management, enterprise-wide tactical planning).
• Intelligence system – non-productive bodies responsible for the development of the enterprise, looking at inside and outside the enterprise and at the present and future outlook, marketing, product design, architecture.
• Monitoring system – qualitatively informing delivery and policy systems; involves dialogue and attention to detail (a complement to performance management).
• Coordination system – automated regulation of the different operational units performed by business systems; can automatically handle simple conflicts.
Also, it is important to note that the VSM is recursive, which means that any sub-system can
be further described using the exact same organisation.
www.leonardo.com.au Page - 8
Where does architecture sit on the enterprise
‘fried egg’ picture? Remember the Group 1 and Group 2 house renovation projects we identified at the beginning
of this article? (Group 1 involving minimal owner engagement; Group 2 with extensive owner
engagement).
In fact, enterprise transformation endeavours are much more than a classic Group 1
engineering exercise. Enterprise transformation endeavours are like our Group 2 house
renovations – mainly because the enterprise system being transformed is not only constituted
by automated processes, but also made of people who will take part in, and will be
transformed by, the enterprise transformation process.
As such, the enterprise is a techno-social system and, as a result, its transformation cannot be
reduced to a mechanistic engineering exercise; it also comprises a strong learning aspect.
As a learning entity, the enterprise has to develop:
1. A better understanding of itself and its environment.
2. A capacity to use that understanding to act on itself and its environment.
3. A capacity to transform itself.
Architecture seeks to develop and maintain artefacts that represent the multiple dimensions
of an enterprise (Business, Information, Technology architectures), as such it contributes to
the development of the enterprise capacity to transform itself. And the intelligence system is
where architecture, as a representation of the enterprise by itself, lives.
Every stakeholder is a potential contributor and consumer of architecture.
www.leonardo.com.au Page - 9
The picture above shows where the architecture models should live in the enterprise as seen
by the VSM.
The enterprise transformation process will need to assess whether the intelligence sub-
system in the enterprise has an architecture component. If it is not an organised body (like a
staffed office or, at least, an identified role), then establishing one might need to be
considered before progressing any further with the transformation.
Once established, the architecture component (team, department, assigned architect) will
constitute and maintain the reference architecture adapted to the very nature of the
enterprise transformation being engaged. The architecture component is informed by
knowledge coming from various adapted methodologies and frameworks (TOGAF ADM,
ARCHIMATE, 7 Enablers, etc.). This knowledge can then be used as a basis for structuring
reference architecture and its organisation into an operational capability.
Using the previous structural coupling notion, we can say that architecture is coupled with all
the other sub-systems of the enterprise. That coupling has inward flows of data collected to
inform architecture artefacts (such as validated lists of processes, people responsibilities, or
applications), and outward flows of architecture views, adapted to the needs of their
consumers throughout the enterprise.
www.leonardo.com.au Page - 10
Conclusion So, returning to our initial ‘thought experiment’, if we had to represent enterprise
transformation as a before/after picture, it might look like this:
Here, the process at the centre of the transformation would benefit from a representation of
the enterprise operating model showing its different sub-system components and their
structural couplings.
The VSM, even simplified and presented as a ‘fried egg’, can be used as a mental model to
observe, question and assess how an enterprise existing operating model compares to the
required ingredients of system viability.
www.leonardo.com.au Page - 11
About the Author Frederick Halas is a Senior Consultant at Leonardo Consulting (www.leonardo.com.au).
Frederick joined Leonardo consulting after more than 15 years’ experience in software
development, related methodologies, and enterprise architecture capability development. He
can be contacted at [email protected].
Leonardo Consulting For 15 years Leonardo Consulting has been a trusted advisor delivering
quality education, technology and consulting services across many
industry sectors around the world. The Leonardo team of experienced
consultants is unrelentingly focused on helping customers achieve their
goals using business process-centric management approaches. The
approach is process-centric; the focus is performance-driven.
Leonardo Consulting has extensive experience, with proven methodologies and tools, to
help implement and sustain effective process-based management. Education programs,
management system design, coaching, mentoring, and implementation reviews are all
available from experienced consultants to establish and maintain contemporary business
process management best practice.