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?

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.)

One of the comments on the previous post on the unacknowledged risks of  ’cooperative IT’ triggered off an essay-length response that really deserves its own post. So here it is.

The comment that started it off was from Ric Phillips. (I’ve trimmed it slightly, but you can see the original here.)

The innovations that led to mini-computers led to the increasing importance of information processing based on the technology’s ability to capture and model transactions (atomistic events). It really did change the nature of work and organisations and made a new kind of information available.

It wasn’t really the advent of PCs that changed things. If the information about the world that could be stored in them and used had not changed radically they would have simply replaced the niche occupied by terminals. But they allowed people to simulate sheets of paper and type writers. And spreadsheets – which were existed prior to software and were done on very large sheets of paper. Later came sound files, photographs, building designs, industrial machinery, complex electronics (like audio mixing decks) and a thousand other things that are now simulated in software.

In this wave computers became personal productivity tools. The changes to how personal productivity expressed itself in our lives when assisted by the new ‘virtual’ things PCs could provide is what changed our jobs, our professions and be extension our lives.

The internet started out as an extension of publication and communications models that already existed. But (in this case much more slowly that in previous transformations) our activity on the internet started to capture large amounts of information that previously wasn’t subject to computation – social information, information about opinions, subjective value, and what we might call (tentatively) knowledge.

There are intersecting trends (consumerisation for example). But mobile computing, ubiquitous data, web 2.0 and so on are all converging to create a new domain of information – information that allows us to model and manipulate in computers new and extremely complex things. Once again this will transform organisations. But this time maybe even whole societies.

I don’t see this as an impending disaster. Our world is changing again. As a strategic profession EAs need to get their heads around this. We are leaving the era of ‘information processing’ and ‘ICT’ and entering the era of social computing and Knowledge Technology.

Reading it again, I now realise that this critique has completely missed the point: all it’s doing is extolling the virtues of each of the transformations in technology, yet seemingly ignoring any possibility that there might also be vices associated with those virtues. Yes, each of those transformations are real and valuable to some context, and that is indeed a key driver for change. Yet the change itself is not the risk, and neither is the technology: it is the dependence on that technology that creates the risk.

So, as I put it in my response, I strongly agree that “mobile computing, ubiquitous data, web 2.0 and so on” are not in themselves an impending disaster. The same applies to their initial impact on organisations and “maybe even whole communities” – in general I see those impacts as desirable, even if certainly not something we can ‘control’.

What does worry me is what happens next. As an EA I’ve spent many months at clients tracking down all those small private-to-a-workgroup spreadsheets and databases and log-files and the like that were a) business-critical and b) unmaintained, undocumented, not backed up, inherently fragile [such as trying to use MS Access as a multi-user database, which it was never designed to do], unregistered, and in many other ways a real business risk. Whenever some key person changed jobs, or a single hard-drive failed, or a sysadmin triggered an automated application-upgrade, or any other of a myriad of seeming-trivial events, that business-unit would literally lose that part of its mind – and an entire business-process, affecting an entire cross-functional workstream, would grind to a halt until someone could work out what had gone missing and how to set up yet another kludged workaround.

When the business-application is non-critical, kludges usually don’t matter: it’s how people learn, it helps get things done, and it’s exactly what ’shadow-IT’ is for. The new mobile technologies and the like are brilliant for this – just as spreadsheets and single-user databases were (and still are). Everything’s fine as long as they’re essentially used in the same way as Lego bricks or a Meccano set or the like – a ’serious toy’ that can be used to knock out a quick prototype to test out an idea, or perhaps even to keep around as a vaguely-useful tool and talking-point. And as long as they’re used for that kind of purpose, it shouldn’t matter much when they do fail – especially if we can use that failure as a way to learn what to do differently next time. In other words, we accept failure as part of the deal – it’s ’safe-fail’.

But don’t try to use a ’serious toy’ for anything that’s business-critical. It’s not inherently wrong, but it’s simply not ‘fit for purpose’: they’re not robust enough, resilient enough, agile enough, secure enough, and so on – which means that as a system we cannot set them up to ’safe-fail’ in such a context. Sure, you could use Lego to build a house (it’s been done), or Meccano to build a bridge (that’s been done, too), but the effectiveness of doing so is questionable at best, especially over the longer term.

