Base-Maps and Cross-Maps

In systems-theory terms, each base-map is a rotation that provides multiple views into the same overall space. Ideally we also want it to illustrate the balance in the context (reciprocation and resonance), and preferably the layering (recursion and reflexion) in that context too.

Which leads us to the base-frame shown in Figure 8-5, as a means to describe an overall context – whether as “problem” or as “solution.”

A framework displays ambiguous, not known, simple and complicated, and reality is encircled in the middle.

One of the problems is that all the arbitrary layerings of cross-maps can provide multiple meanings for the same base-map – sometimes even within the same diagram – which, if we’re not careful, can create plenty of opportunity for confusion. A context-map is not “true” as such: it’s simply a way to look at a context, a tool to help us make sense fast. For example, if we use that preceding base-map, we might decide to add overlays for layers of abstraction, for timescale, and for a spectrum of interpretation-types – which would give us a context-map like that shown in Figure 8-6.

An illustration of timescale versus interpretation. The level of abstraction is marked from high to low above the 4 dimensions of complicated, ambiguous, not known, and simple. Value versus truth is marked in the horizontal axis. Now versus infinity is marked in the vertical axis.

What this really tells us is that Ambiguous-domain experiments and Complicated-domain analysis are a kind of luxury that depend on having time available for prolonged decision-making. The closer we get to real-time action, the more we’re forced into a narrow band where we have to keep things very simple: either follow the rules, or follow the principles, with no time for anything elaborate.

In that sense, the Simple and Not-known domains have some strong similarities. In decision-making terms, the only real choice along that line is in the extent to which a decision is objective (“truth”-based) or subjective (“value”-based). In the Simple case, we assume that context and actions alike are predictable, controllable; in the Not-known case, neither context nor actions can be predicted, while “control” exists only as a myth, a distant delusion. And somewhere in the middle, between these two extremes, is this context, right here, right now.

The context-map shows us that the combination of repeatability (in the problem-space) and the compression of time available for decision-making (in “solution-space”) will force us into this fairly straightforward split in decision-making choices.

The base-diagram in Figure 8-5 is one of the most versatile base-maps for enterprise-architecture, but there are many others we might use. For example, there’s the five-element lifecycle map shown in Figure 8-7, which we can link to specific time-perspectives, and also cross-link recursively to the five themes of effectiveness.

A cyclic pentagonal diagram of five elements includes people, preparation, process, performance, and purpose. It shows effectiveness and time.

Metaphorically speaking, we “walk around” within the base-map, pulling in various cross-maps as overlays in whatever way seems to make sense, to build up a conceptual picture of what’s going in the context. Recursion occurs when we use the base-map as a cross-map on itself – such as when looking at Preparation within a Process, in that preceding example.

Another example of that kind of recursion occurs when we look at relationships between data, information, knowledge, and wisdom. These are usually shown as a vertical “stack,” with lowly data at the base and wisdom as perfection at the top. But if we explore that “stack” using the base-frame, some interesting cross-comparisons appear, as we can see in Figure 8-8.

A framework displays information, knowledge, wisdom, and data in 4 blocks complicated, ambiguous, not known, and simple with reality encircled in the center.

From this, we can see that the vertical-stack notion is misleading: it’s more accurate to say that they each represent distinct regions or dimensions of the conceptual space. So, for example, it’s entirely correct that we have discrete data-management, knowledge-management, and information-management; and it’s no joke to say that we’ll also need something resembling wisdom-management, because we may well have “wisdom-like” items, such as purported “best practices.” These need to be managed in their own right, yet actually make no practical sense until anchored into the real world via concrete data and contextual metadata, and then connected into the personalized knowledge that can be gained only through personal experience.

A recursion here is that data, information, and the like are only one dimension – the “conceptual dimension” – in the set of asset-types we explored earlier with the segment-model framework: physical, such as “things”; conceptual, such as information; relational, such as links between people; and aspirational, such as purpose, or morale, or the somewhat abstract link that’s represented by a brand. These are dimensions, rather than regions that can be mapped directly onto a two-dimensional surface, so it’s often best to show them in a tetradian format, as the four internal axes of a tetrahedron shown in Figure 8-9.

A 3 D pyramidal diagram represents conceptual, aspirational, relational, and physical as complicated, not known, ambiguous and simple domains as 4 arrows pointed outwards as tetradic dimensions.

Those dimensions can in turn be cross-mapped to regions of repeatability, or, for example, to the different types of focus within a business context, as shown in Figure 8–10 on a simple cardboard tetrahedral version of the same model.

Three different views of a 3 D tetradic cardboard model.

As we saw earlier, most actual business-assets are combinations of these dimensions: a paper form is both a physical “thing” and an information-object, which in turn may represent a relational-asset such as via a signature. Hence it’s useful to think of assets – and also functions, locations, capabilities, even events – as occupying a region within that tetradian space. Decision-types, and skill-types in capabilities, will often need to use a different set of dimensions: the underlying concept is essentially the same as for assets, but it’s probably easiest to describe in a base-diagram layout, as shown in Figure 8-11.

An illustration represents the decision types with their domains. Guidelines in ambiguous, principles in not-known, rules in simple, and algorithms in complicated.

Much the same would apply if we use the segment-model framework as a context-space map: the cells within the framework represent dimensional “primitives,” but most real-world entities are “composites” that straddle across rows, columns, or segments, or any combination of those. Yet once we understand that they are composites, we can then drill-down as appropriate, back to the respective base-primitives of the segment-model, as shown in Figure 8-12 – which is one of the key themes that enables architectural redesign.

A framework of segment model. The asset segment is at the base. Vision, values, and standards are universal on the top, below which component segments are marked. Layer segments are on the side edge.

Another valuable base-map is the “business-model canvas,” shown in Figure 8-13, and first presented by Alex Osterwalder, Yves Pigneur, and others in the book Business Model Generation. If used solely at the business-architecture level, it provides us with a bit more detail to extend the basic tier-1 functional business-model, by summarizing who does what and why in the organization’s internal and external relationships.

An illustration of a business model canvas. The key partners and customer segments are linked to key activities, resources, customer relationships, and channels to value the propositions of cost structure and revenue streams.

The meanings of “customer,” “partner,” “value,” “revenue,” and “cost” will all vary with the context, but the principle remains the same in every part of the enterprise – hence a very useful set of tests to assess the context.

Given a set of base-maps such as these, we then need to collect a stack of cross-maps in our conceptual toolkit, to act as “flip-cards” to scan through many different views onto a context. We’ve seen quite a few so far, and you’ll also find some others – most of them overlaid on the main base-map – in Appendix B, later in the book.

I guess we might be in some danger of getting lost in theory at this point, so it’d be wise to throw in a reminder that the key driver here, always, is about finding ways to make sense of the context, and apply it in practice, fast. The theory may be fascinating, but sometimes so in an all-too-literal sense: we need to remember that our clients in the business and elsewhere are no doubt waiting impatiently for real results – and we’d better deliver.

Yet engaging others in this type of exploration is a key part of our work as architects, promoting, expressing and enacting that “one idea”: “things work better when they work together, with clarity, with elegance, on purpose.” We do need the right level of theory in order to provide the proper foundations to explain those ideas in practice: the trick here is in finding the right balance.

Problem-Space and Solution-Space

To make it practical, we need to link theory to practice in a way that also links “problem” to “solution.” One way to do this is to create maps of “solution-space” that position various pre-packaged options for action – “solutions” – onto the same base-maps and cross-maps that we’ve used to assess the “problem-space.” When the two types of maps align, the process of scanning through problem-space will automatically indicate options for action – and usually with the same characteristics of recursion and the like, such that the same “solution” can be used in many different ways and in many different layers and aspects of the organization.

For example, as shown in Figure 8-14, we could start with the five-element lifecycle-model with the overlay of the five dimensions of effectiveness applied recursively onto that, as described earlier, to give us a context-space map with which to assess the respective problem-space.

A pentagon cyclic diagram of the effectiveness of 5 elements. The 5 elements of people, preparation, process, performance and purpose are described in 5 dimensions such as elegant, efficient, reliable, integrated, and appropriate respectively.

With this map, we would typically aim to identify where problem-areas might be: such as the people-side of planning, perhaps, and a general lack of awareness of direction of the organization, which we might describe in those terms as Purpose/Elegant. A matching solution-map will list various options for action against the same categories, such that the process of “walking around” in problem-space also automatically becomes a means to identify appropriate options to address the respective issues. For example, we could take that preceding cross-map of the effectiveness-dimensions and five-element lifecycle, and then cross-map again to a set of example “solutions” for each region within the context-space map:

There are always variations: for example, in the Chaotic case, we might deliberately choose the exact inverse of the options that are suggested in the solution-map, to see if we could trigger off an “immune-system” type of response. That’s where the skill of the architect really comes into play – and also why it takes a lot of careful practice over a long time to develop those skills without causing a lot of damage along the way…

So, in a sense, it’s good that most enterprise-architects start out in IT-architecture, because most of what happens there is in “ordered” contexts – from very-Simple to very-Complicated – that provide a good base for skills-development before tackling any of the genuinely Ambiguous or Not-known “uncertainty” contexts.

The true complexities of business-politics and the like can cause real difficulties for many of the would-be architects coming up from IT, but in practice it can actually be much harder to come the other way, from business to IT. Simple-domain contexts follow strict invariant rules, often with no room for negotiation – a fact that many business-folk will find immensely frustrating – and the sheer volume of simple detail needed to make something work well can be utterly overwhelming if we’re not used to it.

In short, there are very good reasons why successful enterprise-architects tend to be going somewhat grey in places by the time they really hit their stride!

Both “problem” and “solution” are ways of looking at the context: they aren’t separate from the context, nor are they really separate from each other. In a very real sense, as architects, we are “the problem,” just as much as we are “the solution,” the initial means by which the desired change will come about. But how do we describe that, in a way that makes sense to anyone else? We’re going to need a good metaphor.

One metaphor we might use is the answer to the old physics question of “is light waves or particles?” It turns out that the closest to a correct answer to that question is “yes, therefore no”: “wave” and “particle” represent different ways to interpret the phenomena of light, but ultimately neither can describe what light really is. If we describe light in terms of particles, we can understand certain ways that light behaves, such as photoelectric effects and so on. If we describe light as waves, we can explain other ways that light behaves, but which particles can’t do – such as light’s ability to move through solid glass. Both views are “true” in their own way, but each of them contradicts the other, so we can only make sense of what’s going on by using only one of those views at a time.

The important point, though, is that we can do different things with each view that the other view won’t let us do. If we choose a useful set of views, and then switch between them as we need, we can cover a much broader overall scope, and still make sense of what’s going on. Consider a light-bulb, for example. We’d typically say that the light comes out of the light-source as photons, or particles of light. But particles can’t get through the glass, so we’d switch to saying that light is made up of waves. Switching metaphors like this is a bit of a crazy trick, but it works.

Switching between metaphors is also the core to how we use context-space mapping: it’s not that there is a single view that is “the truth,” but that we switch between metaphors to give us different view on that context, and to allow us to make sense of what we see. We then use that sensemaking to guide subsequent decision-making, about what we should do within that context to achieve the results we want. And in the same way, we collapse the supposed separation between “problem” and “solution” to arrive at our choice of action. Making sense, making decisions; observe, orient, decide, act.

So how does this work in practice? At its simplest, as shown in Figure 8-15, we go for a walk – metaphorically speaking – around the “world” described by the context-space map and by what we ourselves observe in the context itself. We begin with any appropriate base-map that seems to fit, or that gives us a useful-seeming place to start, and then add or remove cross-map overlays to give us new questions with which to orient ourselves to what’s going on. Perhaps we might switch over to another base-map, start again from there – all in a matter of minutes. But in essence, that’s it: we go for a walk – all over the map, in whatever way makes sense.

An illustration of walk through the context. The 4 contexts are ambiguous, not known, simple and complicated with reality in the middle.

Relevant aspects may be scattered all over the map, or occupy multiple regions within the map – there’s no set rule that says that there will only be one region of interest or concern within the context. And in the same way, different segments of a problem may need different matching solutions: some parts may be Simple, if we’re lucky, but others may well be Ambiguous in the extreme, and we’ll need to address all of those aspects in some way or other in order to achieve real lasting success.

This, incidentally, is one more reason why describing IT-architecture as “enterprise-architecture” is so dangerous: it views the entire context from an IT-specific viewpoint, and hence ignores anything that cannot be made to fit an IT-centric “solution.” Which, yes, can work quite well – sometimes – when the scope is restricted solely to the “worlds” inside of IT-boxes; but it does not and cannot work with any true real-world context that reaches beyond those artificially Simple constraints.

The blunt reality is that IT systems in general can only handle Simple problems well, and Complicated problems only at ever-increasing expense and fragility, but are often worse than useless in the inherently uncertain domains of deep-Ambiguous and Not-known. Yet most real-world contexts will include aspects in all domains: for example, every real business-system will include Ambiguous human processes alongside any automated Simple or Complicated ones. A “solution” that only handles the Simple parts of any context and dumps everything else into the “too-hard basket” is no usable solution at all.

But that’s exactly what’s happened with every new IT-driven fad. Whenever a new idea comes along – such as business process re-engineering (BPR), service-oriented architecture (SOA), or “cloud”-based systems – IT vendors rush to build some pre-packaged “solution” around that idea, but ignoring all those aspects of the context that cannot be “solved” by IT. Instead of tackling the context as a whole, the vendors push the delusion that everything can be reduced to Simple rules, enabling automation to solve everything, without requiring any change to management models or management thinking. The result has usually been an expensive failure: very expensive. As one of the originators of BPR, Michael Hammer, put it, “I was reflecting my engineering background and was insufficiently appreciative of the human dimension. I’ve learned that that’s critical.”

Ignoring the human dimensions of a context does not work. Most of “the human dimension” sits firmly within the Ambiguous domain – and we cannot “solve” that with a Simple IT-system. Which is why our enterprise-architecture must be a true “architecture of the enterprise” – and not solely “the architecture of the enterprise-IT.”

We keep walking, keep walking, round and round within the context-space map, building up a kind of holographic impression of the overall context, exploring some parts in fine detail, others only skimmed-over, and using recursion and reflexion to fill in the conceptual gaps, switching back and forth between “observe” and “orient,” between “problem” and “solution.” Then at some point – often without apparent warning, though sometimes because we simply run out of time to do any more exploring – we know it’s time to stop exploring, and decide.

That moment of decision is what triggers and enables action.

And that’s the point our clients have been waiting for all along: that’s where they gain concrete value from our work. That’s often also the point where the responsibility passes out of our hands, and into the hands of others – the designers, the engineers, the specialist solution-architects, and others, who will put those understandings that we’ve gained about the context to practical use. Yet for us, as enterprise-architects, the story continues on: every new piece of architecture-work will add another layer, another view, into our “holograph” of the enterprise as a whole. Observe, orient, decide, act, is a continuous cycle: act must always lead to observe once more.

So while others may be more interested at first in the outward results of our work, to us, it’s always that continuing journey of architectural discovery that matters most. Over time, “problem” and “solution” slowly cease to be separate; it may be true that “the map is not the territory,” yet more and more we reach toward a sense in which the context-space map is the territory, the means through which we interact with the context of the enterprise itself.

And as Matthew Frederick put it in 101 Things, “our experience of architectural space is influenced by how we arrive”: the journey is the architecture, the experience is the process. We set out on that journey each time we “take a walk” through context-space; the act of “taking a walk” with others, in an Agile-style architecture, may often be the only intervention that’s actually needed. And it’s a journey that we aim to share with others, each time we uphold that notion that “things work better when they work together, with clarity, with elegance, on purpose.”

So that’s context-space mapping: an architectural version of the OODA cycle, where “problem” and “solution” are both embedded within an architectural context. Try it: see what happens. Observe; orient; decide; and act.

In the meantime, though, we still need to see how some of this works in real-world practice, out there with the bank, and what to do about their lost respect.

Functional Business Model

This time, for once, they do all seem to arrive reasonably close to time, and have actually taken the no-phones critique to heart – even the CEO is more willing to play by that rule. Some of that previous message about the nature of respect seems to be sinking in: a very good sign, if so.

We start by explaining the role and value of a function-model, as an overview that will get everyone literally “on the same page.” So what does each person do? What function does their team serve within the organization? And how does that function relate with all the other functions in the organization?

We use the “generic tier-1 function model” in Figure 8-16 to illustrate the basic idea of how the model fits together.

An illustration of the business model for banking. Manage the business is on the top under which 3 types of transactions accept, process, and verify are displayed. Support the business is at the bottom. Contact customer is on the left and customer relations is on the right.

And we explain that what we’re after here is just the tier-2 model – the basic sub-categories in each of the tier-1 regions, for the bank. We’ll do this at first with sticky-notes, placed on the large sheet on that big table off to one side.

We’ve already provided a base-layout for them, derived in part from the eTOM telecoms-industry standard – deliberately “wrong” for banking, so as to encourage the participants to think more carefully about what they do. As we’d hoped, the model comes together very quickly, almost without argument, showing distinct regions such as strategy, call-centers, risk-management, compliance, trading, back-office, clearing, branch-operations, and IT.

To make it more personal, we say, we’ll ask each person to place their own photograph in the respective place on the model. This creates much laughter, as there’d been some confusion about the instructions, hence some people have brought photographs of themselves as children. Others, of course, have forgotten to bring any photograph at all: one woman sketches out a surprisingly good cartoon of herself and uses that instead. We also come across a more interesting problem, because many of the participants have roles that are scattered across many functions in the organization, we have to find a photocopier to churn out various duplicates as required.

After about an hour, the model looks remarkably complete: a very clear picture of what actually happens in the organization, and who is responsible for what. We all lift it carefully up off the table, hang it from the high cross-beam rafters of the room, and stand back to see what else it can show us.

Two points come instantly to mind. One is that people’s roles are structured according to their geographic location, their position in the hierarchy, or which of the two banks they used to belong to, or almost anything, it seems, than their actual responsibilities in terms of business function. Which may be why there’s so much miscommunication and so many clashes of authority, because almost every function has three or four or even five people with “exclusive” responsibility. Except for one crucial business-function: information-technology.

That’s the other key point: the CIO is conspicuously alone, the sole photograph in a large blank area of the canvas, with no-one else to share any of those responsibilities. So even the function-model shows that she has no real support at all: no wonder that she seems so overloaded... The laughter quietly fades all round: there are some thoughtful faces, even shocked faces, standing in front of that model as we move into the morning break. But there are also conversations starting to happen that have never happened before – creating new links across the whole organization, and creating new respect for each other too.

Enterprise-architecture, in action, in real-time, delivering real business-value, right here, right now.

Once the Functional Business Model is in place – and preferably developed to a more-detailed tier-3 level – there’s a whole lot more you can do with it. At Australia Post, we used it for mapping projects, to identify gaps and overlaps; the financial team used it for Activity Based Costing; and just about every manager had printed out their own copy and used it for onboarding of new staff and all manner of other things, including as a visual telephone-directory. Others have used it for mapping pain-points and compliance responsibilities. It’s one of the most useful architectural models there is, and every new architecture-team should develop their own as one of their very first tasks.

Visioning

We start the second session by drawing a much smaller version of that function-model in the center of a large whiteboard, and then expand it out to show all the key layers of the extended-enterprise: partners and suppliers, clients, prospects and competitors, and government and the broader community, as shown on Figure 8-17.

An illustration of the bank in the context of the enterprise in 3 layers. Bank providers and clients are linked to the bank as cost structure and revenue streams. The market is the active enterprise and the community is the extended enterprise.

That, we explain, is the enterprise that they’re actually working with – not solely the “enterprise” of the bank itself. Which leads to the notion of a “vision” that bridges right across the whole of that context, linking the bank with every aspect of its enclosing enterprise. A Vision is a single, simple phrase that provides the people who comprise “the bank” with a reason to get up in the morning, and that also gives others a clear reason as to why they should relate with the bank. It’s about the whole enterprise – not just the bank itself.

Respect is about being “on purpose” for everyone involved in the enterprise. And that vision of purpose is also where respect comes from. A full audit-trail where every activity at any time anywhere in the bank links to a goal, to a mission or capability, to the role of the bank within that shared enterprise, to the vision that defines why that enterprise exists. And all the way back down again: vision, role, mission, goal, and thence to each and every activity. And, as also shown in Figure 8-18, the vision provides the ultimate anchor for everything that the organization is and does.

A model has 2 divisions of means and ends. It starts with vision, role, mission, goal, and activity.

The vision itself is a short, simple statement describing a “world” desired by all participants in the enterprise. The statement is chosen by the organization itself, but as a means to describe the ecosystem in which it operates, and the reason why the various business-relationships and other relationships would exist within that enterprise. For example, Australian brewers Lion Nathan hold to a vision of “a more sociable world,” while the IT-industry standards-body Open Group maintain the vision of “boundaryless information-sharing,” linked to their tag-line of “making standards work.”

Where most attempts at defining a vision go wrong is that they’re literally self-centered, describing the enterprise only from the perspective of the organization itself: the classic marketing-style “vision” of “to be the best this-that-or-the-other.” To work properly as an anchor for everything the organization is and does, the vision needs to be much broader, describing a “world” with space enough for all the other players too. The organization then chooses one or more roles within that “world,” as providers of some of the services of that “world,” and consumers of others; and the other participants choose their own differing roles, perhaps as “clients” or other service-consumers, perhaps as competitors delivering the same kinds of services, perhaps as regulators, and so on. Yet, in effect, all of the active participants and other stakeholders will share at least some aspect of the vision – which is why they are stakeholders in that vision. The vision provides the common reference-point that links all those services together.

And a vision itself is not something that can be measured, or “achieved”: it just is.

It’s stable – it never changes.

It’s singular and universal – there is only one vision, applying to everything the enterprise is and does.

It’s emotive – it describes “the passion,” it implies desirable or undesirable characteristics for hiring policies, and provides direct motivation, in the sense of “it’s what gets me out of bed in the morning.”

And it’s strategic – it provides a focus-point to identify “weak signals” that forewarn of strategic changes in technology, society, and the like.

The vision for the enterprise cannot change, because doing so would fundamentally change the enterprise. (In fact, if the vision does change, the enterprise could literally cease to exist – and may take out the organization in the process.) And the vision is not abstract: it needs to appeal in a very personal way – and if we can’t connect with it in that literally emotive sense of “getting us out of bed in the morning,” we’re possibly in the wrong enterprise.

For the other nodes in that “audit-trail,” the Role describes what the organization aims to do and not do within the vision’s “world,” as the ways in which it contributes toward the vision. Although a role-statement may often include some kind of boundary, such as processes, overall activities, or geographical constraints, there’s no explicit qualifier, no “best of,” “premier provider of,” or suchlike – it’s just a simple statement about what the organization does in this role. And by placing this boundary around what the organization does, this automatically implies other roles that would be needed to realize the vision: for example, if Lion Nathan sees itself in the role of “brewer and distributor” for “a more sociable world,” the other roles it might need to connect with would include not just the obvious ones such as “customer,” “supplier,” and “competitor,” but others such as “educator in safe and healthy sociability” and even “provider of police services.” Taking a whole-of-enterprise view makes it clear that these odder intersections with other roles would be an expected part of business – which can “surface” hidden opportunities, and reduce the potential for unpleasant surprises from unexpected stakeholders.

A Mission is a description of a capability or service that we will create and then maintain indefinitely thereafter. (Think “trade-mission,” rather than one-off military-style mission – in fact the latter is really a type of goal.) So a “mission-statement” should be a straightforward description of the overall means – the how – by which a role will be delivered, and of what determines “success” in that role. Each mission must identifiably support a role and vision, and must be measurable in some way, because while the mission is never actually “achieved,” we need some means to identify the extent of its success. And in many cases, missions are as much about partners, other roles in the Vision-world, because these are the points of contact with these “outside” roles: the metrics for the mission must also monitor and manage that association. Each mission is also a locus for continuous-improvement processes, its metrics that are key inputs for quality-management; and missions also need regular review, not only in relation to their own metrics, but also to the respective role, because each may change the other.

Finally, a Goal describes a “project” with a specific set of activities, deliverables, and target date for completion. (Every transit through a value-chain is a kind of “project” with a finite goal.) Each goal contributes toward a mission – it never exists in isolation – and each will be immediate, explicit, concrete, and practical, providing clear boundaries of time, space, and context to make it easier to concentrate on the task to hand. Goals also differ from missions in that, at the end of the project-lifecycle, a goal completes, but a mission continues; and we measure or review after a goal, but during a mission. Well-constructed goals can also provide a useful sense of urgency, of need to complete.

That brief wander through theory brings us back to the urgent goal here, which is to find some kind of anchor that will re-link the bank with its market, and start to reclaim the lost respect.

We remind the participants here of the role and aims of a vision, in terms of relationships between the organization and enterprise, and emphasize some key themes, of which the most important is Visioning Rule #1: this is not a marketing exercise! A pitch is a short-term appeal to the market, while the Vision is the unchanging anchor for the organization itself: it’s essential never to confuse these two functions, because mistaking a market-pitch for a vision can kill a company – and often has.

