Tom Graves / Tetradian

An important email for me this morning, from management consultant Ray McKenzie, that’s triggered off a significant re-think on the role and label for one of the nine main cells in the Enterprise Canvas model:

While you labelled the bottom row of ‘Enterprise Canvas’ as Value, somehow as I read through the material I kept thinking ‘Governance’, not sure if this was your intent or just my imagination.

And yes, he’s right: of course it’s ‘Value-Governance’ – of course! Why on earth didn’t I see that before? I knew that ‘Management’ wasn’t right when I wrote it, but I couldn’t find the right alternative. Yet there it is, staring me right in the face: of course it’s ‘value-governance’! – in fact, given its role, at the intersection of ‘our value’ and ‘the past’, it really couldn’t be anything else. Using the term ‘value-management’ for that single cell gives it completely the wrong flavour – in fact that’s the main function of the ‘value-direction’ cell in the somewhat-external ‘guidance’ group, so it’s already covered elsewhere. Management is something that happens throughout the service, not just in one place – but it is fair enough to say that overall governance-activities for a service tend to be concentrated in one subdomain of that service, enacted via its own domain-specific roles.

Value-governance makes sense here in both directions on the Canvas’ grid. On the vertical ‘our value’ axis, ‘value-proposition’ deals mainly with what we will do (future); ‘value-creation’ is concerned with what we are doing (present); whilst ‘value-governance’ looks at what we will do, but perhaps even more at what we have done (past), to ensure that they match up correctly. And in the horizontal value-web axis, ‘value-governance’ sits on the backchannel – completions and the past – to hold the balance between what comes in as ‘value-return’ from the customer-side of transactions, and what goes out as ‘value-outlay’ on the supplier-side.

Hence duly-amended versions of the key diagrams – first, the ’service-cross’ version of the ‘brick’:

…and the ‘robot-chicken’:

Not many people use the shorthand two-letter codes for cells and flows, but these should change from VM to VG (for the cell-label), and XM to XG (for the flow-label). The XG flow now focusses primarily on matters relating to governance between the layers (rather than getting mixed up with overall management and direction, which should probably be associated more with the XD guidance-flow).

In all, this cleans up an inconsistency that had been bugging me for ages in the structure of the Canvas, but I hadn’t been able to see what was wrong or why. Hence, once again, many thanks to Ray McKenzie for this.

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?

Been having a fairly intense (but good ) discussion on the LinkedIn Enterprise Architecture group, about standard economics and its impact on enterprise architecture. This is one of the many side-threads popping up off Kevin Smith’s now long-running discussion on “EA is not the glue between IT and ‘The Business’, EA is the glue between strategy and execution”. I don’t know whether this set of posts from various participants will make much sense to anyone else, but it seems worthwhile to post it where others can see it if they wish.

(Note that I’ve done a small amount of editing of the original posts by trimming and snipping ['...'] and, in one case, concatenating posts from the same person. I believe I’ve kept the sense intact in each case, but if not, please let me know straight away? Thanks.)

For me, in this case, the start-point was a post by Harold ‘Hal’ Stull:

When in doubt I always think Econ 101. An organization manages three resources (capital, labor, and material) to produce a product. If a customer pays more for the product more than the value of the resources consumed, the company shows a profit for its risk and will continue operating. As an architect of any kind, I have to discover the “Who, what, when, how, where, and why” of the client’s operation and add something that may possibly increase the perceived value of the product to his customer or reduce the resources needed to produce it.

I also try to stay away from absolutes: Truth, Best, Optimum, Consistent, etc. I can do a whole lot with organizational and interface symantics. I would never say “ontology” in front of a client, but being able to work with higher abstractions helps me choose and squeeze value from tool kits. (But I see there is another thread for that topic).

As you’d probably guess, given some of the other posts on this weblog (such as ‘Economics: the worst term-hijack ever?’), I kind of jumped at Hal’s comment about ”When in doubt I always think Econ 101.”:

Hmm. That assumes that ‘Econ 101′ makes sense and works in the real world, which it doesn’t. That’s the problem.

You say: “An organization manages three resources (capital, labor, and material) to produce a product.”

The answer would be “Sort-of…”. More accurately, Econ 101 treats all of those items (including non-financial capital, such as conceptual and/or social capital) as ‘possessable objects’ that are the ‘property’ or ‘possession’ of an individual or of an organisation-as-corporate-person. Unfortunately this would take a long post to explain, but in essence the ‘possession’-based concept of economics is a parasitic overlay on the actual economy, which operates on mutual-responsibility rather than possession. The quickest summary is that Econ 101 is inherently dysfunctional and inherently unsustainable: so if we’re to build an enterprise-architecture that will work for an organisation, we need to focus on the responsibility-based economy behind the possession-based delusions of Econ 101, and not allow ourselves to be distracted by those delusions.

To give one very quick example, most conventional ‘business-models’ that I’ve seen assume a very simple Econ 101 market-sequence of:

attention (via advertising) > transaction (via sales) > profit

For enterprise-architecture, we need to deal with a much broader range (e.g. including non-active stakeholders [e.g. government, community, non-clients] and also anti-clients and others who are active participants but who are not involved in sales-transactions), and a much more complex market-sequence, such as:

reputation > trust > respect > attention > conversation > relationship > transaction [ > profit] > reputation > …

We also need to understand that ‘the enterprise’ is not the same as ‘the organisation’: an organisation is bounded by rules, roles and responsibilities (e.g. legal responsibilities), whereas an enterprise is bounded by vision, values and commitments (see my presentation ‘What is an enterprise?‘)

True, an organisation is a type of enterprise, but for most enterprise-architecture the relevant enterprise is typically at least three steps larger in scope than that of the organisation in scope. (We develop an architecture about an enterprise for an organisation.)

Using the assumptions of Econ 101 will guarantee that we will deliver an ‘enterprise’-architecture that will fail in the longer term. To build an architecture that works, we must think wider than that.

Read more…

This one’s about uniqueness and serendipity and ‘chaos’, and I’d better say straight away that it’s a lot more tentative and exploratory than many of my posts of late.

I’m seeing a theme in enterprise-architecture and the like that’s always been there in the background, but seems to have recently started to become a lot more visible to a lot more people. It’s difficult to pin it down precisely, but it can be seen sort-of sideways-on in many other themes:

• design-thinking and the like, now even embedded in the new US Army field-doctrine
• references to the difficulties of designing for uniqueness or ‘being prepared for surprise‘
• a lot of posts on applications of improvisation-training in business, not just for sales-folks but for business-execs as well
• more references to futures (futures-plural, that is, rather than the singular ‘predicting the future’)
• more interest in ideas about personal-level strategies and tactics for innovation, such as those from one of my favourite books, Beveridge’s The Art of Scientific Investigation
• a sense that the pace of change in business is heading towards real-time, and often is already at real-time
• a surprising number of references to serendipity in business, often linked to innovation in various forms
• a renewed focus on disaster-recovery, business-continuity and the impact of ‘long-tail’ kurtosis-risk and ‘black swan‘ events
• the recognition that every sales-event is actually a unique ‘market-of-one’, in which the choices at the moment of choice are not predictable or ‘rational’ at all
• the role of visioning and the like within enterprise-architectures, business-architectures, quality-systems and so on

Or, to illustrate, a couple of items from today’s Twitterstream:

• CreatvEmergence: Improvise to Innovate – http://bit.ly/apch2U
• oscarberg: RT@esauve: “The Social Web is moving toward a future where serendipity replaces search” http://wp.me/p4P8c-zug from @gigaom

