Tom Graves / Tetradian

Back at the launch of TOGAF 9, some eighteen months ago, one of the Open Group leads took me aside to a quiet corner of the hall. He looked around, as if to make sure that none of his colleagues could overhear. “You know what’s missing in TOGAF?” he said, in a near whisper. “People. There’s nowhere for people anywhere in the architecture.”

And he’s right: there isn’t. But it’s not just TOGAF: it’s the same with just about every other mainstream ‘enterprise’-architecture framework. Unlike TOGAF, the FEAF PRM does include a placeholder for what it calls ‘People’ or ‘Human Capital’ – but in essence does nothing with it. The Oracle EA Framework [PDF] includes a section called ‘People, Process, Tools’ – but it’s only about the people who do the architecture work, not the people within the architecture itself. CapGemini’s Integrated Architecture Framework covers What, How and With What – but there’s no mention of Who. (Oh, unless you look in the respective ‘Business Architecture’ sections, which in essence, as usual, are a jumbled-up, meaningless, unusable grab-bag of ‘anything not-IT that might impact on IT’.)

The only mainstream architecture-framework that does explicitly include people is the granddaddy of them all: Zachman. The original version, it’s true, only addressed What, How and Where; but the first revision, completing Kipling’s set of ‘Six Honest Serving Men‘, did make a point of emphasising the importance of Who.

The problem, as I’ve explained elsewhere, is that Zachman’s structure doesn’t really work in practice. Sure, it looks good, it’s easy to read, and those six interrogatives make immediate sense (in English, at least, if not always in other languages). But despite Zachman’s own insistence that the framework covers the whole enterprise, the examples given are all for IT only; it’s based on a metaphor of ‘engineering the enterprise’ that almost by definition cannot work in any real human enterprise; and it’s actually missing an entire dimension – distinctions between fundamental asset-categories and the like – without which it cannot be made to make sense for key architecture-concerns such as implementation trade-offs, load-balancing and disaster-recovery.

Back about three years ago I did a lot of work on ‘Rethinking Zachman‘, ending up with a revised taxonomy-framework that looked like this:

I’ve continued to tweak the various labels since then, and they’re still not quite settled, but the current single-row version that I’ve used in my ‘Enterprise Canvas‘ series looks like this:

The point here is that there are at least five fundamentally different things going on around ‘Who’:

• what the person does – which is what I’ve labelled ‘Capabilities’
• how we connect with the person – which is what I’ve labelled ‘relational Asset’
• how people (or roles) relate with each other, in terms of organisational structures etc – which is what I’ve labelled ‘relational Location’
• what each person is responsible for – which is part-implied here in ‘Decisions’, but is better described in a crossmap with a RACI matrix or equivalent
• who the person is – which isn’t described here

To me, Zachman’s ‘Who’ is a muddled mixture of all of these, which we can sort-of get away with as long as we can safely assume that people and IT and machines each do entirely different things. In terms of skill-levels, each of those groups tend to work on different things, too: machines follow simple rules, IT can also use algorithms, and people tend to be asked to take over for anything that the machines and IT can’t do. But if we use Zachman’s ‘Who’-merge, if there’s a context where they do all have to do the same things – such as when real people have to take over IT-type tasks, in disaster-recovery or the like – we suddenly find that we have no way to describe what’s actually going on. Hence we do need to rework the taxonomy and ontology, to put all of these different items in their respective places.

(The ‘Who’-merge kludge sort-of works because, within IT and machines, function and capability are structurally merged – so at first glance it can seem that we don’t have to assess them separately. Unfortunately, for architectural abstraction and redesign, we do need to treat them as separate: function uses assets, which are acted on by capability, which when linked together provides service, which when linked together provides process, and so on – all of which items can, may or should be interchangeable according to context and need.)

In principle, part of that exclusion of actual people from the frame is deliberate:  people are not assets or ‘units of production’ or whatever, but are themselves as themselves. (The relationship that an organisation has with a real person is an asset – and an extremely important asset at that, which needs to be maintained as an asset.) If we treat people as assets, we find ourselves straight back into the worst of Taylorism, regarding people as interchangeable objects – which is not a good idea.

(There’s also a danger, though, that describing capabilities separate from people would again lead us back into Taylorist temptations. We build capabilities into machines and IT, and those capabilities are [usually!] distinct and definable, associated with the entity-type as itself – the entity does the function using the capability. Each entity of that type is interchangeable with any other – in principle, anyway. But real people carry or express or enact or whatever a very complex mixture of capabilities: in terms of those capabilities, each person is different from any other – and even different from themselves, varying day to day, or even from moment to moment – so they are not interchangeable in the same way. The intersection of different capabilities within each person enables and requires fundamentally different approaches as to how we structure and partition work: treating people as interchangeable ‘production-units’ with fixed capabilities and skill-levels quickly guarantees a lowest-common-denominator result, leading to very low overall effectiveness. But that’s another story requiring another very long post! )

As a result of all of this, I tend to regard real-people as somewhat orthogonal to the architecture – they cut across it, but are not in it as such. There are a lot more places where we describe architectural themes that relate to people, and with people, and about people. Yet they’re still not in the architecture – and arguably shouldn’t be.

But the catch is this means there’s still no explicit place for people as people within the taxonomy of the architecture itself: instead, we need to describe them kind of separately-and-in-parallel-with the architecture. Yet is this a problem, in real enterprise-architecture practice? And if so, how much of a problem is it? What impacts does it have?

Suggestions/comments, please?

This is in effect a continuation of the previous post on Zachman and capability, following on from some further comments on Microsoft architect Nick Malik’s original post on business-capability.

Nick kindly described my comments as ‘extremely interesting’, and perhaps even more kindly remarked that:

Your model is the first honest attempt I’ve seen to remove “Actors” from the ZF [Zachman Framework] and replace that column with Capabilities under the notion of “Who.”

He was concerned, though, that changing Zachman’s ‘Who’ to ‘Capability’ means that we then lock out what Zachman also parks under ‘who’, namely organisational structures:

I’d be concerned about your approach, however, because you leave no room for the combination of organizational structures with other architectural elements, because you replaced the organizational structures with capabilities.

But from my view he doesn’t need to worry, because organisational structures are in the wrong place anyway in Zachman: the correct place is under ‘Location’ – Zachman’s ‘Where’. Or that’s part of it, at least. The point is that organisational structures are kludged into ‘Who’ in Zachman because his model is missing an entire dimension (or more than one, in fact). We need to resolve this absence before we can make sense of org-structures in a Zachman-like taxonomy. The main ‘extra dimension’ that I use relates to asset-categories:

• physical (‘things’)
• virtual (e.g. information)
• relational (e.g. links between people and/or groups of people)
• aspirational (e.g. brand, morale, purpose)
• abstract (‘none of the above’, such as finance)

In essence, an organisational structure is a map of relationships between relational locations (i.e. ‘where : relational’ links), in much the sense sense that a physical network is represented by a map of relationships between physical locations. That’s the primitive, but we more often see it as a member of a broader composite: for example, a business-unit is typically a composite of ‘where : relational’ and ‘capability + function’ (i.e. ’service’). Any change to any of the underlying primitives will change the composite, and hence – in that example – the role, purpose and placement of the business-unit.

Nick expressed some concerns about the relationships between primitives and composites, especially in relation to capabilities:

You have correctly stated that capabilities need to be combined with other things to be interesting, and that “molecules can be based on simpler molecules, in the same way that DNA is based on simple molecules.”

Just as you can take a molecule and add an atom to produce another molecule, I believe that you can take a capability and add a relationship to an architectural primitive and get another interesting composite.

But, can we say that capabilities are, or are not, constructed from existing primitives?  That’s an interesting problem, and one that I don’t have an easy answer for.  Just as the effort to move up or down a row in the ZF is more of a transformation than a construct, is it possible that the capability is a construction that sits on a fictional row, above row zero, that represents not one owner’s viewpoint, but ANY owner’s viewpoint?  That, in fact, the capability is a transformation above a composition of people and process?

To me this stems from a slight misunderstanding about the roles of primitives versus composites in architecture: we need to resolve back to primitives in order to understand our options for re-use and redesign, yet almost everything in the real world will be some kind of composite.

For example, on its own a ‘capability’ is almost meaningless: until it’s combined with a function (Zachman ‘How’) into a service, it literally has no function. But by modelling capabilities separately, as distinct primitives, we enable alternate combinations of capability and function to give different effective services (and hence support different processes). This also gives us a better understanding of what’s needed when we substitute one capability for another whilst maintaining the same nominal function, such as in process-reengineering or disaster-recovery.

To me, capability is a nominal primitive, though it has some characteristics of a kind of ‘compound-primitive’. On one side is the asset-type(s) to which it applies: physical, virtual, relational, aspirational, abstract, or any combination of these. (For example, a sales-capability applies primarily to relational assets, but is usually linked to other asset-categories as well – information, brand, product and so on.) On the other side is what we might call the ’skill-level’: rule-based, analytic, heuristic and principle-based. Crucially, machines are only well-suited to the first skill-level, and IT to the first and second; IT can be used for decision-support (but not decision-making) in the third; and is all but unusable in the fourth. Capability-modelling allows us to determine the extent to which IT should and should not be used in a given context, and what human skills will be needed to fill in the gaps.

I would agree that any move up and down the Zachman rows is a transformation rather than a construct. As described in the framework summary – http://tetradianbooks.com/2008/12/silos-frame-ref/ – each row upward is another level of abstraction, and each row downward adds another component to the modelling-requirements. The vertical dimension is also in effect a spectrum of time, from nominally infinite (row-0) to unchangeable past (row-6). So the same nominal ‘capability’ can be viewed in multiple ways, sometimes as “one owner’s viewpoint”, sometimes “ANY owner’s viewpoint”, depending on the chosen level of abstraction – much as the multiple perspectives in data-modelling, from business to logical to physical and so on.

I do take Nick’s point that we could view a (business) capability as “a transformation above a composition of people and process”. Yet if we do so, we’re actually using the same word – capability – to mean two very different things: a primitive of “ability to act on something” (hence ‘capability‘), contrasted with the complex composite of people, business structure, business-relation, function, process, service and capability that we would describe as “the capabilities and role of a business unit”. We can get away with such blurrings in everyday business conversations, perhaps, but we can’t do so in a taxonomy for enterprise-architecture: we need the precision of proper usage of terms, or we’ll end up in an unworkable tangle.

Nick also dropped in a final comment about dimensionality of a taxonomy:

IMHO: The only real limitation of the ZF is the arbitrary notion that any three dimensional representation has to be in the shape of a cube.

I don’t agree that we have to presume a cube (or equivalent ‘pure’ n-dimensional structure) for an architecture taxonomy. For example, the modified Zachman I use is more like a wedge: that ‘asset-categories’ dimension (physical, virtual, relational and so on) is crucially important at the real-world levels (rows 5-6), but we deliberately focus and de-focus on those categories in reviewing the logical-to-physical trade-offs (rows 3-4), whilst the categories are often almost irrelevant in the true abstract layers (rows 0-2).

Some of these points might sound pernickety – as indeed they probably are for basic-level IT-architecture in information-centric industries, for which Zachman’s simple two-dimensional overview is probably adequate enough. But once we extend the architecture to other industries or contexts that deal more with other types of assets – such as manufacturing, logistics, sales, defence – we must cover the full range, or we end up with an artificially restricted scope that is riddled with gaps labelled ‘Magic Happens Here’, because we have no means to describe what needs to occur there.

This also applies to any business-oriented view of IT-architecture, such as SOA, security-architecture or Enterprise 2.0, or enterprise-scale uptake of cloud-computing capabilities. A true enterprise architecture is the architecture of the enterprise as a whole – not solely the architecture of the enterprise IT.

