The adaptable enterprise

Copyright 2020 Graham Berrisford. A chapter in “the book” at Last updated 28/08/2021 15:36


Reading online? If your screen is wide, shrink its width for readability.


This chapter picks up from where the chapter on “Change” left off. Obviously, an enterprise may fail because it cannot adapt to changing circumstances, inside or outside the business. This chapter addresses what it takes for an enterprise to be adaptable, including several interpretations of self-organization.


Events and antifragility. 1

Making an enterprise more adaptable. 1

Designed activity system mutation. 4

On tackling wicked problems. 8

Conclusions and remarks. 9


Events and antifragility

A UK Prime Minister was asked what the most troubling problem of his Prime Ministership was. Famously, Harold Macmillan replied ‘Events, my dear boy, events’.


Obviously, an enterprise must respond to perturbations, shocks, attacks or failures. Here, all such life-threatening events are called Events (with a capital E).


Antifragility is one or more properties of a system which enables it to survive and thrive after Events. It is sometimes defined as robustness and/or resilience.


Robustness and resilience are so variously defined in the literature than no attempt is made to distinguish them here. Suffice to say that to survive Events a system may:


·       change state, but remain the same system (think, produce antibodies to an infection)

·       call for back up (think, fail over to a back-up system)

·       mutate, evolve into new system generation (think, the evolution of a virus).


Agile development is a process by which a system readily mutates to handle Events.


An agile system is a system that can handle Events without mutating.

Making an enterprise more adaptable

An enterprise may become more adaptable by:


·       managing risks related to Events

·       enabling actors to innovate when Events happen

·       changing activity systems quickly and easily

·       designing activity systems up front to anticipate Events

·       tackling “wicked problems”.


This section discusses the first four above. The fifth is addressed at the end of this chapter.


Managing risks

A social entity can prepare for Events by taking out insurance or managing risks in the normal way.


·       Envisage the future: predict the most likely and serious Events

·       Prepare to resist or recover from bad Events

·       Prepare to respond to desirable new Events

·       Test those preparations if possible

·       Plan an escape route or alternative future if need be.


This chapter is not about the generalities of insurance and risk management in social entities. The focus on ideas more directly relatable to systems thinking terms and concepts.


Enabling actors

One way for an enterprise to prepare for Events is to put responsibility in the hands of (well-trained and well-motivated) human actors, rather than computer actors or machines.


Management scientists often encourage seeing employees as autonomous agents who can learn from experience and adapt what they do. They promote "organizational learning". And obviously, there are many times and places where a business benefits or even depends on its employees insightfully adapting what is done and how it its done. The question here is not whether this is a good thing, it is how to position it terms of social entity thinking and activity systems thinking.


An adaptive social entity is one in which actors are free and able to:


1.     join and leave (be hired or fired)

2.     determine the activities they perform, and even the aims they seek

3.     learn from experience and act in ad hoc and innovative ways

4.     change the rules of activity systems they play roles in


Re 2 and 3. There is nothing more agile than a social entity in which human actors/agents use their intelligence and insight to decide what activities to perform, and even what aims to pursue. However, incrementally, businesses are replacing the evolved complexity of human adaptability, by the designed complexity of human and computer activity systems, which is where EA comes in.


Re. 4. How a business makes discrete changes to the activity systems it employs is discussed later in the section on self-organization.


Changing activity systems quickly and easily

Another way for an enterprise to prepare for Events is to improve its ability to make incremental changes to the activity systems it employs. This has been a focus of software development methodology for several decades now. Among the best-known principles for agile software system design are:


·        You Ain't Gonna Need it (YAGNI)

·        Keep it Simple (KISS).


Software systems are infinitely malleable. Still, a price must be paid for taking a short-term incremental approach to system design, since applying the KISS and YAGNI principles inevitably produces designs that must be modified later, when the cost of database and software refactoring must be paid.