This isn’t about emergence, or the ways in which unique or ‘chaotic’ events can be used to guide sensemaking and pattern-identification in complexity: others are better-qualified to explore that domain than I am. Instead, what I’m seeing here is almost the inverse of emergence: rather than deriving a pattern within complex events, we choose and use a pattern to guide our choices in inherently-unique events. Not just serendipity, but serendipity by choice – an architecture for uniqueness.

One item that comes to mind here is Gooch’s Paradox, identified by the psychologist Stan Gooch: “things have not only to be seen to be believed, but often also have to be believed to be seen”. To enable serendipity to occur, we first have to be a mental space that allows it at all. In that sense, beliefs themselves become tools.

Another is a quote from The Art of Scientific Investigation:

The truth of the matter lies in Pasteur’s famous saying : “In the field of observation, chance favours only the prepared mind.” It is the interpretation of the chance observation which counts. The role of chance is merely to provide the opportunity and the scientist has to recognise it and grasp it.

In a truly unique context – and it seems to me that every real-world context must always be in some part unique – there is only chance: there is no actual connection between anything and anything-else, other than that which we give it. Everything is coincidence, in an exactly literal sense of ‘co-incide-ence’: any meaning that we may ascribe (or not ascribe) to such coincidences is our choice.

Yet from Gooch’s Paradox, this also seems to be able to run backwards: we have the meaning first – predetermined beliefs from our culture or ’scientific law’ or the like – and then find coincidences to match. The belief determines what we see – which can lock us out of an ability to see anything else.

So in a business-context, for example, the beliefs that we use to filter what we see need to be tight enough to allow us to make useful sense of what’s happening around us, but also loose enough to allow true serendipity to happen – where the context itself seems to be giving us what we need. Hence Pasteur’s “chance favours only the prepared mind”: a preparation that has the right balance between precision and openness.

Which leads us to the idea of an architecture of uniqueness, an architecture designed to enable and enhance opportunities for serendipity.

Improvisation is one obvious component of such an architecture: a deliberate practice in working with uncertainty, in real-time.

Another component might be some variant of meditation, where continual, consistent repetition of the same actions or conceptual behaviours provides a stable ground within which useful ideas and events can coalesce. (This is the exact inverse of Einstein’s famous remark that “insanity is doing the same thing and expecting different results”. That dictum is true enough in a predictable world; but in an inherently unpredictable world – any context which is truly unique – anything we do will always lead to different results, hence repeating the same action over and over may be the only thing that will keep us sane! )

Sometimes we also need to deliberately ‘trick’ people into a state where serendipitous events can occur. For science-fiction buffs, this is very well described in Noise Level‘, a classic 1952 short-story by Raymond F. Jones: a group of scientists and engineers are asked to ‘reconstruct’ a supposed anti-gravity device, and actually manage to do so – only to be told at the end that the whole thing had been a kind of hoax, to show them how to open their minds to new possibilities that their conceptual filters would otherwise prevent them from being able to see. The method was a deliberate trick, but the end-results were no trick at all: nicely recursive, in that a very practical real-world technique is embedded in a fictional story about a fictional story.

There’s also the key role of visioning – a real enterprise-vision, that is, not the usual useless marketing-puff ‘vision’ – as a principle-based anchor for real-time decision-making amidst inherent uncertainty: the role in the military of ‘Commander’s Intent‘, for example, or John Boyd’s OODA (Observe, Orient, Decide, Act) cycle.

And there’s much more, such as the distinctions between analysis and emergence – which only ‘make sense’ outside of real-time – contrasted to the real-time spectrum between the simple and the chaotic; or the need for some kind of boundaries between the ’special world’ or chaos – where anything is possible but can send us into panic the moment we go off-balance – compared to the ‘ordinary world’ of rules, regulations and supposed certainty.

So what’s your opinion on this? What can we do to make this work? What strategies, tactics, models, methods would we need for this ‘architecture of uniqueness’, and architecture to support serendipity? And how would we apply this in enterprise-architectures and elsewhere?

