Tom Graves

Celebrate with me, perhaps? Bridging the Silos: enterprise architecture for IT-architects has at last gone off to press - hooray! Somewhat dependent on production-schedules at Lightning Source, but print versions should be available before the end of the month; at a guess, the e-book version should be available from IT Governance before Christmas, but I’ll have to check.

Unlike most of my books, this one’s been a real marathon: some seventeen months and (according to the Word-file statistics) almost 1700 hours of edit-time and more than 130 saved-versions. Dunno why it’s been so hard, but it has. Oh well.

The ‘sample version‘ is up on the Tetradian Books website, of course. But as a ‘thank you’ to all of you who’ve contributed comments and suchlike, I’ll place a full version of the e-book on a private server until the New Year - Tom’s ‘thank you’ Christmas present to everyone! Please email me if you’d like a copy, and I’ll send you the link. (Easiest way is probably to add a comment to this post - if you include your email address in the form but not the body, it doesn’t appear on the web.)

Now, for my next book…

Still recovering somewhat from a thoroughly nasty run-in with a guy named Wolf, on an on-line list about future vision for enterprise-architecture. (For obvious legal reasons, I’d probably better not give any more details than that.) To give some idea, he proudly claimed to be “a man of science”, but amidst a stream of insults - “whining”, “hapless”, “technophobic” - and sarcastic put-downs - “poetic wailing”, “now, for everybody who is still capable of independent rational thinking” - this was what he apparently considered to be a rational argument about the process of enterprise-architecture:

Keep dreaming Tom, and if your dreams also bring you some pay checks, I honestly envy you. Beware, though of the bad economy: less and less bosses are willing to pay for dreams.

He’d started off in the wrong direction anyway, because whilst we were talking about developments in how to do architecture at the whole-of-enterprise scale, his vision for EA, he said, was cloud-computing - in other words, a minor subset of content, not process. It became clear very quickly that whilst he certainly knew his stuff about technical-architecture and IT-based process-modelling, he was completely out of his depth in anything else - particularly business-architecture, whole-of-enterprise architecture, the process of visioning, and in some ways even the process of science. What he did manage, and manage well, was a startling degree of pseudo-scientific arrogance:

I have founded this group for those EAs who feel themselves rather a part of scientific community, using exact terms of scientific discipline to create exact solutions and extrapolate them to the future, rather than part of the order of augurs that make gibberish predictions because they not only cannot foresee the future but are unable to understand the present.

As any real practising scientist would know, we cannot predict ‘the future’: we can sort-of predict ‘a future’ for something which operates only within a defined set of premises, but the real world won’t confine itself within any such convenient constraints. And this, for example, was his ‘First Postulate’ for his ’scientific’ enterprise-architecture:

Modern Enterprise cannot run its Business Model without computing means;

Which is fair enough, in a sense - but it’s not science. There’s no rationale behind it: it’s just a religious-style Great Truth, floating in mid-air, without context and without anchors into the real world - where, in disaster-recovery, ‘Modern Enterprise’ may suddenly find it’s physically lost those ‘computing means’, and has to find a way to run its ‘Business Model’ without them. I was trying to explain that that is what an extended EA would need to cover - but he would have none of it at all. Cloud-computing was it: nothing else mattered.

And in effect, he did the classic TOGAF trick of thinking that the label of ‘business architecture’ in itself resolved all the issues about how to handle ‘all the architecture stuff that’s outside of my area of interest’:

EA has evolved and now includes, among others, distinct disciplines of Enterprise IT Architecture (EITA) and Enterprise Business Architecture (EBA), both well-formalized disciplines. EBA includes EITA plus to business-specific acumen like Accountability (people) and others. Everyone can just google or wiki Business Architecture and learn its definition.

Your ‘EA’ somehow includes ‘everything’ (do not know how - no definition) but does not include BPM, which is the common basis of and the bridge between EBA and EITA. For me all this makes the professional level of this discussion very low. It is a warning.

Apart from, again, the startling aggression and arrogance, real EA practitioners would notice the error here: he’s blurring high-level strategy, human factors such as accountability, and low-level process-mapping (BPM) all into the same randomised ‘EBA’ - the classic ‘business-architecture = everything not-IT’, without any means to separate out all the distinct interfaces and interdependencies. As for the comment “Everyone can just google or wiki Business Architecture and learn its definition”, it was obvious he’d never done so himself: if you try it, you’ll find that there are a near-infinity of would-be definitions, most of which seem to be mutually contradictory. :wrygrin: Far from being a “well-formalized discipline”, as Wolf claimed, the whole field of enterprise business architecture is still a disorganised shambles - a fact that anyone actually in the trade would admit straight away. Getting some sense of order into that mess is part of what the whole-of-enterprise architecture project is all about.

At first his aggression was directed solely at me; but then he realised that the other contributors weren’t joining in on the attacks, but instead were agreeing with what I’d said, and then adding further examples of their own (which was, indeed, what I’d hoped the discussion-thread would do). After he found that attacking them too didn’t work either, he pulled out the ‘I’m the boss here’ tactic:

I, as a specialist and the manager of this group, have said enough. Those who have ears, will hear. From now on, I will observe this discussion, as I do with others, unless I am explicitly asked by any participants to express my mind. Your right to express whatever weird views you want is limited by my right to end a discussion if I see it as compromising the group goals.

Metaphorically speaking, I could see a small boy, pouting in petulant rage at not getting his own way in some game, saying “it’s my bat and ball and I’m taking them and going home and then you won’t be able to play any more, so there!!” Which he did: he killed the thread, and, unsurprisingly, also my membership of ‘his’ list.

The whole affair has left a thoroughly nasty taste in the mouth:  I haven’t met that level of aggressively unprofessional conduct since dealing with a group of self-styled ‘pro-feminist’ men in a social-work context in the early ’90s. Though the same overall problem, I notice: the same obsession in asserting that the one very small subset of an issue - the subset that they (somewhat) understand and for which they purport to have ‘the answers’ - is the whole of the issue, combined with violent personal attacks on anyone who inadvertently threatens that quasi-religious belief. Odd; yet in some ways quite dangerous, especially for others.

But despite that, at least the thread did produce a lot of good ideas, and the interactions with the others in the discussion - particularly a guy called Richard, from Siemens - were definitely worthwhile. Since the content has been killed in its original source, I’ll put some of it up here in subsequent posts.

More later, then.

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…

Diana Stobart Wild’s other question on the LinkedIn business architecture forum was about frameworks:

What is Business Architecture? What does a Business Architecture Framework look like?

I think of Business Architecture as a subset of Enterprise Architecture that describes the business from the Strategy down to the enterprise business models (process, data, business rules, etc.). Business parts of the Zachman Framework? Thoughts? Comments?

My response was as follows:

I’d agree that Business Architecture is a subset of Enterprise Architecture, as long as you don’t fall for the TOGAF-style trap of thinking that enterprise-architecture is only about IT!

Business-architecture proper is the strategy layer (Zachman row-2 and upward, also bridging down into row-3).

The jumbled mess of what’s otherwise called ‘business architecture’ only exists because TOGAF and the other IT-centric ‘EA’ frameworks essentially used the term as a generic dumping-ground for ‘everything not-IT’. Instead, think of the remainder of what TOGAF calls ‘business architecture’ as two distinct layers: the logical or integration layer - the equivalent of TOGAF’s ‘Information Systems Architecture’, Zachman row-3 to row-4 - and the physical or implementation layer - the equivalent of TOGAF’s Technology / Infrastructure Architecture, Zachman row-4 to row-5.

Zachman’s structure of layers still works fairly well for this - the only essential change is an extra ‘row-zero’ for compatibility with the Vision layer of ISO-9000:2000. But it does need some serious rework on the columns: for a start, there’s an entire dimension missing, to handle distinctions between physical assets (things), virtual assets (data etc), relational (what your CRM is all about!), aspirational assets (morale and the like), and abstract (such as the financials that your business people do want in their models!); the same for locations (physical, virtual, relational etc) and so on. Still a month or a so away from finishing my book on this, “Bridging the Silos”, but see the ‘Framework’ chapters in the current draft at http://tetradianbooks.com/2008/04/silos/ .

One point that Zachman did get right, but most of the EA-toolset vendors seem to have forgotten, is the key distinction between primitives and composites. As Zachman says, architecture is about primitives (TOGAF’s ‘Architecture Building Blocks’, or ‘ABBs’), whilst solutions come from composites or patterns (TOGAF’s ‘Solution Building Blocks’, or ‘SBBs’). The Zachman Framework is a taxonomy of primitives - root-level entities, some of them fairly abstract; composites are structured collections of primitives that straddle the columns, making up patterns for re-use.

Composites are usable to the extent that they’re architecturally ‘complete’ - i.e. straddle all of the columns - but are re-usable to the extent that they’re incomplete: for example, a BPMN process-model says nothing about ‘Where’ or ‘Why’, so can be re-used in different locations and (in principle) for different purposes. At the mid-layer of the framework, you need to be able to describe a process in abstract terms, to identify KPIs and CSFs and so on; you’d define different SLAs as you go down towards different implementations - manual, machine, IT, etc, but they should all use the same KPIs etc. This is important because if you’re not able to anchor the detail-layer composites into their component sub-composites, all the way down to their root-primitives, you won’t be able to see options for redesign, such as for disaster-recovery or process-reengineering. Think of the classic IT-centric blunder of assuming that every problem must always have an IT-based solution… your only way to avoid that trap is to use a non-IT-centric framework that covers the true whole-of-enterprise space.