It’s the ‘-ilities’ that usually matter most in architecture. The functional requirements for a system are usually much the same at any scope or scale, but the qualitative or so-called ‘non-functional’ requirements are what will usually make or break the system in practice. Building an IT system that can handle half a dozen strictly-sequential requests in half an hour or even half a minute is relatively trivial; building one that can handle thousands or even millions of parallel, interleaving, fragmented, potentially-incomplete requests every second is not trivial at all; and yet the functional requirements are essentially the same. That’s the difference between a ’serious-toy’ prototype, and serious engineering with serious architecture and serious service-management and support behind it.

What we have right now in mobile-computing, ubiquitous-information and cloud is a whole bunch of serious-toys desperately pretending to be more than they are, and – more worryingly – being sold and used as if they’re more than they are. Sure, the function is there – but that’s easy. It always is. Getting them beyond that ’serious toy’ stage is not easy – and because it’s hard work to get there, it hacks into the short-term profits, too, so it’s not exactly popular amongst the money-obsessed.

So we have here all the ingredients for a ‘perfect storm’: more and more of individual people’s lives and livelihoods being placed onto platforms that are inherently unstable and unsustainable, because little or none of the work to make them stable and sustainable is as yet in place or even in progress. If you’re not already seriously worried about what will happen when large chunks of our society literally lose their collective mind and memory through the failures of these kludged-together toys, you’re not thinking hard enough about the architecture of the enterprise… 

The lessons of history are plain to see, and it’s also plain to see that the level of unaddressed risk has been raised each time, with even the earliest-period risks still not fully addressed even now. You Have Been Warned?

Twitter-correspondent Craig Hepburn posted a Tweet this morning pointing to Dion Hinchcliffe’s excellent ZDNet article, ‘CoIT: how an accidental future is becoming reality‘, about the current rise and rise of ‘consumer IT’ or ‘cooperative IT’:

It’s a story as old as the IT department: New technology arrives in the market, it makes some type of work easier to accomplish, the business asks for it, and IT reacts and delivers it. Not always however, and usually somewhat slowly. It was this way with PCs, it was this way with the Internet, and now IT is faced with what is turning out to be a veritable perfect storm of technology and social change. …

Today’s highly mobile, social cloud has set everyone’s expectations for how easy, powerful, and simple IT can be. The genie will never be put back into the bottle.

For once I’m going to stand firmly on the side of the IT-folks on this one – because no matter how wonderful this looks right now, this is not good news at all. Looking at this with a futurist’s eye, I’m wondering how long it will take before we wish we could put the genie back into the bottle… because what I’m seeing here is a full-on disaster-in-the-making. Or rather, a double disaster-in-the-making, given how much this will interact with the ongoing disaster that is ‘cloud-computing’…

One of the first lessons any futurist learns is to look back at history, to seek out any equivalent occurrences in the past. And the blunt fact is that we’ve been here before… not just once, but several times already. Each time that we came back to the same place – if perhaps from a slightly different direction – it’s clear that the fundamental lessons were not learned, in fact were wilfully ignored; and each time it took a lot of effort, a lot of skill, and a lot discipline, to tidy up the mess – just in time for the next batch of overly-excited idiots to trash the place all over again. This is the dirty end of Gartner’s ‘hype-cycle’: someone has to tidy up the mess. And yes, “it’s a story as old as the IT department”, because in every case so far, that ’someone’ has been the much-derided IT department – and also enterprise-architecture, in its broader sense, beyond IT alone.

Go back sixty years or so, to the first beginnings of mainframes and ‘big computing’. Watch the hype-cycle at work: slow adoption, then a huge take-off in ‘data-processing’ (we didn’t get round to calling it IT until quite a bit later). It will solve every business problem! Control the world! Unlimited information on tap, right here, right now! Except it wasn’t quite as simple as that… turns out it was a lot of work to get standards happening (COBOL, the IBM-360 architecture, and so on), and then all the boring stuff about requirements, governance, maintenance, data-cleansing, service-management…

Twenty years later, it’s the mini-computer boom. It will solve every business problem! Now even medium-sized businesses can control the world! Unlimited information on tap, right here, right now! Except that it wasn’t quite as simple as that… turns out it was a lot of work to get standards happening (the C language, the Digital PDP-series architecture, and so on), and then all the boring stuff about requirements, governance, maintenance, data-cleansing, service-management…

