Enterprise Architecture and Systems Thinking – by Ian Glossop

20 March 2015

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 the work of ZachmanSpewak and others though it really took-off in the late 1990s and early years of the 21st Century. 


But methodological disciplines do not emerge complete and well-formed  from nowhereSpewak’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.]


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. 


“Systems Thinking

“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” (http://www.amazon.com/Beyond-Alignment-Applying-Architecting-Enterprises/dp/184890116X/ref=sr_1_1?s=books&ie=UTF8&qid=1415365247&sr=1-1&keywords=Gotze+Beyond+Alignment)


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. 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 or 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 maybe a set of contingent pattern-action ‘reactions’ – lists of “ if this pattern, event or perception should occur then take that action”. 


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.


Methodology

As to “Methodology”, 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.]


“Systems Thinking”

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


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” – i.e. 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. [http://en.wikipedia.org/wiki/Social_construction_of_technology]. 


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 Architectures 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 (CST), the third wave, is about applying the right sorts of methods of systems analysis (and  synthesisin the right contexts (or change-situations).  


It is “critical” in two senses: 1) it examines the assumptions and ideas behind the methods and 2) it involves critique and “critical thinking” about the situation and the methodologies that may be chosen from. CST is therefore inherently “multimethodological”.


“System of Systems”

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

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 (http://en.wikipedia.org/wiki/Enterprise_systems_engineering– e.g.James Martin 

[ See “Transforming the Enterprise Using a Systems Approach” in Gøtze, J & Jensen-Waud, “Beyond Alignment: Applying Systems Thinking in Architecting Enterprises” (http://www.amazon.com/Beyond-Alignment-Applying-Architecting-Enterprises/dp/184890116X/ref=sr_1_1?s=books&ie=UTF8&qid=1415365247&sr=1-1&keywords=Gotze+Beyond+Alignment). 


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 (http://en.wikipedia.org/wiki/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, in my view a broad grasp of several strands and subdisciplines 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?


© Ian Glossop, Glossop Mallard Consulting Ltd., 2014. (November)


Advertisements

3 Responses to “Enterprise Architecture and Systems Thinking – by Ian Glossop”

  1. wikitect Says:

    Aagh!

    A system isn’t just a collection of interacting stuff. It’s something where there is emergent behaviour (usually expressed as “the whole is more than the sum of the parts”. This implies some feed-forward/feedback interactions so it’s not a simple collection.

    A system is an abstract concept – the things that form it have a physical presence. Systems theory normally excludes physics at a small level (albeit at a bigger level some of these effects manifest themselves). Where you choose to draw the boundary is arbitrary providing the things as a whole satisfies the tests for a system.

    ‘System” in this sense is not a synonym for method / methodology (e.g. classification system). It has quite a specific meaning.

    You skip what a system of systems is. Many systems have systems as parts of the bigger system but this does not make the whole a system of systems (so it isn’t a compositional thing). A system of systems is formed from systems that have an independent existence. Ignoring the hype that is a result of the ease of attracting funding, fame etc. a system of systems is still itself a system, exhibits emergence etc. The only reason we systems engineers pay attention to these is that there is sometimes a SOS where it is difficult or impossible to apply control to the whole (little or no control authority). Sometimes SOSs are unintentionally formed and this may be a problem. A controllable/manageable SOS is no more difficult and needs no more techniques than does a ‘straight’ system. Any potentially uncontrollable system is a problem whether a SOS or not.

    In this sense therefore it’s hard to imagine that an enterprise is a system of systems. It is also amenable to ‘straight’ system engineering despite what you say. Try to get a SOS advocate to identify what techniques that they would use that wouldn’t be used on a system. Emperor’s new clothes I fear…

    Whilst there ought to be a lot of overlap between systems-thinking and enterprise architecture because in both cases you’re trying to identify and describe relationships, boundaries and behaviours you’d be hard-pressed to recognise this in a lot of EA output because the relationships are deliberately hidden (and the types as well). A box that is visibly inside another box is no use to man nor beast in systems-thinking because it tells you nothing about what the relationship is – it’s in the mind of the beholder and therefore at best inconsistent. Much of the EA output is focussed on IT/IS (a historical accident in terms of the location of the ‘priesthood’) and seems to be predicated on language designed to make it almost unintelligible to the rest of the organisation that it’s trying to sell itself to.

    Systems engineering does apply to soft systems involving people and has been used very successfully for the last 30 or 40 years so where you’ve got the notion that it doesn’t / can’t is a mystery. A lot of it is based on mathematical modelling which is not mechanistic at all.


  2. I agree with you in applying system thinking in EA. I applied some of system thinking principles in Enterprise Evolver app (htp://www.enterpriseevolver.com/)

  3. grunger16 Says:

    @ Wikitect

    I mostly agree with you.

    I didn’t want to get into a debate about emergence. While I would consider myself to be philosophically pre-disposed towards emergence, I would be wary of making it a defining characteristic of systems – I would assert that there can be systems that do not exhibit emergent behaviours (or phenomena more generally) – just straightforward simple causality.

    That a system is “an abstract concept” (and by implication has no ‘objective’ reality), is I think I think an article of faith for those with a subjectivist philosophical pre-disposition. For those of us with a Critical Realist predisposition systems do have a sort of objective reality; and I would cite the Criminal Justice System as a very real system that has behaviours and causal influences in the world – and an objective reality. [And incidentally, while it might be technically possible to be a Critical Realist without also being an Emergentist – I think I’d find it too intellectually contrived to be tenable.]

    I tried to allude to the two concepts of a SoS – explicitly mentioning the Mike Jackson, SOSM concept and alluding to the other concept associated with Rouse and the Handbook of Systems Engineering. I disagree that in general an SoS requires no more techniques than a “straight system” – but maybe that is because manageable/controllable SoSs are only a small subset of SoSs in general and the interesting ones are the ones where “control” techniques don’t work. I would observe systems (SoSs) that exhibit a) chaotic behaviour – e.g. Weather Systems and b) systems that exhibit what your might call “psycho-social anti-coercive behaviour” (echoing Mike Jackson’s “coercive systems” category) of which the UK political systems are very prominent examples at the moment. The problem is the flawed concept of “control”. As a technique applied to such systems – beyond Traditional Systems Engineering techiques – I would observe complex systems modelling and data-intensive simulation techniques – including Monte Carlo simulation.

    I agree with much of your critique of EA practice – but to suggest that it is “deliberate” is too strong and I don’t think right. It is just that many EA methodologies don’t push the architects into being explicit and precise about the relationships in their formal models and many so-called architects are naïve and don’t realise the ambiguity in their models. Good techniques (methods) applied by experienced, knowledge people don’t produce such poor-quality output. It is just accidents of analysis made by novices and poorly thought-through methods – not deliberate.

    I find it very easy to imaging an organisation as a SoS – not hard at all. And I find it easy to imagine groups of people in organisations not amenable to “control” as per Traditional Systems Engineering. Mike Jackson’s coercive systems again. Personally I don’t want to even try to treat people like machines with control inputs and a feedback control loop – not the right model for (predominately soft) social systems.

    Lastly I was just following Checkland and Jackson in distinguishing “Traditional Systems Engineering” from “Modern Systems Engineering” – and yes Checkland, Wilson et al developed their Soft Systems approach in the 1970s and it has been successfully applied several times since. However, for many organisations and people – especially it seems people in the IT world – “Systems Engineering” is synonymous with Traditional (hard) Systems Engineering – and neglects the softer aspects – and this lives on in much EA practice. Maybe it is the baggage that the word “Engineering” carries for many people. This distinction is well recognised in the academic literature – and worth emphasising if your business is the engineering of social systems – ie organisations or enterprises. Your should use the Soft Systems methods, not just the hard systems type analyses.


Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: