Tom Graves / Tetradian

One of the most essential tasks in enterprise-architecture is that of enabling conversations on architectural issues, with any groups of stakeholders, anywhere across the enterprise.

Our toolsets play an important role in those conversations. The right tool used in the right way can really help the conversation, help create new shared understandings across the silos and the specifics of each distinct discipline.

But the wrong tool – or even the right tool used in the wrong way – may instead act as a real barrier against awareness and understanding. Getting the balance right is critical to creating the clarity we need – yet the requirements, and the balance, are different for every type of architecture-conversation.

We’ve long had a good range of frameworks and toolsets for IT-oriented architectures. Some were aimed more at systems-development; others more at taxonomy and ontology and metamodel-development; others again at modelling dependencies across IT systems and ‘business/IT-alignment’; and yet others at requirements-traceability, governance and project-management. Yet they all had one thing in common: their whole focus was about precision, about certainty – because that’s what system design and development really needs.

But as enterprise-architecture at last begins to break out of the IT-centric box that it’s been trapped in for the past couple of decades, we start to hit up against some real limitations of those toolsets:

• most of the underlying metamodels and model-types are still very IT-centric
• user-interfaces are usually complicated, abstract, often intolerant of error, and in some cases even downright ‘user-hostile’
• most of the tools – especially at the high-end – are too expensive for general use
• diagramming is usually abstract (‘boxes and lines’) rather than ‘real-world’ (trucks, people, machines, servers, cables etc)
• support for versioning and for tentative ‘what-if’ experiments ranges from poor to non-existent
• none of the user-interfaces are well-suited for use in real-time exploratory conversations

There’s also still no common exchange-language to transfer architecture-information between the tools that we already have – and even when we get one, we’ll need it to go wider than that, anyway. A lot wider.

When we look at how we actually work with executives or process-designers or security-architects or the like, the tools we most often use at present are a whiteboard or a sketchbook – nothing else has the flexibility that we need. None of the existing tools allow us to play ‘what-if?’ as well as we can on a whiteboard; and the precise formal rigour of model-validation is far more of a hindrance than a help in this kind of work, where half the time we don’t even know what kinds of architectural-entities are involved – the whole point is that that’s what we’re aiming to find out!

But we still need some kind of toolset-help here: images on whiteboards and sketchbooks aren’t easy to share – I’ve often seen people simply photograph the results and pass the image-files around as ‘the model’ – whilst office tools such as Visio and Powerpoint give a spurious illusion that the results have been captured with enough rigour to be re-usable (which they’re not), and are usually too slow and cumbersome for an across-the-table discussion anyway.

So here’s our challenge: develop a toolset for the ‘conversations’ end of the enterprise-architecture spectrum – one that will work on laptops and netbooks, on the new tablet and touchpad systems, and preferably right down to smartphones as well.

It needs to be able to cover any aspect of enterprise-architecture – from business-models to skills to security to process to disaster-recovery to operations to knowledge-management to applications to service-management to IT-infrastructure to building-infrastructure and anything in between.

It needs to be able to adapt itself to the needs and worldviews and language of each of those groups of stakeholders – and provide some means of translation between each group, too.

It needs to be fast, easy to use, engaging, enjoyable, preferably tactile too – yet have a fully-structured methodology and metamodel behind it.

It needs to allow freeform development of models and diagrams – yet still be capable of linking to the formal rigour of the ‘top end’ systems.

Coming the other way, it needs to help us explain the structures and reference-models that we already have in our ‘top-end’ systems – and explain the reasoning behind those models, too – whilst still keeping people actively engaged in the conversation.

And more and more, architects are beginning to recognise that spurious certainty is a real risk for the enterprise – so this also toolset needs to help our stakeholders become more comfortable with uncertainty and change.

Working with a loose consortium of colleagues – including Adrian Campbell, Kevin Smith, Milan Guenther, Nigel Green and others – we’ve done a fair bit of work on this already:

• preliminary metamodels and file-structures
• probable user-interface workflows on tablet (mouse/stylus) and touchpad (finger) interfaces
• probable user-experience interactions in multi-stakeholder conversations
• some suggested methodologies
• some key features, such as AudioNote-style synchronised voice-recording and Prezi-style zooming ‘infinite’ workspace
• support for a broad user-extensible range of model-types – potentially-unlimited, including user-defined types
• support for indefinite nesting/layering of models and model-types
• support for freeform-drawing, notes, embedding of user-selected icons and images
• support for reports that enable us to describe some or all of the enterprise as a story

There’s a lot more to do to get this even to an alpha-release state in any format or platform; and whilst all of us, in the group so far, have ‘done our time’ in software-development and the like, none of us is sufficiently available (or, in my case at least, really up to the speed or quality needed) for professional-level app-development on current systems. So we’re going to need help to make this happen.

I for one would prefer to see this as an Open Source or at least freeware/shareware type of development, so as to get this out into as general a usage as possible. (As I see it, this kind of toolset should have many other applications outside of enterprise-architecture, such as in strategy-development, tactical planning etc.) But if some commercial developer wants to take it on, that would be fine too, as long as we can keep the final end-user cost down to app-levels (perhaps $10-30 at most) rather than the three-, four-, five- or even six-digit sums we sometimes see for other toolsets.

So: over to you. Any offers of help or advice? Any other comments or suggestions?

At last – at last – there’s now a ‘framework for enterprise-architecture’ that’s actually worthy of that title.

(Many thanks to Craig Martin of Australian consultancy Enterprise Architects for the Tweet that brought this to my attention, though I suppose I ’should have’ known about it already… )

The framework is called TRAK, (The Rail Architecture Framework) originally developed in 2009 for the London Underground, but now published as an open-source project on Sourceforge:

• TRAK metamodel [download is .PDF] (and metamodel-project website on Sourceforge)
• TRAK viewpoints [download is .PDF] (and viewpoints-project website on Sourceforge), in accordance with IEEE1471 / ISO42010
• TRAK UML profile [download is .XML] (and UML-profile project website on Sourceforge)
• TRAK MDG add-in for Sparx Enterprise Architect toolset [download is .ZIP] (and MDG add-in project website on Sourceforge)

There’s more detail on TRAK’s background and the MDG add-in on the website for Eclectica Systems – the originators of TRAK – and also a brief project-description from IET (The Institution for Engineering and Technology).

The framework is based on MoDAF, the architecture framework used by Britain’s Ministry of Defence (which in turn was adapted from DoDAF, the [US] Department of Defense Architecture Framework). As the TRAK Wikipedia page explains:

The TRAK Metamodel is a simplification of the MODAF 1.2 metamodel. It has removed and redefined stereotypes and any defence-specific constructs have been removed. … Significant changes include:

• System is central to TRAK and can represent hard systems and soft systems (in MODAF 1.2 System is an artefact and part of the Physical Architecture and cannot include non-physical parts)
• TRAK can represent any type of interface / flow – information, energy or materiel
• TRAK can represent exchange characteristics associated with human resources – Organisations, Jobs and Roles
• other types of dependency and associations can be represented – physical, membership, responsibility extent
• addition of ISO/IEC 42010 concepts to represent the architectural task
• addition of consistency rules that constrain how and in what order relationships can be made

With MoDAF’s defence-specific items removed, the TRAK metamodel covers the full scope of an enterprise – for example, clear distinctions are made between information-resources, machines and people:

Although in a few places this does show its physical-engineering heritage, in effect this is a generic high-level metamodel suitable for use in enterprise-architectures for any type of organisation. (This is a very important contrast to the metamodels in TOGAF or even in Archimate [Business, Application and Technology layers], which at present are effectively usable only for IT-centric architectures in information-oriented enterprises such as banks, finance, insurance and the like.)

Note also that, as I’d argued in my post on ‘A question of Who‘, the Human Resources section of the metamodel does not include any reference to real-people. It describes what people do (Job, Role), their relational location (Organisation) and their capability (Competence), but – correctly, to my mind – it does not attempt to include people as themselves.

There’s a lot of detail in this framework: 90+ pages in the metamodel description, another hundred pages or more in the description of the viewpoints. I’ve haven’t read all of it as yet, but so far feels solid, comprehensive and, well, just right, really. (Part of that, I suppose, may be because I’ve spent so much time in engineering and logistics environments – where the information is often more about physical things than merely information-about-other-information – and in other contexts where people need to be viewed as people, rather than solely in terms of information-about-people.)

What’s missing? Well, it’s based on DoDAF and MoDAF, and hence, like them, it only covers the information-description side of  an enterprise-architecture framework: it doesn’t provide any methodology. One option for a methodology would be to use the TOGAF ADM, as described in an Open Group white-paper by Terry Blevins et al on bridging TOGAF and DoDAF: the catch there is that the ADM’s structure is inherently IT-centric, which would rather work against the whole point of TRAK as covering a broader scope. Another (and arguably better) alternative would be to combine that with the modified version of the ADM that I use in my own architecture-work, because – like TRAK – it’s explicitly designed to cover any architecture scope. And another good option – as Craig in fact suggests in his Tweet – would be to link it to the methodology in PEAF, Kevin Smith’s ‘Pragmatic Enterprise Architecture Framework’.

Anyway, definitely worth a detailed look. Even from a fairly cursory review to date, my own strong opinion is that for TOGAF-type architecture-developments that could touch any space beyond IT, we should all standardise on something like this as a base-metamodel, rather than the as-yet unusably-incomplete one provided in the TOGAF 9 specification.

Recommended – very recommended.

Comments, anyone?

[Update: 15Aug10] Philip Allega of Gartner tells me via Twitter that even though it was only developed and released last year, TRAK is already considered obsolete: “EA leads at TfL [Transport for London] and LU [London Underground] presented at [Gartner's] London EA Summit, noting that TRAK retired” – kind of embarrassing, considering how much I’ve gushed about it above… I still feel it’s of real value, though, because it provides a good example of what’s needed in an enterprise-architecture metamodel once we finally break out of the IT-centric deadlock. No information yet as to what (if anything) has replaced TRAK, but will post another update here as soon as I found out.

[Update 2: 15aug10] And have now had a detailed set of replies from Nic Plum of Eclectica Systems (see Comments section below) explaining that TRAK definitely is very much still in use, and also does have a methodology derived from ISO 42101. More details from Nic below, anyway. (Many thanks.)

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?

A great discussion last night, with A Certain Well-Known Architect Who Asked To Remain Nameless, about my previous post on Microsoft EA’s ‘breakthrough’.

One related point provided us both with a certain amount of bleak amusement. Microsoft EA have just ‘discovered’ that ‘business-architecture’ doesn’t mean ‘anything not-IT that might affect IT’, it really does mean ‘the architecture of the business’. The Open Group belatedly ‘discovered’ the same fact late last year – just too late to include it in TOGAF 9. (I’d been hammering them about this for several years now, and even up until late last year most of them had dismissed me as some kind of nutcase. Oh well…) The same with Gartner and Forrester and the other big analyst-firms and big consultancies: they’ve all ‘discovered’ business-oriented architecture somewhen in the past couple of years.

But the catch is that they’ve all spent the past decade insisting, loudly, to everyone, everywhere, that enterprise-architecture is all about IT, and really only about IT. Hence the recruitment-industry thinks ‘enterprise’-architecture is solely about IT; the trade-journals think it’s only about IT; even education and training think it’s only about IT. And most executives now think it’s only about IT, too.

So along come all these supposed ‘enterprise’-architects, who’ve just ‘discovered’ business-oriented architecture. And they now need to talk with executives about business and business-architecture and business-strategy, at business-level, far beyond IT. The response from the executives: “But enterprise-architecture is just IT, isn’t it? That’s what you’ve always told us. So it’s just detail-stuff – no interest to us…”

So having spent a decade trying to convince everyone that ‘enterprise’-architecture is only IT, all those previously IT-centric types now face another long uphill struggle trying to convince everyone that it’s not. Whilst no doubt somehow trying to pretend that they themselves haven’t been inanely myopic and absurdly wrong about the real nature of their own industry for all of that time.

“For ’tis the sport to have the enginer / hoist by his own petar[d]“: would be amusing if all that darn stupidity hadn’t caused so much damage, but there ’tis…

A couple of weeks back, Gabriel Morgan of Microsoft’s internal Enterprise Strategic Planning unit posted an article on what he described as a ‘breakthrough’ in enterprise-architecture, “A Breakthrough: Maturing EA to be a Catalyst to Transform the Company“:

It’s time to rethink enterprise architecture people. Well, at least here in Microsoft IT’s Enterprise Architecture Team it is.

… For the past year or so, I’ve led a crack team of experts focused on aligning IT and the Business, and from this journey I wanted to share with you my current thinking. My team is called Enterprise Strategic Planning and it is a service team dedicated to enterprise-wide strategy and planning. Our initial goal is to become critical to the planning process with the intention of providing data to qualify an optimal set of IT Programs to invest in. … In this article I wanted to share with you something that has occurred to us during our journey and describe some changes we are making that I think is ground-breaking in the Enterprise Architecture domain.

Assuming a primary goal of EA is to align IT to the Business, the problem is that most, if not all, EA Frameworks are not equipped to actually deliver on this goal. They are limited to drawing associations from IT things … to Business things … . Some of the more mature EA teams have partnered with their finance department to apply financial modeling … to these associations to help describe business value in monetary terms and possibly start a chargeback model. These are all great accomplishments but at best they only capture how IT ‘relates’ to the Business. That is, these EA Frameworks and methods are more about IT transparency, not alignment.

I would have to admit that my first response to this would best be described as ‘unprintable’…  (The polite version of ‘unprintable’ would look at certain key phrases in the above, such as “It’s time to rethink enterprise architecture, people”, “a crack team of experts” and “Assuming a primary goal of EA is to align IT to the Business”, and thence to make extremely disparaging remarks about Microsoft, about apparent arrogance, about a supposedly innovative company being literally years behind the leading edge of enterprise-architecture, about breakthroughs that aren’t, and about the vapidity and shallowness of IT-centric assumptions… Oh well…)

My second response, after I’d had a chance to calm down a bit, was perhaps a bit more charitable, if still more than a little sarcastic: something more along the lines of “Welcome to the club, glad to see you’ve woken up at last, any chance we can actually talk about enterprise architecture?” – because to most of us who have been working at that leading edge of EA-development, this supposed ‘breakthrough’ is very old news indeed. It’s actually the understanding that existed decades ago, before IT-architects came in and hijacked the entire industry; several of my IT-oriented clients had each reached that same point independently half a decade or more ago; and even the Open Group, after we’d nagged and bullied and cajoled them for so long, finally ‘got it’ late last year, with “evolving EA from IT to business” now becoming an explicit key theme of current Open Group (TOGAF) conferences. So in terms of the overall EA industry, there’s not a single thing that’s actually new in that Microsoft ‘breakthrough’: and hearing someone call it a ‘breakthrough’ is frustrating in the extreme.

But that second response still misses the point: this actually is a breakthrough – for Microsoft. Which, because of who Microsoft are, means that it’s also a real breakthrough in another sense as well.

Yes, it’s frustrating to note that, from what appears in the article, Morgan and his group seem not to know that much about any ‘prior art’ – not even from other Microsoft EAs such as Nick Malik, who writes a very good ‘Inside Architecture‘ column at the same MSDN weblog-host, and is even listed in the links on Morgan’s weblog. Yet there is real change here: important change. Take a look, for example, at the business-architecture references that Morgan lists later in the article:

• Porter Five Forces
• Balanced Scorecard
• Business Model Canvas
• Geoffrey Moore ‘Core vs Context’

There’s no IT directly involved in any of those models (unlike, say, Ross, Weill & Robertson’s much-lauded ‘Enterprise Architecture as Strategy‘, which still takes a strongly IT-centric view of business-strategy). For someone like Microsoft, whose whole business-focus is and revolves around IT, that absence of IT-centrism is huge… definitely a real breakthrough.

I also need to remember that my own role in enterprise-architecture is very different from theirs. Morgan and his team are practitioners, dealing with the day-to-day realities of real-world architecture in a very large organisation. I’m a practitioner, too, yes, but my own work these days is mostly about setting-up architecture practices, troubleshooting, and doing practice-refresh for existing architecture groups – it’s consultancy, not mainstream production-level architecture. So although I’m a practitioner, my practice is mostly about theory, futures, creating new tools and techniques: which means that if my work isn’t well ahead of the mainstream, I wouldn’t be doing my job properly. Yet that view gives me a rather jaundiced perspective of the industry: too easy to forget that it does take years – several years at least – for the ideas and themes and concepts that we’re working on now to filter down into everyday EA practice. In short, too easy for me to become arrogant about what I see as other people’s ‘arrogance’… Oops…

Coincidentally, Gartner published their current ‘EA Hype Cycle’ this week, described in a press-release and a one-page graphic. They state that there are now two distinct generations of EA: the ‘traditional’ IT-centric one, which has now reached what Gartner term ‘the Plateau of Productivity’; and an upcoming “more business-focused” version that will help to prevent EA from falling permanently into ‘the Trough of Disillusionment’.

To me, though, these two ‘generations’ respectively represent maturity-levels 2 (“clean up the mess”) and 3 (“top-down strategy”), out of five distinct maturity-levels, as described in my book ‘Doing Enterprise Architecture‘. There are at least two more ‘generations’ to go before we reach a fully usable architecture for the enterprise; and, worryingly, far too few architecture-teams seem to have properly implemented maturity-level 1 – “what business are we in?” – which in the longer term places the entire architecture at risk. (It’s not adequately addressed in either TOGAF or FEAF: TOGAF 9 does sort-of include part of it in a kind of half-baked form in the muddled mess that it describes as ‘Business Architecture’, but that’s about it. To me, the only major framework that does cover it properly is Kevin Smith’s Pragmatic EA, which is still not as well-known as it deserves to be.) So there’s a long way still to go – and a lot of repair-and-refresh to do, too, to clean up the problems caused by the IT-centrism of the existing ‘enterprise’-architecture frameworks.

But I’m wondering just how much this article of Morgan’s should change the view that Gartner shows us. Gartner shows ‘Business-Driven Architecture’ as having only just reached ‘the Peak of Inflated Expectations’: yet the TOGAF conferences, and now Morgan’s article, seem to show it much further on, more like the start of ‘the Slope of Enlightenment’. Fact is that Microsoft is just about as mainstream as they get: so if Microsoft’s EA has now turned beyond IT-centrism to a more explicit whole-of-business focus, what it really tells us is that business-driven architecture has just gone mainstream.

It’s still not a ‘real’ enterprise-architecture as I would understand the term: but it’s a heck of a lot better than than the old IT-centrism. That is a real breakthrough – and very good news indeed.

Watch This Space, at last?

Another collection of Tweets from the Open Group Boston conference, mostly from Day 3 (21 July 2010), and variously on business-architecture, the EA profession, cloud-computing and a few miscellaneous themes. As before, a few additional comments from me in italics.) Thanks again to everyone who Tweeted, especially Aleks Buterman (@aleksb6) and @rsevero.

