Tom Graves

Been re-reading Len Fehskens’ presentation “Re-thinking architecture” [may require login] at the last TOGAF enterprise architecture practitioners conference in Munich. His intro [public] indicates at last a fundamental shift in thinking about enterprise architecture, away from the inane IT-centric world towards a real architecture of the enterprise:

Most thinking about IT architecture as a discipline has been shaped by the ideas of the software architecture community, which in turn grew out of the software engineering and structured programming initiatives of the late ’60s and early ’70s.  Increasingly, though, IT architecture is less about programs and more about solutions and enterprises, of which software is only a part.  Does this shift in the focus of IT architecture require a corresponding shift in the way we think about architecture?  Many practicing solution and enterprise architects believe it does, and this session will re-examine the role of architecture from this perspective.

Gratifyingly, or perhaps worryingly, there were several slides which were all but identical in mood, if not content, to my own presentations at TOGAF Paris, eighteen months ago (“Unpacking TOGAF’s Phase B: business transformation, business architecture and business buy-in” - just discovered it’s not up on the Tetradian site, an oversight which I must remedy Real Soon Now ) and at TOGAF Glasgow earlier this year (“Enterprise architecture and the service oriented enterprise” [PDF] - and that one is up on the Tetradian site!). He even included one slide which used exactly the same New Yorker cover to illustrate the limitations of an IT-centric perspective.

(Likewise Business Architecture lead Dave van Gelder’s intro to the session, and Open Group Fellow Walter Stahlecker’s presentation “The quest to apply architecture holistically” (summary and PDF [may require login]) often seemed to be echoing what I’d presented at those conferences and discussed with them in person: “…the implications of addressing architecture of an entire enterprise … possible adaptations of TOGAF for use with the whole enterprise…” and so on, with again some of the text and diagrams that could easily be said to be drawn from my previous presentations. Gratifying in one sense, yes, and all of them nice guys, earnest and honest and genuinely committed to what they do; yet it’s still a trifle galling that I didn’t get any acknowledgement for it at all. A passing reference to “builds on work by … the TOGAF Business Architecture Working Group”, perhaps, but that was it - a ‘working group’ which they’d offically excluded me from last year, and asked me to join this year, but then in effect asked me to pay them several thousand pounds to be ‘allowed’ to correct the disastrous mistakes in TOGAF’s design, and hadn’t bothered to contact me since. So yeah, I will admit I’m more than a bit miffed about it all: be nice to get some acknowledgement for all the work I’ve done, and even - though I’ll accept I ain’t holdin’ my breath for this - ‘twould be nice to actually be paid for some of it too… Hey ho…)

But there was one slide in Len Fehskens’ presentation, ‘Architecture vs Design’, which to me was new, and which gives a very useful tabular comparison of the differences between architecture and solution-design. A handful of examples:

• Architecture: about the entire entity in its environmental context; Design: about components and subsystems of the entity
• Architecture: a different architecture implies a different mission; Design: different designs may address the same mission
• Architecture: defines a class of acceptable solutions; Design: defines a single specific solution
• Architecture: role of the architect is mostly to make correct inferences; Design: role of the designer is mostly to make correct decisions

The last item triggered a fair bit of discussion: Len was trying to show that architecture and design are fundamentally different, but wasn’t quite getting his point over - especially to some of the non-English speakers, for whom ‘inference’ and ‘decision’ seemed essentially to be the same. It was only later that I realised that the critical difference there is around a linkage between two other themes that Len had mentioned, about ‘values’ versus ‘business-value’, and architecture as ‘upstream’ requirements versus design as implementation of ‘downstream’ requirement. So here’s my suggested addition to that list:

• Architecture: explores the values of the business to derive its structure and logic; Design: uses the structure and logic of the business to derive business-value

Design operates within a logic; architecture creates that logic. By definition, logic cannot assess the validity of its own premises; it needs an alogical process outside of itself to do so, and that’s the real service (or one of the key services, at least) that architecture provides. To many people in business, and perhaps even more in IT, architecture often seems vague and blurry and indefinite - but that’s what an alogical assessment of values will need, from which to derive the business logic which the designers can use.

Something to think about, anyway.

And yeah, for the reference to the Open Group folks in general: please note that you did see it here first? Oh well… the joys of the Outsider again, I guess…

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.

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

