Enterprise Architecture and Systems Thinking

Enterprise Architecture is not the only, nor even the first, discipline to take a model-based, methodological approach to the change and development of enterprises.

Key Takeaway

“Systems Thinking” is a significant part of the Enterprise Architect’s armoury of methods and methodologies.

Enterprise Architecture is a young, immature discipline that produces models to guide the development of an enterprise. It is generally recognised to date back to the late 1980s or early 1990s and to the work of Zachman, Spewak and others though it really took off in the late 1990s and early years of the 21st Century.

A model-based methodological approach

But methodological disciplines do not emerge complete and well-formed from nowhere. Spewak’s Enterprise Architecture Planning, for example, builds on and incorporates some of Michael Porter’s thinking on the analysis of enterprises and industries. (Sadly, some more recent EA methodologies seem to have forgotten about this very solid foundation.)


Featured Course
The most widely adopted Enterprise Architecture (EA) framework and methodology today!



“Systems Thinking” may be considered Enterprise Architecture’s older, and perhaps somewhat wiser, big brother. “Systems Thinking” as a very broad ‘tradition’ in analysis and model-building dates back to the 1960s although its origins lie in the focus on efficiency and effectiveness of post-WWII industrial enterprises made possible by new technologies.

It is, I think, no coincidence that this was a time of great social, economic and technological change – that demanded new ways of looking at the world, and the linkages between changes happening in it, and the new possibilities opened up by the changes.

Today, several renowned enterprise architects would identify “Systems Thinking” as the proper theoretical basis for the practice of Enterprise Architecture. For example, James LaPalme and Donald de Guerre identify Enterprise Architecture as “Open Socio-Technical Systems Design” – a particular application of Systems Thinking. (Lapalme, J. & de Guerre, D.W., (2013), “An Open Socio-Technical Systems Approach to Enterprise Architecture” in Gøtze, J & Jensen-Waud, “Beyond Alignment: Applying Systems Thinking in Architecting Enterprises”)

Systems Thinking

With hindsight developed in recent years within the Systems Thinking tradition, it can be seen as comprising three distinct broad categories of methodology or theory:

  • “Traditional Systems Engineering” (TSE) – also loosely known as “Hard Systems (Thinking)” (HST);
  • “Soft Systems (Thinking)” (SST); and
  • “Critical Systems Thinking” (CST).

Gerald Midgely identifies these categories as the first, second and third waves of “Systems Thinking” (Midgley, G., (2000), “Systemic Intervention: Philosophy, Methodology, and Practice”, Kluwer Academic / Plenum Publishing – from the Contemporary Systems Thinking series.) and very roughly, they cover the periods 1965-1980, 1980-1995 and 1995-present respectively.

There are many variations and ‘subdisciplines’ within these broad categories – like Cybernetics, System Dynamics, and Critical Systems Heuristics and so on – but before outlining the key features of each category, we need a little more clarity about terms like “System”, “Methodology” and “Method” – as these words have been so mis-used in recent years as to lose their precise meanings.

What is a “System”?

A system is any identifiable collection of parts or components that interact with each other and with things that are not “in the system”. This simple idea has some profound consequences. To be counted in or out of the system means the parts are defined by being an identifiable whole or unity in their own right. Thus a part can be anything – and it does not necessarily have to be a material thing.

So it makes sense to talk of “knowledge systems”, “learning systems”, “information systems”, “social systems” and “organisational systems” etc. – all of which may feature components that are not material objects.

Since individual people and organised groups of people are identifiable as wholes they also may be components in systems – hence social systems.

Even physical systems may feature elements that are not material objects – magnetic fields, energy, physical space or spacetime, other sorts of fields, information, and ‘causality’.

Since systems are themselves identifiable wholes, they may also be parts of ‘larger’ (in some sense) systems. This leads immediately to notions of relative systems hierarchy and strata, or layers, with subsystems and families of systems – and composition/decomposition, specialisation/generalisation and the ‘black-box’ and ‘white-box’ systems.

Since individual people and organised groups of people are identifiable as wholes they also may be components in systems – hence social systems. As components may be counted in or out of “the system” there is an ‘analytical boundary’ between the system, as modelled, and the environment.

Since analysis, or observation, is the product of theory-based cognition and empirical perception, there may be a ‘real-world’ boundary around the system components – or it may be the boundary is only in people’s thinking. The pattern of interactions within the system, or between the system and its environment, may endure over time – which leads to ideas of structure in and between systems.

Or the interactions between components and systems may involve the fairly rapid movement of material, energy or information – which leads to ideas about system dynamics. Hence the very simple, general notion of a “system”, with a proper definition, bootstraps or kickstarts a whole theoretical framework for looking at the world – or bits of the world labelled as “enterprises”.

One key observation from this way of looking at the world: the real-world is full of thousands or millions of different systems and individual parts may be components in many systems concurrently.

‘Natural Systems’ emerge from the plethora of interactions between components without any conscious intervention but artificial systems emerge when purpose and design are inscribed into the relationships between components by human agency – these are ‘Engineered Systems’. (So the general notion of “System” – that is the one underpinning Enterprise Architecture as a discipline that holistically models the components and relationships in enterprises – is very different from the narrow notion of “Computer System”, “Software System” or “IT System” – that underpins IT Engineering – though consistent with it.]

What is/are “Method(s)”?

A method is a collection of related actions engineered to achieve a purpose. The actions may be :-

  • cognitive-theoretical actions like identifying and labelling things, putting things in categories, identifying types of things, describing the relations between things, assigning purpose to things etc; or
  • practical-physical actions like moving something from one place to another, changing the shape or configuration of some thing or system, initiating a chemical or physical reaction (like putting a match to the bonfire or flipping an electrical switch) and so on.

