A kind of manifesto

Enterprise-architecture is dead; long live the architecture of the enterprise? Or something like that, anyway…

So, what next?

Time for a kind of manifesto, I guess? At the least, time for a fairly major paradigm-change in how we view the architecture of the enterprise – not just a Copernican shift in paradigm, but more like a kind of double-Copernican shift.

Most current so-called ‘enterprise’-architecture is centred primarily or solely around some aspect of IT. Even at best, it’s centred around the organisation and its business. Yet if we think of the architecture of the enterprise as if it were some kind of solar-system, then by definition the enterprise – not the organisation or its IT – is the sun around which that solar-system revolves.

By ‘enterprise‘ here I do not mean the organisation, but something several orders-of-magnitude larger – that which the organisation chooses (if only by default) to orbit:

Which brings us to a first practical assertion for this purpose: that we create an architecture for an organisation, about a broader shared-enterprise.

The shared-enterprise always comes first, not the organisation – not least because if the organisation suddenly ceased to exist, the shared-enterprise would probably continue onward, almost completely unchanged. And, importantly, the shared-enterprise is not, and never can be, under our organisation’s control: if anything, it’s more like the other way round. As designers, or architects or whatever, we can (and should) support the organisation of the organisation: but for the shared-enterprise, the most we can ever hope for is to influence it – never ‘control’ it.

If we were to try to centre the architecture around the organisation, it would be much like a geocentric view of astronomy: something that looks sensible-enough at first – ‘common-sense’, certainly – but eventually requires so many distortions and complications and metaphoric-epicycles and suchlike that a shift to a heliocentric view – an enterprise-oriented view – will become all but essential in practice.

Yet what so often purports to be ‘enterprise’-architecture at present is even worse: in a Copernican sense, almost literally lunatic. Its obsessive IT-centrism is not even the equivalent of a geocentric astronomy: it’s more like a lunacentric view, centred round some relatively-minor moon such as Mimas. Sure, even the smallest moon is part of the overall solar-system – yet the idea that that that moon alone should be considered by anyone to be ‘the centre’ of that system is so far from the reality that it’s just plain laughable. The exact same is true of IT-centrism – or any other form of anything-centrism – in relation to the architecture of the enterprise.

The scale of that error, though, is a useful reminder that even a heliocentric view of the universe is incomplete and inadequate at the larger scale. Our own sun is tucked away on an outer arm of what is in turn a relatively-minor galaxy: and even if we could identify some nominal ‘absolute centre of the universe’, it still wouldn’t make much practical sense to centre all of our descriptions around that one point. To make sense of the whole of that universe – and likewise our ‘business-universe’ – we need to acknowledge that recursion is an inherent part of the picture here, at every scale. Or, to bring this back to our more-mundane world of enterprises and their architectures, every organisation and enterprise is in context of other organisations and enterprises both smaller and larger than itself: there is no ‘the centre’ as such. It’s probable, then, that the only sensible notion of ‘the centre’ is that in a viable architecture of the enterprise, everywhere and nowhere is ‘the centre’, all at the same time.

The organisation ideally operates within just one identifiable shared-enterprise, though in some cases more than one. Each shared-enterprise within which the organisation operates will need to be understood as a system in its own right, in the broadest sense of ‘system’: in effect the shared-enterprise is perhaps best-understood as an ‘ecosystem-with-purpose’. A corollary is that in order to understand the organisation’s choices in that context, we therefore need to understand the effective-purpose of that ‘ecosystem-with-purpose’ – even if only as POSIWID, ‘the purpose of the system is [expressed in] what it does’.

As a system, everything within the shared-enterprise depends on everything else. If something is identifiably ‘in’ the system, it is part of the system, and it is probable that the system either would not operate in the same way, or at all, without it. In that sense, no item in the enterprise is inherently ‘more important’ or ‘less important’ than any other. This has important implications for design-priorities, for example, or supposed ‘justifications’ for hugely-different rates of pay.

This inherent interdependence of everything also points to perhaps the core reason and value for an architecture of the enterprise: that things work better when they work together, on purpose – efficient, reliable, elegant, integrated, appropriate, at every scale, and changing dynamically in accordance with changing needs.

[This in turn implies important follow-on questions within each context: What things? What is ‘work’? What is ‘better’? What is ‘together’?]

If there is such a thing as ‘the centre’ of an enterprise and its architecture, it would have to be people. By definition, ‘enterprise’ is a human construct, a human attribute – not an attribute of organisations as such, and certainly not of IT or any other technology. As Bob Marshall indicates in his somewhat-oddly-named ‘Antimatter Principle‘ – “attend to folks’ needs” – people and their needs are the ultimate start-point and end-point of all concerns in the shared-enterprise.