The sheet is an extract from the ‘Methodology’ chapters in my still somewhat delayed book Bridging the Silos: enterprise architecture for IT-architects, where each step of the adapted ADM is described in a lot more detail.

Share and Enjoy, as usual?

I hadn’t intended to go to TOGAF Munich this week, but a chance email from Jos van Oosten (the lead for the SqEME process framework, over in the Netherlands) got me glancing at the conference agenda - and what I saw there sent me scurrying to search the web for suitable flights. It was previously advertised as being solely about system security - which isn’t my bag at all - but the Tuesday sessions suggest that they’re at last breaking out of the IT-centric rut and getting to grips with whole-of-enterprise architecture - which would be very good news if so… So yup, I’s headin’ there kinda quick to find out, and see which way that wind is blowing.

One side-effect is that I’ve rather hurriedly ’staked my claim’ to the rework I’ve done on adapting the TOGAF Architectural Design Method (ADM) for use at the whole-of-enterprise scope, with a two-page / single-sheet reference-sheet now posted up on the Tetradian Books website. (Doing this before their conference presentations should verify that I did indeed get there first. ) More on that in the next post. Some time in the near future I’ll also post an equivalent ‘cheat-sheet’ for the revised Zachman framework for whole-of-enterprise architecture.

And although I’m still some weeks away from completing Bridging the Silos, I’ll also post an updated draft on the publishing website, to include the material I’ve slowly been adding over the past few months. Apologies that it’s taken so long, but I’s been kinda distracted…

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.

This one’s a follow-up to a comment by Stanly Johnson yesterday to my “TOGAF Certified” post of almost a year ago:

I feel the IASA skill set and TOGAF (and other) frameworks are essential.

IASA skill set do prepare an individual to become an architect.

Frameworks tells us how to architect a system

The important point here is, you need to learn the skill sets and you also need to understand some matured frameworks and then design (or redesign) your enterprise architecture.

Can you design a system without having the basic skill sets (like IASA), by only mastering an architecture framework (like TOGAF)? Yes, but then you are lucky. Lucky that the methods, tools and patterns specified suited your organization.

Can you design a system only by learning the basic skillsets and not even looking into matured frameworks, Hmm yes, then you are a genius. How many organizations HR will know that you are a real genius?

Your comments are highly appreciated.

I’d agree about the value that IASA provide in terms of skill-sets for IT-architects. The problem is that what we’re talking about here is real enterprise architecture - whole of enterprise architecture - of which IT ‘enterprise architecture’ is merely one small subset. And there are no standard frameworks or skill-sets for that as yet - in fact what we’re doing right now is creating them, for the next generation of architects.

Unlike The Open Group, IASA did recognise right from the start that real enterprise-architecture is a great deal broader than just IT. But at present - and wisely, in my opinion - they’ve concentrated on the IT end, because that’s where the immediate need is.

One aspect of my comment about ‘TOGAF Certified’ was really about exactly the point that Stanly made: how would HR departments know that I know what I’m talking about? The need for some kind of proof of competence goes right back to the days of the masonic handshake - a literally tactile proof that you’d been trained to a level where your cathedral wouldn’t come down on people like, well, many tons of bricks… And although, for what I do, the TOGAF certification doesn’t mean all that much (given that it covers only a tiny subset of the scope I need to address in my work), it’s about the nearest to a generic architecture certification that I can get. IASA certification sounds like a good idea, but in practice it leads me further away from where I need to be - it’s specific, specialised to IT, whereas my emphasis is on whole-of-enterprise integration.

To give a specific example, look at the difference between data architecture and information architecture:

• Data architecture deals mainly with logical models and logical-to-physical transforms. In Zachman terms, it sits happily and comfortably within those two levels (’logical’ and ‘physical’) of a single segment (’virtual’) of a single column (’What’). Plenty of custom-built toolsets exist for this purpose - ERWin, for example, or the data-modelling components of System Architect. It’s (relatively!) simple and straightforward; and though it requires real skill, it’s relatively easy to learn via training - and hence appropriate for straightforward certification of competence.
• Information-architecture deals mainly with business-oriented information - particularly counts-of, averages-of, trends-0f, comparisons-of and other complex derivations and aggregates. Although it seems to end up as ‘virtual-What’, it does not sit there - in fact it often pinballs around the entire Zachman frame, through business-rules (’Why’), transform-functions (’How’), skills and heuristics (’Who’), trigger-events (’When’) and much more besides, at every level from real-time operations upwards. Trying to model this in a data-architecture tool such as ERWin is a bad joke (says he from bitter experience…); and despite the claims of the vendors, there are no EA toolsets that come close to tackling this properly. Almost invariably there will be many hand-overs between IT-based and non-IT-based transforms - so a strict IT-centric approach (as in way too much SOA at present…) is going to cause big problems. Doing this work requires a high level of skill, which depends on a great deal more experience than a straightforward training-course; and some at least will be highly context-specific - making certification extremely hard, or dubious at best.

And information-architecture itself is just one subset of real enterprise architecture - which is what I’ve been trying to describe for the past ten years or so. And although, yes, I do use “matured frameworks” where they exist - and yes, I do know how to adapt those to the different contexts we find in different organisations - they don’t cover more than a small portion of the scope we need, and half the time we have to do major surgery to those frameworks to correct for the impact of their mistaken assumptions about the supposed centrality of IT.

(An aside: back in the late ’70s, in the early days of micro-computing, it was generally accepted that the worst qualification for working in the field was computer-science - because graduates came to the problems with mindsets, assumptions and experience which were great for big mainframes and DEC-11s, but entirely wrong for the very different trade-offs with CP/M and Z80s and 6502s. The best qualification was linguistics, followed by arts degrees in general - especially graphic design, which was my background then. We have the same kind of problem here in real enterprise architecture: without careful ‘conversion training’, IT-architecture background and experience can often be more of a hindrance than a help.)

So there are no standards or certifications for that whole-of enterprise level. Real enterprise-architecture - rather than IT-architecture getting grandiose ideas about its own importance - is still way too new for that: and to be blunt, I’m one of the few people who’s actually working to create those broader standards, and to show why it’s essential to break free of the IT-centric mindset. Hence when Stanly asks “How many organizations HR will know” that I know what I’m doing with this kind of architecture, the short reply would have to be a sardonic “Tell me about it…” - I struggle to get them even to begin to grasp what I’m talking about at all, let alone get to the level of checking my credentials… Hey ho…

Stanly correctly emphasises the need for both skill-sets and frameworks - rather than trying to get by with just one or the other - but I’d also add that there’s at least one other key component for which we’re likely to need certification: governance. In an IT-centric context I’d recommend at least a base-level ITIL certification, and probably PRINCE2 and Six-Sigma as well. But at the whole-of-enterprise level? - well, who knows? We ain’t there yet - not by a long way. My guess is that something like a cross-merging of ITIL, TOGAF, PRINCE2 and some of the SOA-governance themes will come out of this work - but it’s probably five years away at least. In the meantime… well, we just have to do the best we can, yes?

It’s taken me about three days to wind down after the flat-out networking / talk-fest that was the TOGAF conference. Today I’ve had to plough my way through something like 45 presentations and half a dozen complete books on various aspects of enterprise architecture just to be able to write all of my ‘thank you it was great talking with you’ emails…

But yes, reviewing all those presentations has reinforced that sense of a quantum shift in understanding as to what enterprise architecture actually is - namely the architecture of the enterprise as a whole, not just its IT. The big driver for the change seems to be SOA (service oriented architecture) - seems the IT types are discovering that they can’t get it to work without extensive business involvement. Hmm…

Was not wonderfully amused to discover that a fair bit of what I said last year, which at that time they pretty much dismissed out of hand, is now all but word-for-word in their ‘new’ description of ‘business architecture’. Humph. At least it is getting through, though.

Felt bizarrely jetlagged for at least a couple of days after coming back - odd because it’s only an hour’s flight and it doesn’t cross any time-zones, but it still feels like jetlag. Didn’t help that the flight was an hour and half late getting in to Stansted, which meant I was decidedly late for meetup in London with Dave Snowden and the Cynefin / Cognitive Edge crew. Glad I did, though, because I had some great conversations about organisational complexity which dovetailed really nicely with the enterprise architecture ideas from earlier in the week.

A real sense of movement happening in both spaces, and worthwhile movement at that. Good.