An interesting (well, interesting to me, anyway ) enterprise-architecture discussion on the position of ‘capability’ in the Zachman framework.

This was triggered by a post by Microsoft architect Nick Malik: “Why Business Capabilities Are Not In The Zachman Framework”. (My thanks to Bart Leeten for the initial link.) Nick uses the common analogy with the Periodic Table of the Elements to point out – correctly – that there’s no primitive for ‘capability’ in Zachman (though he doesn’t actually explain why…). The result, as Malik warns, is that some architects think that there’s no need to model capabilities:

But here’s the rub: business capabilities do not appear in the Zachman framework.  This causes confusion among new architects first learning the Zachman framework.  The confusion goes like this: If the ZF is comprehensive, and defines everything that an architect needs, then why does an Enterprise Architect need a capability?  Are capabilities non-architectural?  Should the notion of capability mapping be disregarded by Enterprise Architects because capabilities are not part of the comprehensive Zachman framework?  Should the development of a taxonomy of capabilities be considered a pointless exercise because it isn’t architectural?

As he explains, capabilities are an essential part of architecture: “capability hierarchies are necessary, nay, essential to modern Enterprise Architecture”. From here, though, he draws the conclusion that because ‘capability’ isn’t a primitive in Zachman, it must therefore be a composite, and that we should necessarily model it as a composite: “are business capabilities part of enterprise architecture, even though they cannot be seen on the Zachman framework?  Yes.  For the same reason that molecules are part of chemistry.”

But one possibility he doesn’t seem to consider is that Zachman is just plain wrong. It’s not a viable taxonomy: the rows – ‘Owner’, ‘Designer’, ‘Builder’ and so on – make practical sense, but for the columns he starts with a set of interrogatives – ‘What’, ‘How’, ‘Where’, ‘When’, ‘Who’, ‘Why’ – and then seemingly hunts around at random finding real-world things that vaguely align with those interrogatives. The result is a kludge that sort-of works for a basic and now rather out-dated approach to IT-architecture, but falls apart as soon as we try to use it as a proper structural taxonomy – a ‘Periodic Table of Elements’ for any true enterprise-scope architecture.

Others have pointed out some of these problems: Jean-Paul Vooght, for example, commented on Twitter that Zachman “misses intra-row cross-tables”, whilst CapGemini’s Mike Turner was a bit more sardonic:

Zachman vs business capability is a bit like “why doesn’t my 8-track have I-pod docking station?”

But the problem here isn’t that Zachman is outdated, like an 8-track tape-player: it’s that it’s structurally flawed. To make it work, we need to replace the crude interrogatives with proper taxonomic categories. As I’ve described elsewhere, my recommendation for the respective categories is as follows:

• Asset (‘what’)
• Function (‘how’)
• Location (‘where’)
• Capability (‘who’)
• Event (‘when’)
• Decision/Reason (‘why’)

Each of these ‘column’-categories will crosslink to a set of Zachman-like rows and at least one other distinct dimension of action-categories – physical (‘things’ etc), virtual (information etc), relational (people etc), aspirational (brand, morale etc) and abstract (finance etc). For capabilities, we need to add crosslinks to another set of categories, for skill-levels: rule-based, analytic, heuristic, and principle-based. Linking capabilities to functions defines services; a business-process is a choreographed pathway through sequences of services; and so on.

A ‘business capability’ can be either the same as ‘capability’ in this sense, or merged with organisational structure (in essence, a map of relational locations) as the capability of a business-unit, and so on: the term is often too blurry to be usable reliably within an architecture taxonomy. But by layering different composites of the underlying primitives, we can build up different views of the enterprise that enable us to describe whatever structures may be needed.

So yes, ‘capability’ is not part of Zachman; but Zachman is not usable anyway – not for enterprise architecture, at any rate. We need a better, more robust taxonomy than Zachman to describe the context and scope of each aspect of an enterprise and its architecture.