Read more…

Yup, I screwed up badly over that last post on IBM’s definitely not ‘new’ Component Business Model. Within a matter of minutes I’d received a whole stream of Tweets warning me I’d been mistaken about the age of the model:

• miket0181: @tetradian IBM’s CBM isn’t new. I think it’s at least 5 years old…
• operninha: @tetradian aqui na empresa contratamos a IBM e eles usaram o CBM (“here the company hired IBM and they used the CBM”)
• seabird20: @tetradian I have seen CBM in RFPs for at least 5 years. Original work 10+ yrs. ago. Takes a while to get to rank and file though
• richardveryard: @miket0181 @tetradian … IBM’s CBM came sometime after my 2001 book on Component-Based Business http://tinyurl.com/23gelj7

So yes, I was wrong on that: badly wrong. A critique about outdatedness that would have made sense if the model had been ‘new’ just looks peevish and petty when it isn’t…

Even the critique about the structure of the model is barely fair. Sure, Stafford Beer’s Viable System Model has been around since at least the mid-1970s, but the number of people who knew about it and were applying it in practice (and I actually could include myself amongst them by the mid-1990s) was and still is very small. It’s better-known these days, and its value and importance is much better-understood; but at the time the Component Business Model was devised, I would doubt that anyone in that IBM team would have even heard of it, let alone known why those kind of whole-of-system cross-checks are so crucial. The critique would definitely be valid for an equivalent model developed now, but most of the current knowledge on whole-of-enterprise impacts simply wasn’t available a decade ago. And whilst critiquing a (relatively) old model on the basis of current knowledge is valid enough, it’s only fair to do so when it’s clear when that fact of history is acknowledged – which I didn’t, because I didn’t know it was that old.