The actions are related to each other in time and space. They may be in a simple linear sequence or an iterative loop or may be a set of contingent pattern-action ‘reactions’ – lists of “ if this pattern, event or perception should occur then take that action”.

The key thing about methods is that they are tested and known to work (proven).

Methods may be applied to any human purpose, and in Enterprise Architecture, that purpose is to produce a relevant model to direct the change. Methods comprising cognitive-theoretical actions are generally called “analytical methods” whereas those concerned with making change in the real world, including constructing shared, explicit models, are generally “methods of synthesis”.

Academics may confine themselves to ‘pure’ (uninformed-by-practice) analysis but in real-world practice analysis and synthesis are invariably mixed and so are their methods. We continually iterate and alternate between analysis and synthesis (or thinking and doing).

The key thing about methods is that they are tested and known to work (proven). Use the method and you get the result you want, assuming an appropriate level of skill and judgement is used in applying the methods. Don’t use methods and you risk wasting your time, effort and resources and falling short of objectives and expectations. Note also the significant relationship between “Method” and “Process” – each implies the other.

As to “Methdology”, I agree with Midgley: “a methodology is the set of theoretical ideas that justifies the use of particular method or methods” – and it should be carefully distinguished from method or methods (see Chapter 5 of Midgley’s book.) In passing, it may be observed that many so-called methodologies available to the prospective practical interventionist or change agent (such as an Enterprise Architect) are somewhat weak in the theory that justifies their methods.

Turning back to “Systems Thinking”, TSE or Hard Systems Thinking is founded in the philosophical ideas of reductive realism and positivism: that complex phenomena can be understood by being broken down into the behaviours of individual components and their relationships and interactions.

Traditional Systems Engineering

TSE assumes that components obey a strict deterministic, linear causality – that if certain “initial conditions” occur, then the prescribed outcomes inevitably follow. The traditional method of “Functional Decomposition”, widely used in Enterprise Architecture, is firmly in the TSE camp. It may even be at the heart of it ironically since “function” is a human construction and non-material attribute imparted to components and systems (and not something derived from the teleology-free material world).

Traditional Systems Engineering may be thought of as mapping straightforwardly onto the technological systems analysis part of Enterprise Architecture. The problem with TSE (alone) is that it does not apply to people intensive systems, which do not follow such a mechanistic causality.

Soft Systems Thinking

This realisation led to the development of Soft Systems Thinking – which focuses its attention on the systemic and systematic way in which the ideas of different stakeholders in a “problem-situation” – ie a situation that at least some stakeholders want to change – are brought together (with the intention of achieving some consensus about change actions).

In this sense, Soft Systems Thinking is more attuned to sociological, not technological systems, and leans towards a “social constructivist” philosophy, like that underpinning the Social Construction Of Technology theory.

SST methods and methodologies include Strategic Assumption Surfacing and Testing (SAST), Ackoff’s Interactive Planning (IP) and Soft Systems Methodology (SSM). Not only do SST methods map onto Enterprise Architecture’s methods and techniques for the analysis and synthesis of social systems in an enterprise, they also inform and illuminate EA methodology itself.

SSM provides a passable and somewhat justified model of social construction of enterprise models – that is of Enterprise Architecture. One important methodology that may be counted as a part of the second wave of Systems Thinking is Socio-Technical Systems (STS) theory, which bridges the social and the technical aspects of enterprises.

Critical Systems Thinking

Critical Systems Thinking (CST), the third wave, is about applying the right sorts of methods of systems analysis (and synthesis) in the right contexts (or change-situations). It is “critical” in two senses:

  1. it critically examines the assumptions and ideas behind the methods and methdologies; and
  2. it involves critique and “critical thinking” about the situation and the different understandings of various stakeholders.

CST is therefore inherently “multimethodological”. Arguably the best-known of the CST methodologies is the System-of-Systems Methodology (SOSM) developed by Jackson, Keys, Flood and others. (http://www.bcs.org/upload/pdf/steve-clarke-paper.pdf)

In essence, it seeks to apply HST to hard systems problems and SST to soft ones while challenging the presumptions of powerful stakeholders. However, the term “System-Of-Systems” (S-O-S) needs to be used carefully. In one context, it may refer to systems of systemic methods – as in Jackson et al.’s SOSM. Yet in another, it may refer to the stratified and partitioned reality of many sociological and technological, natural and engineered systems with shared components interacting with each other.

Some enterprise architects hold the conviction that Enterprise Architecture is synonymous with Enterprise Systems Engineering such as James Martin [ See “Transforming the Enterprise Using a Systems Approach” in Gøtze, J & Jensen-Waud, “Beyond Alignment: Applying Systems Thinking in Architecting Enterprises”.

In my view, it depends what you mean by “Enterprise Systems Engineering”. If you mean Traditional Systems Engineering applied at an enterprise scale and scope, then I’d have to disagree. That was tried before, it didn’t work then, it doesn’t work now and the world has moved on.

If, on the other hand, you mean something more like Enterprise System-Of-Systems Engineering, with both critical multimethodological and engineered enterprise senses of S-O-S, then I am in complete agreement. For this reason, a broad grasp of several strands and sub-disciplines of “Systems Thinking” is an essential and significant part of the Enterprise Architect’s armoury of methods and methodologies. If your EA Team doesn’t have at least one person who has studied Systems Thinking, are you missing out on good, methodological practice?

If you think this post is interesting, please help spread the word – share this!

Sign up to our newsletter for free

Headline image Perspective courtesy Ilker@freeimages.com

There are no comments

Add yours

This site uses Akismet to reduce spam. Learn how your comment data is processed.

freshmail.com powered your email marketing