Some agile development principles may be applied in higher-level business system design. However, people and physical resources are not infinitely malleable. The need to hire, fire or retrain people, and buy or redesign physical machines and resources, can hinder the ability to roll out system changes quickly and easily.


In software system development, the ring-fencing of scope (by time boxing, cash boxing, functionality or persistent data) helps a two-pizza team to be more productive. But this can result in overlaps and disintegrities between systems – and so be sub-optimal at the enterprise level. To counter that, EA tends to favor more up-front analysis and design.


Designing systems up front to anticipate Events

To design a system in anticipation of future changes means making it more complex than is needed initially. From the start, the system has to include a wider range of possible choices and activities. So, contrary to the agile development principles above, the principles are:


·        We Are Gonna Need it (WAGNI)

·        Complexify for change or configurability (CFC).


What can EA do to prepare a business handle to future Events? Design for bad Events, for robustness or resilience, requires redundant components, back up versions, fail over and restore processes.


Design to handle desirable new Events or requirements implies using the "complexify" principle above, since we must design a system that is more complex and resource-intensive than it needs to be right now.


E.g. The architects of a logistics business might design over-sized and resourced "hubs" with highly mechanized storage and retrieval of items, even though the current throughput of packages to be delivered does not require it.


E.g. Software architects might design a broad and rich database structure that will be stable, or perhaps configurable. The idea being the database need not be restructured during the following process of incremental and iterative agile software development.


Note that design up front faces many challenges.

·       How far ahead in time are we looking?

·       What proportion of future Events can we predict? 

·       How often or likely will each kind of Event occur?

·       Can we afford the redundancy, additional complexity and resource consumption that design up front requires?

·       And noting that a robust or resilient capability may be lost if not exercised now and then, will be able to do those exercises?


One way or another, design for antifragility requires time and budget since a) agile development requires time and budget for refactoring after Events, and b) design up front requires time and budget before Events. In practice, this puts pressure on business managers to sponsor the minimum design effort they can get away with.

Designed activity system mutation

Every weather system, every plant and animal, every business activity system (as described in soft systems methodology) and every causal loop diagram (as drawn in system dynamics) is a machine in the broadest sense. Although business activity systems allow human actors the freedom to choose between defined activities, still, the range of actions is limited to those available in the machine.


How do machines - natural and designed - evolve in discrete steps? This chapter focuses on designed systems.


EA is about designed activity systems that are rolled out, changed and replaced in discrete steps. There are motivations, aims, goals or objectives for change. There are designers who work to invent or change the systems. There are designs or plans for systems to be built and deployed. There are baseline-to-target migration projects.


Incremental or transformational mutation?

“Instead of obsessing over spreadsheets, he said, executives should walk factory floors or interact with more customers. Innovation often doesn’t come through one breakthrough idea but a relentless focus on continuous improvement, he said.” Elon Musk


This table characterizes some contrasts that often appear in system thinking discussion.


Management style contrasts

Individuals and interactions

Following processes

Network structures


Bottom up

Top down




Client-server relationship

Self-organization of actions

Direction and coordination of actions


Many social entity thinkers promote the styles to the left. These styles tend to hinder making an enterprise-wides transformational change. (Though paradoxically, to adopt those styles, some promote making a radical transformation to how an organization works.)


How often and how big should discrete changes be? Is it better to make incremental or transformational changes?


The case for making a transformational change is best made when there is an existential threat to survival. It can work, but it requires clear leadership from the center, and a good deal of top-down command and control. It does not emerge naturally from self-organization.


Let me express some doubts about the notion that radical transformations are generally more effective than incremental development.


·       One system thinker - apparently deprecating the continual improvement motto of Lean manufacturing - is quoted as saying “the electric light did not come from the continuous improvement of candles”. However, electric light was not a singular innovation or disruptive transformation. It took many decades of continual incremental development and migration, nearly the whole of the 19th century, for electric light to replace the candle.

·       In this video Pia Macini concludes to push boundaries we must cast aside old models, and make a transformational change. Yet biological evolution, has pushed boundaries and produced amazing sustainable solutions by incremental change.