I know why I screwed up: after five years of constant struggle against IT-centrism in ‘enterprise’-architecture, I’m now seeing management-centrism promoted as an ‘improvement’, and it’s frustrating as heck… The fundamental point in all enterprise-architecture is that there is no centre – everywhere and nowhere is ‘the centre’, all at the same time. In true whole-of-enterprise architecture, making anything ‘the centre’ – IT, finance, management, processes, security, whatever, even the business-organisation itself – will guarantee failure of the architecture over the longer term. When I saw the Tweet that triggered this, I thought it was yet another example of this lethal mistake. So I over-reacted.

In my defence, I did check the IBM site with some care. But the annoying point there is that there are no dates on that part of the site – nothing to give any clue as to when the material was posted, or its probable vintage. (Compare that to, say Apple or Microsoft, where just about everything has a ‘Last Updated’ timestamp.) I looked quite hard for anything there that would give me any clue as to the date. What I didn’t do, though, was search elsewhere – and yes, that was a mistake too. So I misread the implication of the Tweet, and mistakenly assumed the model was new – after all, it still says so, several years later…

Moral(s) of the story:

• Fact-check everything, via multiple sources – not just the ‘official’ site for the respective information
• If key metadata-items such as dates are missing, fact-check elsewhere again, and treat any implied derivatives (e.g. ‘new’) as suspect
• Frustration is fine, and often all too understandable, but don’t let it rule the roost – engage doubt before pressing the ‘Send’ key…

Overall, though, the blunt fact remains that yes, I did indeed screw up there. Mea culpa…

(Another example of How To Lose Friends And Infuriate People, no doubt, but this does have to be said.)

[Update: this post was a reaction to a tweet I received yesterday, but Mike T. (@miket0181) tells me that the IBM CBM described here isn't new, in fact is apparently some years old, so my complaints on that regard are unfair. (Doesn't help that IBM don't put up any dates on their website-posts.) On that part, yes, I ought to apologise, and do - see 'How to screw up in one easy lesson...'. Yet the core critique still stands: it's not a complete model, and potentially is dangerously misleading if used as the basis for a business-architecture. That's my view for now an' I'm stickin' to it, anyways. ]

