Tom Graves / Tetradian

In another interesting thread on LinkedIn, Roderick Lim Banda suggested that one way to resolve some of the arguments about what enterprise architecture is would be to ask what it isn’t.  The discussion has gone round the houses a bit, as one might expect, but I thought my most recent addition to that thread would be worth repeating here:

One possible way to sort out this tangle is to deconstruct a single-sentence description:

• “Enterprise architecture is a business-capability that manages a body of knowledge about enterprise structure and purpose.”

It manages a body of knowledge: it’s a decision-support system, not a decision system. Decisions are the role of strategy, and in a smaller organisation the EA may do that too, but it’s not actually the core of the role.

• If it doesn’t manage an explicit body of knowledge used in organisation-wide decision-support, it’s probably not enterprise architecture

The core business role is to advise: “if you change the strategy, these are the implications on structure, this is the structure we will need; if you change the structure, these are the implications on strategy, these are the kinds of strategy this structure can support”, etc etc.

• If it doesn’t provide executive-level advice, it’s probably not enterprise architecture

It’s about the overall enterprise – the ecosystem in which the organisation operates, not just the organisation itself (which is the preserve of business-architecture). A scope any less than the whole enterprise (business-architecture, applications architecture, technology architecture), it’s domain-architecture.

• If it doesn’t have a whole-of-enterprise scope, it’s probably not enterprise architecture

It’s a body of knowledge about structure and purpose, and especially the intersections between them. If it’s only about structure, it’s primarily an operational issue, or a straightforward structural issue such as software-architecture; if it’s only about purpose, it’s strategy, without any actual attachment to the enterprise or organisation reality. In a small organisation an EA may well also cover some aspects of strategy (e.g. IT-strategy) and will often cover aspects of operational structure (especially e.g. IT-structures), but the real role is about purpose and structure.

• If it doesn’t deal with the intersection of structure and purpose, it’s probably not enterprise architecture

Hope this helps, anyway.

As mentioned in a previous post, I decided at the last moment to go to the TOGAF Munich enterprise-architecture conference. Kind of a wild one-day dash – up at 3:30am; 100kms there and back to Stansted; two hours each way on Ryanair to Salzburg; 300kms there and back Salzburg-Munich; back in Colchester at just before 1:00am – and not exactly cheap (a whopping £170+tax conference-fee for what was in effect just one afternoon), but I hope will be worth it in the long run. If nothing else, it was very good news to see a big shift in perspective about the nature and role of enterprise architecture, such as in these almost throwaway remarks by Len Fehskens, the Open Group’s ‘VP, Skills and Capabilities’:

The conventional wisdom is rapidly becoming that Enterprise Architecture is more than Enterprise IT Architecture.

• There’s a lot more to an enterprise than its IT; IT budgets represent about 2% of revenues.

• An increasing number of enterprise architects believe that the rest of the enterprise, often generically referred to as “the business”, should be architected as well.

To address the architectures of things outside the domain of IT, we need a concept of architecture that is not technological, and that is expressed in nontechnical language.

(Full link to Len’s talk Re-Thinking Architecture is here, but may require login.)

Considering how much so many people in ‘the trade’ (though not Len himself, I’ll hasten to add) have put me down, mocked me and a whole lot worse, for saying such things over the past few years, I’ll admit it is perhaps a little galling to see this now described as “the conventional wisdom”… But hey, the message is getting through. At last. At last.

So can now we actually get down to doing this, as a profession? Can we at last get the tool-vendors to give us some tools that will actually work for this purpose? And perhaps can those of us who’ve been stuck out there on ‘the bleeding edge’ for so damn long now get some help and support in doing so? – and perhaps, just perhaps, even some respect for the work we’ve had to do to get this profession to break out of its utterly inane IT-centric rut? :bleakwrygrin:

A slightly wary sigh of relief: hey ho. But yeah, good news. Worth the trip for that alone.

This somewhat impenetrable acronym is one of the best things I’ve seen in enterprise architecture for a fair old while, ‘cos it means that someone is thinking wider than just IT boxes…

The ’someone’ in this case is Nigel Green and Carl Bate at CapGemini, and the acronym stands for the following:

• Values
• Policies
• Events
• Content
• Trust

They use it as a checklist for a review-process that happens before the usual “let’s rush off and build an architecture solution”. As they put it, “ask ‘What?’ before ‘How?’” (with ‘What’ meaning more ‘what do we want to do?’ – in other words closer to a Zachman ‘Why’). The aim is to create a proper translation between business and IT – hence the title of their book, Lost In Translation [on Amazon.co.uk], which describes the checklist and how to use it in practice.

In essence, this is the Zachman columns ‘Why’ (Policies), ‘When’ (Events) and ‘What’ (Content), with their Values being the equivalent to my extra ‘row-Zero’ on Zachman. (I note, though, that they’re right to point out that Values permeates every layer, not just at the highest level: this suggests that it really is another dimension relative to the Zachman frame, and that my simplification of it to a ‘row-0′ may be just that bit too much of a convenience… hmm…)

The ‘-’ before the ‘-T’ is there for a reason. (It’s not just that ‘trust’ doesn’t sit anywhere in the Zachman frame. Which it doesn’t – which could be a useful topic for another post?) The key issue in all of this ‘translation’ is trust – or, more to the point, the lack of it. And the aim is to create that trust. Because if the trust doesn’t exist, we don’t have a usable architecture. Or, eventually, an enterprise, for that matter. :wrygrin:

More details in the book, or on their website www.LIThandbook.com, which includes a free download of the introductory chapter. Perhaps still a bit too IT-centric for my taste, but hey, that’s where the big problems are, yes?

Had a really good conversation with Nigel Green on all of this last week, and look forward to hearing more.

All in all, very strongly recommended.