Over to you, if you would?

In the previous articles about context-space mapping with the Enterprise Canvas, we looked at the topmost layer, the extended-enterprise and enterprise-descriptor or vision; then the next layer down, summarising all the player in the enterprise ecosystem; and took a first high-level look at the organisation’s business model with an exploration of value-proposition and business-relationships. All of that was moving ‘top-down’ through the enterprise, so we took a brief detour to see how the same principles can be used for ‘bottom-up’ strategic review, where a re-think of existing technology can lead to a new strategy and even to a new enterprise.

We now do another sideways move, to explore how we might use a modified version of the classic Zachman framework to assess the content and activities of each entity (or service) in scope.

Read more…

So far in this series we’ve explored the key concept of the extended-enterprise, used that to summarise the ecosystem in which the organisation operates, and started to model the organisation’s value-proposition and business-relationships.

Up until this point we’ve been working top-down, starting from the most abstract layer, the ‘extended-enterprise’. But we do need to to remember that there’s no reason why we have to work only in this direction, and often many reasons why we should make use of the more freeform approach that context-space mapping will allow. And in the usual serendipitous way – via an article in IndustryWeek, ‘Assessing Product Innovation Assets: What’s in your attic?‘ – we now have a useful reminder that the vision and strategy for an organisation may also be reconstructed bottom-up.

Low-cost innovation doesn’t have to be boring or incremental. Sometimes true innovation is as easy (and inexpensive) as evaluating the technologies and capabilities you currently have and expanding them to a new industry or customer base. It is a particularly powerful product innovation strategy during an economic downturn, yet too few companies today are taking advantage of it.

[An] important message for business leaders: “Use something you already own to generate income in a whole new way.” Truly innovative and resourceful manufacturers can embrace this message by reevaluating their existing assets, intellectual property, and product lines to develop completely new streams of revenue with little investment. The assets are already in their “corporate attics.” All a company has to do is unlock the revenue-generating power of those assets.

So let’s use the examples from that article – and a couple of others – to see how this works, in terms of context-space mapping and the Enterprise Canvas.

Read more…

So far in this series we’ve explored enterprise-vision (Enterprise Canvas row-0) and high-level business-context (row-1) in a fairly straightforward way. It’s been much the same as any other conventional ‘top-down’ strategy-development, except that we haven’t really mentioned our own organisation at all as yet. (That’s coming shortly. )

A few important points have come up in the comments to those two articles, though, which are worth reiterating here before we move on.

One is to remember why we’re doing all of this. It’s not about abstract ‘blue-sky’ thinking: it’s about building a stable platform for organisational change. In enterprise-architecture, this needs to be a platform in which all of the other architectures – business-architecture, process-architecture, skills-architecture, values-architecture, security-architecture and, oh yes, all the IT-architectures too – can all interweave and interlink and intermesh into a single unified, dynamic whole. But although we talk a lot about the extended-enterprise here – especially in these ‘higher’ layers – this isn’t actually for anyone else at all: unless someone seriously-senior decides otherwise, all of this is solely for our own organisation (or client, if we’re doing this work as external-consultants). Working this way, whatever we develop is always in the context of this broader extended-enterprise: but our own organisation (or client) becomes more and more the centre of our attention as we move down the layers. That transition of emphasis starts to happen here. In short:

In enterprise-architecture, we create an architecture about an enterprise, but for an organisation.

It’s really important to remember that point – not least because it’s the organisation, not the extended-enterprise, that’s paying our bills!

Another point that came up in the comments is that the usual nine-cell structure of the Enterprise Canvas can be a bit misleading in these upper levels. The nine-cell structure is really a kind of functional-decomposition – who’s handling what interfaces, and why. But functional-decomposition assumes or describes specific interfaces and relationships – and we haven’t even got that far yet. In row-0 and row-1 we only deal with each entity as a whole, without any internal subdivision into cells. It’s only here, in row-2, that we start to introduce the idea of relationships and roles between entities, which eventually leads us to relationships and roles within entities, which leads us in turn to that nine-cell structure. If you try to use the nine-cell structure in rows 0 or 1, or in most of the work in row-2, you may have missed the point somewhere: at those levels, it’s only about each entity as a whole.