A couple of weeks back, as part of the ‘Patterns‘ section in the Enterprise Canvas series, I put up a an example of a variant of the Canvas which I said was definitely dysfunctional, all but guaranteed to be ineffective, and definitely not recommended – a kind of Taylorist-style model of the organisation and its (non-)relationship with its business-ecosystem:

I said explicitly that it was a stereotype, almost a parody – a guide as to how not to view an organisation, with quality-management and coordination subsumed into ‘management’, and rigid separation between the organisation and its broader shared-enterprise.

I was quite certain that no-one would be daft enough to try to model any real organisation in that way.

I was wrong.

Welcome to IBM’s new Component Business Model, where the organisation’s business-world is partitioned into just three layers: Direct, Control, Execute:

I’m going to have to be rude here, and describe this as a kind of ‘bastard child’ of Taylorism and TOGAF, combining many of the worst features of both and not many of their best. The one good item, and a definite improvement on TOGAF, is that the model does explicitly include People as well as Process and Technology:

Using the Component Business Model methodology, our consultants identify the basic building blocks of your business. Each building block includes the people, processes and technology needed by this component to act as a standalone entity and deliver value to your organisation.

But beyond that? – well, let’s compare it to Stafford Beer’s Viable System Model, which I regard as the minimum requirement for whole-of-business modelling:

• system-5, ‘policy / purpose‘ – uh… might be tucked away somewhere in IBM’s ‘Direct’?
• system-4, ‘outside / future‘ – sort-of in IBM’s ‘Direct’, but no reference to ‘outside’?
• system-3, ‘inside / now‘ – yup, right there in IBM’s ‘Control’ – lots of it
• system-3*, ‘monitor / audit‘ (including overall quality-management) – nope, not a sign of it – presumably squeezed into IBM’s ‘Control’?
• system-2, ‘coordination‘ – nope – no sign of it anywhere
• system-1, ‘operations‘ – yup, that’s IBM’s ‘Execute’ – probably…

In terms of the Enterprise Canvas model above, all it has is Staff-Management (what should be the guidance-services, but all scrunched up together in a nearly-unusable way), Line-Management (the Value-Management cell, blown up out of all proportion to its actual relevance) and, uh, Everything-Else…

In other words, there’s probably less than half of what’s needed to make sense of the organisation – but presented as if it’s the whole of it, much like TOGAF’s hopelessly-IT-centric model purports to be ‘enterprise’-architecture.

The four other worked examples are slightly better, but still dangerously incomplete: a Taylorist manager’s-eye view of the business-world, without any clue as to any of the glue-functions that hold it all together. You’ll also note that each one of those examples has a very different structure in its ‘horizontal’ axis – but no indication at all as to how it’s derived. Presumably only IBM’s own consultants could be considered competent to understand the ‘magic sauce’ needed to do this, and the rest of us mere mortals may do nothing else but bow down in awe?

What’s also irksome is that IBM have the temerity to present this as something ‘new’:

IBM’s Component Business Model is a new way of looking at your business. It represents the entire business in a simple framework that fits on a single page. It is an evolution of traditional views of a business, such as business unit, function, geographic or process.

Fact is that this is nothing ‘new’ at all: okay, it might seem new to IBM, but not to just about anyone else in ‘the trade’. We were doing it more than half a decade ago in Australia Post – certainly 2004, and probably earlier. It was only a Visio hack, but in business terms it proved straight away to be one of the most valuable artifacts from our Business Transformation team: just about every single manager in the whole organisation grabbed hold of their own copy and placed it, much annotated, above their desk. Since then I’ve done one or more of these models for just about every one of my enterprise-architecture clients: you’ll find a couple of (de-identified) examples in that VSM slidedeck referenced above, and in probably half of my other TOGAF-conference presentations over the past few years. I even published the instructions on how to build an ‘organisation-on-a-page’ map, complete with Visio templates, on my Tetradian Books website some two or three years ago. Aleks Buterman and his colleagues have had their own generic version – which they call an Enterprise Architecture Capability Map – up on their website for almost a year now. And it’s even built into some of the EA toolsets, such as Troux Metis, and, I believe, IBM’s own System Architect, and again has been so for years. So what’s ‘new’ about it? Nothing, frankly – other than the fact that IBM have finally cottoned-on to what the rest of us already knew anyway.