Realised that the free-download reference-sheets from the Tetradian Enterprise Architecture books would be useful to have up on Slideshare as well, so have uploaded them there for more general accessibility than solely from the Tetradian Books website.

• “A framework for whole-of-enterprise architecture” – the amended-Zachman reference-sheet from Bridging the Silos: enterprise architecture for IT-architects
  
• “A revised TOGAF ADM for whole-of-enterprise architecture development” – the amended-ADM reference-sheet from Bridging the Silos: enterprise architecture for IT-architects
• “Power and Response-ability – a workplace ‘Manifesto’” – the PDF version of the ‘manifesto’ from the Introduction to Power and Response-ability: the human side of systems
  • (note: a Powerpoint version of the ‘manifesto’ is also available on Slideshare)

A minor glitch in that they ended up as ‘Presentations’ rather than ‘Documents’: anyone know how to fix this? There doesn’t seem to be anything about it in the rather limited online help on Slideshare itself: odd…

Hope it helps, anyways.

And the last in the current series of slide-decks that I’ve placed on Slideshare.

This one’s from early 2007, and describes some of the analysis that I did at that period to find ways to break free from the usual IT-centric constraints of so-called ‘enterprise’ architecture. Full title is Whole-of-enterprise architecture: Extending enterprise architecture beyond IT. Some of the slides have been re-used in other presentations in this series, but the detailed content is specific to this example. Hope you find it useful, anyway.

Another item from my slide-deck collection: this one’s based on some work I did for a client in 2007 on extending Zachman and TOGAF to meet their whole-enterprise architecture needs. It describes TOGAF 8, but much the same applies to TOGAF 9.

Another month, another enterprise-architecture conference, in the hope that it won’t be just another more-of-the-same ‘IT-architecture pretending to be enterprise architecture’. This time, at the IRM-UK Enterprise Architecture Conference 2009 (EAC2009) in London earlier this week, that hope actually showed some real signs of fruition.

Sure, there were plenty of signs of the usual IT-centrism. Roger Sessions is one of those still fighting the rearguard for that cause, mainly because he (correctly) points out that there is a very real need for organisations to clean up their IT act, and always will be. (To illustrate his point, there was an excellent presentation from Johan Krebbers, showing how Shell is using a classic TOGAF-style EA in managing the huge complexity of their IT space.) My concern, and that of what is now a rapidly-growing number of enterprise architects at the conference, such as Sally Bean, Richard Veryard, Chris Potts, Anders Ostergaard (Jensen), John Gotze, Kristof Dierckxsens and Nigel Green, is that starting from IT as the primary (or only) focus is the wrong way round for doing EA: we must start from the whole-of-enterprise scope, and only then explore the information needs, in parallel with all of the other needs of the enterprise. It’s startling how few still of the IT-folks manage to grasp this central point, but the wave is growing.

John Gotze and his co-authors may help in that shift with their upcoming book Coherency Management. They describe three distinct tiers of enterprise architecture:

• Foundation – conventional TOGAF-style ‘enterprise architecture’, centred around IT, and with business-architecture (if any) aimed solely at improving ‘business/IT alignment’
• Extended – what I’ve been promoting as ‘enterprise architecture’, covering the whole-of-enterprise scope, but maintained primarily by an explicit (and, in the earlier stages, often quite large) team of full-time enterprise architects
• Embedded – what I’ve described as ‘hands-off’ architecture, in which the ‘ownership’ and responsibility for the architecture is distributed throughout the enterprise and becomes an embedded part of business-as-usual practices, much like security or health-and-safety

As they say somewhat ruefully in their chapter-summary, the ‘Foundation’ level is “the predominant form of EA practiced today”, but we need to be aware of and build towards ‘Extended’ and ‘Embedded’, rather than leaving us stranded in the limited and limiting IT-centric space. I’m definitely looking forward to reading that book when it comes out in a few weeks’ time.

