The Viable System Model is the missing theory behind Enterprise Architecture

19 May 2011

I am currently involved with the EAST group (an outreach group of SCiO ) which is looking at the overlap between Enterprise Architecture and System Thinking, and in particular the Viable System Model (VSM).

The Viable System Model has been around for many years, coming out of Stafford Beer’s work

This diagram looks complex at first but you can also read a very accessible description of the Viable System Model at and at

An excellent book to read is Patrick Hoverstadt’s book  ‘Fractal Organization: Creating Sustainable Organizations with the Viable System Model’  See

But what is the Viable System Model?

The Viable System Model is a recursive view of five main systems within an organisation.

The word ‘System’ here doesn’t mean an IT system or an information system but has the more generic meaning of the word ‘System’. See

Those five systems are concerned with the following functions and capabilities:

System 5 Policy, ultimate authority, identity.
System 4 Adaptation, forward planning, strategy.
System 3 Internal regulation, optimisation, synergy.
System 2 Conflict resolution, stability.
System 1 Primary activities.

System 1 systems within an organisation are realised by those organisation units that actually make products, deliver business services and create value.

System 2 systems are those organisation units that provide the coordination functions.

System 3 systems are those that provide the audit and operational control functions.

System 4 systems are those that look forward to the future and the external environment.

System 5 systems provide the strategy and business direction.

The Viable System Model is recursive so that the same five systems appear at all levels within an organisation, but it’s easy to see equivalent VSM systems at various levels in an organisation.

At at the top level it is possible to see that the Executive Board is a level 5 system, the general management are mainly level 3 systems, the system 2’s are the programme managers, project managers and solution architects. The system 1’s are the operational service delivery units and project teams.

Where does that leave Enterprise Architects? Well the Enterprise Architect function is essential a system 4 system with it’s focus on strategic planning for the long terms view and creation of roadmaps of strategic initiatives.

The strategic Enterprise Architects (system 4) with their long term, external and strategic focus work in co-operation with the Solution Architects (system 3) with their immediate operational, internal, lean, design and delivery focus.

It’s clear to see with our Viable System Model lens that solution architects and enterprise architects are not doing the same job but a completely different job.