Over the past few years I’ve done quite a bit of work on a ’service oriented enterprise’ framework, based on the classic Stafford Beer ‘Viable System Model’ - see the Wikipedia summary at http://en.wikipedia.org/wiki/Viable_System_Model . We extended this at Australia Post and elsewhere to include support for quality-systems, security-management and so on. Again, there’s still some way to go, and the book is probably at least six months away, but there’s a summary in my article on the service-oriented enterprise in the current itSMF “IT Service Management Global Best Practices” book (see http://www.vanharen.net ) and in my presentation to the TOGAF Glasgow conference back in April (see PDF at http://www.tetradian.com/download/togaf_ea-soe_apr08_FV.pdf ).

Been following a ‘business architecture’ thread on LinkedIn, and came across a couple of discussion-questions by Diana Stobart Wild, who seems to be an enterprise architect somewhere in the north-east US. Thought it might be useful repeating here what I wrote there, as it’s all fairly generic but does summarise my current approach to business-architecture.

Her first question was on business-architecture tools:

Which tools are in the Business Architect’s toolkit?

to which I replied as follows:

If you come from an IT-centric architecture background, the first need is to realise that the standard EA view of business-architecture is a mess - it’s essentially a random grab-bag of ‘everything not-IT’. So you need first need to sort it into the business equivalents of TOGAF or FEAF’s three layers, such as:

• strategy and policy (real meaning of TOGAF’s ‘Business Architecture’ - Zachman row-3 and above)
• tactics and system design (equivalent of ‘Information-systems Architecture’ - Zachman row-3 to row-4)
• process implementation (equivalent of ‘Technology Architecture’ - Zachman row-4 to row-5 [and, in past tense, row-6])

For the strategy layer, one obvious tool is BRG / OMG’s Business Motivation Model [PDF]. It has some flaws - particularly its dangerous mishandling of ‘Vision’ - but it’s a good starting-point. Several EA toolsets implement the BMM, though sometimes under different names: for example, IBM/Telelogic System Architect calls it the ‘Enterprise Direction’ model.

For the middle systems-layer, to be honest, I don’t know: we’ve been doing a lot towards modelling that space - see my book “Real Enterprise Architecture: beyond IT to the whole enterprise”, at http://tetradianbooks.com/2008/04/real-ea/ and the current draft of “Bridging the Silos: enterprise-architecture for IT-architects”, at http://tetradianbooks.com/2008/04/silos/ - but there’s still a fair way to go yet. Troux’s ‘Metis Enterprise Architecture Framework’ covers [covered? it may not still exist…] a lot of the space, but as usual ends up being too IT-centric for real business-architecture use. Even so, Troux is probably the best bet at present: in my experience, to be blunt, most of the other well-known EA toolsets are so obsessively IT-centric that for business-architecture they often seem more of a hindrance than a help.

At the process level, there are plenty of tools and models available, many of which are not inherently IT-centric, such as all the IDEF and TQM and Six Sigma toolkits. Some IT-centric tools can be re-used in a non-IT-centric way, too: you can use BPMN for implementation-layer business-architecture modelling, for example, once you realise that the Process entity doesn’t care how it’s implemented unless you really need to translate across to BPEL; and the ‘Data Object’ entity doesn’t need to be data, but can actually be any type of asset - physical, virtual, relational or whatever.

Another tool I’ve found invaluable for understanding complexity in business-architecture, and the boundaries between what can and can’t be handled by IT, is Cynefin - see the Wikipedia summary at http://en.wikipedia.org/wiki/Cynefin , also Snowden, D & Boone, M “A Leader’s Framework for Decision Making” Harvard Business Review November 2007.

Been thinking for quite a while now that there’s a significant difference in enterprise architecture styles between ‘big countries’ - particularly Britain and the US - and ’small countries’ (smaller population rather than smaller size) such as Australia, New Zealand, Canada, South Africa, Sweden, the Netherlands and so on. Following this post from John Gøtze - ‘Aligning the Ducks‘ - I’ll have to include Denmark in that list as well.

John’s post is an interview with Gary Doucet, Chief Architect for the Canadian Federal Government. (He was a keynote speaker at an Danish Government architecture conference in Århus in April - hence the Denmark connection.) What’s clear from the interview is that there in Canada the entire architecture process is business-driven - not IT-driven. In fact there were only passing references to IT and CIOs and the rest of the IT-centric stuff: instead, the emphasis was on business-centric themes such as their Business Transformation Enablement Program and Municipal Services Reference Model.

That’s the big difference: the ‘big countries’ EA is still clinging (with increasing desperation?) to the IT-centric view, whereas the ’small countries’ EAs have long since recognised that it’s a dead-end, and that we must wrest control of EA from IT if we’re going to get anywhere worth while.

Yet another reason why it’s so damn frustrating being here in Britain: it should be a powerhouse in EA, and yet by comparison with Australia it feels like a stagnant backwater. But I’s here for the while, so just have to get on with what I have and where I am, I guess. Hey ho.

But go look at John’s interview with Gary Doucet: a solid sense of realism there, rather than the usual US/GB IT-centric hype. Recommended.