In the meantime, one of the industry’s living legends was also presenting at the conference: John Zachman. It’s amusing that he still hasn’t made it into the Powerpoint age, let alone anything more current: he did his presentation on a museum-piece of an overhead-projector, reading every word off the transparency with a little hand-shaped pointer, like the worst of school rote-learning from half a century ago. And I do still disagree with his core metaphor of ‘engineering the enterprise’, which is fatally flawed by its failure to make any allowance for the fact that, by definition, an enterprise is a social system, not a machine – and that failure inevitably leads to serious problems in the architecture and in management practice. But the real surprise was at the human level: for someone so famous in ‘the trade’, he is such a nice guy! Engaging, warm, personable, genuinely friendly, genuinely inclusive, genuinely comfortable with critique: a real pleasure, and a real example to us all, I suspect!

A very different conference from the TOGAF ones, in many subtle ways: a much stronger emphasis on practice over theory, for example, and on real-world practitioners rather than primarily the large consultancies. The big-consultancy hype was better held at bay, too – much more realism around cloud-computing, for example.

And I had a lot of good conversations with a range of different folks, again most of them in the live practice space. Much appreciated, and most enlightening in most cases. So yes, I’ll be going to EAC when it comes round again next year. Pricey (of course), but recommended.

I’ve now posted on the Tetradian Books website a two-page (single-sheet) reference-sheet on the revised Zachman framework that I use for whole-of-enterprise architecture.

The sheet is an extract from the ‘Framework’ chapters in my now at-last published book Bridging the Silos: enterprise architecture for IT-architects, where the structure of the framework, and the crucial distinctions between ‘primitives’ and ‘composites’, are described in a lot more detail.

Once again, Share and Enjoy, perhaps?

This one’s another follow-up to another new comment to a rather old post – namely Manish Joshi’s comment today to the post on ‘Zachman and TOGAF revisited‘ from back in August last year:

My focus is on extending TOGAF to include SOA.