·       What to conclude from McKinsey's report that 70% of business transformations fail?  Some may argue it was because people resisted change. Others may argue the transformation was ill-conceived or impractical in the first place.

·       When Karl Marx referred to Darwin in promoting a social revolution in Russia, he misrepresented the nature of biological evolution. Many social revolutions have led to disaster or the opposite of what was intended.


A challenge for system designers today is the pace of change in the system’s biological, social or technological environment. That does not imply we do better to make radical large-scale changes. Arguably it implies the opposite, we need to be flexible, make more small-scale changes, more quickly.


EA doesn't have to be about whole-scale transformation. It can be about stimulating, prioritizing, coordinating and optimizing smaller scale incremental innovations. This is a principle of the manufacturing revolution (Kaizen), and was favored by Elon Musk in the quote above.


Taking a strategic view of change

Obviously, we should match our approach to the situation. Is everything OK, is radical transformation necessary, or do we see discrete problems and opportunities to be explored?


Is everything OK?

Suppose our business services/products appeal to customers, and we're in profit. Then, to embark on redesigning and transforming our whole business would be needlessly costly and risky. Better to prioritize things needing attention and fix or improve them incrementally.


Are there discrete problems?

Although Ackoff is often quoted as saying "Improving a part does not necessarily improve the whole", in practice, improving a part on its own is a reasonable way to improve the performance of the whole. Attending to the most costly part, and removing the largest bottleneck (one at a time) are recommended practices for improving a system. Such incremental development is a feature of biological evolution and agile system development.


Are there discrete opportunities to be explored?

Again, continuous improvement is the name of the game. EA is about planning discrete step changes. If the steps are frequent and small enough they can appear continuous. The only time to put incremental fixing of problems and making of improvements on hold is just before and during large-scale transformation.


Is radical transformation necessary?

Suppose our services/products are not selling, and we're losing money. Then we should consider substantially revising or largely replacing services/products. And then redesign and transform our enterprise to provide those different services/products. We cannot cling too hard to the idea that old businesses should be transformed to meet new demands.


The obstacle to transformative evolution is usually what some call "sunk costs". That is, the investment in people, processes, technologies, buildings and other resources that are hard to discard or change.  The history of civilization tells us that old businesses are replaced by fitter competitors and/or start ups. Sooner or later, most businesses are taken over by new management or replaced by other businesses.


Digital activity system mutation

The remarkable thing is not the difficulty we have designing complex software systems; it is that we succeed at all. Google is said to have 2 billion lines of code. It was not completely designed up from. It grew incrementally, complexifying what started out as a relatively simple system. In biology as in software, each generation of a system replaces the previous one.


The more activity systems a business digitizes, the more data is stored in digital memories, the more systems are integrated by digital messages (the more a business does what technology vendors, consultants and enterprise architects urge it to do), the larger and more complex the business application estate will be.


The vision of "simplifying" the application estate runs counter to the flow of history, the pressure to integrate systems (using ESB, ETL or RPA), the pressure to adopt new technologies, the pressure to complete agile development projects, not to mention mergers and acquisitions.


Nobody should be under the illusion that much legacy can readily be eliminated without costs and downsides. Moreover, a primary simplification technique (data store consolidation) is the very opposite of the current fashion (to make things more complex by dividing monoliths into microservices - for debatable reasons).


Applying meta system thinking to EA

The idea of meta system thinking is readily applies to business operations. EA is the higher system or entity that monitors and changes business activity systems in discrete steps, under change control. The two levels are coupled in a feedback loop.


Meta system

Feedback loop


Enterprise architecture

 ßbaseline roles and rules  

target roles and rules à

Busines activity system


EA monitors the state of a business activity system, and when some condition (say excessive cost or poor quality of service) is recognized, replaces one generation of the system by the next. The higher and lower systems are coupled in one enterprise, but neither re-organizes itself. (And to change EA, we’d need another system or entity, say business management, to monitor the success or failure of EA.)


