Enterprise Architecture, Dynamic and Distinctive Capabilities – by Ian Glossop

16 March 2015

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

Advertisements

3 Responses to “Enterprise Architecture, Dynamic and Distinctive Capabilities – by Ian Glossop”

  1. wikitect Says:

    Adrian – some of the potential confusion might be because ‘function’ is often used as a synonym / reference to part of an organisation (which is therefore also an organisation). If someone refers to the “Engineering Function” they’re more likely referring to that part of the Organisation that is responsible for ‘Engineering’. The word ‘function’ has at least two different meanings. Having a Marketing Function [type=organisation] that performs a function [type = Function] is therefore just asking for trouble!

    The other advantage of thinking in capabilities is that you can distinguish between what the enterprise wants to be able to do and what it is able to do at any point in time by virtue of the various deployed systems that contribute to the capabilities i.e. describe a capability gap.

    Another benefit is then being able to select a capability and identify what systems contribute to that capability. It helps identify common threads e.g. almost every police-like enterprise could be described in terms of the capabilities ‘Prevent’, ‘Pursue’, ‘Prevent’ (which is why they feature in the UK counter terrorism strategy – CONTEST – https://www.gov.uk/government/publications/counter-terrorism-strategy-contest).

    … and of course TRAK (http://sf.net/p/trak) also has ‘Enterprise, requires Capability’, ‘Enterprise aspires to Enterprise Goal requires Capability’ .. to which you can attach claims and a supporting structured argument [Claim, Argument, Evidence] if you so wish.


    • It’s better to be as specific as possible because people will often misuse terms.
      Function is frequently misused and misunderstood.
      I am always careful to distinguish between and organisation unit (Business Actor) and a business function that they perform. I have come across many examples of an organisation unit performing more than 1 business function, and indeed different organisation units carrying out the same Business Function (perhaps only distinguished by Channel (Business interface) being used). There is a many to many relationship between these concepts.

      I also find that it’s easy for people to confuse a Business Function with a Business Capability. Business Capabilities should be defined and named in terms of their outcome or value provided, whereas a Business Function is a type of high level generic activity (see ArchiMate).

      Both MODAF and TRAK have usefully popularised the concept of a capability. I usually use Business Function and Business Capability in the same model.

  2. glomal Says:

    I think we are all ‘on the same page’. Organising enterprises on the basis of ‘Functional Decomposition’ is so common, such an unconscious, assumed paradigm, that people do refer to the Organisation Unit – “Engineering” – using the name of the Function(s) which it carries out – “Engineering”.

    This is simultaneously a source of confusion (do they mean the function or the organisation?) and an inhibitor to thinking. You cannot think about re-allocation of functional responsibilities and accountabilities – or even spot unnecessary duplication – across organisations unless you properly distinguish Functions from Organisations.

    [This is] One reason for using proper models supported by a good expressive but parsimonious graphical language – like Archimate – rather than arbitrary ambiguous words and pictures – boxes with “Engineering” written in them.

    I would nuance Adrian’s view of the defining characterstic of a ‘Capability’ a little; I’d say a capability is an ability to assuredly produce outcomes – whether or not those outcomes are actually produced – ie organisations/enterprises could have ‘unused’ or ‘latent’ capabilities. Either way they should be defined and named (identified).

    Do we all agree that organising by capability is a much better idea that traditional Tayloristic organising-by-function?

    BTW, wikitect, Do your work in SW1 by any chance? We might have met face-to-face.


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: