Tom Graves

Another weblog item that’s been triggered by a question on Twitter, though in this case it came via a personal ‘direct message’ from Australian enterprise-architect Mike Aikins (@AussiMike):

Surely there are groups focused on the art and discipline of strategic planning and execution? How can we coalesce #entarch and these groups

Often there will be several “groups focused on the art and discipline of strategic planning and execution” – or there should be, at any rate. It’s true that enterprise architecture – and especially IT-architecture – will often be landed with a strategic role, though I would suggest that that’s more by default than by actual understanding of what EA is or does.

(Once again this has turned out to be a long explanation, so read on after the ‘Read more…’ link.)

Read more…

The current week’s-worth of assorted Tweets and links, in the usual categories, and with the usual ‘Read more…’ link to open ‘em up.

Read more…

Yet another longish one about enterprise-architecture (EA) and related themes – skip over it if that’s of no interest, otherwise click the ‘Read more…’ link to what follows.

Read more…

A few days ago my colleague John Polgreen posted an article of mine Adapting the ADM for Government Architectures on his ‘TOGAF for Feds’ blog on the (US) Government Technology Research Alliance (GTRA.org) website. The main theme was that to make TOGAF work well for non-information-centric government agencies and similar organisations, we need to do some significant changes to TOGAF’s Architecture Development Method cycle (the ADM). I summarised the modified ADM and taxonomy-framework, and illustrated all of this with a fairly lengthy case-study of the use of this modified framework in a government agency in the social-services sector.

The problem is that for many TOGAF practitioners, those changes are often too much of a jump from standard ADM practice. For example, in an unattributed comment on the blog, John’s colleague ‘GB’ complained:

One can transform TOGAF into any process one wants.

Is this really TOGAF for government? Or even for enterprise architecture?

Or is it TOGAF for business consultants dealing with a government department?

There are actually two separate points here. One is the implicit assertion that ‘enterprise architecture’ is still solely the architecture of the enterprise-IT; as John also mentioned in a comment, that notion is at last becoming more generally acknowledged as unworkable, and that we must extend the architecture out to the full scope of the enterprise. (Importantly, this extended ‘architecture of the enterprise’ is not the same as business-architecture.) The other is that many TOGAF folks are still uncomfortable with the idea of dumping the existing phases B, C and D – ‘Business Architecture’, ‘Information-Systems Architecture’ and ‘Technology Infrastructure Architecture’ respectively – even though they don’t work in practice for anything other than IT strategy-development and implementation. (In the re-worked version of the ADM they’re replaced entirely by a separate focus on as-is, to-be and gap-analysis for the selected scope – similar to the structure of the ADM in the earlier TOGAF 7.)

The core problems here are that the TOGAF 9 ADM is usable only for top-down strategy development (the sequence of the phases B, C and D), and only for IT-systems and IT-delivery (the current content of B, C and D). The enterprise-architecture method needs to cover a broader range of development types – overview, horizontal optimisation, top-down, bottom-up and spiral-out – and to address any scope in the enterprise. Hence the reason for suggesting some fairly fundamental changes to the ADM structure. But as long as we’re comfortable with sticking solely to top-down development, we can still retain something very close to the existing B, C and D, but capable of covering any enterprise scope. To do this, we rename the Phases as follows:

• Phase B: ‘Business Big-picture’
• Phase C: ‘Communication and Common’
• Phase D: ‘Domain Detail’

Phase B: Business Big-Picture

In this layer we explore the strategic imperatives for the business – what we might call ‘business-architecture proper’ – and the business drivers that impact on strategy. This is all at the big-picture level, and would typically include vision, values, business-role, business-missions and suchlike, and whole-of-organisation reference-models such as the Functional Business Model, and the FEAF Business Reference Model (BRM) and Performance Reference Model. This would be similar to the high-level components in the TOGAF 9 ‘Business Architecture’, though would not necessarily focus solely on strategic themes that would impact on IT.

What it would not contain is any tactical or operational themes: so-called ‘manual’ bsuiness-processes and the like. The tendency of TOGAF practitioners to bundle together everything ‘not-IT’ as ‘business architecture’ is a common cause of friction between IT units and the rest of the business, and also a common cause of architectural design-failures at the implementation stage.

Phase C: Communication and Common

In this layer we explore what needs to be shared with domains other than the primary domain in scope. For IT, applications and data are what are shared with other business domains – hence the two subsidiary components in TOGAF’s ‘Information Systems Architecture’. But here we need to make this more general, because the primary domain in scope may be any part of the business – HR, for example, or security, or manufacturing, or marketing. Typical deliverables here would be the domain equivalents of FEAF’s Service Reference Model (SRM) and Data Reference Model (DRM).

A service-oriented analysis of the enterprise will usually be the most appropriate tactic here: define everything as services, and summarises the structure and content for interfaces, service-contracts and SLAs, qualititative criteria, success-factors (CSFs) and performance-indicators (KPIs). This is also where trade-offs between different implementations should be assessed.

Phase D: Domain Detail

In this layer we explore the fine detail that’s specific to the ‘primary domain in scope’, and which should in general not be of any active concern for other domains (’black-box encapsulation’, in service-oriented terms). For IT, this is the detail about network infrastructures, configuration-management, life-cycle management and so on – the TOGAF Technology Infrastructure Architecture’. Typical deliverables here would be the domain-equivalent of FEAF’s Technical Reference Model (TRM), and else capability-architecture models that cover IT-based, human-based and machine-based capabilities.

This layer in particular is where the often-idealised top-down strategy needs to connect with the bottom-up constraints of real-world operations. Architecture governance becomes extremely important here, with cross-linkages to ITIL, CoBIT, Six Sigma and other detail-level process-management and quality-management disciplines, as appropriate to the respective domain.

Anyway, try this in your TOGAF practice: see what you think, see how it works in practice. It’s not as versatile as the full amended-ADM, but it’s a useful ‘halfway-house’ that’s easier for existing TOGAF practitioners – and because it is truly generic, rather than IT-centric, and consistent across all domains, it should also help to bridge the chasms of the dreaded ‘IT-business divide’.

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.