At the level of software design, an agile system development method is a meta system. “Stand up meeting” are times when developers monitor and modify the software development system in which they work. Akin to biological evolution, inter-generational changes to the software system are small; and designer and testers eliminate changes that don't work.  Unlike biological evolution, changed systems are fed with all the electricity they need, which can lead to wasteful use of resources.


“Let’s fire all the managers”

To design a fully self-organizing activity system is impossible, because the moment it starts running its autonomous actors (agents) may change whatever was designed. What we describe as autonomous actors might immediate reorganize themselves into a hierarchy, assigning responsibility for command and control to one of their number!


However, within a given organization structure, any two organization units or individual human actors may negotiate how they interact on a bi-partisan basis. E.g. two business units, one making cans, another canning fruit, agree how many cans will be delivered and when. On a regular basis (say bi-annually) they sit down to agree an interface specification, defining and quantifying the services that one supplies to another. This is exactly the self-organizing principle of a company called Morning Star.


“Every year, the 23 business units negotiate customer-supplier agreements [interface specifications] with one another. And each employee negotiates a Colleague Letter of Understanding [another interface specification] with associates most affected by his or her work. “As a colleague, I agree to provide this report to you, or load these containers into a truck, or operate a piece of equipment in a certain fashion.” [i.e. I agree to provide this collection of services]. This [interface specification] covers as many as 30 activity areas and spells out all the relevant performance metrics.” <>


I recommend you read the Harvard Business Review article in which Gary Hamel talks about Morning Star.


I guess (don’t know) that the parties in Morning Star agree service contracts (in customer-supplier agreements and in letters of understanding) using the “pull” principle of Lean manufacturing, meaning they are defined backwards from the end of the supply chain to the start.


Of course, it is not true that Morning Star fired all the managers. And even in Morning Star, there may be a role for EA in optimising and extending the creation and uses of information to support and enable business processes.

On tackling wicked problems

The original paper on wicked problems, defined a wicked problem in terms of ten points. In short:

·       It has conflicting requirements, no ideal solution and no perfect answer.

·       There are trade-offs to be made between competing goals and design options.

·       The possible solutions can’t be called good or bad, but might be placed on a scale between those extremes.


In practice, most of these points apply to most human activity problems we are asked to address - small as well as large.


How to define and "solve" wicked problems social entities or situations? The first step is not to model a particular system; it is to do some meta system thinking.


This video introduces General Morphological Analysis as a tool to scope a problem and define solution options. GMA is a kind of meta system (see above).

·        The state variables of the meta system are called dimensions.

·        The actors are a pool of experts, and a facilitator.

·        The activities are to populate the dimensions with options and analyse them in various ways.


GMA prompts a panel of actors to think, question and consider options in a systematic way. The video suggests these actors are supported and enabled by a software tool. Typically, there are three two-day workshops with 6 or 7 carefully selected and heterogeneous experts. They define the critical dimensions of the problem (cf. the state variables of an activity system). In each dimension, they define a range of options (cf. values for the variable values).


The experts examine each pair of dimensions to decide if it is possible or impossible. Rejecting impossible permutations narrows the permutations to be considered. The many remaining permutations are akin to Ashby’s measure of a system's “variety”. Fixing the choice between options in one or more critical dimensions further narrows the possible option permutations.


This exhaustive and exhausting analysis of (potentially hundreds or thousands of options) can identify unexpectedly viable and non-viable solutions. Assessment of the most favored options is done in whatever empirical, logical, normative (social) ways can be applied.


Further, proceeding to a solution, we might be able to use casual network analysis. Or else Thomas Saaty’s analytic hierarchy process (AHP). And eventually, apply system theory to design a chosen business activity system.

Conclusions and remarks

This chapter addresses what it takes for an enterprise to be adaptable, including several interpretations of self-organization, and a way of approaching “wicked problems”.