“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 GERAM [correction: TAFIM, not GERAM – many thanks to Len Fehskens for that reminder] – 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.
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.
Ah, tradition. Historically, surgery was a side job for barbers – anyone unhappy about that changing with the times?
Very good point, Gene – ouch… 🙁 🙂
Thanks for bringing this up, Tom. I have had the same reaction to this bizarre assertion or mindset.
Two things.
TOGAF was derived from TAFIM (Technical Architecture for Information Management). The Wikipedia article on TAFIM states:
“The development of TAFIM started around 1986 at the US Defense Information Systems Agency/Center for Information Management. The first concept of TAFIM was derived from the NIST Application Portability Profile and the POSIX (or IEEE P1003.00SE) model.”
I do not know if either of these had any connection to GERAM.
In any case, it doesn’t affect the substance of your argument.
Second, thinking about these issues has led me to consider the epistemological context of enterprise architecture. What can we “know” about enterprise architecture? I have concluded that because EA is a “made up” discipline, i.e., an artifact, itself a consequence of human enterprise, about artifacts, i.e., the consequences of human enterprise, the vast majority of what we can say about enterprise architecture is unavoidably opinion, not experimentally or observationally verifiable fact. Much of what we can observe or experimentally confirm about EA is simply an observation or confirmation of something about other peoples’ opinions.
In this respect, EA is more like the law than anything else. The “factual” basis of enterprise architecture as a discipline (its “body of knowledge”, if you will) should probably be much like that of law as a discipline; though it is “made up”, it is sanctioned by well-defined processes in which both the profession and the community served by the profession participate. These processes are guided by fundamental principles that express values that are important to the profession and the community it serves. These principles and processes are the means by which multiple differing opinions are reconciled. In many cases, reconciliation is not a matter of choice (either of whole concepts or bits and pieces thereof) but of integration by generalization.
The problem with EA is that these principles and processes do not yet exist, and so we are left with the weakest forms of justification like temporal precedence or “consensus” to canonize the opinions that provide the basis for the conventional wisdom, and we seem obsessed with pitting opinions against one another in a sort of contest, rather than looking for ways to integrate them under some umbrella concept.
Unfortunately, my exploration of the field of epistemology has so far yielded no “prior art” that seems directly applicable to the discipline of EA. The epistemology of law seems primarily focused on the interpretation of law and legal evidence, not on the justification of laws themselves.
Be that as it may, the observation that the definition and practice of EA is itself an enterprise, and is therefore amenable to the “recursive” application of EA thinking, strikes me as absolutely fundamental and essential to the soundness of the discipline.
There is far too much “shooting from the hip” going on, and the effects are evident everywhere we look.
len.
Thanks Tom. Concise and to the point. Let’s hope lots of people read this. And the comments too.
Len’s point about people “pitting opinions against one another in a sort of contest” captures an important part of the problem. Everyone (well fortunately not everyone) wants to be the Chief Enterprise Architect – as if we even needed such a role.
One of the reasons Scope gets elevated to first place is the tendency people have to see EA as a project. I honestly don’t think that’s what TOGAF is trying to get across but it’s certainly how it (too often) gets interpreted. Then it becomes a set of rules and boxes one can tick off. Process replacing purpose.
Nice post. This is what I tried to express with GLUE (and where I miserably failed to explain) and what I now focus on every day to reinforce it. Which is btw also the main reason why I do not believe in a magic wand (tool) for Enterprise Architecture. I’ll keep you posted whenever I write my next post.
A good article – and I have always been wary of arguments from tradition.
I think an interesting corollary of the changing nature of enterprise architecture is the changing architecture of enterprises.
I don’t want to over-egg that pudding, and I am not criticising you for not going into it here. Just – I can’t imagine how EA circa 1990 could even be rational in many 21st century organisations (even if it was still all about the IT question).
Cheers.
Nice piece Tom!
Here are some quotes from my books. Not surprisingly there is consistency in our thinking (again…:-))
“Strategic thinking establishes the vision, while action items enable the actualization of that vision. This is an essential element for enhancing the effectiveness of the EA, as often EA is perceived of being overly skewed towards “housekeeping” type of activities, rather than facilitating the enterprises to think forward and enable the “visioning” process. The perception is not entirely incorrect and current EA frameworks reinforce this even further. Current EA frameworks take a top-down, centralized planning approach to EA. They attempt to establish a “target” architecture and set a roadmap to achieve the target. While this planned deliberate approach does provide some directions, the notion of “emergence” is virtually non-existent.”
“Embracing strategic (systems) thinking allows for: (1) a business understanding of business concerns / problems; (2) synthesis to take precedence over analysis, which is essential to manifest the “enterprise-wide” view of the architecture; (3) triangulation of emergent strategy development with the more traditional top-down strategic planning; (4) identification of leverage points wherein the interventions tend to be most impactful; (5) framing the problem space in a way that is comprehensible by the senior executive leadership in the enterprise; (6) de-emphasizing on the siloed mindset; (7) establishment of collective strategic priorities; and (8) designing for coherence (consistent, collaborative, connected).”
“To really derive full benefits of architecture, it is critical that the reference models are used in the context of one or more national (business) priorities. Anchoring architecture efforts towards one or more national priorities result in: (1) Converging and focusing architecture efforts towards something viewed as important by the government and other numerous stakeholders. (2) Quicker justification of architecture efforts and resources required. (3) Better quantification and monetization of benefits, leading to greater effectiveness and visibility.”
In one of the LinkedIn post in 2011, I asked an open question – how can enterprise architects call themselves so, if all they do is clean up the mess others created (housekeeping), and do not engage in any “housebuilding”?