Given the incipient IT-centrism in so much current ‘enterprise’-architecture, we perhaps need to keep hammering home that technology is only ever an enabler – never ‘the sole centre’. IT-centrism feeds hopeless hype-cycles, dysfunctional deus ex machina delusions, and worse – as can be seen all too easily, for example, in the current ‘buzzword-bingo’ around big-data, cloud, social, mobile, ‘internet of things’ and much, much more. Although new technologies can often enable new possibilities and options, we must always place people first in the enterprise – not the technology.

We also need to rethink how work itself is organised, within the organisation and beyond. In part this is because IT-centrism has long formed the other half of a highly-dysfunctional pairing with Taylorist-style notions of ‘management’. This can be seen, for example, in the Frameworx (formerly NGOSS, / eTOM / SID) architecture-framework for telecoms, in which almost every focus-area is explicitly linked to some aspect of ‘management’:

In larger organisations especially, middle-managers tend to live in a misleading and often highly-delusory pseudo-world consisting almost exclusively of IT-delivered ‘information’ – standardised, over-simplified and artificially smoothed-out, or, as one colleague put it, ‘information with all the crusts cut off’ – creating an often-spurious sense of sameness, predictability and ‘control’ that is not actually available in real-world practice. Coupled with the incipient dysfunctions of top-down ‘one-way hierarchies’, sensemaking and decision-making under such circumstances can range downward from dubious and inadequate to downright-dangerous – yet any means via which to identify that it is dysfunctional have also been stripped away in the process of ‘simplification’. In practice, this can easily become a recipe for enterprise-disaster… and redesigns to prevent such failures will often need to be an increasingly urgent priority for any architecture of the enterprise.

Part of the challenge here is that, increasingly, organisations and shared-enterprises enact a VUCA world: volatility, uncertainty, complexity and ambiguity are characteristics that every architecture must address. One of the reasons for this is that most of the easily-automatable ‘tame-problems’ were solved long ago: all that’s left are ‘wicked-problems‘, for which the usual ‘sameness-oriented’ Taylorist ‘management + IT’ pairing is fundamentally unsuited.

In practice, the architecture of the enterprise is inherently contextual – every implementation will include at least some components and characteristics that are contextually unique. There is no ‘one-size-fits-all’: almost invariably, so-called ‘best-practices’ need adaptation to the specific needs of the context, and every experienced designer and architect will be aware of the need to face up to the kinds of uncertainties inherent in phrases such as ‘I don’t know‘, ‘It depends‘, and ‘Just Enough Detail‘.

Whilst most current so-called ‘enterprise’-architecture will focus almost exclusively on structure, it’s probably wiser to assert that architecture sits at the intersection of structure and story. (This is certainly true for most other forms of architecture – especially building-architecture and naval-architecture.) One of the core distinctions highlighted in a narrative-oriented approach to architecture is that structure tends to start from ‘sameness’, whereas story tends to start from ‘difference’, or uniqueness: a structure-only approach will tend to struggle with VUCA concerns and any other form of contextuality.

And finally, architectural methods should support and be applied to the enterprise of ‘the architecture of the enterprise’ itself, as part of a systematic process of validation of those methods. For example, see the categorisation of techniques and methods for the various domains in the SCAN sensemaking / decision-making framework, which itself recursively illustrates the usage of those techniques within and on the framework itself.

In SCAN terms, most conventional ‘enterprise’-architecture methods at present are appropriate only for more-certain contexts, well over to the ‘left-side’ of the frame. To complete the picture, we need full suites of techniques that, together, can cover the entirety of a context, rather solely ‘the easy-bits’ of the classic ‘sameness’-oriented ‘management+IT’ of present-day neo-Taylorism.

Timescales

Note that work for the architecture of the enterprise takes place over multiple, overlapping timescales. From a futures perspective, the respective techniques and applications can perhaps be summarised in terms of four distinct timescales that would align quite well with the four ‘layers’ of the futures-technique Causal Layered Analysis [CLA]:

— Near-future (<1-5 years) [CLA: ‘the litany’]: Most current ‘enterprise’-architecture is focussed on this relatively close future. It usually addresses an immediate or immediately-upcoming business-question, and for the most part delivers direct, identifiable business-value, such as from consolidation or embedding new capability, or some other relatively-immediate form of ‘things work better when they work together’. The skillsets tend to be ‘T-shaped’ – specialist depth often in only one or two disciplines, coupled with basic awareness of the interfaces between those and other specialities across at least the whole domain, often more. The focus here tends to be on explicit models, adaptation and application of generic reference-frameworks, and support for immediate change-projects. Because the value is identifiable, and relatively direct in terms of its linkage to the change-effort, this type of work is often highly-paid.