From an Architecture Continuum perspective (TOGAF9 then the Viable System Model is an example of a generic Foundation Architecture. and a thus a key architecture to reuse when designing organisation specific target enterprise architectures.

The SCiO group has developed the SCiO Organisational Maturity Model which is based on the Viable System Model.

This can be used for assessing the strengths and weaknesses in your enterprise, looking at how efficiently it is working today, both in the immediate operational perspective but aslo the log term viability of your enterprise in the face of changing external market and business environment.

The on-line questionnaire for the SCiO Organisational Maturity Model addresses six aspects of the Viable System Model:

  • Operations
  • Co-ordination
  • Resource and Performance Delivery
  • Monitoring
  • Development
  • Managing strategy

The outcomes are expressed in terms of  a measure of maturity across those six dimensions and a diagnosis of which Archetypes (i.e VSM anti-patterns) apply to your enterprise and which need to be addressed.

Unlike Lean manufacturing which only focuses on operational efficiencies in the the lowest level System 1, System 2 and System 3 systems within an organisation, the Viable System Model looks at the whole enterprise from a recursive perspective which is more sound and holistic.

In some ways it is surprising that it hasn’t yet reached a tipping point within organisations or their enterprise architects. Maybe this is because everyone is too focused on the day to day need for operational efficiency and approaches such as Lean Manufacturing ( and forgets about planning for the future. This is the difference between being reactive and proactive.

Further reading at

and the excellent book: The Service-oriented Enterprise by Tom Graves,

The Service-Oriented Enterprise: Enterprise Architecture and Viable Services

The next time you are challenged on the purpose and value of Enterprise Architecture, then answer that it’s the difference between the external and future oriented perspective of the VSM system 4 as opposed to the inside and now, operational efficiency perspective of system 3 and service delivery perspectives of  system 1 and 2.

As a system 4 system, the enterprise architecture function focuses on:

  • Supporting the business strategy developed by system 5
  • Analysing strategic change initiatives
  • Planning and creating strategic road-maps
  • Scenario analysis
  • Assessment of future risk, agility and viability of the enterprise
  • Coordinating with system 3 systems (i.e. portfolio and programme management, project management and solutions architecture)
  • Governing the realisation of those strategic changes and development of new business capabilities.

The more one looks at the Viable System Model, the more it looks like the unifying theory behind Enterprise Architecture.

7 Responses to “The Viable System Model is the missing theory behind Enterprise Architecture”

  1. Nic Plum Says:

    Hi, Adrian – interesting to see the comparison.

    Not sure that the 5 systems can be placed in a hierarchy (‘level …’) as has been done since a lot of what systems thinking is concerned with is avoiding such hierarchical break-down (and focussing on the dependencies/interactions and integration i.e. the whole. As a result you cannot sum the functions in a part of a system to obtain the functions of the system so formed – this is what emergence is all about. Conversely, if you can it isn’t a system (it doesn’t exhibit emergent behaviour).

  2. Hi Adrian,

    It is an interesting blog post and thanks for the reference.

    Though I disagree with some of the semantics e.g. you mention that the enterprise architect is on the level of strategic planning and as such the concept of strategic planning is something that I associate with the “Planning School” that Henry Mintzberg et al* are criticizing for articulating plans for the sake of plans and not for developing the enterprise in any particular way. On the other hand even a bad (bad as in poor quality) plan is better than none, or that is what Karl Weick would have said.

    But as I said in the start of this comment I think it is a good blog post.

    Best regards,
    Peter Flemming Teunissen Sjoelin

    * Mintzberg et al. 2009, Strategy Safari.

  3. Tom Graves Says:

    Hi Adrian – thanks for the reference to my book! :-)

    Couple of comments. One is that it’s important not to gloss over System-3* (sporadic audit) or the algedonic-feedback mechanisms, as shown in Beer’s original diagram above, otherwise there’s a real risk of reverting to a standard common-and-control Taylorist-style view of the enterprise. Crucially, System-3* reports back to the level above, bypassing part of the hierarchical nesting of systems; and the algedonic-feedback must by allowed to bypass _any_ level, able to go straight from the base to the top if necessary. And ultimately _everything_ is also a ‘System-1’, in that it delivers a service: that’s how the nesting works.

    Strongly agree that the focus of EA is System-4, though also with a strong mix of System-5 (overall purpose) and System-2 (coordination – especially coordination of change). Note too that this also means that EA needs to be understood as a business-function that is distributed throughout every part of the enterprise – not solely maintained by a separate clique of ‘experts’.

  4. Stephen Davies Says:

    Hi Adrian,

    Tom’s comment is right on the mark. The System 3* role is critical particularly when it is controlling the rate of adoption of new capabilities that were planned in System 4 and will be implemented in Systems 3/2/1 as new value producing operations in the here and now. VSM gives us a great place to position the various functions of an EA but the span of organizational relevance for an EA is too large to constrain to System 4 only.

    VSM is one of the most powerful general system lenses that currently exists and provides the context for deep system’s thinking skills. Stafford’s work deserves far more attention, particularly from the Architecture community. If you want to go further, you should check out his book Beyond Dispute and the invention of Team Syntegrity. This large group process methodology (true social technology) beats Open Space into a cocked hat.


  5. Hi Stephen – You mention Team Syntegrity. I am the systems architect at – we are implementing Team Syntegrity in a form adapted to the online medium so people do not have to meet for a 3-4 day face to face retreat to be able to deliberate difficult or multi-spoked issues. We are in beta test mode right now.

    Beer saw Team Syntegrity as a tool for use in System 4 of the VSM. He also made many references that VSM was intended to be a democratic organizational structure, and that the various systems were not intended to form a hierarchical structure. Beer described the VSM in his books “Brain of the Firm” and “Heart of the Enterprise.”

    • Stephen Davies Says:

      Hi Jean-Daniel,

      Thanks for letting me know about your project to adapt Team Syntegrity to an online medium. I’m aware of several attempts to do this previously and would be interested to learn how you are solving some of the challenges presented by the electronic channel. Any chance you could afford the time for a phone call?

      Stafford actually intended Team Syntegrity to be used for the high variety of interactions needed across what he called the System 3-4 homestat. This VSM nexus mediates the ongoing dialogue between the evolutionary strategy of the organization as envisioned by System 4 and the impact of that strategy on the current System 3/2/1 value producing operations. I have designed and delivered literally hundreds of Team Syntegrity events, many of them strategy development events, and could point you towards some of the other resources in the community that may be of assistance to you.



  6. Hi Stephen – sure thing, I’d like to connect. Email me at jdcusin at

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: