Vote leave again

2 June 2016


Churchill salute

14 April 2016


Use of Reason

12 April 2016


Need more bullets

12 April 2016



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” (

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.


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

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

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 (– 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” ( 

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

Enterprise Architecture, as an activity in organisations and ‘discipline of praxis’, is about producing rigorous, explicit models of the enterprise to be used in the organisation’s decision-making processes. Its purpose is to enable the organisation to make better decisions about where to invest its precious resources to change the enterprise for the better.  [Note: The “Enterprise” and the “Organisation” are different things – but the differences between them are unimportant for this article.] 

That investment might be in new or improved IT systems, or new products and production processes – or in new or improved capabilities in the organisation.

An enterprise – any enterprise – has many facets or aspects to it – social and technical – and there are many ways of metaphorically looking at it. In academic jargon, there are several (cognitive, theoretical) ‘lenses’ that might be used to analyse an enterprise. If Enterprise Architecture is done well, several of those lenses will be used and each analysis will contribute something valuable to the models produced. 

The job of the Enterprise Architecture team is to pull together these different analyses, through different lenses, into a coherent whole that can be used, by various people throughout the enterprise, to plot and plan the enterprise’s evolution.

The single most popular, and oldest, ‘lens’ through which people have analysed enterprises might be called “Functional Decomposition”. This is about examining the activities in the enterprise as “black boxes” – focussing only on what it is the enterprise, or some “Organisational Unit” within the enterprise, does – and deliberately ignoring the how of its doingIt is based on the very old tradition of “the Division of Labour” or “Functional Specialisation”, which many people trace back to the very early 20th Century and the management thinking of F.W.Taylor. Others, however, would trace it back even further – and there is no doubt Adam Smith presented a clear idea of it in his “Wealth of Nations” [Book 1, Chapter 1] in 1776 with his “pin-making” example. [Yes, Enterprise Architecture was being done over 200 years ago – but of course it wasn’t called “Enterprise Architecture” then.]

Functional decomposition – and the structuring an enterprise around the functional decomposition – remains popular with management teams and enterprise architects even today. Indeed, it has become so ubiquitous, so commonplace and habitual that managements may even do it unconsciously – without thinking. Nobody would even think to question the existence of a separate “Accounting Function” – and organisational division or unit dedicated to carrying out that function. 

The traditional organisational structure – Operations, Marketing, Finance etc. –  is a reflection of the high-level functional decomposition of the arbitrary (commercial) enterprise. [This is one reason why novice enterprise architects and inexperienced managers sometimes mistake ‘function’ for organisation or vice versa – and sometimes don’t fully appreciate ‘function’ in abstract terms, or produce an organisational model when asked to produce a functional one.] 

Almost every enterprise architecture description would necessarily include a functional (and organisational) perspective. There may even be a view dedicated to just the functional decomposition hierarchy,depending on the methodology used. In the analysis of modern enterprises the functional view is often traced through into the technical architecture – in the functions of software components, or robots, or other machines – as well as the teams of people. The relationship between functions and organisational units may be described by an “interaction matrix” or “dependency matrix” – again depending on the methodology used. [ This is, of course, not possible if managers fail to distinguish properly between functions and organisations (units) – which is one reason for adopting the method. ]

However, most enterprise architecture teams would argue that a functional view alone, or even a functional and organisational view, is far from enough. A functional decomposition and an organisational decomposition are necessary parts of an enterprise analysis and model – but not sufficient to enable rational decision-making instead of unconscious conformity to an historic model. Others argue that “… executives need to re-think the concepts through which they have classically viewed the firm. 

Describing the organization as a set of sequentially ordered parts no longer captures its essential properties. In its place they need to use a dynamic and integrated model …” [Laszlo, E & Laszlo, C. in “The Insight Edge – An Introduction to the Theory and Practice of Evolutionary Management”]. An enterprise architecture model?

A fuller and richer enterprise architecture model would include some other abstract aspects of the enterprise (than functions). An important, related lens would be the capabilities of the enterprise – things the enterprise, or parts of it, are able to do. TOGAF – The Open Group Architecture Framework – DODAF – the [US] Department of DefenseArchitecture Framework and MODAF – the [UK] Ministry of Defence Architecture Framework, among others, include notions of “Capability”, “Capability Architecture” and “Capability-based Planning”. 

This capability ‘lens’ is also not new – though not quite as old as functional decomposition. About 20 years ago it developed from the “Resource-Based View of the Firm (RBVF)” – and saw firms, commercial enterprises, as distinguished by their portfolio of capabilities rather than the assets they happened to own or control. 

Ironically this was about the same time that Enterprise Architecture as a separate, distinct discipline was also being developed. Spewak published his seminal book on “Enterprise Architecture Planning” in 1992.

Dorothy Leonard (later Leonard-Barton) in her book “Wellsprings of Knowledge” produced a taxonomy of capabilities, and what Enterprise Architects would now call a Reference Model for a capability that asserts it comprises Physical Systems, Managerial Systems, Skills and Knowledge and Values – and is surrounded by a ‘learning system’ that makes the capability dynamic – change over time[Contrary to the common misconception, not all EA Reference Models are reference models for technological systems.] She also warned about “Core Capabilities” turning into “Core Rigidities”. 

A couple of years later David Teece and colleagues developed the “Dynamic Capabilities Theory” – as a model of how enterprises innovate and adapt – and ensure their competitive survival. About the same time the Oxford economist John Kay developed his “Distinctive Capabilities Theory” published in his “Foundations of Corporate Success” book

This theory argues that what sets an enterprise apart from would-be copy-cats, and makes it successful, is its “distinctive capabilities” – and these derive from three sources: 

1) Architecture,

2) Reputation and 

3) Innovation. 

Kay’s Distinctive Capabilities Theory recommends itself as a method to formulate strategy   strategy that if successfully executed would lead to sustainable corporate success.

So it would seem that identifying the enterprises distinctive capabilities, its core capabilities, its enabling and supplemental capabilities and actively managing their development individually and as a portfolio is really important to successful execution of the strategy. 

An explicit Enterprise Architecture model, featuring As-Is, To-Be and Transitional Capabilities Architecture – linked to and coherent with other architecture models like Functional and Organisational – is therefore an essential product of an Enterprise Architecture initiative. 

If your Enterprise Architecture team is not producing those models, not doing those analyses, not using those lenses – are they doing something of less value to the enterprise? Why?

Ian Glossop, Enterprise Architect.

(Copyright – September 2014 – Ian Glossop, Glossop-Mallard Consulting Ltd.)

%d bloggers like this: