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?

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?

Self-doubt.

It can be a real killer – in many different senses. A killer of ideas. Of motivation. Of hope, or joy. In extreme cases, even of people themselves.

For once, I’m very glad to say, it’s not me that’s in the throes of self-doubt here. But I’ve been watching several other colleagues go through it this week, in several different domains: narrative-enquiry, archaeology and enterprise-architecture, to name just a few of their respective work-contexts.

Not fun at all, for any of them. Not easy to help them, either: almost by definition, self-doubt is a very personal struggle…

Yet in some ways it seems an oddly necessary stage in the development of new ideas, or whatever: in the labyrinth, it’s the ‘Dark Night of the Soul’ (also known as the ‘”Oh, sod it…” point’ ), where we either have to face the darkness or throw away everything that we’ve gained.

It’s called the ‘dark night’ for a very good reason, because it can be real dark in there, real lonely… Oftentimes in ideas-development we’re assailed by others’ doubts, others’ over-certainties, but here it’s our own doubts that assail us:

• Is this idea any good?
• Will it ever be useful?
• Will it ever make sense to anyone else?
• Will it ever make sense to me?
• Am I just wasting everyone’s time with this?
• Am I just wasting my time with this?
• Am I just a waste of time?

…at which point it tends to go darker still… Yes, not fun…

What’s interesting here is that those who never have to face this space – or who shy away from it – are unlikely to ever create anything new. The ‘best’ that they can do is prevent others from creating anything, developing anything – a ’skill’ that’s of questionable value in the broader scheme of things, perhaps?

So yes, sure, there are plenty of people who are always certain of themselves (or who are careful, perhaps, never to show their uncertainty in public…). Yet in many ways that certainty can perhaps be best understood as a peculiar kind of cowardice, because it takes real courage to face the unknown; it takes real courage to face the dark pain of self-doubt, and keep going through to the other side.

One way to deal with those doubts is to note that often it’s not about us at all: it’s about the idea that we’re working on, trying to find some means to express that idea in a meaningful way. What the labyrinth-model tells us is that that ‘dark night’ is a normal part of the process – an unavoidable stage that we must pass through in order to bring that idea to fruition. The way to break out of the ‘dark night’ is to care for the idea for its own sake – not for what it might bring us. The more we focus on ourselves in the ‘dark night’, the longer we’ll be stuck there.

Self-doubt is an occupational hazard for anyone creating anything new, whether for ourselves alone – such as in development of new understanding, or a new skill – or to be shared with others – such as a new product or process. For those of us whose work revolves around innovation, chronic self-doubt is often our common condition. It’s often made worse by a concomitant feeling that we’re ‘the Outsider’ – yet that ‘Outsider’ is exactly what we are whenever we’re developing something new. But that’s the nature of the work: painful as it is, there’s nothing wrong with self-doubt – in fact if we don’t experience self-doubt in this kind of work, that’s when the alarm-bells should sound.

What helps most, perhaps, is knowing that everyone who creates anything will suffer the same pangs, the same pain, the same inner struggles against a seemingly all-pervasive inner panic. That’s why and where a supportive peer-group will help so much: not just with whom to explore and test ideas, but to remind us that we’re not alone in this.

Self-doubt is hard; yet self-doubt is also good. We need self-doubt in order to create well. When the doubt hits hard again – as it always does, from time to time – it can help a lot to remember this!

[Update: a friend reminded me about Derek Sivers' great TED video, Leadership Lessons from Dancing Guy, which seems particularly pertinent here. (The full transcript is on that link, too: well worth reading.) The 'lone nut' who started dancing on the hill-slope probably suffered a few pangs of self-doubt (if perhaps masked for a while by a sufficient overload of alcohol? ) - but kept on dancing anyway, for the joy of the dance itself. Sometimes - as in this example - we gain a 'first follower' who helps us past the self-doubt, sometimes even moving on, as here, to a landslide of response; but sometimes it doesn't - sometimes (often?) there's no response at all. Either way is fine, in the larger scheme of  things: after all, once the dance ends, we're right back where we started (though perhaps a little happier, we'd hope? ). And since either way is fine, self-doubt is fine too - it's a necessary part of doing anything in depth, doing anything worthwhile. Rather than trying to fight against self-doubt, learning to work with it will certainly prove more useful - and probably less painful, too. Enjoy the dance! ]

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…

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…

The full Enterprise Canvas model is a complex beast, with many ideas, many layers, many ramifications and side-themes: it can perhaps seem daunting at first. Yet when we strip it right down to its bare essentials, it’s actually very simple indeed – and its real power comes from that underlying simplicity. So here’s a Really Simple Summary of the ideas behind the Enterprise Canvas:

Everything in the enterprise is a service.

The Enterprise Canvas is a generic map to describe any service, anywhere in the enterprise, together with its interdependencies and flows.

The Enterprise Canvas therefore provides a consistent means to model anything, anywhere in the enterprise.

To give a bit more detail, to make that Really Simple Summary more usable in practice:

Everything exists within one infinite ecosystem, which we might label ‘the universe’.

For practical reasons – and for sanity’s sake – we usually restrict our view to a much smaller subset of that ‘the everything’. (We do always need to remember that it actually is ‘the everything’, though.)

One useful option, especially for organisations, is to select the subset that describes that part of the ecosystem within which the organisation operates. This ‘extended-enterprise’ (or ‘enterprise’, for short) is always larger than the organisation itself, and coalesces around a single idea or descriptor, usually referred to as the ‘vision’ for the enterprise.

Within that enterprise, we assert that every entity represents a service.

Every entity delivers services, provides services, consumes other services. The ecosystem is made viable by this constant interchange of services.

This interchange occurs at every level. Everything is a service, from whole organisations to the faucet in the bathroom or a single line of program-code.

Everything is a service.

For each entity, it can be useful to divide the view into three partitions, in terms of role and relationship: the role, function and services of the entity itself; its relationships with the entities that provide the services that this entity consumes (’supplier-side’); and its relationships with the entities that consume the services that this entity provides (‘customer-side’).

For each entity, it can also be useful to divide the view into three other partitions, in terms of time: what is intended to happen (‘future’); what is actually happening (‘present’); and what has happened (‘past’).

These two sets of views are orthogonal to each other. We can therefore map this as a three-by-three matrix:

The relationships with other entities are symmetrical in the sense that every entity shares the same pattern: the only difference between ’supplier-side’ and ‘customer-side’ is the main direction of service-flow relative to the entity that is our current focus of attention.

The ‘future’-oriented relationships are essentially peer-to-peer, and bidirectional.

The ‘present’-oriented relationships are mainly about ’supply-chain’ transfer of goods and services from supplier to self, or self-to customer (i.e. left-to-right on the Canvas).

The ‘past’-oriented relationships are mainly about balancing the supply-chain transfer via a ‘backchannel’ from customer to self, and self to supplier (i.e. right-to-left on the Canvas).

We can thus describe the overall entity in terms of nine subsidiary ‘cells’ or sets of related activities:

• supplier-side/future: build and maintain relationships with potential and/or actual ’supplier’ service-provider entities, about things that need to happen in the future – supplier-relations
• supplier-side/present: receive goods and/or services from ’supplier’ entities – supplier-channels
• supplier-side/past: provide balance or compensation to ’supplier’ entities (e.g. pay for goods) – value-outlay
• self/future: identify what this entity will do and deliver, aligned to the overall enterprise purpose and values – value-proposition
• self/present: take all actions necessary to create and deliver the goods and/or services specified in the value-proposition – value-creation
• self/past: ensure the appropriate functioning of the overall entity, balancing past, present and future – value-management
• customer-side/future: build and maintain relationships with potential and/or actual ‘customer’ service-consumer entities, mainly about what should happen in the future – customer-relations
• customer-side/present: deliver goods and/or services to ‘customer’ entities – customer-channels
• customer-side/past: receive balance or compensation from ‘customer’ entities (e.g. payment for goods) – value-return

Each of these ‘cells’ delivers its own services to the entity, and could thus, recursively, be represented by and described on its own Enterprise Canvas.

Each entity may be described in terms of various layers on a spectrum between most-abstract (the enterprise as a whole) to most-concrete (the detailed-past).

Note that ultimately all boundaries are arbitrary, and in most cases exist for descriptive and/or administrative convenience only. Within the overall ecosystem, any or all of its services may be recombined and reconfigured in an infinity of alternate ways. The key criterion for success is not ‘correctness’, but effectiveness:

• efficient: optimises use of resources, minimises wastage of resources
• reliable: predictable, consistent, self-correcting, supports ’single source of truth’ etc
• elegant: clarity, simplicity, consistency, self-adapting for human factors
• appropriate: supports and optimises support for business purpose
• integrated: creates, supports and optimises synergy across all systems

Effectiveness occurs when everything supports everything else, all the way up to the enterprise vision or purpose.

The Enterprise Canvas does not attempt to describe every aspect of every service. Its role is to provide a consistent base-frame to link descriptions together into a unified whole. It would generally be used in conjunction with many other model-types, for example:

• use VPEC-T to model each of the flows to and from the entity in focus
• use modified-Zachman to model the assets, functions, locations, capabilities, events and decisions in each flow, in each cell and in the entity as a whole
• use SWOT to assess strengths, challenges, opportunities and risks in each flow, cell and entity

The Enterprise Canvas will also work well with other techniques for SOA (service-oriented architecture) and any other cross-enterprise concerns such as quality, security, safety and environment.

There’s a lot more to it than just the above, of course, but I hope this ‘really simple summary’ will give you enough to get started?