Ten years later, we get the microcomputer revolution. It will solve every business problem! Now you too can control the world, right here on your desktop! Unlimited information on tap, right here, right now! Except it wasn’t quite as simple as that… turns out it was a lot of work to get standards happening (disk-formats, file-formats, data-architectures, the IBM-PC architecture, and so on), and then all the boring stuff about requirements, maintenance, data-cleansing, service-management…

Yup, you’ll be seeing the pattern here. The exact same sequence applied to the rise of the internet ten years later, the web five years after that (with a merry little hiatus called the Dot.Com.Bomb), the rise of cloud over the past few years, and now the rise of Hinchcliffe’s mobile IT or ‘CoIT’. In every case, there’s the same wild hype, the initial push from outside the IT-department (as ’shadow IT’) which gets the basic idea going to point where it’s usable.

(And to be fair, if that push hadn’t happened, those new developments would probably never have been usable: as Hinchcliffe implies, it’s actually quite rare that innovations arises from within the IT department itself. Because that isn’t it’s job: IT’s real job, unfortunately, is to tidy up the mess that will inevitably follow…)

In every case we see the same exuberance… then the slowly-dawning awareness that it isn’t quite as simple as that. It turns out that there’s a lot of work that’s needed in order to get standards happening – otherwise the new ‘revolution’ turns out to be something that can’t be shared, which means that the whole thing fizzles out quite quickly because we need that sharing to happen. We need clear standards for hardware, software, data-architectures, information-architectures, interchange protocols and much more besides. We need distinct disciplines around requirements, governance, maintenance, data-cleansing, quality-management, service-management and a whole swathe of other areas. And all of those, it’s now clear, need to allow for customisation, agility, security, versatility, adaptability, resilience and the like – none of which are easy to balance with conventional ‘control’-style disciplines.

So here I am, looking at the rise of Hinchcliffe’s ‘CoIT’ – particularly cloud-computing and mobile-apps. And what I’m seeing is an architectural disaster waiting to happen, if not unfolding right before our eyes:

• security – where is it? does it exist at all? (I’ve seen lots of hype and promises, but not much reality as yet)
• file-formats – half the iPad apps I’ve seen seem to embed their data actually within the app itself – they don’t even have a file-format other than perhaps plain-text or unstructured PDF
• interchange-formats -if they have a file-format at all,  most of the apps seem to rely on unpublished proprietary file-structures with no means to enable exchange between different apps, whilst cloud-providers will often deliberately make it difficult to exchange, so as to enforce ‘lock-in’
• escrow – information-lifetimes range between seconds and decades – yet no-one seems to be thinking beyond a year or more at most, and no-one at all seems to be planning for what happens when a cloud-provider or app-provider goes bust – which they will, often (over the long-term at least), and often very expensively
• system-standards – where are they? do they exist at all? – we seem to back in the worst days of early microcomputing, where just about every man-and-his-dog-in-a-garage could and did create an entirely different architecture for everything, often intentionally incompatible with everything else

I could go on… and on… and on… there’s no shortage of other nightmare-level architectural risk-factors that aren’t being addressed at all. Other than by the much-maligned IT-department, that is (who unfortunately tend to be able to see only the IT-related risks, which represent only a relatively small proportion of the whole); or by the few enterprise-architects who actually do think about whole-of-enterprise scope (and who are mostly derided, by the hype-merchants and their ilk, as doomsayers who’ve lost the plot). Not funny… Oh well…

Yes, it’s true that the excitement (or the oft-forlorn hope that it will finally be better this time?) is what gets people going to create new ideas; so yes, the exuberance does matter. Hence, in turn, I suppose, the hype does matter too. And safe-fail experiments are also always a good idea, because they show us where things will break but without causing much damage in the process. ‘Safe-fail’ can get quite extreme, too: for example, think of the buildings in a fireworks-factory, with very solid walls, very lightweight roofs – because when you know there’s a high risk that things can go badly wrong, you can indeed design for that fact. Yet there are also many types of structures that we can’t allow to fail: anyone who’s lived through a major earthquake or major storm-event will know that fact firsthand… Architecturally we need to be able to tell the difference between those two extremes, and design accordingly.

Yet that’s exactly what’s not happening here with cloud or CoIT: architecture of any valid kind, it seems, has all but been abandoned in the usual wild rush towards The Next Best Thing… So might it not be wise to take a brief pause for thought at this point, before we rush headlong into yet another insanely-expensive IT-disaster? Or is that too much to ask of anyone whilst the hype is in full flow?

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…

(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…