Enterprise transformation: what is transformed?

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

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.

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.

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

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.

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.

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.

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.

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 f.halas@leonardo.com.au.