"The history of enterprise-architecture proves..."

(This 'from the archives' article provides supplementary information for the YouTube video 'Enterprise-architecture: How did we get here? - Episode 18, Tetradian on Architectures', released on 31 May 2018. The post was originally published on the Tetradian weblog on 27 March 2014 as '"The history of enterprise-architecture proves..."'.)

----

When a discipline such as enterprise-architecture is changing all the time, just how useful is it to hark back to its history?

The start-point for this one was that, in one of those interminable threads on LinkedIn, several of the participants asserted that enterprise-architecture had to be about IT, and could only be about IT, because, they said, that was where it had started.

In short, their ‘proof’ that EA should still only be about IT in the present-day was that someone in the past had used the term ‘enterprise-architecture’ to describe something about IT.

History as proof.

Hmm…

Let’s do this one properly, shall we?

Let’s use the history of TOGAF as our guideline here – a well-documented example of an enterprise-architecture framework, with quite a long and honourable history.

When it started out, as a fork or reframe of TAFIM – a couple of decades ago now, I think? – it was primarily about IT-infrastructure, about how to clean up the mess of an organisation’s IT-infrastructure, and derive enough clarity on principles and suchlike to guide its future development: in other words, an ‘architecture’, the ‘why’ for a subsequent design’s ‘how’ and ‘with-what’.

For quite a long while – probably up to and including TOGAF 7, in the earlier 2000s – it was in essence only about IT-infrastructure.

Then the team realised that to make sense of IT-infrastructure, we need to understand the applications and data that run on that infrastructure. Hence TOGAF version 8.

And to understand the applications and data, we need to understand the business-use of those applications and data. Hence TOGAF version 8.1.

Then to understand the business use of data and suchlike, we need to know more about the business itself. Hence TOGAF version 9.

And to understand the business, we need to understand more about the business-context – the motivations, the drivers and so on, out to the shared-enterprise often far beyond the organisation alone. Which brings us to the present version, TOGAF 9.1.

History. All of it valid, all of it good.

Yet in all of that time, almost no-one seems to have realised that we might also need to look at the whole enterprise the other way round – looking back down from the whole-of-enterprise scope down towards the detail-areas such as IT-infrastructure. Because when we do that, we can end up with a very different kind of view – which, in some cases, may not even touch IT-infrastructure at all.

But TOGAF – and likewise most other current ‘enterprise’-architecture frameworks – doesn’t allow for that possibility. To that kind of framework, if it’s not IT, or in some way impacts upon IT, it simply doesn’t exist.

Oops… Scope-error…

Which is why – to be blunt – for the most part, I don’t give much of a damn about any so-called ‘EA history’. Rather, I want to know what we need to do, so as to the enterprise-architecture properly now – not merely in some imagined past.

True, there are many things we can learn from history. That’s important. Perhaps the most important of those things, though, is to not get too hung up on history…

In particular, we should not attempt to (mis)use history as ‘proof’ that doing the exact same things now is and will always be the right way to do it. This especially applies to a relatively-young discipline such as ours, where we’re still ‘finding our way’, and in a field often undergoing extremes of change, and where any supposed ‘truth’ or ‘certainty’ is inherently fluid and highly-volatile.

When the starting-point for a field or disciplines turns out to have been a mistake – too narrow in scope, in EA’s case – it is not wise to continue to defend and maintain that mistake – that arbitrary constraint of scope – solely on the basis that that was what was done in the past.

To illustrate this, let’s pick up on another comment from one of the participants in that LinkedIn thread, that at first looks innocuous enough, but actually isn’t:

Surely there is no EA or SA framework that does not start with stakeholder identification and management and scope definition?

Agreed. Mostly.

The catch is that sometimes (often?) that’s the first place that the framework fails.

The starting-point for many frameworks is to predefine the scope – or, at least, put arbitrary constraints and bounds on the allowable scope. (For most current ‘EA’-frameworks the scope is predefined as ‘anything-IT’, possibly extending to ‘anything not-IT that might impact on IT’.) Then they set out to identify the stakeholders that apply for that scope. And only then do they get round to asking about the current business-question to be addressed by the framework, in context of those preselected stakeholders and within the predefined scope.

Which is pretty much exactly the wrong way round.

Instead, what we need a framework to do is to start with the business-question – or, more usually, what is believed to be the business-question.

From there, we then identify the stakeholders for that question – and thence, with their guidance, refine the business-question.

From there, working with those stakeholders, we then identify the scope that applies to the business-question, which helps yet again refine the group of stakeholders and their relationships to the business-question.

(There’s a bit more iteration and recursion in there, but that’s essentially the right way the flow should go: business-question, stakeholders, scope.)

Which then leads to the work to be done, as guided by the framework.

There will often be parts of the real scope of the business-question that the framework does not expect, or for which the framework can provide little or no guidance. The framework must provide adequate ‘hooks’ to connect beyond its own designed-scope, otherwise it will prevent resolution of the actual business-question.

The business-question always comes first in priority: not the framework. We must not allow the limitations and constraints of the framework to arbitrarily constrain the boundaries and scope of the business-question.

Especially, what the framework must not do is pretend that its designed-scope is the only possible scope for enquiry – that nothing exists, or is relevant, beyond its designed-scope. If it does so, it will guarantee failure in its usage for many or most business-questions.

Which, unfortunately, is what every darn one of the IT/IS-centric ‘EA’ frameworks currently does. Certainly in the ways that many people try to use them, anyway.

Which is precisely why the history-myth of ‘EA is only about IT/IS’ has been so damaging: stuck in the past is no way to work with the present, let alone the future. Not a good idea, folks, not a good idea…

History is something to learn from, not to idolise.