Tom Graves

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.

A theme which came up several times in the Troux Directions conference, and came up in several different ways, was the need for some means to share and exchange enterprise-architecture information between multiple organisations, so as to handle the reality that ‘enterprise’ is now very often broader than a single organisation.

The catch right now, of course, is that every vendor has their own proprietary file-format and metamodel. They’d each no doubt be very happy if their own format became ‘the exchange standard’, because that would de-facto enforce a single-vendor monopoly, in the same manner as Microsoft Word. But the multi-vendor environment is a reality: and that ain’t going to change - especially at the prices that the EA-toolset vendors charge for their products… But what could change the game is an open-source approach to the whole field: firstly for exchange-formats, and possibly for toolsets too. When vendors charge upwards of US$500,000 for a single complete suite of products, there has to be room for an EA equivalent of OpenOffice there somewhere…

I’ve summarised what I think are the overall requirements for such a toolset in my book Bridging the Silos: enterprise architecture for IT-architects - see page 14-15 (p.20-21 of the PDF file) in the current draft version on the Tetradian Books website. But to get all of that together will take a fair time, and the most urgent need right now is for some kind of exchange-format. A few places that seem to provide useful pointers:

• IDEAS Group (International Defence Enterprise Architecture Specification) - okay, it’s military, but at least the site makes it clear that it’s not IT-centric
• XPDL eXtensible Process Definition Language (Workflow Management Consortium) - process-specific, but could be extensible for enterprise architecture
• OMG standards around MDA Model-Driven Architecture, such as XMI XML Metadata Exchange - sure, the MDA is still IT-centric at present, but OMG are putting a lot of effort right now into breaking it out of the IT-only box

The key to all of this, though, is going to be defining not just an extensible file-format but an extensible system-architecture that can be flexible enough to handle all of the present and future requirements for enterprise-architecture. Sounds like a big ask, I know, but should be doable as long as we keep the core ideas really simple, and focus on leaving the right hooks for extensibility.

Anyone else interested in this? If so, let’s set up a suitable forum on LinkedIn, perhaps, and continue the conversation there.

Spent Thursday at the Troux Directions conference in London, hosted by Troux, one of the leading vendors of toolsets for for enterprise architecture. A good day in many ways, yet overall I’ll admit I did come away feeling more than a bit disappointed.

Troux seems more advanced in their thinking than some of the other big-name vendors, but still a strong sense of stuck in business-as-usual. Given that EA has been so ‘poisoned’ by the TOGAF types and worse, clinging desperately to their delusions of an IT-centric world, Troux have tried to re-badge their offering as ’strategic IT planning’: but in reality it’s still same-old-same-old. Firstly it’s ‘planning’: yet as they themselves freely admitted, we can’t plan any more - the world we deal with now is too complicated and too dynamic for that. Secondly, it’s still hopelessly IT-centric: ’nuff said, really… And thirdly, they still have not even begun to grasp the bald fact that in the present-day business climate, ‘enterprise’ and ‘organisation’ are no longer the same thing.

I can understand their dilemma: they need to sell to single organisations - because that’s where the budgets come from - but what they’re selling needs to cover any scope, from a small subset of the organisation (as in classic IT-centric ‘EA’) to a wildly dynamic superset of an enterprise that spans partners and suppliers and customers and even competitors across many different industries and across the entire globe. They’re not even starting to tackle those issues, in fact they seem to be running away from them as fast as they can: but that’s where EA practices - and hence EA toolsets - definitely need to be, right now, whether the vendors like it or not.

(To be fair to Troux, their panel of ‘industry experts’ was even less aware of those realities. When I asked about what kind of support they could offer to non-IT-centric enterprises, and/or those to whom financial return was not the sole measure or even the primary measure of success, my question was met with blank stares of incomprehension, and eventually a muttered non-reply from one of the panel members that didn’t even remotely answer the question. Oh well.)

Also disappointing was that their star turn, a lead architect from Merck in the US, perfectly illustrated my point about ’small countries’ versus ‘big countries’. He purported to be showing work which was brand new, world-leading and the rest, and he obviously believed it was (well, after all, it came from the United States, which everyone knows is the world-leader in everything, right?). But in fact his centrepiece ‘capability model’ was, in essence, a pale reflection of the work we did at least four years ago at Australia Post: as far as the ’small countries’ were concerned, it was nothing new at all, in fact just a routine technique that I’ve used in several clients now over the past few years.

Oh well.

But thanks are due to Troux, in any case, for putting on a good show, and a good place to exchange ideas with the handful of practitioners (once again, most of them from the ’small countries’, I note) who were trying to tackle the much broader scope that a true enterprise architecture requires.

More comments in the next post or two, anyway.

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.