Read Blog Post

Read Blog Post

Contributed on September 4, 2016

1.5K

1.5K

Enterprise-architecture – a changes report

Blog: Tom Graves / Tetradian

A couple weeks back I wrote a post about what I see as the current status for enterprise-architecture – where the discipline is right now, how it’s different in different parts of the world, and how some of the big changes in technologies and markets are impacting on the overall profession.

Seems worthwhile, though, to accompany that with a view on the dynamics of enterprise-architecture – how the discipline has changed over time, where it’s likely to be headed, and the probable timescales. In short, its past, present, and future – although, to paraphrase William Gibson:

The future [of enterprise-architecture] is already here – it’s just [very] unevenly distributed.

For those with no time or patience, though, here’s the TL;DR version of this report:

• Enterprise-architecture expresses and enacts one simple idea: that things work better when they work together, on purpose.
• To understand anything and its purpose, we need to understand its context; yet every context is itself a subset of of a broader context.
• The scope of enterprise-architecture therefore will and must continue to expand outwards towards ‘the everything’. Hence any boundary we place on that scope is not a ‘fact’, but always an arbitrary choice – and we need to choose well…

In other words, it’s fractal. And if we think in terms of services, then for any given service-in-focus for which we’re building an architecture – hence IT-architecture, business-architecture, security-architecture or whatever – the context for which we need to be aware is typically outward to around three layers broader than the immediate context of the service itself:

(We’ll see more-concrete examples of that as we go along.)

So let’s start our journey into the past of EA with the origins of what many people might consider to be ‘enterprise-architecture’ – namely the shambles of large IT-systems and IT-procurement, particularly in the US, back in the 1980s to 1990s.

The term ‘architecture’ had already been well-established in the IT domain by then, since at least the days of the IBM-360, hence no surprise that ‘IT-architecture’ became expanded to ‘enterprise-wide IT-architecture’ as its scope became broadened across whole organisations and, later, whole consortia. It was somewhat later (perhaps in the mid-1990s?), that someone became careless and collapsed that term down to the shorter ‘enterprise-architecture’ – with unfortunate consequences, as we’ll see later. But we could summarise the scope of that ‘enterprise’-architecture visually as follows:

In terms of common notions of ‘inside-out versus outside-in‘, we’d probably best describe this as ‘inside-in’ – essentially a black-box within which changing its architecture shouldn’t affect anyone else:

That structure underlies essentially most mainstream ‘enterprise’-architecture frameworks up until the early 2000s, such as with TOGAF up until version 7. With the first so-called ‘Enterprise Edition’, TOGAF 8, in 2002, another layer is added to the scope – ‘the business’, providing the broader context for the previous IT-only context:

It’s from there that we get the development of so-called ‘business-architecture’, and the much-referenced ‘BDAT-stack‘, ‘Business, Data, Applications, Technology’. We need to note, though that this supposed ‘business-architecture’ is barely about business as business at all – instead, solely about the broader ‘business’-context for IT, and best summarised as ‘anything not-IT that might affect IT’.

In other words, at this stage – in the mid-2000s – all of this mainstream ‘enterprise’-architecture was still strictly IT-centric. For example, whilst the FEAF PRM (Performance Reference Model) briefly mentions ‘Human Capital’ and ‘Other Fixed Assets’ (non-IT technology), there’s nothing in that specification that actually describes them in any significant detail. For anything more than that, we had to turn to industry-specific frameworks such as eTOM (for telecoms) or SCOR (for logistics), or else roll our own.

And where ‘enterprise’ is mentioned at all in the mainstream ‘EA’-frameworks, there’s also an assumption that ‘the organisation’ and ‘the enterprise’ are one and the same. By the time of the launch of TOGAF 9, in 2009, this becomes more overt: there’s an implication that whilst there must be some clients out there somewhere, they’re essentially ‘out-of-scope’ for the architecture, and that the maximum reach we’d need to worry about as enterprise-architects is an ‘inside-out’ view of the business-world:

Yet within just a year or two from then, it was already becoming obvious that this organisation-centric view just wouldn’t work any more. With the rise of cloud, mobile, social and the need to integrate with popular new business-architecture tools such as Business Model Canvas, the pressure to expand the scope further outward and engage with ‘the enterprise beyond the enterprise’ became all but impossible to ignore:

What we see at that stage – coming towards a full flowering at the present time – are the beginnings of explicit inclusion of client-oriented techniques such as customer-journey mapping and value-proposition modelling. Thought-leaders and practice-leaders such as the UK’s Government Digital Service demonstrate that we need to build a much better balance between ‘inside-out’ and ‘outside-in’:

Yet the blunt reality for present-day EA is that almost none of this is supported by any of the mainstream ‘enterprise’-architecture frameworks. For a start, everything in those frameworks is still rigidly IT-centric – still everything revolving around IT-hardware that, with the rise of cloud-services, barely exists any more in many organisations; still with a now-decades-out-of-date concept of applications and data; and still with so-called ‘business-architecture’ essentially as ‘anything not-IT that might affect IT’. It’s kinda like looking upward from the bottom of a well, with ‘the business’ seemingly allowed, or even able to look downward at IT:

Whereas what we need now are frameworks that can look ‘outward’ to the organisation’s interactions with others – with its clients, suppliers, prospects, competitors, regulators, the broader market, and beyond. And frameworks that also, when we look ‘downward’ at how all of the internal services are implemented and operated, can understand and choose between all the different options, where any service might be implemented by any appropriate combination of people, machines and IT:

It should be obvious, I think, that we’re not going to be able to make sense of “how things work together, on purpose”, if we arbitrarily exclude from consideration whole swathes of the things that need to work together: yet even the latest version of TOGAF can barely support any of those extensions to the real scope of enterprise-architecture as the literal ‘the architecture of the enterprise’. And whilst it’s somewhat better than it used to be, the latest version of Archimate – released barely a couple of months ago – still handles anything not-IT only via near-impenetrable abstracts, largely leaving the user to sort out the mess, without any kind of clear standards or guidelines. Bah.

In short, as I put it in the ‘EA status-report’ post:

the mainstream ‘EA frameworks that we now have are almost perfectly unsuited for the real EA contexts that we now face

Which is kinda dispiriting, to be honest…

And to make the situation even worse, those existing ‘EA’-frameworks also only cover a small subset of the overall process of business-transformation – in essence covering solely the easier stages of specification, design and and governance for change-projects. (Yes, there are concepts such as TOGAF’s ‘Motivation extensions’ or Archimate 3.0′s new ‘Strategy’-entities, but in practice they’re still only half-framed ideas, with little or nothing to support their usage for real-world architectures.) In Zachman-type terms, we might summarise this ‘vertical’ scope visually as follows:

Whereas in practice, in order to be able to work with ‘outside-in’ as well as ‘inside-out’, we need to be able to explore all the way out to the core purpose of the shared-enterprise which which the organisation operates. And whilst the Architect’s Mantra always applies, we likewise need be able to do deep-dives right down into operational detail when necessary. In the same Zachman terms, then, we might describe the real ‘vertical’-scope that we need to cover, as follows:

Again, a much broader scope – yet which is barely supported at all by our current so-called ‘standards’ for enterprise-architecture.

It’s also here that that phrase about “the future is already here, it’s just unevenly distributed” rings out so loud and clear. For example, Gartner’s ‘Future of EA 2025 – Evolving From Enterprise To Ecosystem‘ predictions-article outlined their belief that by 2025 only the most leading-edge ‘Vanguard EA’ would tackle that kind of scope I’ve described just above. Yet barring a few minor tweaks, their ‘Vanguard EA’ is actually quite a good description of what we were already doing at Australia Post way back in 2005 – and to us that wasn’t even that much of leading-edge. No wonder that when I moved back to Britain a decade ago, it was a huge shock to discover just how backward most EA practice was in this country, and largely still is – and judging from Gartner’s ‘predictions’, it seems that in the US the self-styled ‘leading-edge’ of mainstream enterprise-architecture may well be yet another full decade further back again. Sigh indeed…

There’s some hope, though, that this might at last quieten down some of the more jingoistic claims that enterprise-architecture is an entirely new discipline, invented solely in the US in the 1980s. Yes, it’s true that those now-absurdly IT-centric frameworks did mostly arise from the US, if largely in response to specific local challenges such as the impacts of a business-culture built around hyper-individualism and hyperspecialisation. But once we do break out of the IT-centric box, the reality is that there are vast numbers of precedents from right around the world and throughout history, such as:

•  General Systems Theory (e.g. Bertalannfy, Austria, 1937 onwards)
• the Dowding System (UK air-defence, 1930s onwards)
• Ford’s ‘integrated factory’ (US, 1910s onwards)
• railway/railroad networks as large-scale integrated-systems (particularly US, 1890s onwards)
• military logistics (e.g. Hannibal, Carthage [Tunisia], c.200BCE)
• imperial administration-systems (e.g. British empire, Inca empire, Roman empire, Chinese empires and more)

And there’s a lot that we can (and need to) learn from those precedents – even in the present state of ‘enterprise’-architecture…

Yet even ‘outside-in’ doesn’t go far enough. To cover what we really need in the futures for ‘the architecture of the enterprise’, we’ll often need to be able to extend our architecture view all the way to ‘outside-out’:

There seem to be some understanding of this point in mainstream-EA – though as yet still not enough to be usable. For example, Gartner did sort-of describe this in their ‘EA 2025′ paper – yet, being Gartner, they dumbed-it down to the point where their ‘predictions’ on this would have to be described as yet another overly-simplistic mess…