And finally, I would hope that by now you’ll have realised that this can be a lot harder to do than it might seem at first glance. It’s so easy to fall back to organisation-centric habits, where the organisation is placed as the sole centre of everything. The blunt fact is that it isn’t that ’sole centre’ at all: in fact, the organisation only has a reason to exist if it’s placed within the context of its extended-enterprise. If we don’t understand that broader context, we would have nothing to guide us when that context changes – which, these days, can happen on a literally moment-by-moment basis. One of the keys here is that the description of that enterprise is literally emotive – it drives change. So although a lot of thinking and analysis will be needed here, ultimately it’s not a rational matter – it’s about what feels ‘right’, about identifying what is valued. This is especially true of the vision-descriptor: we need to keep exploring that context-space until we hit upon a phrase that can engender emotions and commitment that are literally strong enough to get people out of bed in the morning.

Anyway, time to move on: time to start looking at the business of the enterprise, and of the organisation itself. To summarise where we’ve gotten to so far with this example, we’d established a row-0 ‘Enterprise’:

We then started a Zachman-style row-1 ‘Context’ with a conventional market-based view of our enterprise, with our own organisation as its centre:

Which didn’t show us many options. But as we started to explore what that enterprise-vision meant in practice, and what kinds of stakeholders would be engaged in that vision, we realised that the actual enterprise was much broader than our current market:

Which should create many more strategic opportunities than we were able to see before. To make this work, though, we first need look more closely at the meaning of a common business-term: value-proposition.

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.

In the previous post in this series we did a quick review of context-space mapping and the Enterprise Canvas, and set out this into practice with a real-world example that, for me, is very close to home: rethinking my own enterprise-architecture consultancy business.

We started at the top layer, aiming to identify the core ‘enterprise’ within which I work. From exploring my own professional history, it became clear that the main focus of my work is about enterprises themselves, of any size, and always with the aim of enhancing enterprise effectiveness. From that, we ended up with an initial enterprise-descriptor – or ‘vision’ – of “creating more-effective enterprises”.

Notice, though, what’s happened right here, in that paragraph above. In trying to summarise that initial rather clunky vision-statement – ‘creating more-effective enterprises’ – we’ve accidentally hit upon a better one: ‘enhancing enterprise effectiveness’. It reads better, has a smoother flow to it, a poetry almost. It does describe what I’m passionate about – and finding that passion is central to the success of an enterprise. And ‘enhancing’ is actually a much more accurate term for what I do: I don’t often create enterprises in the sense that, say, an entrepreneur would do, but I do work to enhance their effectiveness. So note that this process is typical of what happens in context-space mapping: for example, we arrive at a ’solution’ – in this case, the initial ‘vision’-descriptor – which itself quietly dropped us back into the ’sensemaking’ space. So the trick here is to notice what’s happening, notice these little serendipitous events – and learning how to do that is a real skill in itself. To quote one of my favourite books, William Beveridge’s The Art of Scientific Investigation:

If these discoveries were made by chance or accident alone, as many discoveries of this type would be made by any inexperienced scientist starting to dabble in research as by Bernard or Pasteur. The truth of the matter lies in Pasteur’s famous saying, “In the field of observation, chance favours only the prepared mind.” It is the interpretation of the chance event which counts. The role of chance is merely to provide the opportunity and the scientist has to recognise it and grasp it.

Anyway, that’s what we now have as the ‘row-0′ or ‘Enterprise’ layer for the Enterprise Canvas model of my own enterprise:

Now what? Very pretty and all that, but what do we do with this?

Read more…