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 doing. It 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.)
on Enterprise Architecture 