And I hate to think how much they charge for this ‘new’ approach… a lot, no doubt…

Sorry, folks, but I’d have to say I’m underwhelmed at all of this. Seriously underwhelmed. Oh well.

Bah.

A collection of Tweets from and/or about the Open Group conference in Boston. A few references to Day 1 – particularly the ‘unconference’ – but mainly about Day 2, where the Jeanne Ross keynote was obviously the highlight.

I’ve split this into sections, mainly around the current speaker. I’ve also added occasional comments of my own at the end of some tweets, shown in italics.

Many thanks especially to Dana Gardner (@Dana_Gardner), Brenda Michelson (@bmichelson), Aleks Buterman (@aleksb6), Lisa Melsted (@lmelsted) and @rsevero (apologies, I don’t know the proper name), who provided the bulk of the Tweets here.

Read more…

Everyday Enterprise Architecture, the latest book in my Tetradian Enterprise Architecture series, is now available on Amazon:

• ‘Everyday Enterprise Architecture‘ on Amazon.com
• ‘Everyday Enterprise Architecture‘ on Amazon.co.uk

Note that Amazon have an unfortunate habit of listing print-on-demand books as ‘out of stock’: all that it means is that it takes at most one extra day for delivery.

The publisher-blurb is as follows:

All of architecture comes down to one simple idea: things work better when they work together, with clarity, with elegance, on purpose. Yet how do we express that ‘one idea’ in practice, within our organisations? With what results, and for what business-value? This book describes the down-to-earth detail of everyday enterprise architecture, to show what architects actually do to deliver value fast, across the entire enterprise.

Working step by step through a real ten-day architecture-project, this book explores the activities that underpin sensemaking, strategy, structures and solutions in the real-time turmoil of an enterprise-architect’s everyday work.

Topics covered include:

• • how to use enterprise-architecture to tackle executive-level business-problems
  • how to develop an agile architecture practice that can keep pace with the real-time pressures of the real business world
  • how to identify the business-reasons and business-value for each activity
  • how to thrive on the inherent uncertainties of the architecture process
  • how to use context-space maps to guide sensemaking and solution-design
  • how to apply architecture ideas and activities to describe what actually happens in a real enterprise-architecture project
  • how to enhance architectural skills, judgement and awareness, for continuous improvement across the enterprise and in the architecture itself

If you want your enterprise to flourish and prosper in the midst of relentless change, this is one book you’ll definitely need.

The book describes the actual thinking-processes and business-activities that typify real architecture-work at an enterprise-wide scope and scale. The structure of the book is a walk-through of a simultaneous pair of architecture projects, using an agile-style adaptation of the well-known TOGAF Architectural Development Method. Both of the projects need to be delivered in parallel, and fully completed within a ten-day period. One of the parallel projects focusses on ‘the architecture of architecture’; the other – adapted from real whole-of-enterprise architecture-consultancy assignments – tackles a serious business-strategy problem for a fictional bank.

The book also introduces a new sensemaking technique for enterprise-architectures, known as ‘context-space mapping’. The technique draws on systems-theory and complexity-theory to enable a much richer view of the architecture context, yet still deliver actionable results in tune with the timescales of the real business world.

The book-cover includes an illustration from the Dover Collection, indicating the kind of stress under which most enterprise-architects work! The aim is that the book should help to ease some of the overload, and make it easier to describe to others what it is that enterprise-architects actually do.

At present you can also download the full ebook version for free from the Tetradian Books website; note that this offer will only be available for a few more days, after which the the full ebook will be replaced by a  ’sample’ edition, containing contents and sample-chapters only.