My approach was to add SOA as a cross-cutting architecture (cutting across BA,ISA,TA & also the governance of TOGAF (since SOA also needs SOA governance).

Roland [Ettema] has also suggested a nice approach above of having SOA in place of IA and making IA a horizontal.

How do you guys compare these 2 approaches and is there any other way around for customizing TOGAF for SOA ?

As many people have discovered the hard way, trying to use the standard TOGAF methodology for SOA seems to work well at first, but will suddenly hit intractable problems that just don’t make sense if we come from an IT-centric perspective. (In fact if we come from that perspective alone it’s almost impossible to see why they don’t make sense – which is why SOA so often seems so damn’ hard…) The actual reason is three-fold:

1. an iterative approach – e.g. an Agile methodology – suits SOA developments best, but TOGAF’s methodology (despite its claims to be iterative) is still essentially a ‘big bang’ approach to architecture development
2. the TOGAF methodology purports to describe the whole of ‘enterprise architecture’, but in fact describes a very narrow IT-centric subset – too narrow even for an IT-centric SOA, let alone a full ’service-oriented enterprise’
3. the TOGAF framework still draws heavily on Zachman, which itself draws on technologies that are at least twenty years old – long before the days of interactive user-interfaces and layered servers, let alone current SOA web-services and service-buses

To resolve items #1 and #2, we need to rework the first half the TOGAF methodology – Phases A to D – with a few lesser amendments in the Preliminary Phase and Phases E to H:

• for item #1 – agile – we split the existing Phase A in half, moving the ‘architecture vision’, documentation, framework skeleton and overall authorisation into the Preliminary Phase, with Phase A amended to focus only on the needs of the specific iteration

• for item #2 – methodology – we expand the scope of TOGAF’s layering of ‘business architecture’, ‘information systems architecture’ and ‘technical architecture’:
  • ‘business architecture’ describes the overlighting business concerns – i.e. Zachman’s ‘contextual’ and ‘conceptual’ layers, with some touch into the ‘logical’ layer, and not the generalised ‘everything not-IT’ grab-bag as described in the present TOGAF 8.1 spec
  • ‘information-systems architecture’ becomes the common interface layer – i.e. Zachman’s ‘logical’ and ‘physical’ layers, but across every aspect of the enterprise, not just the IT [Roland Ettema's placing of SOA here is just one possible subset of this]
  • ‘technology architecture’ becomes the detail-layers across the whole enterprise, not just the IT – e.g. skills, logistics, vehicles, and much else besides, right down to the real-time operations layers

We could use these amended layers as the content and focus for Phases B to D respectively. The catch is that, once we’re tackling a true whole of enterprise scope, we end up with a requirement for an almost endless stream of stakeholder reviews within each phase. So for purely practical reasons I’d recommend using an alternate split for Phases B to D, as ‘As-Is’, ‘To-Be’ and ‘Gap Analysis’ respectively: with this split, the stakeholder reviews become the phase boundaries.

To resolve item #3, we need to rework Zachman itself – a major rework, since a bit of careful analysis shows not only that he’s missing a layer at the top, but an entire dimension of depth (which I’ve described as ’segments’), and also the original content and descriptions for several of his columns are, frankly, a scrambled mess. (His latest revision in effect quadruples the complexity of his framework without addressing any of the core underlying problems – and he’s still stuck in the metaphor of ‘engineering the enterprise’, which does not and cannot work with the complexity and dynamics of real-world systems. But that’s another story for another time…)

But in that rework, what we don’t do is add more columns. The basic principle of What, How, Where, Who, When, Why is sound – the catch is that they don’t necessarily correlate directly with anything in the real world. Instead, we focus on Zachman’s valid principle that ‘architecture is primitives; solutions come from composites’. An interface, for example is a composite – it doesn’t sit in a single Zachman cell. (Depending on the context, it’s a composite of How and Who, plus probably When and What as well.) EA-toolset vendors have made this worse by trying to shoehorn all their models into single columns or single cells. If you add ‘interface’ as a column – which I’ve seen several people do – you end up with a Zachman-like muddled mixture of primitives and composites, which is not a good idea. It may look fine at first, and may seem to make solution design easier; but it really does cause utter chaos later down the track, when the technology changes on you, or when you try to model alternate implementations such as for disaster recovery. In short, don’t shoehorn: primitives are primitives, composites are composites – don’t mix them up.

So for SOA, what we need first is an exercise in meta-models and meta-architecture: we start from primitives of the Zachman frame – single cells – and build a layered set of root-composites (meta-patterns) that describe our key entities. (Meta-architecture is a swine to get your head around, but if you want your solutions to be ‘future-proofed’ you can’t afford to skip over this stage.) Services are a good place to start: they’re composites of How (functions) and Who (capabilities), whilst the messages and trigger-events are composites of What and When. We then build cross-linking composites (functional patterns) that are closer to our implementation layer: a web-service, for example, links a service definition with a message definition with an interface definition. That gives us our logical layer, which we can still specify in a true implementation independent manner – which is what we need for, say, disaster recovery planning. Then we can describe entities (implementation patterns) for the the implementation specific physical layer. Then we can do our SOA designs – which may well traverse IT-based and non-IT-based processes. But because they’re all anchored all the way back to the root-primitives, we have a straightforward trail of derivation and dependency to guide redesign when (not ‘if‘…) we get hit by a change of technology, or context or whatever.

To see how this works, have a look at my presentation for the last TOGAF conference: ‘Enterprise architecture and the service oriented enterprise‘ (PDF, 850kb) – it summarises all of this, together with a broader view of ’service oriented architecture’.

I’m also working on a book on this – Bridging the Silos: enterprise architecture for IT architects – which tackles this general problem of extending TOGAF and Zachman to whole of enterprise architecture. It’s taking a little longer than I’d hoped but there’s a PDF of a partial draft already available up on the Tetradian Books website, at tetradianbooks.com/2008/04/silos-ebook/ – any comments much appreciated!

Hope this helps, anyway.