The key point is that the vision never changes. Strategies and tactics implement the paths toward the vision, and positioning relative to others who connect to the same vision: we use strategy to review the continuous subtle changes needed in the role, and create and maintain missions to match; and we use tactics to define the goals and activities that are needed to support each mission. Successful strategies depend on clear goals and the like; and goals in turn depend on clear missions, roles, and vision. But a misframed vision will render strategy unreliable, unstable, and error-prone. Hence getting the vision right is important in the extreme.

Because it’s not so much a choice as a feeling, identifying a valid vision does take time. Unfortunately we don’t have much time here in this workshop, but we should have enough to get a sense of what a workable vision would feel like.

The participants divide up into small teams of four or five, and we split the remaining time into brief development-and-review cycles of ten to fifteen minutes each, to work toward something that resembles a usable vision.

To no one’s great surprise, the first few passes provide several all-too-obvious examples of falling for every one of those pitfalls: a hyped-up “to be the best we can be!”, for instance, or the dreary marketing-slogan “the best bank for you.” Back we go, and back again, as the same mistakes get repeated time after time: and we begin to get worried, because it’s looking all too possible that this group simply won’t be able to get the point of the exercise – a way to reach beyond the usual self-centric marketing spiel, to something that will allow people to connect with the bank, and to re-create that respect.

Then out of the blue – or out of the welter of excitable slogans now scattered all over the walls – something usable at last appears: “better financial futures.” It doesn’t look much at first glance – it might not attract a marketer’s eye, for example – but it does have the right feel, the right characteristics. What is it that interests every player in this shared-enterprise? Better financial futures. What is it that interests the government? Better financial futures. The bank? It wants better financial futures too. And likewise the customers, prospects, partners, suppliers, competitors, probably even the bank’s enemies and anti-clients: everyone’s interested in better financial futures. It makes sense: it works. Or well enough for now, anyway – and much better than those marketing-slogans would have done so on their own.

And now we can come back to all the marketing-slogans and internal exhortations, to review each of those in terms of the vision. There are plenty of phrases up on that wall that – with perhaps a few tweaks here and there – would line up very nicely behind that feeling described by “better financial futures.” Everything they’ve done so far still works: but they now have a clear reference-point against which everything and anything can be assessed. So it’s now all starting to make sense: we can see the metaphoric light-bulbs lighting up behind many participants’ eyes…

But at that point, it really is time to stop: time for a quick wrap-up, and then let them get on with the rest of their day.

Wrap-Up

We’d started from the problem of respect, or loss of it. From there we’d seen how respect was poor even within the organization, but more in a passive sense, that there was nothing to help tie them all together as an organization, and thence with their market and the broader community. So that’s what we’d concentrated on: how we could link everything together.

You’ll notice that we didn’t mention “architecture” anywhere here – even though that’s actually what this is.

That’s why we’d started the workshop with the function-model, as a way to get everyone within the organization on the same page – literally so. Each member of the executive and senior-management could now see the part their own work played within the overall organization, where they overlapped with others, and where gaps in responsibilities might appear in future.

We’d then expanded that to show how the organization fitted in turn within the broader enterprise – the implied value-propositions and service-interfaces with every other player in the enterprise, including those stakeholders who might have no direct interaction with the organization.

And from there we’d moved on to the notion of a “vision,” a single phrase that links every participant in the entire enterprise, both within the organization and beyond it. We’d shown how this differs from, say, a marketing-slogan, or from the usual business metrics. They themselves had found a usable starting-point for this – “better financial futures” – and we’d then explored how this could be used in practice, with immediate effect, and immediate practical impact.

Together, in effect, we’d created a space in which respect could exist: respect for each other within the organization, respect for the other players in the market and the broader enterprise, and also respect from those other players toward the organization and all the people within it. Sure, there’s lot more still to do, to reclaim that respect, over the coming months and years: but the necessary foundations for all that work are now in place.

Quite a lot to have covered in a single morning, then.

As the participants file out of the room for the midday break, we grab the chance to make some quick notes for the following day’s review with the change-manager; and then settle down to the quiet unnoticed slog of tidying up from the session.