— Mid-future (3-20 years) [CLA: ‘systemic causes’]: A significant and increasing amount of work is being done on this longer timescale, primarily for evaluation and development of future capabilities for individual organisations or consortia. (This is also the timescale of most current architecture-framework developments and revision-cycles – TOGAF, DoDAF/MoDAF/NAF etc.) The skillsets tend to be ‘V-shaped’ – specialist depth across a range of disciplines in at least one primary domain, with basic to mid-level knowledge of interfaces to other domains. The focus here tends to be on the creation rather than usage of frameworks and reference-model base-templates. Although the connection to business-value is relatively clear, the commercial value-return from the work is less immediate – hence this work tends to be done either as an ‘overhead cost’ within a corporate strategy-unit, or pro-bono in broader industry consortia.

(Note: in many business-contexts, this timescale may well be considered to be the far end of ‘far-future’, but as indicated by the linkage with CLA, is actually very limited in terms of its ability to work with deeper or larger-scale issues.)

— Further-future (10-100 years) [CLA: ‘discourse / worldview’]: A small yet perhaps increasing number of practitioners also work at timescales that are typically longer / broader than those usually acknowledged as ‘of interest’ for commercial organisations. This type of work is all but essential for assessment of architectures for ‘enterprises of enterprises’ (the enterprise-equivalent of ‘systems-of-systems’) – see, for example, the Twitter hashtag #rbpea (‘Really-Big-Picture Enterprise-Architecture’). The skillsets tend to be ‘weave-shaped’ – a meshwork of varying ‘thicknesses’ of experiences across many different disciplines, industries, levels and contexts – and often tend to focus more on the connections between things than on things themselves. There’s also a strong emphasis on metaframeworks and metamethodologies – tools to create frameworks and methodologies that in turn can be used to create context-specific models and methods. Since in effect the practical focus here tends to be on developing tools for the overall disciplines – rather than direct usage of those tools – it can sometimes be difficult to establish evidence of connection to immediate business-value; there’s also a practical problem in that, by definition, much of this work may require questions or challenges to existing paradigms and ‘sacred-cows’. This can make it hard to ‘justify’ the costs or even the credibility of the work, and hence is usually done either pro-bono or by academics and other semi-independent practitioners.

— Far-future (50-200+ years) [CLA: ‘metaphor / deep-myth’]: A very small number of practitioners – mostly also experienced as futurists – do also work at whole-of-culture timescales, providing a literal form of thought-leadership for the profession as a whole, in its interaction with changes operating over longer timescales, often at a fully global scope. The skillsets tend be eclectic almost in the extreme – ‘story-shaped’, perhaps – that enable a kind of ‘Brownian-motion‘ towards enterprise-serendipity, and emphasise a form of generalism that is a specialism in its own right. The work can often be difficult to explain even to experienced practitioners, since by definition it must explore themes and principles that question even the base-foundations of the entire economics and culture. Again almost by definition, the work may often have little if any apparent connection with immediate business-value – in fact may clash strongly with current concepts of ‘business-value’. As a result it’s often extremely hard at present to gain any kind of income from this work: its effective ‘business-model’ is often closer to that of an artist, reliant not so much on ‘clients’ as ‘patrons’.

In a way, these four timescales also align quite well with the decision-making emphases of the four domains in SCAN, as in the diagram earlier above:

• near-future architecture-work provides simple rules to guide immediate design and delivery in the enterprise
• mid-future promotes predefined frameworks that act as algorithms to tackle complicated requirements
• further-future provides patterns and guidelines – such as in the form of metaframeworks and metamethodologies – to guide adaptation to contextual-ambiguity and emergent needs
• far-future explores implications of principles on responses to changes in existential-myth and deep-story, in the face of unavoidable inherent-uncertainty and the not-known

Note that, as indicated both by CLA and by SCAN, all of these types of work are necessary for the overall development of the architecture of the enterprise, especially over the longer-term. In the present business-culture, though, remuneration seems to be linked tightly to short-term business-value, providing strong incentives for most practitioners to work only on near-future concerns. It needs to be understood, though, that just as with the architecture itself, all of the timescales and related work-types are equally important. As illustrated by the old farmer’s adage that ‘the best time to plant a fruit-tree is twenty years ago’, ignoring further-future or far-future work as ‘out-of-scope’ may turn out to be very dangerous indeed: just as with a fruit-tree, deep-futures work takes time to come to fruition – and when we get to that future time, if the tools that we need for that time are not already in place, there is no possibility to go back in time to create them. If further-futures or far-futures work is not supported, the architecture of the enterprise will literally have no long-term future – hence some means to cover the costs of these types of work must be found if the profession is to be viable over the longer term.