The reason for that failure is that, as can be seen in my post ‘Big-consultancies and getting it right‘, they again used that misleading conflation of ‘organisation’ and ‘enterprise’ – ‘enterprise as large commercial organisation’ rather than ‘enterprise as bold-endeavour’. The result is that they’re left floundering about how to describe ‘the enterprise beyond the enterprise’ – which, unsurprisingly, makes little sense at all. They struggle their way outwards a sort-of understanding that the broader market might have an impact on customers’ and suppliers’ choices and the like, but that’s pretty much where they stop – what we might describe as the organisation’s direct-context. In practice, though, we need to be able to extend the view outward further again, to the real ‘outside-out’ of the respective indirect-context:

That indirect-context includes a whole bunch of stakeholders who don’t transact with the respective service, who don’t even interact directly with it, but can have huge impacts on the entity’s ‘social licence to operate’ and suchlike.

(It’s at this point that it can be useful to consider that, as architects, the respective stakeholders include anyone who can wield a sharp-point stake in our direction…)

In essence, the scope of ‘outside-out’ is ‘the shared-enterprise as story‘ – or, perhaps, in many cases, a meshwork of interrelated stories held together by a common theme. The shared-vision and values that define a market, and that the organisation must align to if it wishes to work well within that market, in fact arise from that shared-story, the ‘outside-out’. For a commercial organisation, for example, its ‘outside-out’ includes communities and governments, the families of its employees, its investors and beneficiaries, and many others too:

Why do we have to be able to go that far out? The short answer is that if we don’t, we’d have no meaningful way to describe non-clients or anticlients or communities or non-transacting stakeholders or even the organisation’s investors, and so on, and so on. Which means there’d be no way, for example, to describe hidden risks in business-model design, from outsourcing and the like, or hidden perils of co-branding, or kurtosis-risks and suchlike that, to that organisation, would seem to hit without any warning at all, but can wipe out the organisation’s business entirely. In other words, kind of important, you might say?

Or to put it another way, if you really want to be the ‘enterprise’-architect who has to go in front of the board and explain why your architecture wilfully ignored key factors about that shared-enterprise that just caused a multi-million or multi-billion dollar loss, go right ahead and ignore everything I’ve said above. If not? – well, up to you, really…

Yes, it might seem a big jump all the way from inside-in to outside-out – especially when most of our so-called ‘enterprise’-architecture frameworks still only cover a very small subset of just the first of those perspectives. Yet it’s the real scope that a real enterprise-architecture has always needed to be able to cover, right from the start – and to anyone who’s actually bothered to look at how the leading edge of thought on enterprise-architecture has developed over the past few decades, none of this should be news at all. For example, take a look at James Lapalme’s paper on ‘Three Schools of Enterprise Architecture‘, or Len Fehskens’ classic Open Group blog-post ‘Enterprise Architecture’s Quest For Its Identity‘: both of those are from 2011, but refer to earlier work going back at least or decade or more. One of my own key influences was from back in 2002, when Dana Bredemeyer and Ruth Malan were both describing not only EWITA (Enterprise-Wide-IT-Architecture) and ‘EWITA + Business Architecture‘ [PDF], but pointing beyond both of those, towards a real ‘architecture of the enterprise’ (PDF).

And there are plenty more examples, if we can bothered to look for them: even if often hidden in plain sight, the future for enterprise-architecture was always there – just very unevenly distributed. And the key point here, perhaps, is that all of them are ‘enterprise-architecture’, each in their own way. So maybe the simplest way to summarise all those changes to enterprise-architecture would be this:

• past: ‘inside-in’ – internally-focussed, scope usually constrained to IT-only
• present (mainstream): ‘inside-in’ and ‘inside-out’ – transactions with the outside-world, always organisation-centric, scope usually still IT-centric
• present (early-adopters): ‘inside-in’ to ‘outside-in’ – customer-focussed, market-aware, scope increasingly beyond IT alone
• future (innovators): ‘inside-in’ to ‘outside-out’ – any scope, any scale, fully aware of shared-enterprise

We’d rarely develop an architecture for an entire shared-enterprise, of course: instead, we’d more usually do architecture-work about a shared-enterprise, for an organisation that needs to operate within that shared-enterprise. The point here is that architecture needs to able to cover any appropriate aspects of that scope, even if it doesn’t actually need to cover all of it. We need frameworks, tools and methods to help us do that – and not, as at present, actively hinder us almost every step of the way…

Enough on this for now, perhaps. Yet we also need always to remember that all of this is fractal: the respective ‘the enterprise’ at one organisation’s scope of context may well be ‘the organisation’ – as we can see in the relationship between the IT-department and ‘the business’ that’s assumed and implied within the classic IT-centric ‘enterprise’-architecture frameworks, or in how a market can be part of ‘the enterprise’ to a business but also ‘the organisation’ in context of its own shared-enterprise.

So as both futurist and toolmaker, for enterprise-architectures and the like, I need to be aware not only how things are changing in ‘the trade’, but what kinds of tools and techniques will need to be developed to support those changes. What that future may look like, and what tools we’ll need for it, is what I’ll start to explore in the next post.

In the meantime, any comments so far? Over to you for now, anyway.