Mapping the Enterprise Modelling the enterprise as services

with the Enterprise Canvas

Tom Graves Tetradian Consulting

Published by Tetradian Books Unit 215, Communications House 9 St Johns Street, Colchester, Essex CO2 7NN England http://www.tetradianbooks.com First published November 2010 ISBN 978-1-906681-26-5 (paperback) ISBN 978-1-906681-27-2 (e-book) © Tom Graves 2010 The right of Tom Graves to be identified as author of this work has been asserted in accordance with the Copyright Designs and Patents Act 1988.

Contents Introduction .......................................................................................................................... 1 What is the Enterprise Canvas?.......................................................................................... 4 The nature of service.......................................................................................................... 14 Service context and market ............................................................................................... 21 Service vision and values .................................................................................................. 36 Service layers ...................................................................................................................... 47 Service actors and other entities ....................................................................................... 57 Service roles and relationships ......................................................................................... 63 Service structure ................................................................................................................. 69 Service flows ....................................................................................................................... 79 Service guidance................................................................................................................. 90 Service investors and beneficiaries ................................................................................ 102 Service decomposition..................................................................................................... 112 Service content .................................................................................................................. 116 Services as systems........................................................................................................... 147 Example patterns.............................................................................................................. 165 Integration with architectures......................................................................................... 177 Rethinking vision bottom-up.......................................................................................... 186 Appendix A: Enterprise Canvas – a visual summary ................................................. 194 Appendix B: Working with Business Model Canvas .................................................. 201 Appendix C: Sources and resources .............................................................................. 207

Acknowledgements Amongst others, the following people kindly provided comments and feedback on themes in the various drafts of this book: Jose Antonio Alvarez (TransCreativa, MX), Shawn Callahan (Anecdote Pty Ltd, Aus), Adrian Campbell (Enterprise Architects, Aus/GB), Pat Ferdinandi (CBDI, US), Ian Glossop (Glossop Mallard, GB), Nigel Green (5Di, GB), Anders Jensen (Meeho, DK), Cynthia Kurtz (CFKurtz, US), Nick Malik (Microsoft, US), Alex Matthews (ToBeEA, GB), Alex Osterwalder (BMGen, CH), Kim Parker (AusPost, Aus), Ron Segal (Mindhut, NZ), Kevin Smith (PragmaticEA, GB), Michael Smith (Latidos, MX), Peter Tseglakof (NAB, Aus), Peter Ward (BCS, GB), John Wu (LiteEA, US). Please note that, to preserve commercial and personal confidentiality, the stories and examples in this book will usually have been adapted, combined and in part fictionalised from experiences in a variety of contexts, and do not and are not intended to represent any specific individual or organisation. Registered trademarks such as Zachman, TOGAF, FEAF, ITIL, Business Model Canvas etc are acknowledged as the intellectual property of the respective owners.

1

INTRODUCTION

Modelling the enterprise How can we describe the enterprise? More specifically, how do we describe what happens there, how, when, where, why, by whom, with what? For architects and others tasked with creating conversations and connections across the enterprise, these are not trivial questions: they strike right to the core of the work that we do. The usual answer is ‘models’ – data-sets, drawings, diagrams – that illustrate specific aspects of the respective issues. But the catch is that there are a myriad of model-types in use in enterprise-architectures and elsewhere, all different, all applying at different levels, all applying only to specific subsets of the context, and all with weak connection at best to any other type of model. It’s a huge problem – though one that’s not easy to see until we try to link everything together across the whole of the enterprise... Hence the Enterprise Canvas: a new model-type that can be used to describe just about anything in any part and at any level of the enterprise, and that also acts as a consistent frame for all the other types of models that we need in our architectures. The Canvas can take several different forms, but the same basic frame provides a consistent anchor in how to view everything else in the enterprise. It doesn’t really replace any other model: but within that frame, all those other models start to work together, and start to make practical sense.

2

Enterprise Canvas: a basic example

That’s the role of the Enterprise Canvas: not “one model to rule them all”, perhaps, but “one model to bind them”. Consistency at last; consistency that makes sense; that’s the aim here. Interested?

Who should read this book? The book is intended for enterprise architects, business-architects, IT-architects, process-designers and others who deal with the practical implications of whole-of-enterprise issues. It should also be useful for strategists and service-managers, and for anyone else who works with other enterprise-wide themes such as supply-chains, value-webs, quality, security, knowledge-sharing, sustainability, business ethics and social responsibility, or health, safety and environment.

What’s in this book? The text is divided into two main sections:

• a step-by-step introduction to each of the components in the Enterprise Canvas model, and their function and use in modelling the overall enterprise

3

• a variety of patterns, practical examples and business usages for the model and its associated tools and techniques

Each chapter builds on the previous descriptions, and provides a set of ideas and methods to apply straight away in your day-to-day work. Although there’s a fair amount of theory behind the Canvas, the emphasis is always on practice – something that you can use – so each chapter includes examples and stories to place the ideas into a real-life context. Most chapters also include an ‘Applications’ section, with sets of questions to help you apply the material within your own context. And the book ends with a ‘Resources’ section, pointing to sources for further information. But what is the Enterprise Canvas, anyway? Let’s start with a brief overview.

4

WHAT IS THE ENTERPRISE CANVAS?

The Enterprise Canvas is a quick, easy way to describe just about anything in an enterprise. It’s simple enough to scribble on the back of a napkin, yet it can also carry enough detail to link in with formal modelling tools for project-management, system-design, strategy simulation and the rest. It’s a way to support conversations about how the different things – the different services – all connect together across the enterprise, both within and beyond the organisation itself. To start, we assert that there’s always one key idea that in effect defines the enterprise. Everything that happens in the enterprise revolves around this one idea or ‘vision’. For example, everyone involved in the TED conferences connects in some way with their vision of ‘ideas worth spreading’. This single idea defines what the enterprise is: everything else is some means to help make that vision happen, and share it amongst the players in the enterprise.

Serving the enterprise vision

5

Everything in the enterprise is a service that contributes towards that vision. Or it should do – hence the need for conversations, to find out what’s going on at each point and what we could do to make it more effective at contributing towards the vision. The whole point of a service is that it serves something: it adds value. We bring in something from elsewhere in the shared enterprise; we create or add value; and we pass it on to some other player in the enterprise. This flow of value around the enterprise is a supply-chain, a value-chain, a value-web: the name we use doesn’t matter that much, what does matter is this flow of value.

Each service connects the value-web to the vision

That gives us the simplest version of the Enterprise Canvas, suitable for a back-of-the-napkin scrawl sufficient to identify what the service is and what it does. That’s what we would aim to elicit in an initial conversation with service stakeholders. Next, what’s moving around in this value-web? Who else is involved? This too provides us plenty of cues for conversations with our service-stakeholders.

• Who are the suppliers for this service – its providers? What services do they provide, and in what form?

6

• Who are the customers for this service – its clients? What services do they consume, and in what form?

• What connection do those suppliers and customers each have with the desired-ends – the vision – for this overall service?

• And what relationships does this service have with each of its providers and clients?

Given answers to questions such as these, we’ll then add to the sketch-diagram a supplier-side and a customer-side, to document what comes in, what goes out, what is shared with whom, and the reasons and choices for that flow of value.

Service, suppliers and customers

For reasons that will become clear as we go into the detail later, it’s useful to split each flow into and out of our services into three distinct phases: what happens before, during and after the main transactions of a service. This gives us a simple grid that would work well for on a back-of-the-napkin scrawl in the midst of a conversation.

7

Flows before, during and after transactions

We might ask our stakeholders other questions to elicit a bit more detail about the structure and operation of the service itself. For these questions we would expand our view of the service in those two dimensions: the core of the service itself and the parts that face towards suppliers or customers, as they link to those three sets of flows before, during and after the main transactions.

Service, suppliers, customers and flows

There are a few other items that might be useful here: for example, we could ask further questions about what guides this service:

8

• Who or what will coordinate this service with others in the same organisation, or value web, or the overall extended-enterprise?

• Who or what takes responsibility for mapping out the future of this service? • And who or what will help to keep it on track to the vision and values of the

extended-enterprise? This sketch-map of the Canvas provides us with placeholders where we can link our stakeholders’ descriptions of those other guidance-services to the service that’s in focus on the Canvas.

Service and its guidance-services

And we could also ask:

• Who or what invests in this service to get things started? • Who or what extracts value from the overall flow, as a beneficiary of the service,

rather than a customer? (Note too that the investors and beneficiaries are not always the same.)

9

Service investors and beneficiaries

We can mix-and-match between all these various views and add-ons as we need. The same Canvas – and the same service in focus – could be shown as anything from a simple cross to an all-the-extras ‘kitchen sink’ view, depending on the amount of detail that we need in our back-of-the-napkin scrawl.

‘Kitchen sink’ back-of-the-napkin Canvas (service)

10

And we then can link in any other models we might want, too: for example, that might include Zachman or Porter Five Forces or a SWOT or a BPMN process-model. The Canvas provides a frame that links them all together and helps them to make more sense. We can also make it more formal – the kind of boxes-and-lines diagram that we would show on a Powerpoint slide rather than the back of a napkin. The simplest version is the service on its own, as a means to act on the value-flow in alignment with the desired aims of the overall enterprise.

Formal version: the service in focus

More often, we would add a bit more detail about the service by splitting it into that three-by-three grid: inbound (supplier-side), this (this service), outbound (customer-side); and before (future), during (present) and after (past) the main transaction. There are default labels for each of the resultant nine cells, but we can use any other appropriate label if we wish – which would usually be the case if we’re modelling the real services of an enterprise.

11

Formal version: standard nine-cell grid

As with a back-of-the-napkin sketch, we might add further detail about other services that connect with this service, and about the flows that make up the value-web between all these services.

Formal version: supplier, customer and value-web

And might also want to add the investors and beneficiaries, or links to the various guidance-services.

12

Complete formal version: investors, beneficiaries, guidance

We can use any or all of these variations to describe any type of service, at any level of abstraction, anywhere in the enterprise: whichever way we portray it, it’s all the same simple model. Simple, yet powerful. And easy to use in practice, in real everyday business conversations with business stakeholders. That’s what the Enterprise Canvas is for: keeping it simple, keeping it real.

Application • What models and model-types do you use in your work? To what domains and

levels of abstraction do each of those models apply? • How and why do you link the various models together? If you can’t link the

models together, what difficulties does this present in practice?

13

• Do you develop or work with business-models? If so, in what ways do you need to extend that model to broaden its scope, or to link it to other types of models? How do you implement a business-model in practice?

14

THE NATURE OF SERVICE

Summary This introduces the core ideas beneath the Enterprise Canvas: in particular, the notion that everything in the enterprise can be described as a service – an entity that creates and delivers value in terms of a desired aim or ‘vision’ that is shared across the entire extended-enterprise.

Details Everything is a service

Within any organisation, we need to keep track of how everything connects with everything else: all the way up to the big-picture view, all the way down to everyday process and practice, and all the way across every aspect of the enterprise. Yet it’s not simple: at one end of that spectrum we can lose our way in the clouds, and at the other end there’s a real danger of drowning in all of that detail. Until now, there’s been no one type of model that would cover the whole of that range. Each type of model seems optimised to describe just one part of the puzzle: we end up trying to translate from one model to another, jumping back and forth from abstract to concrete – and there’s a lot that can get lost in the translation. There’s an almost desperate need for consistency here. That’s where the Enterprise Canvas comes into the story. It’s true that the complete model might at first seem quite a complex beast, with many layers and side-themes.

15

Yet when we strip it right down to its bare essentials, it’s actually very simple – and its real power comes from that simplicity, in how it links together a handful of key ideas:

• The enterprise exists to create and share value – in whatever way ‘value’ may be defined in that enterprise.

• An enterprise is a dynamic structure – a ‘value network’ - in which value is continually created, transformed and transferred in a continuous process of flow and change.

• Everything in the enterprise is or delivers a service of some kind that adds value to the enterprise, and that passes value on to other services in the overall enterprise.

• The enterprise consists of services that connect with and support each other in creating value for that enterprise.

To the Enterprise Canvas, everything is a service, each helping to create value as it flows around the overall enterprise. Products are services too – or ‘proto-services’, perhaps – in that they provide people with the ability to deliver the desired service via the use of that product. Each of the actors in the enterprise – as suppliers, customers, competitors, regulators, or whatever other roles – provides those services to the overall enterprise. And even the enterprise itself is a service: it exists to serve a vision of some kind, in accordance with some set of values, even if only implied and unacknowledged. So the Enterprise Canvas is a generic map to describe any service, anywhere in the enterprise, together with its interdependencies and flows. To give a bit more detail, to make this more usable in practice, we can assert the following:

16

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

• 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 ‘shared-enterprise’ or ‘extended-enterprise’ (or just ‘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 – the business-ecosystem, in this case – 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 in the enterprise is a service, provides a service, can be described in terms of services and flows between services; there are no apparent exceptions to this. And every service serves – it serves something else, someone else; it serves the unifying ‘vision’ that defines the extended-enterprise. We also note that, over the ecosystem as a whole, all relations are symmetrical. Everything is a service, hence everything is also a ‘supplier’ to at least one other service, and a ‘customer’ of at least one or more others – otherwise the service literally has no purpose within the enterprise (other than as a potential parasite, perhaps). Within the overall flows of value in the enterprise, everyone is both ‘supplier’ and ‘customer’: those types of roles arise from the relationships between

17

the players rather than from the enterprise itself, and increasingly – such as in Agile-development techniques and crowdsourcing – the old boundaries between these roles will often become blurred. Overall, everything needs to balance out somehow, yet also keep creating value for every player: if some of the players set out to ‘win’ by trying to make everyone else lose, the enterprise as a whole will die – in which case everyone loses. Another key theme is about layers of abstraction. At the top-most layer, there is only the enterprise itself, and the vision and values that define it; at the lowest layer, there are the myriad of activities and details where the aims of the enterprise come into contact with the real world. Between the two extremes are other distinct layers: strategy, tactics, action-plans, and so on. The same patterns of services and relation-ships will recur at each layer – hence we can use those patterns to describe how strategies and tactics will be put into practice, and how ideas and experiences from the real-world can influence those tactics and strategies. Finally, there’s a strong underlying emphasis on effectiveness: finding the right dynamic balance between efficiency, reliability, human-factors, the overall business-purpose, and the processes that link all of these together. We’ll see more on all of these themes as we explore the Enterprise Canvas in depth.

A matter of metaphor Two specific metaphors will be of real value here. The first is that of enterprise as organism – rather than enterprise-as machine. For the past century and more, the dominant organisational metaphor has been that of ‘organisation as machine’ – a machine for command and control, a predictable machine for making money, and so on. This Taylorist machine is focussed on making product: and being a machine, it has no concept of service as such.

18

An enterprise, though, is a social construct: it’s bounded by human values and shared-commitments. And whilst it can be extremely difficult to get machines to emulate real people; it’s relatively simple to get people to emulate machines. Yet so many subtle and maybe essential nuances can be lost in the translation that ‘command and control’ is little more than an illusion – and one that can be very dangerous indeed to the overall enterprise. Hence the value of viewing the enterprise as a living entity in its right. Where a machine is made up of engineered components, a living system consists of services, each interweaving and interacting with all the other services in the overall ecosystem. An enterprise is defined by shared commitment to a shared vision: the purpose of a machine is extrinsic, externally-defined, but to a human enterprise its purpose is intrinsic, an essential part of its definition of itself. Since the enterprise is a social structure rather than a machine, this warns us is that we can’t actually ‘engineer’ an enterprise: to get it to work to its greatest effectiveness, we have to start with purpose, and build outward from there. The core idea behind the Enterprise Canvas is that everything can be described in terms of services. So whilst we can perhaps interpret each Enterprise Canvas module as a kind of component – and this certainly does make more sense as we get closer to real-world action – we need to take care not to fall back into the Taylorist trap. No matter how machine-like something may seem, it’s still delivering a service within a larger ‘life-like’ ecosystem. The second metaphor is that of model as holograph – rather than model-as-photograph.

19

A photograph depicts a scene from a single viewpoint, and is usually quite easy to decipher. If we cut up a photograph, we’ll have a pile of tiny jigsaw-puzzle pieces, each in full detail, yet with nothing to link those pieces together. A holograph, as its name suggests, depicts a scene from every possible viewpoint, all at once. If we cut up a holograph, each of those fragments still depicts the whole scene, though in less detail than the complete holograph. Most existing model-types in business contexts are more like the photograph: they depict one part of the context from a single point of view. That’s often essential at the detail level, but it’s very hard to link them all together. The usual solution is to try to build some kind of frame that describes ‘Life, The Universe, Everything’, all of it in ‘excruciating detail’ (to quote John Zachman). But it’s often hopelessly impractical, because it could literally take forever – and in the meantime the world will have moved on anyway, so the whole approach is doomed to failure even before it starts. With the Enterprise Canvas, though, each view or module is more like a fragment of a holograph. Each view carries its own small collection of detail, just like any other conventional model: but that model is always linked to everything else, is always part of a greater whole, in an identifiable way. In practice, the Canvas is perhaps more of a hybrid, combining the advantages of both metaphors – photograph and holograph, detail and scope – in ways that still make simple, straightforward, practical sense. Yet when we look at the amount of detail that can be carried in a single Enterprise Canvas model, it’s sometimes easy to forget that it is still connected to everything else: so it’s useful to remember that holograph metaphor, and always to keep it in mind whilst we work.

20

Application On services

• If everything in the enterprise is a service, what or whom does each service serve? How would you model those relationships of service?

• If everything in the enterprise is a service, how does that change your perception of the enterprise itself? Whom does the enterprise serve, and why, and how?

• In what other ways could you describe the functioning of the whole enterprise? How does each of these views change your perception of the enterprise and how it works?

• In your architecture, how do you describe the different layers of abstraction – from vision to strategy to tactics to operations, and back again? How do you describe and govern the various transitions between these layers of abstraction? How do you depict the same nominal service at different layers of abstraction?

On metaphor • In what ways do you describe the enterprise as a machine? How is this reflected

in everyday language, such as ‘operations’, ‘functions’, ‘business units’ and the like? What impact does this metaphor have on the operation of the enterprise as a whole?

• In what ways do you describe the enterprise as some kind of living organism? How is this reflected in everyday language, such as ‘culture’, ‘health’, ‘taking the pulse’, or even the term ‘corporation’? What impact does this metaphor have on the operation of the enterprise as a whole?

• What other metaphors do you use to describe the enterprise? How are these reflected in everyday language, such as ‘getting a green light’ (a roads-metaphor), ‘taking a bet’ (finance as gambling), or ‘cooking up a new project’?

21

SERVICE CONTEXT AND MARKET

Summary

This describes the context of the service within a shared-enterprise that includes and often extends beyond the nominal market of the respective organisation. The service’s overall ‘business model’ must encompass every aspect of that shared-enterprise.

Details Organisation and enterprise

No service exists in isolation: it always exists within a context or ‘ecosystem’ of other services with which it interacts. This occurs at every level, with every service, from an operations-layer ‘web-service’ or the services of a customer-service desk or an entire organisation. It’s simplest, though, to describe this at the whole-organisation level.

22

To make sense of the relationships, we need a clear distinction between ‘organisation’ and ‘enterprise’. Although the two can coincide, and many people often seem to think they’re one and the same, we do need to treat them as separate. For our purposes here, an organisation is an entity that delivers services within an enterprise. An organisation is bounded by rules, roles and responsibilities. There’s an explicit boundary of protocol and contract, an explicit boundary of responsibility for revenue, taxes, legal-liability and so on. (In this sense, an individual person is an organisation of one.) Boundaries are explicit and ‘logical’, and much of the structure and purpose and identity of the organisation revolves around command and control. An enterprise is bounded by values and (shared) commitment. The ‘vision’ for an enterprise identifies its emotional drivers, “that which gets me out of bed in the morning”. (An individual is technically an intersection-point of an almost infinite number of enterprises.) Boundaries are often blurry and ‘non-rational’; and much of the structure and identity and purpose of the enterprise revolves around engagement and trust. Or, to put it in its simplest terms:

• the enterprise is; the organisation does • the enterprise provides motivation; the organisation provides action

The boundaries of organisation and enterprise may sometimes coincide – hence the notion of the organisation as ‘the enterprise’. But in effect it's only a special-case, and a potentially dangerous one at that, because it can lead us into a kind of narcissistic self-centrism or a combative ‘us versus them’ relationship with the business-ecosystem.

23

The enterprise creates the connections that the organisation needs between itself and its ecosystem: in enterprise-architectures, we’ll usually define an architecture for an organisation, but about an appropriate enterprise in relation to that organisation. The same applies to when we assess any other kind of service: our aim is to describe the service (the ‘organisation’), but we must always do so in context of its ecosystem (the ‘enterprise’). For most practical purposes, the enterprise that we need in scope should be at least two to three steps larger than the boundaries of the organisation in scope. For an IT-service unit, for example, the respective enterprise might extend to the whole of the business, and perhaps even beyond. For a business organisation, this would include its supply-chain and its relationships with community and government – in other words, its market and beyond.

Service and market To make sense of this, we would typically model the service’s market and ecosystem in a series of stages. One place to start is with the common self-referential notion of the organisation as its own enterprise, where all meaning and value is defined in terms of the organisation itself – as in the old railway joke that “the trains would run perfectly on time if it wasn’t for the passengers!”

The organisation as enterprise

A disturbing number of organisational units and even of whole organisations tend to think this way – that the world not only revolves around them but that it begins and ends with them alone, that there is nothing of any value beyond them.

24

A moment’s thought would indicate that we can’t make sense of services this way: a service has to serve something. So the next step outward is the basic business-model: we receive goods or services from a supplier, add some form of value, and deliver the amended goods or services to a customer. There’s a two-way flow of value here – typically goods and services one way, and some form of payment or ‘value-return’ the other way.

The basic business-model as enterprise

There’s not much opportunity for change and enhancement in that view, though, and we have no way to see what might affect our enterprise from outside, impacting on our direct suppliers and customers. One option here is to expand our view of the supply-chain – such as in the SCOR (Supply-Chain Operations Reference) standard, which extends from supplier’s supplier to customer’s customer.

The supply-chain as enterprise

This gives us a good tactical view of our market, but not a good strategic one, because there’s more to a market than just our own supply-chain. Thinking strategically, we also need to be aware of all the prospective customers and suppliers, our competitors and other market players, industry standards-bodies, analysts, government regulators, and many more besides.

25

The market as enterprise

This would seem to make sense as long as we only think in terms of the most visible transactions of goods and services. Yet there’s much more to an overall enterprise than that, because there are many people who may not engage in direct exchange of products or services with us, but who are still affected by what we do – and who can affect us in return, too.

The shared-enterprise as enterprise

This shared-enterprise includes government in the broader sense – such as general taxes, rather than industry regulation. It includes the families of our employees, the towns and municipalities where they live, the broader economic and social communities in which we operate and that determine our social ‘license to operate’, as business-writer Charles Handy puts it.

26

It includes non-clients – people who are not and will probably never be customers of ours, such as people who live in a different country than one we serve. And it also includes our anti-clients, people who don’t trade with us in the normal sense but who don’t like us or what we do – of whom we now need to be much more aware, because social-media and other new technologies provide them with much more leverage than they may have had in previous times. The ways in which we interact with this enterprise-ecosystem do differ from the simple exchanges of goods and services in our main market: but we ignore them at our peril, because they’re the most common cause of ‘unexpected’ business-problems and even business-failure. To make sense of this, we need to understand the real nature of the broader ‘market’ of the enterprise. It’s true that markets are transactions. Most of the visible activity of the market is about deals, supply-and-demand, ‘things’ being exchanged and paid-for – the content of the market supply-chain. Yet as the Cluetrain Manifesto famously observed, markets are conversations. Information is exchanged in many different ways – sometimes as the content of the transaction itself, but some of it with little direct import for the transaction at hand. Sometimes a conversation is just a conversation – yet it’s also evident that it’s an essential component of the workings of the market. And markets are relationships too. In every market, relationship has an enormous bearing on the way the market works – though that fact is perhaps more obvious in a street-market than in the sanitised ‘market’ of a seemingly-soulless shopping-mall. Finally, markets are purpose. In effect, a market is defined by the shared-purpose of its enterprise-vision, the overall descriptor for its “common set of missions or goals”.

27

Four-dimension tetradian of activity in the market

When we summarise this, it’s clear there are four distinct strands or dimensions here, each in rough correspondence to one of the four core categories of activities and assets:

• physical – alienable ‘things’ – if I give it to you, I no longer have it • virtual – non-alienable items such as information – if I give it to you, I still have it • relational – a person-to-person connection that cannot be directly exchanged with

or transferred to anyone else • aspirational – a personal commitment to an idea or belief such as a brand or

enterprise-vision – again, cannot be directly exchanged with or transferred to anyone else

The usual view of the market is about transaction: the transfer of ‘exchangeable goods’ via the main-channel of the supply-chain, and, separately and in return, payment or its equivalent, through a return-channel. And in its simplest form, profit is the difference between the value-return that comes in from the return-channel from the customer-side, compared to the value-outlay that goes out on the return-channel on the supplier-side. Once we also subtract the value-outlay for internal

28

costs of running the service itself, the result is the ‘bottom-line’ net-profit that is the near-obsessive focus of so many business-folk. Yet those transactions of ‘exchangeable items’ are only one part of the overall activities of the market; and all of those transactions – and the resultant profit – occur only at the tail-end of what we might call the market-cycle.

The market-cycle

The whole structure is a complex feedback-loop. For example, reputation – which itself is a kind of third-party precursor to trust – depends in part on whether the transactions are perceived overall as ‘fair exchange’. Hence before any transactions can take place, the relationships need to exist: and those relationships – and conversations too – are strongly linked to and dependent on the service’s value-proposition. Likewise after the transaction, there not only needs to be the return-channel exchange that completes the ‘fair exchange’ of the transaction, but that too also needs to link back to the value-proposition and the relationships, tying everything together in terms of the various definitions of what ‘value’ actually is within the overall enterprise.

29

All of this needs to be symmetrical, in that – in terms of the overall market – this service that is our current focus is both a customer of other services, and a provider to other services, hence all of the above will apply in similar ways on both ’supply side’ and ‘customer side’. We need ’supplier relationship management’, for example, just as much as we need ‘customer relationship management’. And the value-transfers and follow-up need to be in terms of all forms of ‘value’ defined by the overall enterprise – and not measured solely in monetary terms, for example, no matter what the shareholders may demand.

Vision, values and the enterprise The actual core of an enterprise is its vision. The key point here is that the vision is a stable, permanent, shared reference-point for all players in the enterprise – including the organisation for whom we’re building an enterprise-architecture. We can summarise this in terms of the structure ‘vision, role, mission, goal’.

Organisation and enterprise: vision, role, mission, goal

30

The vision expands out to a set of values, which determine what is value in the enterprise. The values are expressed in practice as principles, which – to use the ISO9000 quality-system terminology – act as the guides for policies, which in turn expand out to procedures, and thence to the fine-detail of work-instructions. Yet all of these will anchor back to the core vision and values, which determine what value is within the enterprise, what we mean when we use the term ‘value’. And that specific combination of ‘value’ and values is unique to each enterprise. The enterprise vision and values are shared in some way by all players in that specific enterprise, which in turn is why they are players in that extended-enterprise. And each of those players presents some kind of ‘value proposition’ that aligns with the vision and that then links with other players in the enterprise.

Every player presents a value-proposition

Later we’ll explore more of this question of ‘what is an enterprise’, but the key point here is that, in effect, the vision and values traverse vertically through each player –

31

each organisation – whereas the supply-chain or value-web provides a horizontal link between them. Each player thus exists at an intersection in the value-web, a point where organisation brings the vision and values of the enterprise in touch with respective roles of the supply-chain. Every organisation within the enterprise provides a service within that chosen enterprise. In turn, each organisation can be subdivided into sub-organisations, and sub-sub-organisations, and so on, almost ad-infinitum; and each of these ‘units’ provides a service that delivers value to the overall enterprise.

Each service sits at intersection between values and supply-chain

Each service provides its own unique emphases on value:

• value-proposition: what the organisation commits to be responsible for (what value it will add to the enterprise)

• value-creation: how, where and by what means the organisation will add value to the enterprise

32

• value-governance: how the organisation will ensure that it can, has and will continue to add value to the enterprise

This also links back to those three distinct transaction-stages that we saw earlier:

• what happens before transactions of ‘exchangeable items’ – an emphasis on relations, which link most strongly to the service’s value-proposition

• what happens during (and with) transactions of ‘exchangeable items’ – an emphasis on actions, which link most strongly to the service’s value-creation

• what happens after transactions of ‘exchangeable items’ – an emphasis on value-transfers (payments and receipts etc, as ‘value-outlay’ and ‘value-return’) and other follow-up and overall integration, which link most strongly to the service’s value-governance

In a ‘service-oriented architecture’ of this kind, everything is a service – so we’ll see these value-themes recur in every part and aspect of the organisation and enterprise. This provides the basis for our Enterprise Canvas – a model we can use in a consistent way to model anything in the enterprise.

Application (Note: the questions here are mainly intended to ‘set the stage’ for your stakeholders, and establish a sense of the space and scope with which we’ll work. The questions can be skimmed over fairly quickly here, because we’ll revisit each of these themes in more depth later.)

Organisation and enterprise • What to you is an organisation? What to you is an enterprise? Are they the same?

If not, how would you distinguish between them, and why? How would you

33

explain these differences to others, and for what purposes? What are the practical implications of treating them as the same, or as separate?

• If we view any specific service as ‘the organisation’, what is its encompassing ‘enterprise’? How do you make sense of the ways in which all these different ‘enterprises’ intersect?

Service and market • What is the market and industry – or industries - in which your organisation

operates? What is it that defines the respective market and industry? What belongs in each? What does not belong in each, and why? What defines the boundaries?

• Who are your organisation’s market – the people provide services to your organisation, or who use your organisation’s services?

• In what ways do you distinguish between roles such as ‘supplier’ and ‘customer’? In what ways and for what reasons may the boundaries between these roles become blurred?

• What are the transactions in that market? What is exchanged, by whom, how, and why?

• What are conversations take place in that market? How do these conversations underpin the transactions? In what ways are they distinct from the ‘exchange’ transactions – in effect, separate transactions in their own right?

• What are the relationships in the market? What creates those relationships? How are those relationships maintained? What actions, inactions or events place those relationships at risk, or cause damage to those relationships? How, and why? And what can be done to mitigate those risks?

34

• What is the purpose of the market – its shared-purpose? How is this purpose conveyed to and shared by every player in that market? What mechanisms exist to keep everyone on-track to that purpose of the market? What happens if a player - whether by accident or intent – goes against that shared purpose?

• How do the relationships between players balance out across the enterprise? What happens when one player tries to take control of the enterprise for their own benefit alone, trying to force everyone else into a subservient relationship to them? How are those strains expressed in practice in the enterprise?

Vision, values and the enterprise • What are the boundaries of the extended-enterprise in which your organisation

operates? What vision and values define that shared-enterprise? How does your organisation connect with that vision and its values?

• Who are the various players in that extended-enterprise? What vision or reason links together all the players in this enterprise?

• In what ways do the chosen visions of each player differ from each other? In what ways are they the same? What are the common threads that link the players together, and keep them apart?

• What transactions take place in the market and enterprise? What conversations? What relationships? For what overall purpose? And how and why and to whom are each of these of value?

• What value-proposition does your organisation present to the shared-enterprise? What services underpin that value-proposition?

• For each service that delivers anything, who or what manages that service? Who or what coordinates that service with other services? Who or what ensures

35

compliance with enterprise vision and values? What links all of these subsidiary services together?

36

SERVICE VISION AND VALUES

Summary

hold conference

vision (desired ends)

(realised ends)real-world

(means)

“ideas worth spreading”example:TED conferences

service

The shared-enterprise is defined by its vision and values. Every service within the enterprise needs to align with the vision and values, and assist in making them real – and demonstrate that it does so, through meaningful metrics. A simple checklist – vision, role, mission, goal, outcomes – can help our stakeholders make sense of this in practice.

Details Vision, role, mission, goal, outcomes

The vision is the ultimate anchor for the entire enterprise – perhaps the one point on which everyone involved would agree. A functional vision for an enterprise is not centred around a single organisation, and, crucially, it’s not some crude piece of self-aggrandising puffery set out as a marketing-pitch – which is what is usually purported to be a ‘vision’. Instead, it’s a much simpler phrase or ‘mantra’ that

37

summarises that enterprise’s ‘reason to be’. Good examples of valid visions include the Open Group’s vision about supporting ‘boundaryless information flow‘, or the vision for the TED conferences, ‘ideas worth spreading‘. A vision is literally emotive: in a very real sense, it needs to be powerful enough to drive everyone involved out of bed in the morning, helping them to want to get to work for the enterprise. (This is also a key reason why “maximising returns for our shareholders” just doesn’t cut it as an enterprise vision…)

It’s perhaps important to emphasise here that this vision is not imposed on the organisation from outside by some unspecified ‘the enterprise’. In reality, the organisation decides which enterprise to ‘belong’ to. The organisation chooses a vision to work to, but when the choosing is done properly it will instead feel like the enterprise-vision has chosen it.

The vision is a statement of the core-requirement – the ‘desired ends’ – for all players in that overall enterprise. Everything else in the entire enterprise devolves from that: everything provides a service as a means that contributes towards realising those desired ends.

Service as a means to realise desired-ends

38

Another way to describe this, as mentioned in the last chapter, is in terms of vision, role, mission, goal and outcomes:

• the vision and associated values define the aims of the enterprise as shared by all its players – in essence, an aspiration or idea

• the organisation identifies its role within this enterprise, the part it chooses to play in achieving those desired-ends – a role which also indicates points of connection with other players who choose other parts or roles within the overall enterprise

• the organisation’s mission is the set of capabilities or services via which it will deliver its overall value-proposition that will contribute towards achieving the vision of the enterprise

• each activity within the organisation will typically contribute towards some bounded goal within the organisation’s mission and role

• every goal in the organisation needs an identifiable outcome the realised ends of the service– and that outcome needs metrics that link it back to the original vision of the enterprise, to indicate achievement in terms of those desired ends

The outcome’s metrics help to verify the effectiveness of the role, mission, goals and activities in relation to the overlighting vision.

39

Linking ends and means

Yet the anchor for the whole of this ‘stack’ is the enterprise vision – hence that is what we need to identify first.

Identifying the vision Despite much discussion about vision in business, unfortunately many if not most actual examples seem almost useless for any practical purpose. A vision that does work will usually consist of a very brief phrase – typically no more than four or five words – with a distinctive three-part content and structure:

• something that identifies for the content or focus for this enterprise • some kind of action on that content or focus • a qualifier that validates and bridges between content and action

These components may occur in any order, but all of them need to be present in a vision-descriptor. For example, take the vision for the TED conferences, “ideas

40

worth spreading”. It’s clear, succinct and emotive – and it conforms exactly to that structure above:

• ‘ideas’ [content] • ‘worth’ [qualifier] • ’spreading’ [action]

Note too that none of these items describe the organisation at such – but do describe the focus, the area of action, and the key value-metrics which define the meaning of ’success’. That’s what we need to look for at this stage. The content part of the descriptor should be a noun that identifies and summarises the ‘things’ of the enterprise as a whole. These will usually not be products or services as such – because that’s what the players in the enterprise deliver to each other in order to create value in the enterprise. Instead, it’s more about what those products or services act on, and are of interest to every player in the enterprise. The action part should be a verb, summarising the overall activity of the enterprise. If at all possible it should be explicit and distinct, rather than a generic such as ‘supporting’ or ‘making’ or ‘creating’ – though such generics can be useful to give something to work with whilst searching for a more distinctive vision. The qualifier part should be an adjective or suchlike that is both emotive and implies some value or valuation – for example, the adjective “worth” in the TED vision of “ideas worth spreading” would imply some means and value-criteria to identify which ideas are worth spreading, and which are not. To identify the vision, look around both within and outside the organisation for anything that engages or excites people in their work and in their relations with others in the shared-enterprise. And excitement or engagement is the key here – though note that it can often take somewhat strange forms.

41

A nice example seen on a large billboard beside a freeway in Melbourne, Australia. The poster shows a football game at night: all the spectators in the floodlit stadium are intent on the action that’s happening on the pitch, just out of shot from the billboard. All spectators except one, that is: a man in yellow rain-slickers, standing up, facing the other way to everyone else, gazing up at the huge floodlights. The caption? “We’re excited about electricity, even if you’re not.” The billboard was for an electricity-company, of course, but makes the point very well: you may not be interested in electricity right now, but when you are, we’re the kind of people you’d probably want to meet. Remember that enterprises are dynamic, not static: people in ‘customer’-type roles especially will wander into and out of a shared-enterprise according to their needs of the time. It’s up to those who are most committed to an enterprise to make it of interest to others to join in. This is where marketing often comes into the picture (and also often makes a complete hash of it, as we’ll see later…), but a better approach is to focus on vision as a way to draw people in when they need to connect, and also allow them to disconnect cleanly when their needs no longer align with that vision.

Expect to take several tries at this: our experience has been that for most business-folk there’s an almost automatic reflex to go for meaningless marketing ‘puffery’, and it takes quite a while to find a way past that habit.

The example vision-descriptor we’ll use for the descriptions of the Enterprise Canvas here – “making feet happy” – was suggested by one of my colleagues in Mexico. We had been working together on enterprise-scale issues for several banks in the region, and decided we needed a non-bank example to illustrate some of the broader issues. So we imagined a medium-sized shoe-manufacturer and retailer, Las Zapaterias de Mexico, or ZapaMex, currently selling only to the local market, but with intentions to expand out into Latin America over the next few years. We’ll see how this vision is used in practice as we explore deeper into the Enterprise Canvas. I’ll admit it’s far from a perfect vision-descriptor – for example, the verb ‘making’ is a bit generic and weak. But it is typical of the kind of vision that most people would get together in the early stages of this kind of work, and hence a useful example to work with here.

42

Values and principles The vision itself should suggest distinct values, either direct from the ‘qualifier’ part of the vision-descriptor, or by implication. The values that we need to identify here are those values that are needed to realise the desired-ends indicated by the vision, and hence values that we actually want and need in the organisation.

When we start to expand on these, though, we’ll note that there’s often a large difference between required values, espoused values, and actual – and we need to be clear which is which! Required values are the values we need to make the enterprise work. Espoused values are the values that the organisation claims that it holds to, and to which it expects to be held accountable. Actual values are the values that the organisation actually lives by – which may be very different even from the espoused-values, let alone the required-values. To identify actual values, explore the behaviours or phrases actually used within the organisation, or as indicated in social-media and the like. Stafford Beer’s somewhat cynical yet often painfully-accurate dictum POSIWID – “the purpose of the system is [expressed in] what it does” – can also be a useful guideline here. Note, though, that these actual-values will often vary at different levels or in different parts of the organisation, and differ again as seen from inside or outside.

To identify required values, assess what ‘effectiveness’ would look like in relation to the enterprise and its vision: for example, fairness, trust and financial probity would all be required in any functional enterprise.

For ZapaMex, the vision of “making feet happy” implies values such as comfort, support, satisfaction, ‘feeling good, looking good’ and so on. Which also means that we need metrics to monitor how well we’re performing relative to those values, too.

From values we move to principles, because the organisation’s principles describe how its values should be expressed in practice. In themselves, values are somewhat abstract; whereas principles are – or should be – concrete, actionable and verifiable. (Values on their own are just a ‘nice idea’: it’s only when they’re expressed as principles that they become meaningful in practice as values.)

43

Principles represent the core reasons and decisions of the organisation, pervading the values throughout every layer and function, downward into the fine detail of systems designs and individual actions. We typically document them in a four-part structure:

• name – a succinct summary of the principle itself • statement – an unambiguous description of the rule and its intent • rationale – the practical benefits from following the principle • implications – summary of probable costs and impacts both from following the

principle, and from not following it One obvious complication is that principles will often compete or conflict: transparency versus privacy, for example, or innovation versus the safety of ‘the known’. We’ll return to this later in the chapter on Service guidance (p.90); for now, just document any such clashes you can see, and move on.

Application (Use these questions to identify the vision, values, core metrics and other anchors for subsequent Enterprise Canvas models.)

Identifying the vision • What are the ‘things’ or context that are the main focus for everyone in the

enterprise? • What is the main activity on those ‘things’ or context that concerns everyone in

the enterprise? • What adjective best describes people’s engagement in those ‘things’ and activities

– the qualifier that provides the driving ‘why’ for the shared-enterprise?

44

• Linking the above answers together, what vision is common to all stakeholders in the enterprise? What single phrase describes the overall enterprise?

Vision, role, mission, goal, outcome • Given the vision above, what role or roles does the organisation play within the

enterprise, to contribute towards the vision? What roles does it not play – hence leaving open for other stakeholders? Who are these other stakeholders, and what roles do they play within the overall enterprise? How would you verify that each role – especially the organisation’s own chosen role or roles – does support the enterprise vision?

• What mission or missions – ongoing services and capabilities – would be needed to support each role undertaken by the organisation in that enterprise? What metrics would you need to confirm that each mission is ‘on purpose’ and effective in supporting the respective role?

• What short-, medium- and longer-term goals and objectives underpin each mission? What are the timescales and deliverables for each goal?

• By what means – what outcomes – would you verify that each goal is achievable, and has been achieved? How would you verify that each goal does support the respective mission in an appropriate and effective way?

Values and principles • What is value? What do you value? What is considered to be ‘value’ in your

organisation, or in other organisations that you know? • How do you describe value? How do you depict it? How do you model it, in your

own work, and in the enterprise?

45

• How is value created, changed, destroyed, shared? How does this differ from one type of value to another? How would you model these changes in value, and for what reasons?

• How do you measure value? In what ways are these metrics different for different forms of value? Are there any forms of value that you cannot measure? If so, why or how?

• What values devolve from the enterprise vision? What shared values are required from every player in the overall enterprise, in order for that enterprise to achieve success within the terms of its vision?

• What do these values imply for your organisation in terms of requirements for quality, in all its various forms? In what ways can you express these values in terms of principles to guide decision-making within your organisation and its relations with the broader enterprise?

• What individual and collective values – either implicit or explicit – are required to support the organisation’s role within the enterprise?

• What values does the organisation espouse, both in its relationships with others and its relationships within and to itself? What actual values does the organisation express in its actions and relations with others and within itself? If there are misalignments between required, espoused and actual values, what impacts do these differences have on the effectiveness of the shared enterprise and the organisation? What could you do to correct these misalignments?

• What principles devolve from and between each of these values? How are – or should – these principles be expressed in practice in the organisation and the broader enterprise?

• What to you is effectiveness? How would this differ from efficiency alone – the usual focus of most business-change efforts? How does effectiveness link to

46

value? What impact does effectiveness have on value? Why does effectiveness matter, and to whom?

47

SERVICE LAYERS

Summary

A service may be usefully described in terms of a set of distinct layers of abstraction, extending from the idealised vision down to the concrete reality of what is actually achieved. As we move downward through the layers of abstraction from overall intent to real-world implementation, the same nominal service will be described in different ways – usually as different levels of detail.

48

Details Four types of layering

One of the core concepts in the Enterprise is the notion of layering. We need to be clear, though, as to what type of layering we mean, and what we don’t, because there are at least four different types of layers that are in common use in business:

• layers of reporting-relationships (management-hierarchy) • layers of decomposition (services composed of sub-services, units composed of

sub-units, etc) • layers of separation (often as ‘distance-from-self’) • layers of abstraction (from abstract to concrete)

On reporting-relationships, management-hierarchies themselves are usually irrelevant for Enterprise Canvas, because they can change almost at random. However, management information-flows are significant, and are described later: see ‘Information-flow for management’ in Service flows (p.85). Service-decomposition is also important for Enterprise Canvas, and is likewise described later: see Service decomposition (p.112). Layers of separation only make sense where a single arbitrarily-selected start-point is chosen as ‘the centre’. This is typified by the ‘stack’ of technology, data/applications and ‘the business’ that is commonly used in IT-architectures. But in practice such layering can be misleading, because in a true enterprise-scope architecture everywhere and nowhere is ‘the centre’. In general, we should not use this kind of layering with Enterprise Canvas.

49

Layers of abstraction, however, are fundamental to the Enterprise Canvas, because each service can be described in different ways dependent on the current layer of abstraction. That core concern is the focus of this chapter.

Layers of abstraction For our purposes, we use seven distinct layers of abstraction. The numbering starts at ‘0’ (zero) rather than ‘1’, for compatibility with the commonly-used Zachman framework.

Layers of abstraction for Enterprise Canvas

These layers are distinct from each other because they each add something more at each transition ‘downward’ in the stack. Row-0 is essentially timeless. Rows 1-5 – as in Zachman – describe views of what we intend to happen, moving from big-picture to fine-detail. Row-6 is about the past, a record of what has happened, which we can use to guide us to keep on track to the desired-ends of the vision.

50

In general, each Enterprise Canvas model applies at one layer only. The only routine exception is where we explicitly show how one layer devolves or translates into another. Row-0: Enterprise. The topmost layer consists of just one item – the enterprise as a whole, as defined by its vision and values.

Row-0 Enterprise: vision and values

We’ve already explored themes for row-0 in the chapter Service vision and values (p.36). Row-1: Scope. In this layer every entity is just a member of a list, without relationships or attributes as such. One commonly-used way to populate these lists is by using the interrogatives Who, What, How, Where, When and Why in relation to the enterprise. For example, the ‘Who’ list would identify relevant players (roles) in the enterprise, including the organisation itself.

Row-1 Scope: lists of entities

We explore these themes in more detail in chapter Service actors and other entities (p.57).

51

Row-2: Business-services. At this layer we add relationships between the roles and other items – in other words, we start to add the horizontal value-network to the vertical dimension of shared-value, to identify the services presented by each player or other entity. These relationships are determined in part by the respective value-propositions offered by and to each of the players. We explore these themes in more depth in chapter Service roles and relationships (p.63).

Row-2 Business-services: roles and relationships

Row-3: Service-content (also known as System-model or Logical model). In this layer we start to include more details of attributes alongside the relationships, describing the internals of each high-level service and the flows between them. These are always abstract and generic: they define one or more classes of possible implementations, but do not specify any particular technology or method. This is the first layer in which the Enterprise Canvas will describe the internal structure of each service.

52

Row-3 Service-content: abstract structures and flows

We explore specific aspects of these themes within each of the subsequent chapters, from Service structure (p.69) onward to Services as systems (p.147). Row-4: Service-design (also known as Physical model). In this layer we provide detailed specifications for technologies, processes, interfaces, flows, protocols, skillsets and the like, translating the abstract system-models into requirements and project-plans for detailed implementation. On the surface, the model looks much the same as for the row-3 Service-content model: the difference is that it describes an actual intended solution rather than a whole class of possible implementations.

Row-4 Service-design: specifications for implementation

53

We explore these themes here in each of the subsequent chapters, much as for row-3. The main difference is that we would need to go into more specific implementation-detail, and would be likely to do much more service-decomposition to describe that detail. Row-5: Service-deployment (also known as Operations-model or Action plan). This layer specifies exact details of the service- configuration to be used and/or enacted on a specific day at a specific location for a specific purpose with specific staff, and so on. For example, where the row-4 design-model might specify a database-server, here we need to know the exact identifiers, types, configurations, physical locations and virtual addresses of the production servers, fallback servers, development servers, test servers, and all the related support-equipment and switchgear.

$

Row-5 Service-deployment: run-time action-plan

Again, we could describe it with the Enterprise Canvas in the same way as for row-3 and row-4, but there would be a lot more detail embedded in the model. For architecture, the main use of this level of detail is to provide an understanding of qualitative concerns such as availability, adaptability, variance in loads, and so on. Row-6: Action record. Unlike the others, this layer is not a model of an intended future, but a record of actions in the past.

54

Row-6 Action-record: detailed metrics

These metrics would describe the same level of detail as the row-5 action-plan, and in principle the core of it should be exactly the same as row-5. In practice, though, it’s rare that it is the same: rostered staff are absent for any number of reasons, a server breaks down, people get switched around onto different machines, half our customers are at home watching the football match, a traffic-hold-up forces a change of the delivery-schedule – all manner of deviations from the original plan.

Action-record metrics close the loop

55

Although there’s no chance of changing anything – because it’s all in the past – these records are extremely important to process-designers, to organisational-learning specialists and many others who do extensive system-design (row-3 and row-4) in order to enhance effectiveness at the operational level (row-5). Whenever we do any work with the Enterprise Canvas, at any layer, we should always aim to identify row-5/row-6 metrics that could help us to keep on track to the initial row-0 enterprise vision, values and principles.

Summary • Row-0 Enterprise: vision, values and principles only • Row-1 Scope: adds lists of actors and other items in scope in the enterprise • Row-2 Business-services: adds relationships between actors and other items,

describing roles and responsibilities • Row-3 Service-content: specifies generic (implementation-independent) content

within services and in flows between services • Row-4 Service-design: identifies implementation-specific content (technology,

assets, locations, skill-sets etc) within and between services • Row-5 Service-deployment: identifies specific configuration-details for run-time

operation • Row-6 Action-record: identifies what has actually happened

Strategy will focus primarily on rows 0-2, with some emphasis on row-3. Tactics will focus primarily on rows 3-4, with some emphasis on row-5. Operations will focus primarily on rows 5-6.

56

Application (Use the following questions to identify which layer an Enterprise Canvas model will illustrate.)

• Does it describe anything other than vision, values or principles? (If so, must be row-1 or below.)

• Is it simply a list of items, without relationships between those items? (If so, will be row-1, or row-3 if internal details and attributes of those items are also described.)

• Does it describe relationships between items? (If so, must be row-2 or below.) • Does it describe detailed attributes of items, or flows between items? (If so, must

be row-3 or below.) • Does it describe a specific implementation, technology, vendor, business-process

or the like? (If so, must be row-4 or below.) • Does it specify explicit deployment-details – a complete set of assets, functions,

locations, capabilities, trigger-events and business-rules? (If so, must be row-5 or below.)

• Does it describe a record of something that has already happened in the past? (If so, must be row-6.)

57

SERVICE ACTORS AND OTHER ENTITIES

Summary

The first requirement, as we start to move towards realising the vision, is to list all the key actors, assets, and other entities that would be required to make the vision happen in the real world. At this level, these are just lists of items, though the list will include somewhere the organisation or service that will be our main focus of attention.

Details One of the key functions of the Enterprise Canvas is to get us to think wider, understand the ecosystem in which our organisation operates. Amongst other advantages, this will help us to identify ‘unexpected’ opportunities and risks. To do this, we need to go right back to the roots, beyond the ‘known’ of our organisation. Given that we’ve described the core vision and values shared-enterprise in row-0, what we aim to do here in row-1 is to identify all of the key items that are needed to make this enterprise happen. At this level, we always look at the whole shared-enterprise – not solely the view as seen from our own organisation’s perspective. Later, in row-2 and especially in row-3 and below, we’ll identify the parts that we choose to do or not-do, as our own

58

‘business-model’; but for now we need the complete picture of the shared-enterprise, so that we can also identify the roles and activities that others will play. We do this here by circling around six simple interrogatives: who, what, how, where, when and why. The answers we receive for one of those queries will often trigger off a review of one of the others, and so on, round and round, until we have every key item or item-type for the enterprise somewhere in our lists. We do need to remember to include not just our basic supply-chain, but extend outward to the industry and market, all the way out to the entirety of the shared-enterprise, as in the Market Model – see ‘Service and market’ in chapter Service context and market (p.23).

We do need to keep some sense of focus here, because in many cases the answers could run almost to infinity. The idea is to gather ‘just enough, just in time’ to guide subsequent development and enquiry: aim to gather perhaps ten to twenty items for each of the interrogatives, but probably not much more than that.

For simplicity it’s best to focus on item-types rather than specific items at this stage: we’ll assign names and other more specific details later, in row-2 and below.

Every item in each list links back to enterprise vision

The ‘Who?’ question asks us who is likely to be involved, is likely to feel engaged in and motivated by the vision and its values. For ZapaMex’s vision of “making feet happy”, this would of course include ZapaMex itself, but it would also include

59

anyone who’s interested in footwear for any reason: the general buying public, fashionistas, sports facilities and trainers, schools, general health and footcare specialists, industrial health and safety, and so on. It includes people on the supply-side: manufacturers of materials, or, further back, the farmers and others who supply them. There are marketers, advertisers, event-organisers. On the distribution side, there would be retailers, wholesalers, warehouses, logistics providers. There’s local or national government, the communities, employees’ families and others. And there are standards-bodies, testers, market-analysts and other industry-level players.

Note that we don’t use role-labels such as ‘supplier’ or ‘customer’ or ‘competitor’ here: we only describe the type of player or ‘actor’ relative to the enterprise as a whole, not relative to ourselves as an organisation. We’ll come back to that role-analysis later, in row-2: see Service roles and relationships (p.63).

The ‘What?’ question asks for a list of assets or resources that would be needed within the shared-enterprise. (For this purpose there’s no need to distinguish between assets and resources; the distinction we’ll use later is that assets are resources for which the organisation is directly responsible.) We need here to include not just physical assets, but also information and other virtual assets, relational assets that provide links to real people, and aspirational assets such as brands. For ZapaMex’s enterprise, this includes complete shoes, shoe-components and shoe-making equipment and facilities; it includes buildings and physical and virtual (web) distribution-channels; it includes customer-records and customer-relations; it includes brands, both for each organisation and for the industry as a whole. The ‘How?’ question asks for functions, processes and capabilities that would be needed to create value within the enterprise. (Often these may be bundled rather carelessly together with the ‘Who?’ items, but it’s best to describe them separately

60

because that often highlights other opportunities and risks later on in the model-development process.) For ZapaMex, this would include shoe-design, shoe-making, shoe-retail, assessment of footwear needs, marketing, materials manufacture, materials-acquisition, logistics, testing and so on.

Note that for simplicity we bundle function, process and capability together here as if they’re the same. They’re not, but the distinctions don’t really matter at this level. They do matter when we go further down into the detail, but we can sort that out later: see Service content (p.116).

The ‘Where?’ question asks about locations of all types – physical, virtual or otherwise. For ZapaMex’s enterprise, the geographical locations are actually worldwide, even though ZapaMex itself only operates in Mexico. Note that there’s also often a cross-over here between Where and What – or rather, that many What items, such as warehouses and retail-outlets, will each have a physical location as well. Include virtual locations such as phones, emails and web-sites; include relational locations such as supplier or market networks; and note too that brands often have a kind of ‘location’ relative to each other as well. The ‘When?’ question asks about events that are important in and to the shared-enterprise. For ZapaMex’s enterprise these would include physical events, such as materials arriving at a factory, or a parcel entering or leaving logistics. It would include virtual or information-related events, such as the accounting-cycle or the tax-cycle. It would include composite events such as the physical and relational event of a customer-prospect walking into a store. And it might also include aspirational events such as PR impacts on a brand. Plenty of examples to choose from there, anyway. The ‘Why?’ question is the one that is most strongly linked to the enterprise-vision – because the vision is the core ‘why’ for the entire enterprise – but also asks about other types of decisions that are required for the proper functioning of the shared-

61

enterprise. For ZapaMex, these would include decisions to launch or close a product; to expand or contract market positioning, in any sense of the term; or to place orders for materials or to purchase products. Each question cross-links with other questions: Why leads to How leads to When, which leads back to Why; What may leads to How, and onward to Who, which again leads us to How. Anywhere may take us anywhere else, and often does – hence this kind of exploration is often iterative, each question triggering off a review of the content previously provided via another question. Note also that:

• the What will link strongly to the ‘things’ or context of the vision descriptor (i.e. ‘feet’, for ZapaMex’s vision)

• the Why will link strongly to the qualifier’ of the vision-descriptor (‘happy’, for ZapaMex)

• the ‘How’ will link strongly to the action-verb of the vision-descriptor (‘making’, for ZapaMex)

Once again, remember that the end-result of this enquiry is a set of lists, without any explicit relationships between them; and it covers the whole of the enterprise, not solely the organisation or service that is the main focus of our interest.

Application (Use these questions to populate the lists of your row-1 Enterprise Canvas. Use this in a brainstorming fashion, bouncing between questions and revisiting them in whatever way feels appropriate, but do ensure that every question is addressed at least once.)

62

• Who are the people and organisations needed to make the vision come to life in the real world? What links each one of these actors to the vision and values of the shared-enterprise?

• What types of assets and resources are needed to make the vision a reality? What links each of these items to the vision and values of the shared-enterprise?

• What functions, processes and capabilities are needed to make the vision a reality? What links each of these items to the vision and values of the shared-enterprise?

• In what locations – physical, virtual or otherwise – will the work of the shared-enterprise take place? What types of locations will be needed to make the vision a reality? What links each of these locations to the vision and values of the shared-enterprise?

• What events would drive the transactions and interactions of the various players and processes in the shared-enterprise? What events will be needed to make the vision a reality? What links each of these events to the vision and values of the shared-enterprise?

• What decisions will guide the choices and interactions in the shared-enterprise? What decisions will be needed to make the vision a reality? What links each of these decisions to the vision and values of the enterprise?

63

SERVICE ROLES AND RELATIONSHIPS

Summary

Having established the key items for the shared-enterprise, we next need to identify roles and relationships between them. We would usually do this by placing our own organisation or service as the centre of attention, but we can in fact start anywhere – such as with a competitor as the centre, for competitor-analysis. Note too that the flows between entities often determine the respective relationships, rather than the other way round: often we’re best to start by thinking about how value moves around the enterprise, rather than about the individual nodes in the value-network.

Details In the previous row-1 brainstorming exercise we identified all the key items needed to make the vision of the enterprise a reality – who, what, how, where, when, why. Here in row-2 we now need to link all of those items together into a complete

64

picture of the enterprise – and establish our organisation’s proper place within that picture. For this exercise, we carry through the lists we created in row-1, ready to use as our source-material for a set of cross-maps of roles, responsibilities and relationships. (For a whiteboard session, we might set out the lists as sticky-notes, using a different colour for each list.) We then pick one list to start with – typically ‘Who’ – and start to build a map of the working enterprise from there. Each ‘Who’ in effect presents one or more services to the overall enterprise: so what are those services? Who consumes them? Who provides to them? What flows between those services in each interaction? If we start from ‘Who’, this review will automatically raise questions about what is used in each service and transferred in each interaction: like what is done in each service, where it takes place, the trigger-events for each interaction, and the decisions needed in each case to keep the overall flow of value around the enterprise on track to the overall vision. We can then do the same kind of map by starting with ‘What’, or ‘How’, or any of the other lists: the aim is to build up a picture of the overall flow of value around the enterprise, and who or what is responsible for each activity and decision in each case. So far all of that has been relative to the enterprise – not to our own organisation. To make sense of where we fit, we do another map in which we place our own organisation at the centre, assigning ourselves one or more roles from the ‘Who’ list. We then select items from each of the other lists that represent what our own organisation does – or, for a ‘to-be’ map, what our organisation would choose to do – to play its part in this overall enterprise. Every other item in the lists is something that our organisation would choose to not-do, yet needs to exist for the overall

65

enterprise to work well. In other words, we need it to exist, even if we ourselves don’t do it or use it. Which, in turn, defines our relationships with all of those aspects of the enterprise that we (or our organisation) will choose not to do.

Roles and relationships relative to the organisation

Roles relative to our own organisation will fall out automatically from the respective relationships and mutual responsibilities. For example, three classic supply-chain roles:

• anyone who provides a service, or has responsibility for an item, that we need in playing our part in the enterprise has a potential supplier relationship with us

• anyone who, for their part in the enterprise, has need of a service or item for which we have responsibility, has a potential customer relationship with us

• anyone whose part in the enterprise suggests that they need a relationship with any potential ‘customer’ or potential ‘supplier’ of ours may have a potential competitor and/or partner relationship with us

Note that other players may well have multiple roles relative to us in terms of the whole enterprise: the same organisation could well be supplier, customer, competitor and partner, all in distinct and separate relationships relative to us.

66

We need to keep developing this map until all of the items that we identified in the row-1 exercise have been referenced at least once somewhere in the model. The reason for this is that we’ve already established that each of these items is needed for the effectiveness of the overall enterprise: so if there’s no-one doing that type of work, or we have no direct or indirect relationship to it, then it represents either a risk to us or to the whole enterprise. In either case, the apparent risk may well represent a worthwhile business-opportunity for someone – and it might well be us. Useful indeed. Remember that this is really only an idealised overview at this stage: the real-world detail will come later, in row-3 and below. We need to develop a good sense of the overall flows – the nodes and links of the value-network that enacts the enterprise – but do keep the emphasis here on the abstract big-picture view, and don’t allow it to get dragged down into the depths of the detail.

Application (Use the following questions to populate your row-2 Enterprise Canvas models.)

• Starting from ‘Who’, who are the players in this enterprise? What roles do they each take within the enterprise? What relationships and transactions are implied by these different roles within the enterprise? What assets and resources do they need to carry out these roles? Which assets and resources would they be responsible for? To which functions, processes and capabilities would they apply? Where would they do this role? What events trigger activities and transactions for which these roles are responsible? What decisions do they need to take on behalf of the extended-enterprise? And which real-world individuals or organisations would carry out these roles?

67

• Starting from ‘What’, which assets and resources are used in this enterprise? What are their relationships to each other? In which transactions do these assets and resources play a part? Who is responsible for each of these assets and resources? What functions, process and capabilities are used to create or change to these assets and resources, and add value within the enterprise? Where are these assets and resources located, at each point in their lifecycle? What events trigger changes relative to these assets and resources? What decisions apply in each case?

• Starting from ‘How’, what functions, processes and capabilities apply in this enterprise? What are their relationships to each other? In which transactions and interactions do they play a part? Who is responsible for each of these functions, processes and capabilities? On what assets and resources do they apply? In what locations are these functions, processes and capabilities applied and used? What events trigger the use these functions, processes and capabilities? What decisions control or guide their use?

• Starting from ‘Where’, what locations apply for this enterprise? What are their relationships to each other? In which transactions and interactions do they play a part? Which roles apply at each of these locations? Who is responsible for each of these locations? What assets and resources are found at or acted upon at these locations? What functions, processes and capabilities are used at these locations? And what decisions apply to or at each location?

• Starting from ‘When’, what events occur within this enterprise? What relationships exist between these events? Which transactions and interactions do they trigger, or are triggered by? To which roles do each of these events apply? Who is responsible for each event? What assets and resources are affected by each event? What functions, processes and capabilities are required by each

68

event? At what locations do each of these events take place, and which locations do they connect? What decisions trigger or guide each of these events?

• Starting from ‘Why’, what decisions control or guide this enterprise? What are their relationships to each other? In what transactions and interactions would each of these decisions be involved? To which roles would each of these decisions apply, and who would be responsible for each? To what assets and resources would each decision apply? To which or in which functions, processes and capabilities? In which functions, processes and capabilities would each decision be enacted? Where would these decisions take place? Which events would trigger these decisions, or be triggered by them?

• Starting from your own organisation as ‘Us’, which role or roles within the enterprise would you choose? Why? Which assets and resources would you use in this role? With which functions, processes and capabilities? At what locations? In response to or creating which events? And enacting which decisions?

• What aspects of the enterprise – who, what, how, where, when, why – would you not do, and why? What relationships does each of these decisions imply with other players in the enterprise? What transactions and interactions does each of these relationships imply?

• Which items – if anything – does no-one appear to be doing or using within the enterprise? What risks or opportunities does this imply for the enterprise as a whole, and for your part within it?

69

SERVICE STRUCTURE

Summary

As we move closer towards real-world implementation, we need to elicit more detail about the enterprise and its services, via our conversations with the stakeholders. For the services themselves, we do this by partitioning the service into a simple standardised three-by-three matrix, with each cell representing a distinct and discrete set of activities and viewpoints for the service as a whole.

Details In row-2 we established a big-picture overview of the enterprise as a whole, and of our organisation’s role and place within it. That overview provides an important anchor for strategy, but also need to start to link that strategy down towards the real world. To do this, we turn to the Enterprise Canvas proper – a systematic means to model the services of the enterprise. We’ll divide this into five parts:

• the overall structure of services, in a generic sense – described in this chapter

70

• the flows between services, that create the value-web of the enterprise – see chapter Service flows (p.79)

• the various related services that help to link this service with others, and keep it on track to the aims of the overall enterprise – see chapter Service guidance (p.90)

• relationships with the service’s investors and beneficiaries, in various forms of value – see chapter Service investors and beneficiaries (p.102)

• the fine-detail of the structure and content of each of these services and flows – see chapter Service content (p.116)

We’ll also explore how to expand each of these descriptions out into detailed real-world services – see chapter Service decomposition (p.112). For here, though, we’ll summarise a structure that can be applied to any type of service. To start on this, we go back to the notion that a service is a means via which the desired-ends of the vision can be achieved in the real world. The service does this in part by linking and adding to the value-flow as it moves around the overall shared-enterprise.

Service at intersection of vision and value-flow

71

Some while back, we saw that each service provides three distinct views on value – value-proposition, value-creation and value-governance – and that these respectively relate to what happens before, during and after the main transactions of ‘exchangeable value’. That was about the internal operation of the service itself; but we can also generalise that three-way view to include the relations with services on the ‘incoming’ side of the supply-chain – from ‘suppliers’ or service-providers – and on the ‘outgoing’ side – from ‘customers’ or service-consumers. 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:

• ‘future’-oriented relationships are essentially peer-to-peer, and flow both ways (bidirectional).

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

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

This gives us a three-by-three nine-cell matrix that summarises clusters of ‘child’-services within each service, all of which are necessary in some form for the proper operation of that service.

72

Supplier-side (inbound):

• Supplier-Relations (supplier-side/future): build and maintain relationships with potential and/or actual ’supplier’ service-provider entities, about things that may or do need to happen in the future, and to keep on track to the vision

• Supplier-Channels (supplier-side/present): receive goods and/or services from ’supplier’ entities

• Value-Outlay (supplier-side/past): provide balance or compensation to ’supplier’ entities (e.g. pay for goods)

Self (this service):

• Value-Proposition (self/future): identify what this entity will do and deliver, aligned to the overall enterprise purpose and values

• Value-Creation (self/present): take all actions necessary to create and deliver the goods and/or services specified in the value-proposition

• Value-Governance (self/past): ensure the appropriate functioning of the overall entity, balancing past, present and future

Customer-side (outbound):

• Customer-Relations (customer-side/future): build and maintain relationships with potential and/or actual ‘customer’ service-consumer entities, mainly about what may or should happen in the future, and to communicate the Value-Proposition in relation to the enterprise-vision

• Customer-Channels (customer-side/present): deliver goods and/or services to ‘customer’ entities

• Value-Return (customer-side/past): receive balance or compensation from ‘customer’ entities (e.g. payment for goods)

73

A service serves – and in every case, what it’s really serving is the vision of the enterprise, via the mission that underpins its role in the enterprise. This nine-cell structure gives a first glance at how it actually delivers its service, in relationship with other services.

supplierrelations

value-proposition

supplierchannels

value-creation

customerchannels

customerrelations

value-outlay

value-governance

value-return

thisinbound outbound

future / before

present / during

past / after

before / future

during / present

after / past

Nine-cell service-structure

To guide consistency, the cells are assigned those generic labels such as Supplier-Relations, though in practice we would identify other real-world services that deliver the same kind of function. To use our example of ZapaMex, it has a simple manufacturing setup: materials and components come in through the warehouse, are made into shoes on the production-line, and sent out again as end-products via the warehouse. That’s the basic supply-chain: Supplier-Channels, Value-Creation and Customer-Channels.

Although in that example the inbound and outbound channels went through the same warehouse, the channels have different functions, and it’s extremely important to keep them apart even if they share the same location. One of my clients – an engineering research establishment – found this out the hard way. Everything came in and out through the one warehouse; and their method for deciding which way anything was going relied on a risk-prone mix of paperwork and guesswork. Eventually, as one might expect, the system failed spectacularly. A truck-driver came by during a lunch-break with a large aircraft-part

74

for testing. No-one was around, so he dumped it in the middle of the warehouse bay. One of the labourers came back from his meal, saw the seemingly used-looking part lying on the floor, assumed that it was scrap, and dumped it in the trash-metal bin, which was duly picked up a short while later. By the time the researcher called by to check whether his irreplaceable quarter-million-dollar aircraft-part had arrived, it was long gone – and despite many frantic days of searching at every scrap-merchant in the city, and even every rubbish-tip, the part was never found. After that fiasco, the warehouse was provided with clearly-marked ‘In’ and ‘Out’ sections on the floor…

Yet there are also other parts of that organisation – often regarded as ‘cost-centres’ rather than ‘profit-centres’ – that support the whole supply-chain process. Some deal with procurement and the like – in other words, Supplier-Relations. There’s marketing and product-development, which form part of the Value-Proposition. Sales and customer-service provide Customer-Relations. On the return-channel, there are accounts-receivable – Value-Return – and accounts-payable – Value-Outlay. Line-management and the like deal with the budgeting for the operation itself and also keep everything on track – otherwise known as Value-Governance.

procurementproduct-

development + marketing

warehouse inbound

production-floor

warehouse outbound

sales + customer-

service

accounts-payable

line-management

accounts receivable

thisinbound outbound

before

during

after

before

during

after

supplier customer

Simplified example: ZapaMex shoe-manufacturing

Remember that this structure will apply to any service. In row-3, it’s likely that the first service or ‘Self’ that we’ll work with will be the organisation as a whole, or perhaps some specific department or business-unit within the organisation. But as

75

we start to look in more detail – and especially as we work downward into row-4 and row-5 – we’ll use this same structure to explore the services that make up the services that make up the more visible ‘business-services’ that we see as services at the larger scale. In that sense, every service is the same – even though every service is also different from any other. This structure gives us a consistent frame with which to compare every type of service at every level of decomposition. We can also think of this as a kind of functional-decomposition: 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. And we can also describe each entity in terms of a spectrum between most-abstract (the enterprise as a whole) to most-concrete (the detailed-past). We design and implement a service by moving ‘down’ the layers; we redesign and rethink by moving ‘up’. As we move ‘down’ towards the real-world, we’ll usually need to add more and more detail – but in essence it’s still the same overall service, or rather a more specific implementation of that service. We’ll explore this in more depth later, in the chapter on Service content (p.116).

Application (Use these questions to populate the Enterprise Canvas model for a single service. In row-3, ensure that the answers are independent of any implementation; in row-4, and even more in row-5, specific implementation-detail should be acquired.)

• Who or what is responsible for the Value-Proposition of this service – developing and defining what it can offer to create in terms of the enterprise definition of ‘value’ and identifying the preparation needed to implement this in Value-Creation? How does this part of the service do its work? What resources

76

does it need to do this? In what locations does it do it? What events must it initiate or respond to? And what decisions will guide it in this work?

• What real-world services or business-functions implement the Value-Proposition work of this overall service?

• Who or what is responsible for Value-Creation in this service – creating and adding value to the overall value-web of the shared-enterprise? How does this part of the service do its work? What resources does it need to do this? In what locations does it do it? What events must it initiate or respond to? And what decisions will guide it in this work?

• What real-world services or business-functions implement the Value-Creation work of this overall service?

• Who or what is responsible for Value-Governance in this service – ensuring that everything is kept on track to the service’s role, mission, goals and outcomes? How does this part of the service do its work? What resources does it need to do this? In what locations does it do it? What events must it initiate or respond to? And what decisions will guide it in this work?

• What real-world services or business-functions implement the Value-Governance work of this overall service?

• Who or what is responsible for Supplier-Relations in this service – ensuring that everything required for ‘inbound’ transactions and interactions is properly set up? How does this part of the service do its work? What resources does it need to do this? In what locations does it do it? What events must it initiate or respond to? And what decisions will guide it in this work?

• What real-world services or business-functions implement the Supplier-Relations work of this overall service?

77

• Who or what is responsible for the Supplier-Channels of this service – dealing with tangible (or sometimes intangible) inbound products and services required by this service for its operation? How does this part of the service do its work? What resources does it need to do this? In what locations does it do it? What events must it initiate or respond to? And what decisions will guide it in this work?

• What real-world services or business-functions implement the Supplier-Channels work of this overall service?

• Who or what is responsible for Value-Outlay in this service – returning the required value to the service’s suppliers, and ensuring satisfaction in the terms of the enterprise? How does this part of the service do its work? What resources does it need to do this? In what locations does it do it? What events must it initiate or respond to? And what decisions will guide it in this work?

• What real-world services or business-functions implement the Value-Outlay work of this overall service?

• Who or what is responsible for Customer-Relations in this service – ensuring that everything required for ‘outbound’ transactions and interactions is properly set up? How does this part of the service do its work? What resources does it need to do this? In what locations does it do it? What events must it initiate or respond to? And what decisions will guide it in this work?

• What real-world services or business-functions implement the Customer-Relations work of this overall service?

• Who or what is responsible for the Customer-Channels of this service – dealing with outbound products and services being delivered by this service? How does this part of the service do its work? What resources does it need to do this? In

78

what locations does it do it? What events must it initiate or respond to? And what decisions will guide it in this work?

• What real-world services or business-functions implement the Customer-Channels work of this overall service?

• Who or what is responsible for Value-Return in this service – obtaining the required returned-value from the service’s customers, and ensuring satisfaction in the terms of the enterprise? How does this part of the service do its work? What resources does it need to do this? In what locations does it do it? What events must it initiate or respond to? And what decisions will guide it in this work?

• What real-world services or business-functions implement the Value-Return work of this overall service?

• What real-world services or business-functions appear to bridge two or more cells of the Enterprise Canvas? What does this show you in terms of the real-life partitioning of the work? What risks – if any – does this specific partitioning entail?

79

SERVICE FLOWS

Summary

We apply the same kind of review to the flows that make up the relationships between services, to establish what needs to pass to and fro with each provider or client, and in what order – before, during and after the main transactions in each case. Here we may also explore the information and other assets that need to pass up and down the service-management hierarchy, with resources dispersing downward and performance-records aggregating upward through the tree of services.

Details To understand the value-web that is the shared-enterprise, we need to pay as much attention to the value-flows between services as to the services themselves.

80

Every cell in the Enterprise Canvas has its own distinct flows, which we’ll explore in four parts:

• main transaction-flows with other services – see this chapter • information-flows for management – see later in this chapter • guidance flows – see Service guidance (p.90) • investor-management flows – see Service investors and beneficiaries (p.102)

Methods to identify the detailed content for each of these flows are described in chapter Service content (p.116).

Main transaction-flows These flows form the most visible transactions and interactions of the service. It’s useful to separate these into the ‘before’, ‘during’ and ‘after’ phases of transaction, because they’re often handled by different groups of people or different sub-services within the overall service. There are also some important differences in the emphasis of each flow:

• ‘before’ flows link primarily with supplier/customer relations, and must always be regarded as bidirectional

• ‘during’ flows link primarily with supplier/customer channels; whilst there are always some bidirectional components, the main flow is along the supply-chain (i.e. left to right in the EC diagram)

• ‘after’ flows link primarily with value-outlay/-return; whilst there are always some bidirectional components, the main flow is opposite to the supply-chain (i.e. right to left in the EC diagram) – hence ‘return-channel’

81

Flows: pre-transaction, transaction, post-transaction

We also need to view these flows in terms of the market model and market-cycle – see ’Service and market’ (p.23). A transaction takes place within the context of a market, which itself takes place within the context of a shared-enterprise. The market sets the rules for transactions; the shared-enterprise provides the reasons and purpose for transactions. Before the service can enact any transaction, it needs to establish that it’s in the right market, following that market’s rules. To do that, it needs to engage in conversation with a potential supplier or customer. But before it can do that, it needs to create relationship with that prospect, to gain sufficient respect to bring them into the market; and to do that, it needs first to establish reputation and trust that the service shares the same overall aspirations – in other words, is in the same shared-enterprise. Hence there are many often-subtle interactions that need to take place before there’s any chance of a profitable transaction.

It should be self-evident that this applies at the whole-organisation scale, but it also applies right down at the detail-level too. A cloud-based web-service must likewise establish ‘conversation’ with a potential transactor, to identify the appropriate interface-protocol and the like; and where financial transactions are involved, must also establish trust that appropriate payments will be made.

82

Moving outward a level or two, firewalls, public-key encryption and the like are used to establish boundaries of trust. And further out, there will be a real person somewhere who makes the design-decisions that permit the web-services to establish their automated versions of mutual respect and trust. These interactions are not just ‘overhead’, because without them the transaction would not take place at all.

For the market and enterprise to succeed, the transactions and interactions also need to be profitable to all parties involved – not solely to the service in focus. (Note too that ‘profit’ will be defined by the nature of ‘value’ in the enterprise, and will usually be much broader than monetary terms alone.) Hence there will need to be closure at the end of each interaction or transaction, to ensure that that balance is achieved, and trust overall reaffirmed.

shared-enterpriseincludes community, government,

non-clients, anti-clients, others

marketincludes prospects, competitors, regulators, others

transaction

organisationsupplier customer

Reputation / trustRespect / relations

Attention / conversation

Transaction / exchange(profit / value-return)

(completion)

(reaffirmed trust) Enterprise and market-cycle

The Supplier-Channels and Customer-Channels manage the main transaction-flows of the supply-chain, and the Value-Return and Value-Outlay cells deal with the main returned-value coming back in the reverse direction along the same chain. But we need to be aware that there’s much more to the service’s flows than just those two pathways, and we also need to take care that the remainder of those flows are not dismissed as unnecessary ‘overhead’. The Supplier-Relations and Customer-Relations cells manage most of those ‘non-transaction’ flows – though in a sense

83

they’re actually transactions in their own right – yet also need to work with the other cells in order to ensure correct closure of the market-cycle. The Supplier-Relations and Customer-Relations cells establish connection with prospects by communicating the service’s Value-Proposition, which also links the service to its market (via the offer embedded in the value-proposition) and to the shared-enterprise (via vision and values). One of the key functions of these flows is to establish that prospective suppliers and customers also align to the vision and values of the shared-enterprise – because if they don’t, problems will almost certainly ensue further down the line.

For this purpose it’s often useful to have a published guide to business-principles, to which the service asserts that it will adhere and to which it expects all players – including itself – will be held accountable. As Shell put it in their ‘General Business Principles’, “We are judged by how we act – our reputation is upheld by how we live up to our core values”: an explicit published document about principles will help to provide clarity where it is often much-needed!

For our fictitious company ZapaMex, it would no doubt be easy for its production-team to think only in terms of the supply-chain transactions, and ignore everything else.

Production view of service-flows

Line-management, however, would insist that some attention is paid to monetary flows; and sales, marketing and procurement would all have their say as well – in other words, a market view.

84

Market view of service-flows

Yet ZapaMex needs to think beyond the basic transaction-oriented view of the market: it also needs to build trust and gain respect, within the market and beyond. A focus on values, for example, would guide any discussions with suppliers or customers about material-quality, because the values define what ‘quality’ is within the enterprise. In the same way, ZapaMex needs to ensure proper closure in terms of the market-cycle – otherwise its reputation will be at risk, and the market with it. When we assess the flows of a service in an Enterprise Canvas, we need to be clear which kind of scope we’re working with, and to ensure the completeness of the picture in each case.

85

Enterprise view of service-flows

Information-flow for management Another key type of flow we need to consider is the information-flows between services in a service-hierarchy. We can illustrate this with a (much-simplified) view of a service that creates a new account, shown in BPMN process-model notation.

Acc

ount

Man

agem

ent

Simplified account-creation service as BPMN process-diagram

86

These diagrams are common enough in solution-architectures, but in essence they only describe the basic transaction-flows and, if we’re lucky, some aspects of the flows in the return-channel. What these diagrams very rarely describe is the context of the service – especially its reporting-relationships up and down the service-hierarchy. To understand the service, we also need to know how it would be managed, what performance-criteria it should report, and where those reports should be sent.

Context for simplified account-creation service

The same would be true of this service’s links with its ‘child’-services ‘Verify Details’ and ‘Create Account Record’: they too would need to share requirements and performance-information with their ‘parent’ service. In Enterprise Canvas, we show these flows as a vertical double-arrow.

87

Management information-flows

In essence, these flows are usually the responsibility of the Value-Governance cell, so although the flows may move both ‘upward’ and ‘downward’ in the service hierarchy, often only the lower double-arrow is shown.

The space for the upper link may already be occupied anyway if links to guidance-services are also shown on the Enterprise Canvas – see Service guidance (p.90).

Methods for assessment of detailed content for all of these flows will be explored in more depth in chapter Service content (p.116).

Application (Use the following questions to guide discussion on the flows between services, and to populate the flows in each respective Enterprise Canvas.)

88

Main transaction-flows • What flows form the main transactions of the service? What is carried in these

flows, and in what sequence? What value is added to the overall transaction-flow by this service? From which supplier does each incoming flow derive? To which customer is each outgoing flow directed, and how? Who is responsible for each of these flows, both incoming and outgoing?

• What flows form the return-channel for each main transaction? What is carried in these flows, and in what sequence? From which customer does each incoming return-flow derive? To which supplier is each outgoing return-flow directed, and how? Who is responsible for each of these flows, both incoming and outgoing?

• What return-value is captured from the return-channel by this service for its own use? What governance is applied to this value-capture? What measures are taken to ensure that this capture is aligned with the values of the overall shared-enterprise?

• What methods are used to ensure and verify satisfaction of all parties in a supply-chain satisfaction?

• What flows are required before any transactions may take place, either with suppliers or with customers? What is carried in each of these flows, and in what sequence? What values are implied, expressed and referenced within each of these interactions? With which customer, supplier or other non-transaction stakeholder is each interaction linked, and by what means? Who is responsible for each of these flows?

• What methods are used to monitor and verify reputation and respect of the service within its market and its broader shared-enterprise? What methods are used to monitor the impact of each flow on such reputation and respect?

89

Information-flow for management • What flows form the ‘upward’ linkage between this service and any ‘parent’

service in the service-hierarchy or management-hierarchy? What is carried in these flows, and in what sequence? What methods are used to ensure that each flow is directed to the appropriate ‘parent’? What value is added to the organisation, the market and the overall enterprise by each flow? Who is responsible for each of these flows?

• What flows form the ‘downward’ linkage between this service and any ‘child’ service in the service-hierarchy or management-hierarchy? What is carried in these flows, and in what sequence? What methods are used to ensure that each flow is directed to the appropriate ‘child’? What value is added to the organisation, the market and the overall enterprise by each flow? Who is responsible for each of these flows?

90

SERVICE GUIDANCE

Summary

No service stands alone: it always exists within a broader context. Another distinct set of services and flows should exist somewhere to provide guidance to the service to link it into that broader context, helping to coordinate it with other services, providing direction on future change, and keeping it on track with enterprise values. We use this part of the Canvas to support our stakeholders in exploring the roles, relationships and requirements for these broader-scope guidance-services.

Details A structure for service-guidance

The information-flows for management (p.85) align with the old Taylorist machine-like model of the organisation, with a strong separation between management and

91

production or delivery. But in the metaphor of services as parts of a ‘living-entity’ – a ‘Viable System’, as Stafford Beer described it – we might identify four distinct categories of services:

• delivery-services– the ‘profit-centre’ services that contribute directly to the organisation’s ‘value-proposition’

• management-services that direct what the delivery-services should do – the classic vertically-oriented ‘management hierarchy’ and suchlike

• coordination-services that link horizontally across the silos to allow the supply-chains and the like to flow smoothly through the organisation

• validation-services that provide various forms of whole-of-system support – finance, HR, infrastructure – and that monitor and maintain quality throughout the organisation

Four categories of services

Ultimately, all services actually have the same structure, because all of them deliver a service: whatever way we might label or categorise them, in the end every service

92

is a ‘delivery-service’. In effect, all that changes in each case is the value-proposition, and the content that the service delivers: the relationships within and between services remain much the same. Yet the point still remains: who or what will manage the services-managers? Who or what will coordinate this service with other services? Who or what will ensure that quality is established and maintained? None of that is in that core nine-cell service-structure as such: and there’s a real need for some forms of guidance to make sure that these things do happen. Hence although in principle every service is a ‘delivery service’, there are those three other key categories of service: management-services, coordination-services, and the ‘pervasive’ services’ that help to create, maintain and pervade quality throughout every part of the enterprise. Collectively, we could describe these other services as ‘guidance services’. An alternate name for ‘management-services’ is direction, because their role is actually quite a bit broader than simple management of a business-unit or service. And another, perhaps more business-friendly name for ‘pervasive-services’ would be validation, because that’s what they do – they ensure that everything holds to the values of the chosen shared-enterprise. The actual relationships of these guidance-services is that they are almost orthogonal to each other.

93

Guidance-services and delivery-service

Another and perhaps simpler way to show the guidance-services, in relation to the service to be guided, would be to link them to the frame of the overall ‘delivery-service’ – shown here as a dotted-line around the standard nine-cell Canvas.

Guidance-services and nine-cell Canvas

94

Note that each of these will attach at the respective layer or ‘row’, as described in the chapter on Service layers (p.47). The same layering and recursion applies to these services too, from most-abstract (row-0) to most-concrete (row-6). Each of these services also has their own flows that pass between them and the service in focus in the Enterprise Canvas. And each of the guidance-services also has its own emphases within the cells of the Enterprise Canvas.

Emphases of the guidance-services

With the exception of some of the coordination-services, few of these services have much direct impact on the day-to-day running of most of the delivery-services. Their real role is to assist in the dynamics of services – the ways in which they can, may and must change over time to adapt to changing context and to align more strongly with the enterprise vision.

95

Direction services Direction represents the management-services that provide oversight of the direction and operation of the unit. In turn, these services are split into three distinct categories:

• policy, purpose and identity: long-term view to ‘develop the business’ for the unit • strategy and context (‘outside/future’): near-future view to ‘change the business’

for the unit • direction and tactics (‘inside/now’): immediate focus to ‘run the business’ for the

unit Within the nine-cell Enterprise Canvas frame, these connect most strongly with the Value-Governance cell and, from there, to Value-Outlay and Value-Return. As local management, Value-Governance has a natural tendency to look to the past – the ‘bean-counters’ – or at best to include the near-future for local planning purposes with a view that’s tightly constrained to local needs. The role of the direction-services is to connect the governance of this service to the big-picture, and to the present and future direction of the enterprise as a whole. There’s usually only one of set of these services attached to each ‘delivery-service’ unit, though one of these will often be shared across and guide many sibling-units (as in a classic organisational-hierarchy).

Coordination services Coordination represents the coordination-services that link units together to create webs of cross-functional processes as required. As with the ‘direction’ services, these can be split into three distinct categories:

96

• develop the business: coordinate portfolios of longer-term change across units – also provides cross-functional bridge between direction’s ‘policy purpose and identity’ and ‘strategy and context’

• change the business: cross-functional coordination of change-projects – also provides cross-functional bridge between direction’s ‘strategy and context’ and ‘direction and tactics’

• run the business: cross-functional coordination of run-time processes – also provides cross-functional bridge between direction’s ‘direction and tactics’ and the unit’s own processes and interfaces

Within the nine-cell Canvas frame, these connect most strongly with Value-Creation and the ’supply-chain’ interfaces – Supplier-Channels and Customer-Channels. Value-Creation has a natural tendency to focus only on the here-and-now, on doing the same things the same way to maximise local efficiency and reliability without concern for whole-system effectiveness. The coordination-services ensure that this service is connected to others as required at run-time, and is also connected to organisational and enterprise change. There’s often only one organisation-wide ‘develop the business’ strategy-coordination service, though a variable number of ‘change the business’ services, dependent on the organisation’s portfolio/project-management mix. There will be a large number of ‘run the business’ links, often forming a complete ‘shadow network’ that is almost invisible to the standard hierarchy.

Validation services Validation represents the broad range of ’support-services’ that guide the organisation towards ever-stronger alignment with the enterprise vision and values. These services need to touch every part of the organisation, without exception,

97

ultimately as part of the background ethos, culture and collective habits – hence the alternate label of ‘pervasive-services’. Once again, these too can be split into three distinct categories:

• develop awareness: advertise and evangelise to create awareness of the importance of the respective values and their practical implications (principles etc)

• develop capability: educate in practices and metrics to implement and monitor compliance to the enterprise-values via their derived principles etc

• verify and audit: review records and lessons-learned to assure compliance to the values

Within the nine-cell Canvas frame, these connect most strongly with the Value-Proposition cell. From there, they link with the ‘relations’ cells – Supplier-Relations and Customer-Relations – to ‘spread the word’ outward to the supply-chain, the market and the broader enterprise. Internally, though, they must link with and become embedded in every cell of the service. In principle, there should be one matched set of these services, organisation-wide, for each key value of the enterprise (e.g. safety, security, quality, innovation, knowledge-sharing etc) – although the whole point of these services is to reaffirm that upholding the respective value is ultimately everyone’s responsibility. The full set of services needed will be different for every enterprise, aligning with the different needs and different values of the respective enterprise. Note that for some values such as financial probity or occupational health and safety, various laws or other constraints may mandate that the ‘verify and audit’ services should or must be kept separate from the respective ‘develop awareness’ and ‘develop capability’ services.

98

Application (Use these questions to guide discussions on guidance in general for this service, and to elicit information to populate the respective nodes and flows of the Service Guidance sections of the Enterprise Canvas.)

Direction services • Who or what is responsible for policy, purpose and identity for this service? Who

or what within this service is responsible for ensuring that this service connects to organisational and enterprise policy, purpose and identity? What flows are needed between this service and other services to ensure that this happens? What is the content of such flows? What events and decisions will trigger and guide such flows? What functions, capabilities and assets are needed in this service to enact those requirements?

• Who or what is responsible for strategy and context for this service? Who or what within this service is responsible for ensuring that this service connects to organisational and enterprise strategy and context? What flows are needed between this service and other services to ensure that this happens? What is the content of such flows? What are the events and decisions that trigger and guide such flows? What functions, capabilities and assets are needed in this service to enact those requirements?

• Who or what is responsible for near-future direction and tactics for this service? Who or what within this service is responsible for ensuring that this service connects to organisational and enterprise direction and tactics? What flows are needed between this service and other services to ensure that this happens? What is the content of such flows? What events and decisions will trigger and guide

99

such flows? What functions, capabilities and assets are needed in this service to enact those requirements?

Coordination services • Who or what is responsible for engaging everyone in ‘develop the business’

whole-context review and change? Who or what within this service is responsible for ensuring that this service connects to ‘develop the business’ review and change? What flows are needed between this service and other services to ensure that this happens? What is the content of such flows? What are the events and decisions that trigger and guide such flows? What functions, capabilities and assets are needed in this service to enact those requirements?

• Who or what is responsible for engaging this service in broad-scope change-programmes and change-projects? Who or what within this service is responsible for ensuring that this service connects to such ‘change the business’ activities? What flows are needed between this service and other services to ensure that this happens? What is the content of such flows? What are the events and decisions that trigger and guide such flows? What functions, capabilities and assets are needed in this service to enact those requirements?

• Who or what is responsible for engaging this service in process-choreography and other run-time coordination? Who or what within this service is responsible for ensuring that this service connects to broader-scope run-time coordination? What flows are needed between this service and other services to ensure that this happens? What is the content of such flows? What are the events and decisions that trigger and guide such flows? What functions, capabilities and assets are needed in this service to enact those requirements?

100

Validation services For each value, principle or quality required by the enterprise vision:

• Who or what is responsible for developing general awareness of the importance of this value to the enterprise? Who or what within this service is responsible for ensuring that this service engages in developing the awareness of that value? What flows are needed between this service and other services to ensure that this happens? What is the content of such flows? What are the events and decisions that trigger and guide such flows? What functions, capabilities and assets are needed in this service to enact those requirements?

• Who or what is responsible for developing the capability to enact this value within the enterprise? Who or what within this service is responsible for ensuring that this service develops its capability to enact this value in its operations? What flows are needed between this service and other services to ensure that this happens? What is the content of such flows? What are the events and decisions that trigger and guide such flows? What functions, capabilities and assets are needed in this service to enact those requirements?

• Who or what within this service is responsible for ensuring that this value is expressed in the real-time operations of this service? What flows are needed within this service, and between this service and other services, to ensure that this happens? What is the content of such flows? What are the events and decisions that trigger and guide such flows? What functions, capabilities and assets are needed in this service to enact those requirements?

• Who or what is responsible for auditing and verifying the practical expression of this value across the enterprise? Who or what within this service is responsible for ensuring that this service connects appropriately to the processes for auditing and verifying this quality within the service? What flows are needed between

101

this service and other services to ensure that this happens? What is the content of such flows? What are the events and decisions that trigger and guide such flows? What functions, capabilities and assets are needed in this service to enact those requirements?

102

SERVICE INVESTORS AND BENEFICIARIES

Summary

Many services, perhaps most, require some form of investment to start them going; and some services, perhaps many, provide some form of value-return to ‘external’ beneficiaries. Although stockholders and other ‘owners’ are an obvious example of this at the larger scale, similar relationships can occur right down to the code-level, with automated services. We should note, too, that the investors and beneficiaries are not always the same. In this part of the Canvas we explore those value-flows, and also the flows that govern these investor- or beneficiary-relationships.

103

Details Investment and dividend

There are another couple of sets of flows that we will often need to include in our assessment. The first is the value-flow links with any external ‘owners’ – the external investors and beneficiaries:

• investors provide value (initial funds, etc) to start up and, if required, make up any shortfall in the value-outlay – in other words, to start up the outgoing return-channel and the service itself, and to keep it going

• beneficiaries receive ‘excess-value’ (dividends, etc) from the value-return side of the return-channel – such as, in monetary terms, the ‘net profit’ after value-outlay and internal operating-costs have been subtracted

Although they’re also linked to Value-Governance, it’s simplest to show these flows as linked to Value-Outlay and Value-Return respectively. These flows are shown in the diagram as an up-arrow for investment, and down-arrow for dividend.

Flows: investment and dividend

104

In a sense, an investor is a kind of supplier, but the flow usually goes the opposite way to what we would expect, feeding into the return-channel (right to left) rather than the main-channel (left to right). Invested-value is an input to the service, but no specific value is added by the service (as Value-Creation) before it is sent on to a supplier. The simplest example of this kind of investment is in monetary terms: a new business will typically need to buy in some supplies in order to be able to sell them onward with some form of added-value. But since there are many kinds of value, there are also many other kinds of investment, including:

• entrepreneurs provide a start-up with ideas, commitment, drive • friends and family provide entrepreneurs and employees with material,

emotional and aspirational support • business-references or a government export-certificate provide a new business

with vital credibility in the market-place • a community invests sufficient trust to grant a social ‘licence to operate’ • an analyst-firm invests their personal reputation, status and credibility when

recommending the company as a suitable financial investment • a customer does likewise in recommending the company’s products and services

A ZapaMex customer makes a video about ‘unboxing’ her newly-delivered shoes, commenting on the quality of the packaging and presentation as much about the shoes themselves. Putting the shoes on, she comments on the look, the fit, the comfort, on how they make her feel – linking her to the enterprise-vision of “making feet happy”. She then posts the video on the net for anyone to see. In doing all of this, she invests her effort, her trust, her own reputation, her pleasure in both the company and the ZapaMex brand. She’s not been paid to do this – the opposite, in fact, in that she has paid for the privilege to do all of these things. Up to the company, therefore, to make sure that to her it continues to feel like a privilege, and that her investment has for her been worthwhile.

105

Perhaps the simplest way to explore investment is to identify the respective assets in terms of the tetradian dimensions – see ‘Service and market’ (p.23):

• physical – alienable ‘things’ and tangible services • virtual – non-alienable items such as ideas and information • relational – person-to-person connection • aspirational – personal commitment to an idea, belief, brand or enterprise-vision

Note that others may have multiple roles relative to the service in this respect, and may also invest multiple forms of value. A supplier who extends a financial line of credit to the company is investing both money and trust. That satisfied ZapaMex customer who tells her friends about how much she likes her new shoes is both a customer and an investor because she’s investing her own reputation in the company. The inverse may apply if a ZapaMex customer, for example, is not satisfied with their purchase: they become an anti-client who ‘anti-invests’ their reputation and their effort against the company, and will usually try to induce others to withdraw their investments too. In former times this usually didn’t matter all that much – a single complainant wouldn’t be able to do much on their own. But it now matters much more than it did: in the days of social-media, a single disgruntled customer can cause a lot of damage…

Probably the textbook-example of this is Dave Carroll’s song United Breaks Guitars. A professional musician, he became annoyed with United Airlines, having been given the run-around for almost a year by the customer-service department after his beloved Taylor guitar was damaged in baggage-handling. He wrote a song about his troubles, which he and his band performed in a low-cost music-video that they then posted up on YouTube. The song’s catchy tune and chorus, and the bright, ironic humour of the video, were enough to make it an instant internet hit: it passed the million-views mark in well under a week. Quickly becoming a lightning-rod for anger at all airlines’ often customer-hostile ‘customer-service’ systems,

106

it appeared on national TV only a day or two after release; on international TV a day or two after that. United, caught completely off-guard, probably spent upwards of $20million in urgent damage-control; the damage to brand was incalculable, but the incident certainly played a part in triggering a short-term hit of almost a billion dollars off their share-value. The irony, of course, was that United could reasonably claim that none of it was their fault: the initial incident fell into one of those awkward grey-areas where many different people were involved and no one of them could be assigned exclusive responsibility to repair the damage. But no matter: it was United that wore the blame – and the costs, in every sense. Don’t ignore your anti-clients: anyone can become one, for any reason, at any time, and any one of them could kill the company, yet you have no way at all to know in advance which one of them it might be…

Many companies will acquire some of their anti-clients as a direct consequence of the nature of the work that they do: oil-drillers and miners opposed by environmental activists, for example, or a family-planning clinic challenged by those who hold opposing religious beliefs. In a sense, every competitor, of whatever kind, is an anti-client too, although that kind of anti-investment is to be expected and should be planned for from the start: it shouldn’t much matter unless the competitor is able to incite a more general anti-client attack – as may happen often in politics, for example.

The only way to tackle this risk – and opportunity – represented by anti-clients is to go to the visible effort of building a reservoir of trust and reputation with the broader community. At some point you are going to have to draw on that reserve, and – courtesy of the naturally chaotic nature of real-world interactions and events – you have no way to know when or why that will be. One of the few proven tactics to do this is to build dialogue connection with the broader enterprise by being clear on your enterprise-vision, and demonstrating by explicit action that you hold yourselves accountable to that vision. The alternative is simply to sit and hope that nothing will happen: not a wise move, as United Airlines discovered there the hard way…

Going the other direction, a beneficiary is a kind of customer – the recipient of a dividend – but the flow again will usually go the opposite way to the usual

107

customer-flow, coming from the return-channel rather than the main-channel. Value here is an output from the service, but no value has been added directly as such by the service itself. As before, the simplest example is in monetary terms, such as a dividend-payment to a stockholder. Again, though, there are many other kinds of value: for example, the government gets payback for its export-licence in terms of enhanced credibility for the country as a whole, whilst the local community may see returns in terms of ‘good citizen’ behaviour by the business, and also wages and employment supporting the local economy. Most investors will expect some form of direct or indirect return on their investment: the complication here is that the dividend may not necessarily take the same form of value as in the initial investment. Someone who invests time may expect to be paid in money; someone who invests money in a social project may simply want the satisfaction of seeing the job done well, with a good social outcome; you’ll see that there can be an almost infinite array of possible permutations in this. It’s important to avoid any reliance on the usual overly-simplistic notion of ‘double-entry life-keeping’, and instead take care to identify what each potential investor’s expectations may be – otherwise, again, there’s a risk of creating another dangerously-disgruntled anti-client where, with a little extra effort, we could have ensured strong satisfaction all round for everyone.

A question of balance From a simple monetary perspective, especially in a commercial context, the investors and beneficiaries will often seem to be the same – the stockholders or shareholders, for example, or the members of a cooperative. But in reality, and especially in a not-for-profit or government context, they will often be different, at least in terms of a money-only calculation. In addition, as we’ve seen above, invested-value and returned-value may take on very different forms: a financial

108

investment may be returned in a form such as reputation or social standing. In many cases, simple book-keeping may be more of a hindrance than a help. But it still is essential that the various ‘books’ balance up in some appropriate way. The key is simply that the investor feels satisfied with the effective return on their investment – in whatever form each may take. The result, though, is that achieving that proper balance across all forms of investment can be anything but simple.

Investors and beneficiaries: maintaining the balance

In the Enterprise Canvas, most of this work will fall to the Value-Governance cell. There will often need to be distinct activities and flows associated with that cell – such as an Investor Relations unit, for example. (Note, though, that the actual task needs to address all investors and forms of investment – not solely monetary forms.) These flows will need to link both to investors and to beneficiaries – who, once again, may in many cases be different people. And a major focus is not just to

109

maintain appropriate relations with all of these stakeholders, but to ensure also that an appropriate balance is maintained on either side of the investment/dividend equation. A strong link to the ‘direction’ guidance-service – see ‘Direction services’ in chapter Service guidance (p.95) – will help in keeping focus on the overall vision of the shared-enterprise as the ultimate arbiter for decisions on balance. Whilst unintentional imbalance will always create enterprise risk, deliberate imbalance can be downright lethal. Unfortunately, both of these can be all too common – in part because of the way in which financial investment is arbitrarily assigned a questionable automatic priority over all other forms of investment. As business-commentator Charles Handy put it, the notion that the financial investors can purport to ‘own’ other people’s lives is downright obscene – and yet at present that is often what actually happens in real business practice, because in many if not most organisations the majority of their assets are intangible, residing in people rather than exchangeable ‘things’. The privileging of financial investment over all other forms also enables all manner of options to ‘game’ the enterprise, from hostile takeovers to asset-stripping to overt dumping and worse. That such activities may technically be legal does not change the fact that in almost other any context they would be classed as serious crimes: and the point here is that every other investor in the enterprise will know it. In short, such game-plays can create a time-bomb for the overall enterprise, and at some point – as is already starting to happen in some cases – that bomb will eventually explode, with messy results all round. It’s likely that the only people who can take appropriate action on this are senior executives and lawmakers – and whether they will have the courage to bite the bullet on this is another question entirely. But in the meantime, this section of the Enterprise Canvas can help to surface serious concerns such as these: and that at least will give us – and the lawmakers – something to work with when the appropriate time comes.

110

Application Investment and dividend

• What investments are made in this service? In what forms of value do these investments occur? Via what flows are these investments made in the service? Who or what is responsible for making these investments? Within the service, who or what is responsible for receiving these investments, and for ensuring satisfaction of the investor in the investment?

• What dividends are disbursed by this service? In what forms of value do these dividends occur? Via what flows are these dividends disbursed by the service? Who or what is responsible for receiving these dividends? Within the service, who or what is responsible for disbursements, and for ensuring satisfaction of the beneficiary in the dividend?

Balancing investors, beneficiaries and the enterprise • What facilities exist within the service to ensure appropriate balance between

investors and beneficiaries, between investments and dividends? • What facilities exist to ensure satisfaction both of investors and beneficiaries? Via

what flows do these facilities communicate with investors and beneficiaries? Within the service, who or what is responsible for each of these facilities, for their appropriate operation, and verification of appropriate results?

• What facilities, mechanisms or flows are used to ensure appropriate linkage to the enterprise vision?

• What action is taken in the event of unintentional imbalance between investment and dividend, or between different investors and beneficiaries? Who or what is responsible for taking such action?

111

• What action is taken – or can be taken – in the event of deliberate imbalance between investment and dividend, or between different investors and beneficiaries? Who or what is responsible for taking such action?

• Where such action to correct imbalances is prevented by current corporate law or other ‘external’ forces, what else may be done to minimise damage to the overall enterprise?

112

SERVICE DECOMPOSITION

Summary

As we move more towards realisation of the service, we’ll often need to split the generic descriptions in each Canvas cell into the more explicit ‘child’ services and sub-services of which it is composed in real-world practice. We can use the Canvas with our stakeholders as a guide to elicit details about these ‘child’-services – and, if appropriate, model each of them on their own Canvas.

Details The Enterprise Canvas provides a kind of idealised view of the services of which the enterprise is composed, what each service does, and how they interconnect. In the real world, of course, few things match up exactly to that nominal ideal. In the upper layers of abstraction – above row-3 – this should not matter at all, in fact most of the time there we should take some care to avoid paying too much attention to how things will work out in practice, or, especially, to what already exists. As we move downward, though, we do need to pay more and more attention to the various constraints and practicalities of the real world. In row-3 we need to bounce

113

back and forth between the ‘ideal’ of the Canvas and the real-world services that either do or will implement each cell and flow of the Canvas, including the guidance-services and the links with investors and beneficiaries.

In rows 3, 4 and 5 we also need to become much more explicit about the content and structure of each service and flow, and the row-6 metrics for each, but we’ll look at those in more detail in chapters Service content (p.116) and Services as systems (p.147).

For example, for ZapaMex, we need to explore our options for the real-world Customer-Channels. At present the company sells only through its retail stores, but would it be practical to do sales via direct-mail as well? If so, what about phone-sales, to complement the direct-mail order-forms? In which case, what would be the cross-over with the existing customer-service call-centre – in what ways would those Customer-Relations service need to change? And what about e-commerce, via a web-store? We may plan to do that only in a few years’ time, but it would be wise to think about those services now – especially as they would impact on the way we handle Value-Return payments from the customer, and the Customer-Relations services too.

ZapaMex: decomposition of Customer-Channels services

Each step in this process of service-decomposition brings us closer to the real-world. (This detailed-decomposition is often also known as describing the granularity of a

114

service.) Yet each of these items is still also a service in its own right – and hence a candidate to model on its own Enterprise Canvas, complete with its own flows, guidance-service links and possibly its own service-specific links to investors and beneficiaries as well.

Each cell is also a service

In the same way, we can, and often should, apply the same decomposition to each of the cells within an Enterprise Canvas. Each cell is a service, hence also has its own subsidiary services and flows. This also means that there’ll almost certainly be flows between cells within an Enterprise Canvas, which we will likewise need to map in the same way as for any other service. In theory this decomposition could go on ad-infinitum – which is a quick way to get stuck in ‘analysis-paralysis’. So in practice we do need to know when to stop! The simplest guideline here is that we should aim always to do the minimum decomposition needed to make sense of the service, and stop as soon as we’ve reached that point.

115

Application • What are the services within each cell of a service? What are the flows between

each cell of a service? Going down a level if necessary, what are the cells and flows of each of these subsidiary cells of the service?

• What real-world services implement each service in a high-level Enterprise Canvas? How does the view change as you delve deeper into finer-grained partitioning of services?

• Which real-world services bridge between two or more of the cells in the idealised structure of the Enterprise Canvas? Why is it necessary that they should do so? What implications and trade-offs does this suggest for the service’s orientation (to its suppliers, to its own value-creation or to its customer) or its time-focus (future, present or past)?

116

SERVICE CONTENT

Summary

In the quest for more detail, we apply various checklists to each cell in the service structure and its flows, to enquire about the assets, functions, locations, capabilities, events and decisions at play in each case, and how they link together to deliver the service itself.

Details After those descriptions of its various structures and components, we now have the complete Enterprise Canvas. Hence time to put this model-type to practical use, to identify the actual content of each service and its flows and relationships. This chapter deals with general content, whilst the next chapter - Services as systems (p.147) – goes into more depth on how services work together as systems, and how support for strategy and the like would need to be embedded within services themselves.

117

We would usually start to apply these detail-assessments in row-3 – such as in business-model development and verification – and use service-decomposition to expand out the detail in row-4 and row-5. In each case we need not only to develop appropriate row-6 metrics, but also identify how these metrics will be used for ‘run the business’, ‘change the business’ and ‘develop the business’ performance-reviews for each service. The process for modelling is essentially the same in every case, whether we want to do an as-is, an as-was or a to-be model for the respective service that is the focus of this Canvas.

Start anywhere Each instance of a Canvas describes a single service at a single layer of abstraction, in context of the flows and interchanges it shares with each of its stakeholders. We really do first need to know the enterprise vision and values, in order to know what ‘value’ is and means within any part of the enterprise. If we don’t already have it, we need to start at row-0 to set that in place. Once we do have that Enterprise layer in place, though, we can start anywhere, with any service, at any level, in any aspect of the organisation and extended-enterprise. There’ll be many cross-references in what follows, so for brevity’s sake here’s a version of the complete Canvas with simple two-letter codes assigned to each cell, flow and external party.

118

RSsupplierrelations

VPvalue-

proposition

CSsupplierchannels

VCvalue-

creation

CCcustomerchannels

RCcustomerrelations

VOvalue-outlay

VGvalue-

governance

VRvalue-return

GDGVGK

coordinationdirectionvalidation

PSsupplier

PCcustomer

PIinvestor

PBbeneficiary

NLnext layer

mgmt

XKXDXV

XO XRXG

XTS

XCS

XBS

XTC

XCC

XBC

XAI XAB

Complete Enterprise Canvas with two-letter codes

(Key to prefixes: V=value, R=relations, C=channel, P=external party; G=guidance, X=flow (exchange).) The Canvas is also holographic: every service ultimately connects with everything else. Hence any assessment we do in any part of the enterprise implicitly contributes to the detail of everywhere else. So we don’t need to try to gather every piece of information about everything in ‘excruciating detail’, as John Zachman once put it; instead, we pick any appropriate starting-point, model only what we need for that specific task, link the models together as required, and allow the overall detail to emerge over time through the layering and interconnections of the Canvas structure.

119

So: start somewhere. Anywhere will do. It doesn’t need to be a ’service’ as such – just an area of interest, an aspect of the organisation or enterprise where something happens.

Layers What layer is it, in terms of the Enterprise Canvas? To put it another way round, how abstract is it? or how concrete? Use the descriptions in the Layers chapter (p.47) to identify which layer you want to be working on.

The important point here: don’t mix layers. Each layer has a different architectural function, and you create architectural risks if you blur them together. If you need to see how something changes across layers – going from row-3 abstract to row-4 implementation-design, for example, or from an actual row-5 implementation back up to row-3 to rethink alternate options – then use a separate Canvas for each layer, and link them together via GV/GD/GK oversights [see the labels in the diagram above] and/or via XV/XD/XK or XM service-interfaces and flows. Don’t mix them up!

Nature of the service

Tetradian dimensions

120

We use the tetradian dimensions – physical, conceptual (virtual), relational, aspirational – to summarise the nature of the service:

• What does it do? (‘physical‘ dimension) What services or products or other ‘deliverables’ does this create through its work? (The answers define the role and emphasis of the Canvas’ Value-Creation cell.)

• What information does it need, to guide and plan and schedule and improve what it does? (‘conceptual‘ dimension) With whom or what does it need to share this information? (The answers define the role of the Value-Governance cell, with some emphasis on the Value-Outlay and Value-Return cells and the XK, XD, XM, XG and other interfaces.)

• For whom or for what does it do this? With whom or with what does it relate? (‘relational‘ dimension) Via what transactions and flows does it deliver? (The answers define the role and content of each of the flows, with an emphasis on each of the ’supplier-side’ and ‘customer-side’ cells and the XC interfaces, and the direct transactional stakeholders.)

• Why does it do what it does? (‘aspirational‘ dimension) What value does this add for each of its stakeholders, and for the overall enterprise? (The answers define and emphasise the role of the Value-Proposition cell, and key aspects of the Customer-Relations, Supplier-Relations, Value-Outlay and Value-Return cells, the XV, XT, XB, XO and XR interfaces, and the non-transactional stakeholders.)

Repeat the process for each of the cells (Vx, Rx, Cx), each of the flows (Xx), and each of the stakeholder-relationships (Px). What does it do? For and/or with whom or what does it do this? What information does it need? Why does it do this? For example, often the service will need some form of investment to get it started, or keep it going (XO interface, linking between VO cell and PI or other stakeholder). What is this investment? What value and/or values does it represent? (Remember to

121

think of ‘value’ in more than solely monetary terms.) What does this investment do? From whom does this investment come? What information is required to determine what investment will be needed? Why is this investment needed? and so on. Review the service’s needs for the guidance services (GV, GD, GK) that connect this to other parts of the enterprise and its values:

• Who or what provides run-time coordination (GK) with other services? Identifies and coordinates medium-term change of this service (such as via change-projects, -programmes or -portfolios), in parallel with other services? Develops overall potential for value-creation, in conjunction with other services?

• Who or what provides operational or run-time direction (GD) for this service and its sibling-services? (What are this service’s sibling-services? What do they do? Why?) Who or what provides business-intelligence and other guidance for medium-term transition from strategy to tactics for this service? Who or what links this service to the overall enterprise to identify appropriate longer-term strategy?

• Who or what ensures validation (GV) and alignment to enterprise values, principles, rules and regulations? (What values and the like will apply to this service? Why? What are their relative priorities, and why? What values and principles do not apply? Why not?) Who or what develops awareness within this service of the need, importance and application of each value, principle and so on? Who or what assists this service in developing its capability to enact and align with that value? Who or what will monitor, audit and assure compliance with each value within this service?

• What interchanges, flows and interfaces are needed to support, guide, coordinate and validate all of this?

122

• What value does all of this provide to the service, in delivering its value-proposition to the enterprise? What impacts and constraints would apply to this service in the short-, medium- and longer-term if this coordination, direction and/or validation does not occur?

With all of that in place, we now have some solid understanding of what this service does, and why, and for and with whom. We now need to look more closely at the ‘how’ and ‘with what’ of the service – for which we use the Service Content model.

Service content Those interrogatives of Who, What, How, Where, When and Why that we used for quick assessments of content earlier are easy to remember, but can be surprisingly misleading when we get down into the detail of an architecture. To understand and describe content-service, we need a more precise model, one which also adds another dimension – a set of segments to describe entity-types and/or decision-types. So we’ll use a slightly different expanded checklist here, that we can use in conjunction with each row of the Canvas. The content-model splits everything into a set of primitives, which are then combined as required into composites. A primitive is something that can be defined or described in terms of a single cell, whereas a composite straddles across cells.

123

Capabilities

(acti

ons)

Locations

Functions

Assets

Capabilities

(skil

l-leve

l)Events

Decisions

Service Content model

So pure data, for example, is a primitive, a virtual asset, whereas a book is a physical ‘thing’ that also contains information, and hence is a composite physical + virtual asset. A function changes assets, yet cannot do anything on its own until combined with a capability (an ability to work on an asset-type at a particular skill-level), a combination that we describe as a ’service’; a ‘process’ represents a sequence of service-requests; and so on.

A composite should not be able to straddle framework rows, but that doesn’t concern us here, because we should only be working with a single row at a time. Note, though, that a pattern can straddle more than one row: for example, one very common design-pattern in data-architecture is that the abstract (row-3) ‘many-to-many’ data-relationship may be implemented (row-4) as a cross-reference-table.

One of the main roles of architecture is to apply abstraction –moving ‘up’ the rows towards row-0 ‘Enterprise’ – to split the composites apart into smaller composites and primitives, so as to enable reconfiguration and redesign into other, more effective ’solutions’ for the given context.

124

Design and implementation go the other way, moving ‘down’ the rows towards the ‘now’ between row-5 ‘immediate-future’ and row-6 ‘past’. At that point, by definition, everything must be an ‘architecturally-complete’ composite across all the content-model columns, which we could summarise as:

with Asset do Function using Capability at Location on Event because Decision

‘Architecturally-complete’ composites may use any appropriate set of segments: for example, the same nominal function (“sort the mail”) might implemented using a machine (‘physical’ capability), an IT-system (‘virtual’ capability) or a manual process (‘relational’ capability), or any combination of these. One of the keys to design for disaster-recovery is to structure the business-functions such that one type of capability may be swapped for another at any time – for example, a manual process that can take over if and when the regular IT-system fails. Assets are entities for which the respective service is responsible.

Note that that point about responsibility is the key distinction between assets and generic ‘resources’. There’s a crucial distinction between ‘possession-based’ versus ‘responsibility-based’ concepts of economics which would take too long to explain here. Conventional economics is based on notions of ‘rights’ of possession, whereas internally a business will operate on responsibilities – for example, a process-owner is the person who is responsible for that process, not the person who ‘possesses’ it. The shortest summary is that enterprise-architectures only work when we use a responsibility-based model throughout, and that in essence ‘resources’ become assets when we take on responsibility for them.

As described in the market-metaphor in Service context and market (p.23), the key asset-categories are:

• physical ‘things’ • virtual items such as data and information

125

• relational links between real people • aspirational links between people and abstract ideas, represented by brands in one

sense, but also by morale, by values, and by the idea of the enterprise itself Two other quick notes here: Time is arguably also a kind of resource, but it’s not an asset as such: it can’t be possessed, nor can it be directly exchanged for anything else. It’s best understood as a location – events occur in time, but time itself is not an event. And whilst some people might class money as a special case of abstract asset, it’s actually better understood as a simple composite of virtual and aspirational, as information about a belief in future ‘rights’ of access to assets. Architecturally speaking, money isn’t a value, it’s actually a belief about value – and often a very muddled belief at that! A bit technical, perhaps, but very important once we start to explore in depth how value actually works within enterprise-architectures.

An asset may also be represented by any composites between these types. In practice, it’s probable that most real-world entities are composites in this sense: for example, a key point in marketing is creating emotional attachment to objects – in other words, a composite-asset of physical+aspirational. Functions will use, reference, act on, change and/or return assets, and hence can be described in terms of the same asset-types. Note that the function is only one part of the ‘how’ of a service, the description of what usages or changes it will apply to those assets. It doesn’t describe the ‘with-what’ aspect of ‘how’, which is represented by the capability that actually enacts the function. In classic machine-design or functional-programming for IT-systems, function and capability are merged within the machine or the program itself. But in fact it’s an arbitrary constraint, and one that doesn’t apply when processes are enacted by real people, or when we move back to the abstract for process- or service-redesign.

126

Architecturally, it’s important to keep the functions and capabilities separate at a conceptual level, and be aware of how and why we merge them in each service-implementation. Locations can also be described in terms of the same asset-types: physical locations; virtual locations such as a URL or an IP-address; relational locations, such as displayed in an org-chart; and even aspirational locations, such as relationships between brands. As usual, there may also be composites of these types, such as the physical+virtual location of a data-server. As noted above, it’s also best to describe time as a kind of abstract-location: for example, events may occur in time – in other words, may be located in terms of time – but are not actually part of time itself. Capabilities should be described both in terms of asset-types they act on, and skill-levels or decision-abilities used in that action. The asset-types are the same as described for Assets above:

• physical ‘things’ or tangible services • virtual information or advisory information-based services • relational links with real people • aspirational links and their anchors, such as brands, beliefs and identity, often

expressed as commitment or morale Skill-levels are similar to decision-levels, and are closely-related. A model of repeatability can also be useful here: the skill-levels of rule-based, algorithmic, guidelines and principle-based are likely to be needed in contexts that match the repeatability categories of Simple, Complicated, Complex and Chaotic.

127

Capabilities: repeatability and skill-levels

We can summarise the skill-levels as follows:

• simple rule-based decisions such as following a predefined step-by-step process or checklist

• more-complicated algorithmic or ‘hard-systems’ capability that still assumes predictable rules but can accommodate many branches, delayed-feedback, damping and the like

• heuristic or ’soft-systems’ capability, often using guidelines or patterns to interpret emergent contexts with complex inherent uncertainties, such as so-called ‘wicked-problems’

• principle-based decision-making for contexts that are unique and inherently unpredictable

The distinctions about skill-levels become crucially important in process-design, because physical machines, IT and real people have very different capability-curves. In general:

• physical machines can usually work only on physical assets, and are best-suited to following rule-based decisions

128

• IT-systems can work on virtual-assets and, via control of physical machinery, physical-assets, using rule-based or algorithmic decisions, but are still limited in capability for pattern-recognition, and in general should not be used for decision-making in inherently-unique contexts

• real-people can work on any types of assets, with varying skill-levels, though in many (most?) cases are notoriously not well-suited to the rigid rule-following and mechanical repetitive-tasks assumed and required in Taylorist ’scientific management’

Attempts to use inappropriate types of systems and capabilities in a given context will usually lead to ineffectiveness and, in many cases, ‘unexpected’ failure. Note too that a capability is embedded in or enacted via some kind of asset – such as a machine (physical) or computer-program (virtual), or via a relational-asset to a real person.

It's essential to understand, by the way, that real people should never be described as 'assets', either in an architecture, or anywhere else. This is the whole point about relational-assets: the relationship is the asset, not the person - it's the relationship with the person that creates the access to that person's capabilities. If the relationship is damaged or destroyed, almost all value will be lost, even if the person is physically present.

The common label for this column – ‘Who’ – does sort-of make sense in relation to real people, but makes no sense at all when the capability is embedded in anything else. It would force us to merge function and capability together for machines and IT, but not for people, thus further compounding the skill-level problems described above. Events are triggers for action, and can again be described in terms of the same asset-types:

• physical events

129

• information-events, signals and other virtual-events • relational events, such as a phone-call or the arrival of a prospective customer at

a store-counter • aspirational-events, such as a change of brand, or an event causing damage to

morale As usual, many if not most real-world events will be composites of these types, and for many purposes a broader notion of event as a kind of ‘package’ may be more useful – see the service-flow content-model below. Note also the point above about time: events occur in time, but are not actually part of time itself. Decisions represent the ‘why’ or ‘because’ of the enterprise. These are usually built up in layers or hierarchies of dependencies, with the question ‘why?’ moving upwards through the layers, and ‘because’ moving down.

The enterprise-vision is the ultimate ‘Because.’ of the enterprise: note the period/full-stop, which indicates that the layering of ‘why’ stops here!

There are many ways to describe this layering – for example, see the Business Motivation Model standard – but probably the most useful categorisation is the same set as for the capabilities skills: rule-based, algorithmic, heuristic and principle-based. Again, most (perhaps all) real-world contexts require composites of those decision-type categories, as a chain of exception-trapping and escalation. Any real-world process-design will need to ensure that the ability to make appropriate decisions does indeed exist at each escalation-level in the context, otherwise the overall process is guaranteed to fail on some ‘unexpected’ event.

130

Using the content-model with Enterprise Canvas

The content-model tells us what happens within each entity, and also helps us to distinguish between the cells in the entity. Or, to put it the other way round, the Enterprise Canvas cells specialise in different areas of the content-model frame – for example:

• the core functions of the entity-as-service take place within the Value-Creation cell

• the supplier-side and customer-side Channels deal with the main transaction-events

• the Relations cells are especially important for dealing with relational and/or aspirational-assets

We can also use the content-model to tell us which Canvas layer we’re working in at any given point - for example:

• if we’re dealing with records – in other words the past, the ‘as-was’ – then by definition we’re in row-6

• if we’re looking at relationships between entities, we cannot be above row-2 • if we’re looking at lists of things, we could be anywhere up to row-1 • if we’re looking at attributes of things, we can’t be above row-3 • the moment we mention a specific technology or technique, we’re in row-4 or

below. These are all fundamental to architecture-driven redesign, and help to prevent us from treating any prepackaged ’solution’ as an architectural requirement – unless we choose to do so. Note that the only absolute architectural requirement for the organisation is the enterprise vision, with its associated core-values: everything else is just implementation, at varying levels of abstraction.

131

The relationships between primitives and composites are also important here. In essence one of our most important architectural concerns comes down to this:

Services are usable to the extent that they are architecturally ‘complete’ Services are re-usable to the extent that they are architecturally incomplete

To enable new architectural options, we need to be able to split our composites apart. To enable new service-implementations – and new business-options – we need to be able to re-combine the resultant primitives into new combinations. That’s what an architecture does in this context.

As an author, I might think of myself as ‘a writer of books’. But a printed book is actually a composite, a ‘bundling’ of information in a specific physical form – and as an author, my actual product is the information, not the physical book. (It would be the other way round for someone who worked in a printing business, of course.) Once I understand that point, it opens up a whole raft of new possibilities, new options to deliver the service represented by that information. For example, I could dispense with the physical book, and present the same content in electronic form, as an e-book. I could split up the content in different ways, perhaps serialised in smaller chunks in an online magazine. I could present it another virtual-medium, via video or voice. Or I could deliver it via a relational-asset channel, otherwise known as in-person consulting. All of these options become possible once I split ‘the book’ into its real root-primitives – or, perhaps more to the point, remain entirely invisible unless I do so.

To make something re-usable, we need to move up the layers of abstraction, to split apart the implementation-composites, and to expose any ‘bundling’ that could perhaps be recombined in new ways. To make something usable, we need to go down the layers, linking each item into more ‘complete’ implementation-bundles. At the point where it touches the real world, everything must be architecturally-’complete’. That’s what the layering describes.

132

The other key point about the content-model is that it acts as a checklist to make sure that we line things up correctly: for example, that we don’t try to use IT for something for which it’s not well-suited, or which it can’t handle at all.

Another example (which should be obvious to everyone, but painful experience indicates that it isn’t…) is that a record of a ’something’ is not the same as the thing itself. The record is information – a virtual-asset – whereas the item referred to in the record could be any type of asset at all – a physical object, a data-event, a business-relationship, whatever. So the moment we find a record of something, we need to look for the matching audit-process or equivalent – such as data-cleansing and de-duplication – that ensures that the records do line up correctly with the respective items: because if that audit-process doesn’t exist, we have an architecture that almost guarantees service-failure.

We can also use the same checklists to ensure proper coverage for disaster-recovery, business-continuity or just everyday operations. Machines fail, computer-systems fail, power-supplies or network-connections fail, whole buildings can be swept away in a natural or man-made disaster: we may well need ‘manual’ processes to take over at a moment’s notice. Which means that we need the respective processes to exist, and people with the appropriate skills to do them – and also know how to switch over to those ‘manual’-processes, too. All of those are items that we can check by using the content-model checklists, in a layered way. Apply these checklists to the service in focus on the Enterprise Canvas, and to each of its cells and flows:

Assets

• What types of physical assets – physical ‘things’ – are important to this service? What roles do these assets play in the service – for example, as input supplies, as output products, or used as consumables in business processes?

133

• What types of virtual assets – data, information, knowledge – are important to this service? What roles do these assets play in the service – for example, as records, as metrics, as content for delivered services, as controls in business processes?

• What types of relational assets – relationships with other organisations and actual people – are important to this service? What roles do these assets play in the service – for example, as links with employees, suppliers, customers, shareholders, regulatory bodies, other stakeholders? How are these links used in business processes – such as through contracts and other agreements?

• What types of aspirational assets – the personal sense of belonging, commitment and shared-purpose – are important to this service? In what ways do others connect to the service – for example, morale and commitment of employees, customers’ sense of ‘belonging’ via a brand, or community perception of reputation? To what does the service and its organisation itself belong – for example, to a nation, to an industry, or to the shared enterprise as represented by its vision and role? What impacts do these assets have in business processes such as in HR, productivity, marketing?

• What types of other abstract assets – abstract conceptual entities such as finance, credit and energy – are important to this service? What roles do these assets play in the service – for example, as access to resources for business processes, as measures of success, as relational factors in transactions?

• What types of composite assets – combinations of any of the above ‘atomic’ asset-categories – are important to this service? What are their base asset-categories? In what ways is it possible – or not possible, in practice – to split the composite into its base-categories? What are the consequences of not being able to split the composite into its base-categories?

134

• What value does each type of asset have for the service? For relational and aspirational assets, by what means does the service identify when these assets need to be created, or have been changed, damaged or deleted, by the entity at the ‘far end’ of the link? How are these assets obtained, maintained, monitored, managed through their life-cycle, and disposed-of at the end of it?

Functions

• What are the major categories of business functions in this service? How do these functions relate with each other, in terms of service-categories and service-layering?

• What assets does each function use, create change, update, delete, destroy? What category of asset, or combination of asset-categories, is involved in each case – physical, virtual, relational, aspirational, abstract? In what way does the function change the respective asset? What category of function, or combination of function-categories, is involved in each case – physical, virtual, relational, aspirational or abstract?

• What locations are related to each function? What category of location, or combination of location-categories, is involved in each case – physical, virtual, relational, aspirational, abstract?

• What events trigger or are triggered by the function? What category of event, or combination of event-categories, is involved in each case – physical, virtual, relational, aspirational, abstract?

• What reasons or decisions apply to or impact on the function? What category of reason, or combination of reason-categories, is involved in each case – rule-based, analytic, heuristic guideline, or principle?

135

Locations

• What types of physical locations and their associated location-schemas – geographic, building-floor etc – are important to this service? What roles do these locations play in the business – for example, as retail contact-points, manufacturing locations, physical storage, resource sites?

• What types of virtual locations and their associated location-schemas – networks, naming, web-addresses, contact-numbers etc – are important to this service? What roles do these locations play in the business – for example, as virtual contact-points, as nodes for information routes?

• What types of relational locations and their associated location-schemas – such as market-segments, nodes in reporting-relationship trees and social-networks – are important to this service? What roles do these locations play in the service? How are these locations used in business processes?

• What types of aspirational locations and their associated location-schemas – in particular, the end-nodes of aspirational-assets – are important to this service?

• What types of other abstract locations and their associated location-schemas – time and time-zones, for example – are important to this service? What roles do these locations play in the service – for example, as reference-points for measurement of performance?

• What types of composite locations – combinations of any of the above ‘atomic’ location-categories – are important to this service? What are their base location-categories? In what ways is it possible – or not possible, in practice – to split the composite into its base-categories? What are the consequences of not being able to split the composite into its base-categories?

• What value does each type of location have for the service? For relational or aspirational locations, by what means does the service identify when relational-

136

locations need to be created, or have been damaged or deleted, by the entity at the ‘far end’ of the link? How are these all of these locations identified, obtained, maintained, monitored, and – where feasible – managed through their life-cycle?

Capabilities

• What capabilities are implied as required by the overall enterprise? What capabilities are implied as required by the functions of this service? How would you categorise each capability, in terms of asset-type acted upon, asset-type of agent, and required skill-level?

• What capabilities are implied by each key asset-type, location and event identified in assessments here? What is the required skill-level in each case?

• What capabilities are implied by each key reason, decision, constraint, standard or suchlike identified in the assessments here? What is the required skill-level for appropriate decision-making in each case? What asset-types would be involved in each case? What events or functions would call for this capability?

• Does the capability need to vary in different locations? If so, what location-category is implied in each case?

Events

• What types of physical events are important to this service? • What types of virtual events – messages, signals, data-values – are important to

this service? • What types of relational events – arrivals, departures, contacts, other events in

relationships with other organisations and actual people – are important to this service?

137

• What types of aspirational events – such as reputation- or public-relations events, or changes to brand – are important to this service?

• What types of other abstract events – such as cycles of time – are important to this service?

• What types of composite events – combinations of any of the above ‘atomic’ event-categories – are important to the organisation’s business? What are their base event-categories? In what ways is it possible – or not possible, in practice – to split the composite into its base-categories? What are the consequences of not being able to split the composite into its base-categories?

• What roles do each of these events play in the service, as input- or output-triggers for routine or exceptional business processes? What value does each type of event have for the service? How are these events identified, monitored and managed within an overall life-cycle?

Decisions

• What decisions, business-rules, principles and guidelines apply within this service? What decision-levels and skill-levels are required in order to appropriately enact each decision? Who or what would enact each decision? Who would be ultimately responsible for each of these decisions?

• What laws and other regulations apply to this service? To what extent and in what ways are they binding on the organisation? In what ways do these vary in differing jurisdictions and the like?

• What standards – quality-standards, technical standards, interface standards, language standards and suchlike – apply to this service? To what extent and in what ways are they binding on the respective areas of the organisation? In what ways do these vary in differing regions and the like?

138

• What social expectations and social standards – ethics, environment, general ‘good neighbourliness’ and so on – apply in each area of this service and its business context? To what extent and in what ways are they binding on the respective areas of the organisation? In what ways do these vary in differing regions and the like?

• What constraints – and opportunities – do these imply for the organisation and its business in the enterprise? What trade-offs do these imply against the business requirements?

• By what means would the service confirm its compliance with these constraints? What actions and information would be required? How would you monitor and measure compliance? What would be the consequences of failure to comply? What opportunities arise from the required compliance with these constraints?

More questions on content

• Given the asset-types list, what capabilities are needed to work on them? • Given the decision-types list, what exceptions will cause a decision to be

escalated – all the way up to truly-unique yet business-critical events? • Does the skill and capability exist to resolve that escalation? Via what means will

that capability be delivered? • How can we design the service-interfaces to be ‘transparent’ to the

implementation-method – for example, such that people can take over when an IT system fails, or a machine can take over when people are overloaded?

• What are the trade-offs? • What are the costs – in any sense of ‘cost’?

139

Service-flow content The main content of a service-flow – its payload – will consist of a context-specific mix of asset-types, which should be assessed as above. In addition, there will also be various ‘wrappers’ which are not necessarily the payload itself, but are essential in maintaining the integrity of the overall service.

Service-flow content ‘wrappers’

This section of the content-assessment is based on the VPEC-T framework developed by Nigel Green and Carl Bate. Note, though, that this is an adaptation for use with the Enterprise Canvas, and differs significantly from the original in some places – in particular, the ‘Content’ dimension from VPEC-T has been replaced here with a ‘Completions’ dimension that has a somewhat different role.

We can categorise these according to the part that they play in the overall flow, and also in the market-cycle: Values, Policies, Events, Completions, Trust. Note that in many cases these ‘wrapper’ flows will take the form not just of a single ‘package’, but a back-and-forth interaction that may comprise many messages and asset-exchanges between any two or more distinct parties. There may also be service-critical stages within the overall interactions of each of these ‘wrappers’ – for

140

example, see the distinct ‘Completions’ stages in ‘Strategy and lifecycle completion’ in chapter Services as systems (p.159).

Service flow content and the market-cycle

Values represent “that which defines the flow” – the overall values that frame the context of the flow, and in which the quality of the results will be assessed. This type of content is often a precursor to any interaction via either the Supplier-Relations (RS) or Customer-Relations (RC) cell, or direct with the Value-Proposition (VP) cell. Policies represent “that which directs the flow” – the decisions, rules and reasonings to guide subsequent activities that would (in principle) add value to the content of the flow. This type of content is often an outcome of any interaction via either RS or RC, or direct with VP, but also may be a prerequisite to an Event flow on a main-channel (CS or CC). Events represent “that which triggers the flow” – the triggers that mark the initiation of action on the content of the flow. This type of content is a precursor to a transaction on the main-channel (CS or CC), and will often contain information and

141

other content as part of the event-trigger. In conventional process-models, this would also represent the ‘start-event’ marker for the process. Completions represent “that which validates the flow” – the flags that mark the end of the flow, and the metrics that are used to verify satisfactory completion for all parties to the flow. This type of content marks the end of a transaction on the main-channel (CS or CC) – in conventional process-models this would represent the ‘end-event’ marker for the process – but also marks the start of the matching interactions on the return-channel (VO or VR). Trust represents “that which dominates the flow” – the feedback on the perceived value of the flow, and belief in future efficacy (effectiveness: efficient, reliable, elegant, appropriate, integrated) of equivalent future flows along this overall pathway. This type of content marks completion of a set of interactions or transactions on the return-channel (VO or VR). It would typically include metrics that verify customer-satisfaction and the like. The core-content of a flow through a Relations channel (RS or RC) will typically be bounded by Values and Policies wrappers. The core-content of a flow through a main-channel (SC or CC) will typically be bounded by Events and Completions wrappers. The core-content of a flow through a return-channel (VO or VR) will typically be bounded by Completions and Trust wrappers.

• What comprises the Value interactions for each flow for this service? • What comprises the Policies interactions for each flow for this service? • What comprises the Events interactions for each flow for this service? • What comprises the Completions interactions for each flow for this service? • What comprises the Trust interactions for each flow for this service?

142

• What assets, events, functions and other entities are involved in each of these interactions?

• What is the core-content ‘enclosed’ between each of these sets of ‘wrapper’ interactions, that is the primary exchange through each respective channel?

• Who or what is engaged in each of these interactions? Who is responsible for each?

Responsibility RACI is a standard checklist to identify responsibility and needs for engagement in a project or any item. There should always be one person who is uniquely responsible for any item; and, equally, every item needs one person who is uniquely responsible for it at all times. Look for any overlaps in responsibilities (often occurring in transitions between layers – for example, one person may have operational responsibility for an item, another has tactical responsibility, another the strategic responsibility). Look also for gaps in responsibilities, where no-one has apparent responsibility or where the responsibility has been nominally assigned but not actually taken up or enacted.

Note that simply assigning someone responsibility does not necessarily mean that that responsibility is taken up! – functional responsibility is an active choice, not an arbitrary label.

Also note that responsibility can only be held by a real person: a machine or an IT-box is not capable of taking responsibility for anything in any legal sense of the term. Hence, especially where IT or machines are involved, it may be necessary to follow lengthy trails of non-responsibility (or evasions of responsibility) in order to identify the actual responsible person. Finally, a person can only be responsible for something if they also have the authority and competence to make the required decisions. If they don’t have that authority or

143

competence, they cannot and must not be considered responsible or accountable for the item, and hence a further search will need to be made for someone who can have both responsibility and authority. (Note that mismatches of responsibility, authority and competence are very common, especially in dysfunctional organisations.)

RACI responsibility-model

Apply a RACI frame to identify responsibilities for each item, activity, event and decision within the service and its cells, within and for each flow or interchange, and equivalent responsibilities in and of each stakeholder:

• Who is responsible for this, and any changes to this? – “those responsible for the performance of the task”

• Who assists in this, and any changes to this? – “those who assist in the completion of the task”

• Who should be consulted about this, and any changes to this? – “those whose opinions are sought, and with whom there is two-way communication”

• Who should be informed about this, and any changes to this? – “those who are kept up-to-date on progress, and with whom there is (usually) one-way communication”

144

• Optionally, who does not need to be (or should not be) responsible, assist, be consulted and/or be informed about this, or any changes to this? (e.g. an executive does not normally need detailed reports about every minor operational change)

Opportunity and risk

SWOT: strengths, weakness, opportunities, threats

Next, do a SWOT assessment on the overall service, and on each of its cells, its flows and its links with each of its stakeholders, and on the links up and down the rows, from abstraction (redesign) to implementation.

For this purpose I would recommend my own extended variant of SWOT, called SCORE – Strengths, Challenges, Opportunities/risks, Rewards, Effectiveness – but I would have to admit that SWOT is better-known. For more details on SCORE, see the book SEMPER & SCORE, another volume in this series.

• What are the Strengths in this context? Which of these strengths – if any – is underutilised, or could be applied in other, even more effective ways?

• What are the Weaknesses in this context? What impacts could or do these have on operations, on tactics, on strategy? In what ways could these challenges be redressed or mitigated?

145

• What are the external Opportunities in this context? In what ways could these opportunities be exploited? What concomitant risks do each of these opportunities imply?

• What are the external Threats in this context, from what and/or from whom? In what ways could these risks be redressed or mitigated? What concomitant opportunities do these risks imply?

Effectiveness It’s also important to review service-content in terms of overall effectiveness. (The frame used here – as indicated by the secondary captions for each of the five domains above – also crosslinks to a framework on lifecycles, which is described in the next chapter.)

integrated(Performance)

past

appropriate(Purpose)far-future

elegant(People)

people-time

efficient(Preparation)near-future

reliable(Process)

NOW!

Multiple perspectives to review overall effectiveness

The aim here is that everything should fit in with and support everything else. These questions help to identify where they do support overall effectiveness, where they don’t and, if they don’t, what to do about it.

146

For the service overall, for each of its cells, and for each of its flows, we need to ask, everywhere, and in every way:

• Is it Efficient?– maximises use of resources, minimises wastage of resources • Is it Reliable?– predictable, consistent, self-correcting, supports ’single source of

truth’ • Is it Elegant?– clarity, simplicity, consistency, self-adjusting for human factors • Is it Appropriate?– supports and maximises support for business purpose • Is it Integrated?– creates, supports and maximises synergy across all systems

Application (Use the questions in the respective sections above to review all aspects of service-content.)

147

SERVICES AS SYSTEMS

Summary

Services contain other services and themselves form webs and networks with other services, so it can be useful to take a ‘systems’ view of a service and its context. This section introduces a small suite of systems-type tools and techniques to assess a range of integration issues, strategic concerns and other related themes that are relevant to service-models and Enterprise Canvas.

Details This final part of modelling with Enterprise Canvas will take us for a brief wander through the wilds of systems-theory, with an emphasis on recursion, flow, strategy and overall integration.

148

Some of this may perhaps be too abstract for use with a general business audience, though the diagrams should help to explain the concepts and their applications where required. These assessments apply especially in rows 3, 4 and 5, but much of it – especially the section on strategic completion – could also apply all the way up to row-1.

Enterprises as systems The point here is that everything is a system, is part of a larger system, contains other systems: systems ad-infinitum. In dealing with anything on the scale of an enterprise, we need to be to able to think in terms of systems and systems-of-systems if we’re to have any chance of making sense of what’s going on. Yet whilst formal ‘hard-systems theory’ has gained a well-deserved reputation for near-incomprehensibility, much of what we need here can be summarised in five simple, straightforward principles: rotation, reciprocation, resonance, recursion and reflexion.

Repeatability and systems-principles

Rotation is the simplest of the systems-principles. Any real-world system is too large and too complex to be seen in its entirety from one view alone: to make sense of it all, we need to be able to rotate through a variety of different views and

149

viewpoints, and merge those different views together to build a more complete picture of the whole. This is straightforward enough: every checklist does it. One of the key aims of the Enterprise Canvas is that it provides a suite of checklists to give us many different views on the service in scope. We just have to remember to use it, as a checklist, as a systematic rotation through multiple views.

• What checklists could be used in this context to build a more complete view of this service?

• How do we move between the different views and tests indicated by the checklist? What do we need to do to avoid becoming stuck on a single view as ‘the truth’?

• What checklists and checklist-items are missing from this view? What other views or checks do we need?

• How do we link all the different views together? Since all of them present some form of ‘truth’, how do we resolve the any conflicts that may occur between all of these different forms of ‘truth’?

Reciprocation and resonance are a matched pair of principles that apply mainly to flows. In a simple world, flows will all need to balance somehow: “for every action there is an equal and opposite reaction”, and suchlike. In that sense, flows need to be reciprocal; at the market level, there needs to be ‘fair exchange’, ‘quid pro quo’ – or at least a verifiable perception of that. Reciprocation is a key part of what we explore when we do an assessment of service-flow content. The complication is that although things do have to balance up somehow, the flows may not be a simple ‘tit for tat’. Often there will be delays in a feedback-loop, or translations from one form of energy to another – for example, financial donors to a

150

not-for-profit typically receive a return in the form of a different kind of satisfaction. In terms of point-to-point physics, each transaction can be seen as a simple win/lose; but when we take the resonance of those feedback-loops into account, win/lose turns out to be a special-case in a full spectrum between win/win and lose/lose. That last point applies especially in social flows and transactions – and frequently leads to ‘unexpected’ wicked-problems if we’re not aware of what’s actually going on. To help us make sense, we can use the Enterprise Canvas to describe resonance and reciprocation in the interactions and flows across the whole system, especially over time.

• How do we ensure that there is balance – reciprocation – across all flows for this service?

• Given that forms of value may change across the service, or between the relations-channel, main transaction-channel and return-channel, how do we keep track of these changes? How do we ensure that there is ‘fair exchange’ even when the form of value has changed?

• At what point do simple notions of balance – ‘double-entry life-keeping’ – become more of a hindrance than a help in understanding the flows of this service? At what point do we need to accept natural resonance – increasing or decreasing – within the flow?

• How would we create a resonance in a flow, to increase a desirable effect, or dampen (reduce) an undesirable one? And who decides which resonances are ‘desirable’ or ‘undesirable’?

• How do we ensure that changes in balance – such as created by resonance – are shared appropriately between all parties in the enterprise? Who decides how that

151

changing balance is to be shared? How can we ensure that those decisions are in line with the enterprise-vision?

Recursion and reflexion are another matched-pair that become particularly important when dealing with true complexity. Recursion will occur when the same pattern repeats, or is ’self-similar’, at different levels of the same system. A conventional reporting-hierarchy is recursive: the pattern repeats at different levels of management. A service-oriented architecture is recursive: the same concept of services – the same pattern of services – applies in much the same ways at every level of the enterprise. Reflexion is the inverse of this: if recursion means that every part in some ways reflects the whole, then we can also infer the whole – or some aspects of the whole – from within every part. Note, though, that it’s like the holograph, in that every discrete part of the image also contains all of the image, but in less detail – and that loss of detail can sometimes be misleading if we extrapolate anything out too literally. Within the Enterprise Canvas, one of the most immediate examples of recursion is that every cell within the Canvas is also itself a service. So the Supplier-Relations cell, for example, not only provides ’supplier-relations’ services on behalf of the service that we depict on the Canvas, but to do so it must also have its own Value-Proposition in presenting those services, it has its own Supplier-Channels and Customer-Channels (the latter rather than the former being how, in this case of Supplier-Relations, it actually delivers its services), it has its own Value-Creation in which it creates the value of those supplier-relations, and so on. And each of those sub-cells too have their own flows, some of them linking externally on behalf of the main service, others linking to other cells and sub-cells within the service:

152

The inverse is also true. Whenever we come across a business entity or function that delivers what we might interpret as ’supplier-relations services’, we need to ask who or what service it delivers these services for. We also need to look for and identify its matching Supplier-Channels, Value-Creation, Customer-Channels, Value-Outlay and the like that provide its ’sibling’ services in terms of the Enterprise Canvas. Typically, whenever we go ‘down’ a level into the recursion, we move closer towards real-world implementation; and whenever we go ‘up’ a level in the recursion, we’re usually also moving up a layer of abstraction, as described in the previous chapter on layers. In that sense, abstraction and recursion are closely linked within the Canvas – which is also another reason why abstraction (rather than, say, management-hierarchy) is the most useful framework for layering here.

• What patterns of recursion can you identify within the structure of the service and its flows? In what ways could you use such patterns to reduce complexity across the overall system? What advantages and potential problems are implied by those patterns?

• In what ways can aspects of the whole be seen reflected in any or many of the system’s individual parts? In what ways could you use such patterns to reduce complexity across the overall system? What advantages and potential problems are implied by those apparent patterns?

Impact of time-compression The spectrum of repeatability, from predictable to unique, can tell us a great deal about what skills are needed in any given context. However, there is an important rider to this, which relates to the amount of time available for decision and action.

153

Introducing this additional dimension in effect forces that simple linear spectrum into a more complex two-axis frame.

Repeatability, time and order

There are many other axis-pairs and interpretive frames that can be used with this popular layout for the repeatability-model, such as the well-known Cynefin framework – see my book Everyday Enterprise Architecture for a range of other practical examples.

The key point about this variant of the repeatability-model is that it describes what may happen at different timescales. The split between ‘order’ and ‘unorder’ is fairly straightforward:

• order: repetition of a rule or formula will always deliver the same results; there is an identifiable ‘right way’ or ‘best practice’ for any context; analysis is the most reliable approach; key driver is logic or ‘truth’

154

• unorder: repetition of a rule or formula will either not ensure the same results (Complex) or will never repeat the same results (Chaotic); there is no identifiable ‘right way’ or ‘best practice’ that will always deliver the same results in a given context; iterative experimentation is the most reliable approach; key driver is value or feelings

At different timescales, different options become emphasised. As ‘time for thinking’ becomes available, the emphasis shifts towards experimentation (Complex) or analysis (Complicated). At the extreme, with infinite time seemingly available, there tends to be a drift towards ‘analysis-paralysis’, or endless experimentation that seems to lead nowhere. But in the other direction, as time becomes more compressed into an increasingly-urgent “do it now!”, the available choices become squeezed into a narrow spectrum between simple rule-following, at one extreme, to a kind of impenetrable real-time improvisation, dancing with the chaos in a way that would be incomprehensible to anyone else – or even to those doing the work, in some cases. In effect, it present a savage split between the limited competence of the raw trainee – unable to adapt to anything outside of the rules – and the hyper-competence of the multi-year master – who has no time to explain – with no apparent means or time to learn how to move from one capability to the other. In practice, the Value-Creation and the main-channel interfaces – Supplier-Channels and Customer-Channels – tend to fall naturally into this latter time-compression: the nature of the work there is that there will be no time available to stop and think. Other cells will often fall into much the same pattern, simply from day-to-day pressures of work. Yet skills-development will only take place if there is sufficient ‘time-to-think’ to reflect on action. Hence it is essential that every service, and every cell in every service, is backed up by learning-processes – usually delivered via the

155

Validation and/or Coordination guidance-services. The aim would be that time-to-think is available before action – as planning – and time-to-think is available after action – as reflection on performance – so that there is no need to think during the real-time action of the service itself.

• What are the skills and capabilities required in the service? • If the service requires delivery in very short timescales, what checklists and other

Simple-domain tools and techniques are available to reduce the risk of falling into an unmanaged Chaotic state? What ‘master’-level skills are required in order to bring the service out of such a Chaotic state? From where are these skills available?

• What time is available for analysis and experimentation within the service itself? If none, where does planning and reflection take place? Who or what guides this planning and reflection?

• If there is no time within the service for planning, reflection or capability-development, and there are no links to outside services that can provide these, what impact does this have on the effectiveness of the service in the long-term, medium-term or even short-term?

Continuous lifecycles Another useful frame here – Five Elements – is a counterpart to the Effectiveness frame described in the previous chapter, that describes services in terms of continuous lifecycles. This is derived in part from Bruce Tuckman’s well-known Group Dynamics model of the project life-sequence: forming, storming, norming, performing, adjourning. In Five Elements, these align to Purpose, People, Preparation, Process and Performance. Here, though, the stages form a continuous cycle, conventionally starting at Purpose.

156

Performance(adjourning)reporting etc

Purpose(forming)

strategy etc

People(storming)

HR etc

Preparation(norming)

scheduling etc

Process(performing)

production etc

Five Elements: five phases in the continuing lifecycle

The same pattern will also repeat across an organisation, with different business-units enacting different parts of the cycle:

• Purpose: strategy, futures, business-intelligence, corporate identity, brand • People: HR, training, organisational development, narrative-knowledge, health

and safety, security • Preparation: planning, scheduling, project-management, procurement,

infrastructure, logistics • Process: production, manufacturing, sales [in a sales-context], any ‘service-

delivery’ function • Performance: book-keeping, performance-records, accounting, audit, archive; also

‘lessons-learned’ review Each grouping also has its own specific perspective on time: far-future, ‘people-time’, near-future, ‘now!’ and past respectively. It’s important to note these

157

differences in time-perspectives, because they can often lead otherwise ‘inexplicable’ clashes between the groups.

Five Elements and service-flow content

The service-flow content-dimensions – Values, Policies, Events, Completions, Trust – in effect form the boundaries between the phases in this overall cycle. Or, to put it the other way round, the Five Elements groupings identify the sets of activities that need to occur in order to deliver the respective node or dimension in the service-flow content. Linking together both the Five Elements set and the service-flow content-dimensions into a single sequence, we can also see how they link together moving ‘downward’ on the Enterprise Canvas, with Five Elements as the backplane and the service-flow content set as their expression to the service’s ‘outside world’.

158

Enterprise Canvas and continuous lifecycle

So for the service overall, for each of its cells, and for each of its flows, we need to ask:

• Who or what is responsible for the Purpose of this item? (This should link strongly with the Value-Proposition cell, for example, and also the ‘direction’ guidance-services.)

• Who or what is responsible for the People-issues for this item? (This is where the ‘validation’ guidance-services are likely to play a key part in the service and, for external links, the Supplier/Customer-Relations cells.)

• Who or what is responsible for the Preparation and scheduling for this item? (This should link strongly with the Value-Governance cell, and also the ‘coordination’ guidance-services.)

159

• Who or what is responsible for the Process and action of this item? (This should link strongly with the Value-Creation cell, probably the Supplier/Customer-Channel cells, and probably also the ‘coordination’ guidance-services.)

• Who or what is responsible for the overall Performance of this item, including completions and lessons-learned? (This should again link strongly with the Value-Governance cell, the Value-Outlay/Return cells, and also the ‘validation’ guidance-services.)

• Who or what is responsible for integration between all of these domains – such as in resolving clashes in time-perspective between the groups?

Strategy and lifecycle completion The Five Element model also provides an important view into the relationships between strategy, tactics and operations:

• strategy is about the relationships between the organisation and the enterprise, between the organisation and the people who work within it, and between the organisation and its various ‘external’ stakeholders – relationships which mostly centre around identity, belonging and feeling

• tactics is about translating those relationships into explicit plans for action in the near-future – activities which mostly centre around analysis and thinking

• operations or ‘execution’ is focussed on action in the immediate present – everything here will centre around doing

The overall flow of the activities-lifecycle passes through each of these modes in turn – which in practice means that an explicit balance needs to be maintained between them.

160

Strategy, tactics, operations: links to Five Elements

However, the modes also often represent fundamental differences in mindset and worldview – which can lead to serious problems if any one of the modes comes to dominate over the others.

Short-term, medium-term, long-term

161

We can perhaps see this most easily via a cross-map to the market-cycle. The Completions section of the cycle actually consists of three distinct stages – each of which offers a choice as to whether to continue in the cycle, or loop back to an earlier stage.

Short-term failure: operations mistaken for strategy

The ‘short-term’ version loops back to the next task as soon as the current main-channel task is complete, without checking for completion of anything coming back along the return-channel. This is typical for any production-oriented service, though can often work quite well if there is linkage to another service that can take over the main cycle at that point. The catch is that it must assume that there are no changes at all in the context, because it has no means within itself to adapt to change: if there is any change in the context, the service will usually fail. If an obsessive focus on ‘doing’ comes to dominate so much that operations itself is taken as ‘strategy’ – as in the fixed Five Year Plans of the old communist era, for example – then system-failure is guaranteed in the relatively short-term.

162

Medium-term failure: tactics mistaken for strategy

A more common source of failure-risk occurs at the second Completions-choice, which occurs early in the Performance phase. In a commercial context, this is the ‘monetisation point’, the point at which payment has been received, and in which the financial part of the transaction is complete: from the service’s perspective, a basic ‘satisfaction for self’ has been achieved. In services that are dominated by notions of ‘results’ – as is all too common in business – there is then a tendency to want to loop back straight away to a point somewhere within the Preparation phase, to set up the next transaction and get back to ‘monetisation’ as quickly as possible. This leads to a situation where relatively short-term tactics are mistaken for strategy – as in the classic pseudo-strategy of “our strategy is last year’s target plus 10%”. The problem is that the overall transaction – ‘satisfaction for all’ rather than solely ‘satisfaction for self’ – was never completed, there is no reaffirmation of mutual Trust, and the all-important reconnections with Purpose and People were never made – often dismissed as ‘unnecessary overhead’. The result is an initially slow yet

163

accelerating deterioration of trust within the market, and a widening disconnect from the enterprise and the people within and beyond the organisation – setting the stage for an increasingly desperate yet apparently ‘inexplicable’ slide into irrelevance. So this too can be an all-but-guaranteed recipe for service-failure over the longer term. The reality, though, is that the full Five Elements cycle can be very time-consuming, and a too-frequent review of Purpose and even of People will not only be an excessive overhead in most contexts, but will soon become an extreme annoyance as well. In practice, especially in most production-oriented environments, it usually is safe to take those two ‘short-cuts’, to keep the overall flow moving as quickly as possible, for everyone’s satisfaction. The keyword, though, is “usually”: the trick is to know when it’s safe to do so, or when we do need to work our way through all of the Completions, carefully, and in sequence. There are key questions there that need to be asked in any service-design with the Enterprise Canvas.

• Is there a choice in the service’s handling of Completions where it can short-cut back to start straight away on the next task? If so, to what other service is the responsibility passed to handle the remainder of the service’s Completions? What processes and decisions ensure that the service does continue on through the whole of the Five Elements cycle at appropriate intervals?

• Is there a choice in the service’s handling of Completions and Performance where it can short-cut back to set up the next transaction? If so, to what other service is the responsibility passed to handle the remainder of the service’s Performance activities? What processes and decisions ensure that the service does continue on through the whole of the Five Elements cycle at appropriate intervals?

• What decisions and processes are needed to ensure an appropriate balance at all times between strategy, tactics and operations – between feel, think and do?

164

Application (Use the questions in the respective sections above to review all aspects of services-as-systems.)

165

EXAMPLE PATTERNS

Summary This section describes four example-patterns that summarise a range of ways to use the Enterprise Canvas in typical enterprise-architecture assignments: the business context for a for-profit business; a not-for-profit charity; IT service-management with ITIL; and a BPMN process-model.

Details Example: for-profit business

I’ll admit that this example is very much a stereotype, though it’s actually a typical outcome of Taylorist ’scientific management’ and current commercial law, especially in the US. In this structure, ‘the enterprise’ is deemed to be synonymous with ‘the organisation as a whole’ (the boundary shown by the dotted line). By custom and even by law, monetary return is defined as the only meaningful form of value; and it’s assumed that the only reason that the organisation exists is to make money for the stockholders, the purported ‘owners’ of the enterprise. So the enterprise vision is straightforward, and exclusive: ‘make money’ from the market, as much of it as possible, any way that we can.

166

Overview Canvas for (dysfunctional) for-profit business

There is no real link – or even awareness – of a shared-enterprise beyond the organisation: relations with suppliers and customers alike are characterised by a combative ‘us against them’. All of the guidance-functions are subsumed into ‘direction’, all of which is possessed exclusively by the executive management on behalf of the stockholders. ‘Validation’ and ‘coordination’ are replaced by ‘command’ and ‘control’ respectively, and often explicitly disconnected from anything beyond the organisation – such as typified by an insistence on proprietary standards and the ‘not invented here’ syndrome. Within the service-functions represented in the main Canvas, the natural boundaries between the cells tend to be exaggerated and reinforced as distinct silos. There is often a rigid separation between development and production, and even

167

more so between line-management against all other parts of the service: the classic Taylorist separation between ‘management’ and ‘workers’. Line-management also often claims the entire return-channel as its own private domain, asserting rigid control over budget and all monetary matters, and using the resultant scarcity of resources as a substitute for proper governance. The anomalous position of ‘marketing’ – stuck halfway between the Value-Proposition (‘product-development’) and Customer-Relations (’sales’) cells – is a direct outcome of the disconnect from any shared extended-enterprise. Since no connection exists to link the organisation to a broader enterprise-vision, there is no available option for a ‘pull’-based marketing model via a shared Value-Proposition; the only alternative is product-development, in essence derived from internal assumptions about ’something we can sell’. Without any direct engagement in the value-proposition, the organisation’s potential customers are unlikely to feel much inherent engagement in the product; hence it becomes the unhappy role of marketing to attempt, via ‘push’, to manufacture a sort-of-‘relationship’ with customers where no real reason for any such relationship actually exists. Overall, not a happy picture; certainly not a very effective one. It is also, unfortunately, very common. Oh well… Yet a comparison of this dysfunctional structure with the generic Enterprise Canvas indicates what can be done to improve matters – of which the most important is to break the delusion that the organisation ‘is’ the enterprise, and instead connect the organisation with the shared-vision and shared values of its broader market and extended-enterprise.

Example: not-for-profit charity This is somewhat less of a stereotype than the previous example, but still very much generic.

168

Note that much the same principles as here should apply to the government context, since that too is nominally ‘not-for-profit’. In practice, though, the ‘guidance’ functions there often tend to be subsumed into the executive, much as in the dysfunctional for-profit model, and with much the same dysfunctional results.

Overview Canvas for charity

In this example, the charity aims to deliver a service to its recipients, yet to do so must engage donors to provide the resources needed in order to deliver those services, and hence must also act as a direct and explicit intermediary between donors and recipients.

The same principles apply to almost any charity, but charities in practice often have very complex relations between many different types and roles of providers; for this example we’ll keep it simple, and imagine a charity that provides clothing to victims of natural disasters.

Here the boundaries of the organisation (shown by the dotted-line) may include the ‘direction’ guidance-functions – as in a conventional for-profit business – but the

169

‘coordination’ and ‘validation’ functions must extend beyond the organisation itself. On the ‘coordination’ side, this charity must coordinate its service-delivery with other charities and services that operate in the same disaster-zone – medical, shelter, food, rescue, security and suchlike; and on the ‘validation’ side, the charity’s services and activities will only make sense to donors and recipients alike if they connect to a shared-vision such as “keeping people safe, warm and comforted after an emergency”.

Many charities start off with something like a ‘product-development’ model, designing support-services of some kind as a metaphoric equivalent of ’something we can sell’, and then delivering those services. As a ‘push’-type activity, though, it may be difficult for it to make sense even to the nominal recipients, and unless the connection is made to a ‘higher cause’ that will engage others, the charity will soon run out of resources, and fail. All the problems and potential mistakes faced by commercial ’startups’ apply just as much to charities and other not-for-profits: the only difference is that resources and ‘profit’ may be measured in a different way.

The Value-Proposition here is straightforward: given the shared-vision, there is a clear need for clothing to replace items lost in natural disasters – a need which will be all too evident to the intended recipients, and will also make immediate sense to potential donors. This in turn implies the need for a service to deliver such clothing in a disaster-recovery context (the Value-Creation cell, here described as ’service-operation’); and for some form of management, in donor locations, on the spot in the disaster-affected region, and in logistics in between (the Value-Governance cell, here labelled ’service-management’). The linkage to value and enterprise-values is therefore reasonably clear, though we will have to drill down from this very simple row-2 model all the way to a row-5 detailed-implementation model to get a proper picture of what all of this would entail in practice. On the donor side, we need to explain what the need is, and why it should be seen as important (Supplier-Relations, here labelled ’cause-marketing’), and encourage

170

two-way conversations that will engage people directly in the enterprise-values and thence in the charity’s value-proposition. Assuming that this engagement does happen, we’ll also have created the space for transactions to occur, much like a supplier-relationship in a commercial context – in this case, the donors supplying either clothing, or money to assist in delivery of that clothing, or both (Supplier-Channels, here labelled ‘fundraising / collection’). On the recipient side, we need to identify appropriate ‘customers’ for our clothing service. Given that this will take place in a disaster-recovery context, gaining their trust will also be crucial here – hence, again, the importance of two-way communication to create engagement in the shared-vision (Customer-Relations, here shown as ‘recipient-relations’). We then need to match their needs with the available resources, both on-the-spot and via requests further back along the charity’s logistics chain (Customer-Channels, here labelled ’service-delivery’). In both cases the return-channel (Value-Return and Value-Outlay, here labelled ‘recipient-results’ and ’cause-results’ respectively) is significantly different from that in a commercial context. For a business, ’success’ is a profitable sale; income and costs alike can, it seems, all be reduced to monetary metrics, which makes the measurement of ’success’ a mere matter of quick calculation – all very simple and straightforward. But as soon as we realise that there are other forms of value in play than money alone – as is immediately evident here, if perhaps less so in a commercial context – then we need to look for a much broader definition of ’success’, in fact drawn directly from the shared-values of the extended-enterprise. In this case the charity would probably not expect any payment from the recipients for the clothing. What will matter much more instead will be some form of proof that the service-delivery was in accordance with the shared-values of the enterprise – hence, for example, all those photos of happy, smiling, well-clothed children that

171

we would expect to see passing through the return-channel, to appear as ’cause-results’ on the charity’s website and in reports to donors. The return-channel closes the loop of value; and its balance overall, across all relevant forms of value, provides the proof that the organisation has indeed delivered added value in terms of the extended-enterprise’s vision and values. Note that it’s not true that money doesn’t matter here: it does. In fact it matters a lot, not least because potential donors are very quick to withdraw support from any charity that is perceived to carry too much overhead in any form, monetary or otherwise. The key point here is that money is not the only form of value in play in the overall transactions of the charity – a point which, in an architectural sense at least, also applies in every ‘for-profit’ organisation as well.

Example: ITIL IT service-management For this next example, let’s pick on something more in the mid-range: IT service-management within a large organisation. The typical reference for this is Version 3 of ITIL, the IT Infrastructure Library. This standard describes service-management overall in terms of five distinct strands: Service Strategy, Service Design, Service Transition, Service Operation, and Continual Process Improvement. We can map those core ideas onto the Enterprise Canvas, and see what we get in terms of an overall pattern for service-management. The result shows that it does all fit quite well. One immediate point is that the definitions of ‘customer’ and ’supplier’ are fairly fluid here: many actual stakeholders will take both types of roles at various times, so it definitely does help if – as the Canvas allows us to do – we take a symmetric view of the respective relations, main-channel and return-channel interfaces.

172

suppliersuppliersupplier

supplierrelations

“the right IT services, when we

need them”

supplierchannels

IT service-management

activitiescustomerchannels

customerrelations

value-outlay, incl. costs

governance of service-

managementvalue-return, incl. billing

coordinationdirectionvalidation

contactin

‘customer’ role

nextlayermgmt

suppliersuppliersuppliercontact

in‘supplier’

role

Multiple layers of abstraction / implementation

Many contacts in multiple ‘supplier’ / ‘customer’ roles

Many qualitative concerns: availability, reliability,

security, ‘green IT’ etc

Many coordination concerns: run the business, change the business, develop the business

Overview Enterprise Canvas for IT service-management

Another key point is that it does depend strongly on a clear value-proposition, here summarised as “the right IT services, when we need them”. All of the ITIL processes revolve around that core idea, and the values that lie behind it. The ITIL specification helps in this, too: for example, in describing Service Strategy, the Overview document states:

The service strategy of any service provider must be grounded upon a fundamental acknowledgement that its customers do not buy products, they buy the satisfaction of particular needs. Therefore, to be successful, the services provided must be perceived by the customer to deliver sufficient value in the form of outcomes that the customer wants to achieve.

173

Achieving a deep understanding of customer needs, in terms of what these needs are, and when and why they occur, also requires a clear understanding of exactly who is an existing or potential customer of that service provider. This, in turn, requires the service provider to understand the wider context of the current and potential market places that the service provider operates in, or may wish to operate in. A service strategy can not be created or exist in isolation of the over-arching strategy and culture of the organization that the service provider belongs to. The service provider may exist within an organization solely to deliver service to one specific business unit, to service multiple business units, or may operate as an external service provider serving multiple external businesses. The strategy adopted must provide sufficient value to the customers and all of the service provider’s stakeholders – it must fulfill the service provider’s strategic purpose.

All of this requires very strong linkages beyond the service itself – almost the exact antithesis of the Taylorist-style model for the ‘for-profit business’ example above. In the Enterprise Canvas, these linkages are provided by (or rather, modelled as) the guidance-services: the structured layers of ‘validation’, ‘direction’ and ‘coordination’, as described in chapter Service guidance (p.90). To model ITIL in its entirety, we would probably create a separate Enterprise Canvas at row-2 for each of the five major service-streams, shown in parallel on a single diagram, and linked upward to the organisation (row-1) and the extended-enterprise (row-0). We would then expand downward, into a more detailed set of row-3 models (some of which would be shared across two or more of the ITIL service-groups), and then downward again to row-4 and beyond. But it’s clear that it does all fit well: a very useful exercise for any group of enterprise-architects with suitable time to spare, perhaps?

174

Example: BPMN process-model This one is perhaps a bit unfair, but it is a pattern, and one that will help to demonstrate why there should be serious concerns about the limitations and incompleteness of so much current so-called ‘enterprise-architecture’. To illustrate this, let’s return to the simplified BPMN diagram from the chapter on Service flows (p.79).

Simple BPMN model of account-creation process

The process-model purports to describe the service of creating an account – in other words, something that we would expect to model on the Enterprise Canvas. So let’s map this onto the Canvas, and see what we get:

175

Derived Enterprise Canvas for account-creation service

For which the short answer is “Not much”… only a tiny subset of what we actually need in order to make sense of it as a service:

• There’s no concept of any precursors to transactions – the content and interfaces for the usual Supplier/Customer-Relations cells.

• There’s no concept of any return-channel – the content and interfaces for the Value-Outlay/Return cells.

• There’s only the most minimal of content for Value-Governance, namely the small part that deals with the decision-making and business-logic with the execution of the process.

• There’s no ‘why’ anywhere in the process-model – no Value-Proposition, no known reason why this particular process and service should even exist.

• There’s no linkage anywhere to ‘the big picture’, the guidance-services that link this process to the various qualitative concerns, or even to the inter-service

176

choreography need to coordinate the execution of the complete end-to-end business-process.

(To be fair, the equivalents of ‘Supplier’ and ‘Customer’ and their interfaces would be represented by headers in parallel swimlanes – but that still doesn’t tell us anything about the coordination of the full end-to-end business-process.) The Canvas itself doesn’t show the assets (the account-record, for example) or the triggering events, or the location (something else that’s absent from the BPMN model); but all of those are items that we would expect to pick up straight away by applying a service-content assessment (see Service content, p. 116) to the respective cells (especially the Value-Creation cell, here shown as ‘process execution’). Likewise a service-flows assessment of the interfaces (see Service flows, p.79) would tell us much more about the respective flows than we have here in the BPMN model. I know this example has been a bit unfair, somewhat of a straw-man. But what worries me is that I’ve seen all too many examples where BPMN diagrams and the like have been presented as ‘architecture’ – even as ‘enterprise-architecture’… which it isn’t. At all. What this pattern does show us, though, is how to use a BPMN diagram to populate this part of the base-content for an Enterprise Canvas – and then go on from there to fill in all of the blanks, to build a complete model of the service that we need for the required purpose.

177

INTEGRATION WITH ARCHITECTURES

Summary One promise, back in the introduction, was that the Enterprise Canvas can provide a unifying frame through which all the different model-types at the different levels can link together and support each other. In this section we skim through a wider range of model-types that are in common use in or around enterprise-architectures, to show how the Canvas could be used with each of them to support an overall integration across the architecture.

Details (Note: See the ‘Other resources’ section in Appendix C: Sources and resources (p.211) for links and references to models and techniques mentioned below.)

Architectural frameworks and model-types VPEC-T – Values, Policies, Content, Events, Trust – is probably one the most useful frames with which to assess the various flows in an information-system. VPEC-T is described in detail in the book Lost In Translation, by Nigel Green and Carl Bate. In adapting VPEC-T for use with Enterprise Canvas, as its ‘service-flow content model’, I made one important change, in that ‘Content’ is reframed as ‘Completions’. In the original, ‘Content’ included the content of the flow, because it was in the context of information-systems, where the information is the content. In the adaptation, though, the effective content may take many forms, which may or may

178

not be information (‘virtual’). To resolve this, the content is handled by the related Process phase in the Five-Element cycle, and the former ‘Content’ dimension acts as a marker for the end of content handling – in that sense, similar to the role of the ‘End Event’ in BPMN process-model notation. I then expanded this closure to include post-transaction ‘follow-up’, to act as the bridge between the Process and Performance phases in the Five Element cycle. This adaptation works well, especially with Enterprise Canvas – but it should be noted that it is not the same as the original, and hence should not be called ‘VPEC-T’. ArchiMate is a standard notation for enterprise architectures, originally developed in the Netherlands and now adopted as an international standard by The Open Group. (There is an intent that in the medium-term it should extend to cover a true whole-of-enterprise scope, but at present it’s still mostly constrained to IT-oriented architectures only.) It defines architectures in terms of the usual three IT-oriented ‘layers’ (Business, [IT] Applications and [computer-based] Technology) and three interlinked ‘vertical’ emphases: Static Structure (data etc), Behaviour (services and functions) and Active Structure (roles and interfaces). From a Canvas perspective:

• Archimate layers: ‘Business’ primarily sits in the row-2 to row-3 Canvas layers, whereas ‘Application’ and ‘Technology’ sit in parallel domains in the Canvas row-3, row-4 and sometimes row-5 layers.

• ‘Static Structure’: data-items and other artefacts would translate to content that is held and/or manipulated within the Canvas cells or exchanged via the Canvas flows (it would be considered primarily as ‘Content’ in VPEC-T terms, or as ‘assets’ in Enterprise Canvas terms).

• ‘Behaviour’: each service in each Archimate layer would typically be modelled on its own Canvas, whilst processes and functions would typically sit in the Value-Creation cell of the respective Canvas.

179

• ‘Active Structure’: roles would typically translate as external parties, interfaces as Canvas flows, and components (‘device’, ‘application component’, ‘network’ etc) as part of the respective Supplier/Customer-Channel cell.

TOGAF (The Open Group Architecture Framework) is another well known framework in IT-oriented ‘enterprise’ architectures that includes a well-defined process (Architecture Development Method [ADM]) and an underlying metamodel. The metamodel is less well-structured than Archimate’s, but much the same general principles apply as for Archimate: in fact there is an ongoing effort within Open Group to align the two models, so any differences should fade away in the relatively near future. The ADM works well with the Enterprise Canvas, but in its standard form is still very IT-oriented and almost unusable beyond IT; over the past few years, though, I’ve done a lot of work to adapt it for use at a whole-of-enterprise scope, as documented in some of my books such as Bridging the Silos and Doing Enterprise Architecture. The Zachman Framework is probably the ‘granddaddy’ of all enterprise-architecture frameworks, and a valuable counterpart to the Enterprise Canvas. (The standard version is unfortunately still somewhat IT-centric – for example, the only asset-type (‘What’) listed is Data, the only decision-type (‘Why’) is [IT] Business-Rule – and needs some modification to be usable for whole-enterprise architectures.) The Enterprise Canvas layers are an extension of the Zachman layering, and directly compatible with it; and as shown in chapter Service content (p.116), a much-modified single-row version of Zachman is used to assess content and structure of a Canvas and each of its cells. VSM, Stafford Beer’s ‘Viable System Model’, was one of the core inspirations for the Enterprise Canvas. Although the original VSM focussed mainly on information-

180

flows, the same concepts can be applied to flows of any asset-types, both simple and composite. On the Canvas:

• VSM system-1 (operations or service-delivery): represented by the nine-cell core of the Canvas

• VSM system-2 (coordination): represented by the ‘coordination’ guidance-service (upward-pointing triangle)

• VSM system-3* (audit): represented by the ‘validation’ guidance-service (downward-pointing triangle)

• VSM system-3 (planning and control), system-4 (near-future) and system-5 (far-future): represented by the ‘direction’ guidance-service (square)

Beer’s concept of an algedonic high-priority feedback-path that can bypass the normal channels is extremely important, and should be considered when assessing any or all of the Canvas flows. For more information on the standard model and its usage in business, see Patrick Hoverstadt’s The Fractal Organization; for more on its adaptation for service-oriented whole-enterprise architectures, see my book The Service-Oriented Enterprise. Context-space mapping is the actual framework and process on which the Enterprise Canvas is based, and is described in more detail in my book Everyday Enterprise-Architecture. The core of it comes down to just four keywords:

• sensemaking – making sense of the context • strategy – deciding what to do with we’ve discovered • structures – we look for patterns, for structures, for something that’s stable

enough for us to build something on it or with it or around it • solutions – we identify and/or define the detail of what we’re going to do within

the chosen context

181

The underlying process draws strongly on John Boyd’s OODA (observe, orient, decide, act) model for agile problem-solving, crosslinked to a concept of sensemaking domains derived from my book Inventing Reality (originally published in 1986). In context-space mapping, we choose a base-frame as a core-model, and then cross-map to other compatible model-types whilst we ‘go for a walk’ – metaphorically speaking – through all of the different perspectives offered by the base-model and the cross-maps. The Enterprise Canvas was designed for use as a base-map in context-space mapping; other useful base-maps or cross-maps include modified-Zachman framework, Cynefin-categorisation, RACI and SWOT, and the Five-Element lifecycle and effectiveness frameworks.

Strategic frameworks and model-types The Business Model Canvas was in some ways the inspiration for this work, and the Enterprise Canvas is intentionally designed to be compatible with it. As shown in Appendix B: Working with Business Model Canvas (p.201), business-models developed with Business Model Canvas can be mapped directly onto Enterprise Canvas for expansion ‘downward’ toward implementation, and ‘upward’ for verification of alignment with the vision and values of the shared-enterprise. The book Business Model Generation by Alex Osterwalder et al. could well be regarded as an essential companion for any work with the Enterprise Canvas, especially at a row-2 or row-3 level for business-architectures. The OMG/BRG Business Motivation Model provides a standard framework to assess business drivers and business goals, and would particularly apply to the XD flow between the core Canvas and the ‘direction’ guidance-services. Be warned, though, that its method for definition of ‘vision’ – which should be the key to the entire enterprise – conforms almost exactly to how not to frame an enterprise-vision, and in practice is all but guaranteed to cause failure, especially over the longer-term.

182

To avoid major architectural problems, use the more functional framing for shared-enterprise vision, as described in this book. Other common strategy-frameworks that would work well with the Enterprise Canvas include Porter’s Five Forces model, Blue Ocean Strategy and the ubiquitous SWOT. In each case we would typically use the framework to assess the service or organisational unit in the Canvas, comparing it against others (such as for competitiveness analysis) or assessing the flows between the service and other players in the shared-enterprise (supply-chain partners, competitors etc). SWOT would be used to assess strengths, challenges, opportunities and the like in the usual way, on the service as a whole, on individual cells, on flows, and on stakeholder-relationships, as summarised in the chapter on Service content (p.116).

Structural and operational frameworks and model-types Industry-specific structural frameworks such as SCOR (supply-chain), eTOM (telecoms) and ITIL (IT service-management) fit well with the Enterprise Canvas: each model describes its context in terms of services, each of which – with its relationships to other services – would be a candidate for modelling on a Canvas. The main value of modelling with Enterprise Canvas is that it adds distinctions between types of flows that occur before, during and after the main service-transactions, and also documents the necessary ‘guidance-service’ linkages to overall direction, cross-functional coordination and whole-of-enterprise values. SCOR is a layered, hierarchical model whose structures map to Enterprise Canvas as follows:

• SCOR’s levels 1, 2 and 3 correspond approximately to the Enterprise Canvas rows 2-4

183

• the SCOR level-1 structure of Source / Make / Deliver corresponds almost exactly to the Enterprise Canvas linkage to the supply-chain: SCOR ‘Source’ corresponds to EC ‘Supplier-Channels’ flow and cell; SCOR ‘Make’ corresponds to EC ‘Value-Creation’ cell; SCOR ‘Deliver’ corresponds to EC ‘Customer-Channels’ cell and flow

eTOM is another layered model: eTOM’s levels 0 to 3 correspond approximately to the Enterprise Canvas rows 1-4. As a matrix structure, services are defined within intersecting cells of the matrix, as well as within the row/column overlays themselves, but in each case the respective service and its relationships can be mapped onto its own Canvas. At the highest level, the eTOM ‘Strategy Infrastructure and Product’ grouping has strong links to the ‘direction’ and ‘coordination’ guidance-services modelled in the Canvas, whilst the eTOM ‘Enterprise Management’ grouping is in part shared across the ‘direction’ and ‘validation’ guidance-services; the eTOM ‘Operations’ grouping summarises what happens within the nine-cell core of the Canvas. Note too the strong emphasis in eTOM on ‘Customer’: this would especially be linked to the ‘Customer-Relations’ cell and flows on the Canvas. We reviewed a mapping for ITIL onto the Enterprise Canvas in Example patterns (p.171). At the topmost level (row-1) there might be a single Canvas for ’service-management’, but at row-2, where relationships come into the picture, we would need to model each of the five main service-groups as a separate entity – in other words a separate Canvas for each. We would then devolve downwards as required, detailing each of the services first in generic (row-3) and then more context-specific (row-4) form. The ISO-9000 quality-system international standard aligns almost exactly with the Enterprise Canvas layers:

184

• ISO-9000 ‘vision’ layer: Enterprise Canvas row-0, row-1 • ISO-9000 ‘policy’ layer: Enterprise Canvas row-2, generic part of row-3 • ISO-9000 ‘procedure’ layer: Enterprise Canvas detail of row-3, generic of row-4 • ISO-9000 ‘work-instruction’ layer: Enterprise Canvas detail of row-4, row-5

Balanced Scorecard is a useful frame to apply across the Canvas, but especially in the Value-Governance cell, which is where performance data and post-transaction records should naturally accumulate. It may be useful to augment or review Balanced Scorecard’s four standard perspectives – Financial, Internal Business Processes, Learning & Growth, and Customer – with other themes from enterprise vision and values, as appropriate. The single most important point, especially in a commercial for-profit business, is to loosen the stranglehold of finance-centric metrics, and to instead cover the full range of meanings of ‘value’ that apply in the shared-enterprise. Standard review-processes and process-improvement models such as Deming/Shewhart PDCA (Plan/Do/Check/Act), Root-cause analysis, Value-stream mapping and, where appropriate, Six Sigma, can all be usefully applied to the models developed on a Canvas, and in some cases modelled in relation to the activities shown on the Canvas. Conceptually and operationally, they belong as part of what the Canvas would model as its guidance-services – in practice usually a collaboration between the ‘validation’ and ‘coordination’ services. Note that in general Six Sigma should not be used unless the service on the Canvas handles literally millions of nominally-identical events.

Summary There are many other model-types used in enterprise-architecture and related disciplines. In many if not most cases they can either be used with the Enterprise

185

Canvas via direct cross-mapping – as per context-space mapping – or as a secondary analysis of what shows up in cross-maps on the Canvas. The simplest suggestion is: try it and see.

186

RETHINKING VISION BOTTOM-UP

Summary This section describes five examples where an alternate business model – or even an alternate enterprise – may be suggested via a re-evaluation of some of the organisation’s existing assets and capabilities. The Enterprise Canvas concept of an enterprise-vision provides the central core for this re-evaluation.

Details For most of this book we’ve been working top-down, starting from the most abstract layer, the ‘extended-enterprise’. But we do need 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. So it’ll be useful here to work with some examples from an article in IndustryWeek magazine, ‘Assessing Product Innovation Assets: What’s In Your Attic?’, to explore how 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

187

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 see how this works in terms of enterprise-vision and the Enterprise Canvas. The examples here are Swatch; Mars M&M customisation; Oceaneering animatronics; Play-Doh; and Nokia. (The middle three examples are from the IndustryWeek article – the respective quotes appear below.) In each case we’ll assess the context and the trigger for change; the relationship between the new market and the old; the role of and impact on technology; and the impact on enterprise-vision, echoing back down through the organisation itself. For Swatch, the trigger for urgent change was the shift in watchmaking from fine mechanical-engineering to digital displays and thence to digital movements. By the late 1970s the Swiss watchmaking industry – with a long tradition of unsurpassed engineering excellence but at high price, even in the mid-range – had been decimated by Japanese competition. The only apparent market that remained was for luxury craftsman-watches, and even that seemed under threat. In the early 1980s Nicolas Hayek combined business-restructure, technological innovation and radically different marketing to reframe the Swiss watch-industry – most of it under the new ‘Swatch’ brand – and reclaim its previous preeminent position. The market for the new type of watch was actually a new ‘Blue Ocean’ niche, presenting a new concept of the watch as a low-cost, almost transitory fashion-statement, where the notion of ‘the watch’ is linked less to the raw function of timekeeping than to the statement about self. In effect, this is actually closer in concept to the ‘luxury’ end of the market – both markets are more about the joy of time and relationship to time, rather than time itself.

188

New technology included the use of plastics and ultrasonic welding, and an almost Taylorist approach to manufacturing and reduction of number of components. This experience was also carefully echoed back into the ‘old’ Swiss-watch industry, retaining its ‘craftsman’ focus but combined with lessons-learned from bulk-manufacture. The marketing for each of the sub-markets is different, yet interestingly the enterprise remains the same, if anything becomes more explicit, as something like “expressing the joy of time”.

Mars has had the technology to write “M&Ms” on little candies without smudging for decades. Recently, it created a multimillion dollar business using the same machine to let people write customized messages on their M&Ms.

The trigger for what is now MyM&Ms was an idea from within Mars’ ‘Advanced R&D’ unit – not the marketing department. The new market (gifts, promotions, special events) is significantly different from the regular market for M&Ms (retail candies / sweets), but leverages strongly from the main market in that the underlying product is well-known – in fact the ‘unique selling-proposition’ largely depends on the idea that this is a special personalised version of something that is not new. The technology is actually much the same as in the main market: real-time labelling of mass-produced product. The main difference is that the new version of the labelling-technology permits mass-customisation. The market would not exist without this mass-customisation technology. The core enterprise is significantly different from that of the main Mars company: although the enterprises are related, the focus here is on the customisation rather than on the underlying product (a point emphasised by the fact that Mars are also

189

starting to provide mass-customisation of others of their products). The Mars website describes core-principles but no explicit vision-descriptor; it’s notable, though, that MyM&Ms is marketed through its own distinct website. The probable enterprise-descriptor for MyM&Ms would be something like “celebrating who we are”, compared to a probable main-organisation enterprise of something like “the enjoyment of small moments in the everyday”.

Oceaneering once only applied its hydraulic technology to deepwater remote operated vehicles and other oilfield related products – that is until the company met with some Hollywood executives who wanted to use the technology to power large dinosaurs for Jurassic Park. Revenues from the entertainment industry now make up over 15% of Oceaneering’s top line.

As described above, the trigger for the new market appears to have been a chance meeting, or a cross-connection made by someone within the entertainment / animatronics industry rather than by the company itself. Functionally, the new market is very similar to the old, namely specialist engineering applications for hydraulic technologies and control-systems. The main difference (as with their aerospace engineering applications) is that the application itself is outside of their main area of expertise in marine and underwater systems for oilfields, and hence will require much closer collaboration with the end-client. The technology is essentially the same as in their main market – if anything, is actually simpler, or at least for use in less-extreme physical environments. The enterprise can remain unchanged as long as the focus is on the activity (i.e. engineering) rather than on the application or purpose of that activity (oilfields or animatronics or space any of their other ‘advanced technologies’ areas).

190

Unfortunately their ‘About’ page includes a ‘Mission Statement’ that is an almost perfect example of what to not do in an enterprise-descriptor: “Oceaneering’s mission is to increase the net wealth of its shareholders by providing safe, cost-effective, and quality-based technical solutions satisfying customer needs worldwide”. And it seems clear that the emphasis of identity is very clearly on the main application: “Oceaneering is a global oilfield provider of engineered services and products primarily to the offshore oil and gas industry, with a focus on deepwater applications”. The animatronics section does not even rate a mention anywhere in that description: “Through the use of its applied technology expertise, Oceaneering also serves the defense and aerospace industries”. Despite the Industryweek reference, and the apparently sizeable contribution to corporate income, the animatronics application appears to be a poor fit with Oceaneering’s current identity. If that is the case, it should almost certainly be split off as a separate-but-linked enterprise, much as in the relationship between MyM&Ms and the parent Mars Group.

Play-Doh used to be a wallpaper-cleaning product with dwindling sales. All it took was the willingness to change markets and a clever revenue-sharing agreement with Captain Kangaroo to convert Play-Doh into one of America’s most successful children’s toys.

As described on Wikipedia, the trigger for the new market was a request in 1955 from a school-teacher – a relative of the company founders – for “a safe and fun modeling clay substitute”; they sent her “a sample of a non-toxic compound used to clean wallpaper”, which the children used to make Christmas decorations, with results that were described all round as “a hit”. The new market is fundamentally different from the old: from trade cleaning-products to children’s toys.

191

The technology is essentially unchanged; in later developments the formula included colourants and changes to improve plasticity, but the basic bulk-mixing technology remains almost identical. The enterprise is radically different, largely following the change in market: from something like “effective and reliable cleaning for the building-trade” to “safe and fun modelling” (an enterprise-vision which does not restrict the market solely to children). Much as with Mars and MyM&Ms, but even more so in this case, the base-technology is unchanged but the enterprise-vision is so different that they must be operated as separate divisions or even formally-separate organisations. Over the years, the production and marketing for Play-Doh has been acquired and transferred more and more into a ‘toy’-oriented enterprise. Meanwhile, the original parent-company Kutol continues as a manufacturer of cleaning-products specialising in hand-hygiene. Nokia is perhaps the most extreme example of an organisation that has mutated and reinvented itself and its enterprise many times over the decades. The Wikipedia page shows it starting out in the mid-1860s as a lumber company – initially named after the town in which it was located, Nokia – and later moving into electricity-generation in the 1900s. The trigger for that change was recognition of market-opportunity. In the 1910s the organisation was essentially taken over by another company, a rubber-products manufacturer, which later, in the 1920s, acquired a cable-manufacturer. The trigger in the first case seems to be commercial opportunity, retaining the name because of the location; the acquisition would have been driven by parallel interests, in that rubber-products would have been used for electrical insulation.

192

In the 1930s, and onwards into Finland’s engagement in the Second World War, Nokia changed into more of an industrial conglomerate, including products such as paper, bicycle and car tyres, footwear, cables, televisions and other consumer-electronics, electricity-generation equipment, communications equipment, plastics, aluminium and chemicals. All of these products and related business-lines can be traced back to the four roots of the corporation: lumber, electricity-generation, rubber and cables. However, the spread of market and scope of enterprise had become far too broad to be practical, causing major financial losses in the late 1970s and 1980s, and arguably a key contributing factor in the suicide of the then CEO, Kari Kairamo. During the late 1980s and 1990s Nokia refocussed itself on telecommunications, divesting the rubber, cable, footwear and consumer-electronics divisions. Its current enterprise is summarised by its tag-line “connecting people”. Guidelines for corporate culture are described in the document The Nokia Way; the Wikipedia article indicates that up until May 2007 the defined core-values had been “Customer Satisfaction, Respect, Achievement, Renewal”, and were redefined as “Engaging You, Achieving Together, Passion for Innovation, Very Human”. The Nokia history indicates the problems that arise when an organisation grows without an explicit form of identity to guide choices as to what should and should not be included as the organisation expands via natural growth and via mergers and acquisitions. Over time, the enterprise – and hence organisational identity – slowly loses clarity, leading to excessive tensions across the entire organisation. The break-up in the late-1980s and 1990s was a necessary foundation for its later growth, because each sub-unit could now align with a more-clearly defined enterprise-vision.

193

Looking back at all of these examples, it’s clear that strategy can be driven bottom-up as well as top-down. Sometimes, as with MyM&Ms and Play-Doh, the change in strategy requires the creation of a new enterprise, distinct from that of the parent. In both those cases, the technology essentially remained the same, with the new identity linked to the new market. In effect, the new identity is based on a new role for the technology. In the case of Oceaneering, the new application of the existing technology remained under the old enterprise. It would in fact have been a good fit to the existing enterprise, if that enterprise had focussed around the technology rather than its application. However, the organisation’s declared enterprise is firmly linked to the application (underwater oilfields) rather than the technology (specialist bespoke hydraulic-engineering). The apparently highly-profitable animatronics division barely even rates a mention on the website, and is not included at all in the organisation’s stated vision or mission. It seems likely that a split similar to that of Mars and MyM&Ms will be necessary in the fairly near future.

194

APPENDIX A: ENTERPRISE CANVAS – A VISUAL SUMMARY

Enterprise Canvas The enterprise is composed of services. Each service has the same conceptual structure.

supplierrelations

value-proposition

supplierchannels

value-creation

customerchannels

customerrelations

value-outlay

value-governance

value-return

thisinbound outbound

before

during

after

before

during

after

supplier customer

195

Layers The services can be described in terms of a series of layers of abstraction, from far-future to now to past.

196

Extensions to Enterprise Canvas Each service is supported by a set of guidance-services that link it to the broader enterprise and organisational purpose. Each service may also optionally have investors and beneficiaries.

197

Enterprise The organisation exists within the context of a market, which exists in context of a broader shared-enterprise.

Market content The tetradian summarises the content of the market itself.

198

Market-cycle Value-flows in the market tend to fall into a supportive cycle.

199

Service content Use this visual checklist to review service-content.

200

Service-flow content and flow-lifecycle Use this visual checklist to review the Five-Element phases and service-flow content ‘wrappers’ for each flow for the service.

Performance

Purpose

People

Preparation

Process

PoliciesValues

Events

Completions

Trust

201

APPENDIX B: WORKING WITH BUSINESS MODEL CANVAS

Summary This appendix describes how to transfer a business-model from the popular Business Model Canvas format into a service-style description in Enterprise Canvas format, to identify how to realise the business-model in real-world practice.

Details The Business Model Canvas (BMC) is a popular framework for developing business-models. It was originally developed by Alex Osterwalder, and published in his book Business Model Generation. Although mainly intended for developing business-models for for-profit organisations, it can also be used for equivalent models for government, not-for-profit and other types of organisations. The BMC is available in the public domain under a Creative Commons ‘Attribution / Share-Alike’ license: it may be used for any purpose, including commercial purposes, with attribution to the author (Alex Osterwalder), and adapted in any way, provided that the adaptation is also released under a similar license.

202

Business Model Canvas

In essence, it’s an organisation-centric view into an enterprise supply-chain, organised around a business-model as the delivery of a value-proposition to a set of customer-segments. (Note that its definition of ‘value-proposition’ is slightly different to that in the Enterprise Canvas: “the bundle of products and services that create value for a specific Customer Segment”, without anchoring in an enterprise vision or values.) It seems to assume that money is the only form of value to be exchanged (Revenue Streams, Cost Structure), with flows as a linear supply-chain that ends with the customer, rather than a value-web across the enterprise. It’s also asymmetric in that it describes the transactions with customers in detail (Customer

203

Relations, Channels, Revenue Streams), whilst transactions with suppliers (Key Partners) are not. In Enterprise Canvas terms, it sits at the row-2 to row-3 level – relationships and abstract attributes. Hence a business-model in BMC format will always need some translation and expansion into other model-types to make the model realisable in practice. Overall, it’s a frame which makes it easy for most people to grasp what’s going on in a business. And it makes even more sense once we understand that the business-model actually depicts relationships between a set of interdependent services – which means that by its nature it aligns well with the underlying core of the Enterprise Canvas. That’s why the Enterprise Canvas was laid out to be directly compatible with the BMC: the two models do have different roles and emphases, and the Enterprise Canvas describes a much larger scope and scale, but the intentional similarity of layout means that we can easily translate between them.

From Business Model Canvas to Enterprise Canvas Develop a business-model on the Business Model Canvas, using the instructions and guidance in Business Model Generation. Then translate from BMC to Enterprise Canvas as follows:

• Key Partners [KP] to one or more ‘Supplier’ blocks • Customer Segments [CS] to one or more ‘Customer’ blocks • Customer Relationships [CR] to Customer-Relations • Channels [CH] to Customer-Channels • Revenue Streams [R$] to Value-Return • Cost Structure [C$] to Value-Outlay

204

• Value Proposition [VP] to Value-Proposition • initially, merge Key Resources [KR] and Key Activities [KA] into Value-Creation,

though some aspects are likely to be moved to other cells on detailed analysis

KPsupplier

CScustomer

(KP)supplierrelations

VPvalue-

proposition

(KP)supplierchannels

KR / KAvalue-

creation

CHcustomerchannels

CRcustomerrelations

C$value-outlay

(C$ / R$)value-

governance

R$value-return

KAKey

Activities VPValue-

PropositionKRKey

ResourcesCH

Channels

CRCustomer

Relationships

C$Cost Structure

R$Revenue Streams

KPKey

Partners

CSCustomerSegments

Mapping Business Model Canvas to Enterprise Canvas

Use text-descriptions and any other documentation attached to the business-model to populate the flows between the core service and its suppliers and customers. Do a review to check the initial translation. Some aspects may need to be split as follows:

205

• some aspects of Key Partners [KP] may need to be moved to Supplier-Relations and/or Supplier-Channels and/or to the respective flows

• some aspects of Cost Structure [C$] may need to be moved to the supplier-side return-channel

• some aspects of Customer Relationships [CR], Channels [CH] and/or Revenue Streams [R$] may need to be moved to the respective customer-side flows

• governance aspects of Cost Structure [C$] may need to be moved to Value-Governance

• governance aspects of Revenue Streams [R$] may need to be moved to Value-Governance

All aspects of Key Activities [KA] and Key Resources [KR] should be reviewed in terms of service-content (see Service content, p.116) and moved into the respective Enterprise Canvas cells as appropriate. The result of the translation should be a row-2 or simplified row-3 Enterprise Canvas. Use the methods and questions described in this book to work with the stakeholders to link the business-model to its guidance-services, investors and beneficiaries, and the vision and values of the broader shared-enterprise. Expand the model downward through the layers, to identify how to bring it to real-world implementation, and to modify the model as necessary according to real-world opportunities, risks and constraints.

From Enterprise Canvas to Business Model Canvas On occasion it may be useful to translate in the opposite direction, from Enterprise Canvas to Business Model Canvas – such as for a business-audience who are known to be familiar with the latter.

206

In essence the translation is the reverse of that above. Start with a simplified row-3 Enterprise Canvas model. Flows between services, and also between cells within the Enterprise Canvas, should be described as links between cells on the Business Model Canvas. Note that the translation may not be straightforward in some places, particularly on the supplier-side, because of the inherent asymmetry of the Business Model Canvas. Some decisions will be needed to simplify service-content into the BMC Key Resources and Key Activities cells. As a guideline:

• service-content assets and locations go into Key Resources • service-content functions go into Key Activities • service-content capabilities and decisions may end up in either cell as appropriate • service-content events can be reframed as links between cells

‘Round-tripping’ between Enterprise Canvas and Business Model Canvas can be problematic because information may be lost when translating from Enterprise Canvas – particularly about guidance, investors and flows. Often the only way to carry this information through to a Business Model Canvas is via text-annotations and hand-drawn links. So although round-tripping is possible here, do be aware of the risks as well as the advantages.

207

APPENDIX C: SOURCES AND RESOURCES

Sources If you’re familiar with enterprise-architecture or related fields, you will no doubt have recognised a few familiar frames amongst the various aspects of the Enterprise Canvas – if perhaps in somewhat unfamiliar form at times. Yet this should be no surprise, because a lot of effort has been made to ensure that the Canvas is compatible with other commonly-used model-types, to simplify translation to and from those models – such as in the example for Business Model Canvas, as described in the previous Appendix. The core idea that ‘everything is a service’ is drawn from my book The Service Oriented Enterprise, which in turn draws on principles adapted in part from Stafford Beer’s Viable System Model (of which more later).

• Tom Graves, The Service-Oriented Enterprise: enterprise architecture and viable services (Tetradian Books, 2009)

The concept of vision as an unchanging ‘guiding star’, and the consistent structure for the bridge between that abstract vision and concrete everyday activities, is drawn in part from the ISO-9000:2000 international standard on quality-systems.

• ISO-9000:2000: see Wikipedia, en.wikipedia.org/wiki/ISO_9000 The Market Model was in part derived, though much-extended, from the assertion in the Cluetrain Manifesto that “markets are conversations”. The remainder of the

208

model comes from own work on the tetradian dimensions, as described in my book Doing Enterprise Architecture, and from various of my weblog articles.

• Cluetrain Manifesto: see www.cluetrain.com • Tom Graves, Doing Enterprise Architecture: process and practice in the real enterprise

(Tetradian Books, 2009) • Tom Graves / Tetradian weblog: see weblog.tetradian.com

The layers for the Enterprise Canvas were adapted and extended from the Zachman Framework. Zachman uses five distinct layers (rows) of abstraction of change from future to present; I’ve added one more layer above and below, to represent the unchanging future of the vision, and the unchangeable past of actual metrics and records.

• Zachman Framework: see www.zifa.com/framework.html or Wikipedia, en.wikipedia.org/wiki/Zachman_Framework

The set of interrogatives – what, how, where, who, when, why –used to identify lists of entities for row-1 of the Enterprise Canvas is derived directly from the Zachman Framework.

• Zachman Framework: as above The nine-cell structure for the core of the Enterprise Canvas is inspired by the Business Model Canvas, developed by Alex Osterwalder and described in the book Business Model Generation.

• Business Model Canvas: see Wikipedia, en.wikipedia.org/wiki/Business_Model_Canvas • Alex Osterwalder, Yves Pigneur et al., Business Model Generation: a handbook for

visionaries, game-changers and challengers (self-published, 2010)

209

The matrix checklist used to identify service-content is based in part on a much-amended version of the Zachman Framework, and also in part on my own work on the tetradian dimensions, as described in my book Bridging the Silos.

• Tom Graves, Bridging the Silos: enterprise-architecture for IT-architects (Tetradian Books, 2008)

The method for assessing flows between services was adapted from the VPEC-T (values, policies, events, content, trust) framework, developed by Nigel Green. Note that this adaptation differs from the original framework in that the ‘Content’ dimension is reframed in somewhat different form as ‘Completions’.

• VPEC-T: see Nigel Green and Carl Bate, Lost in Translation: a handbook for information-systems in the 21st century (Evolved Technologist Press, 2007); also www.lithandbook.com

The ‘guidance-services’ for the Enterprise Canvas are adapted and extended from Stafford Beer’s ‘Viable System Model’ (VSM), as originally described in his book The Brain of the Firm and used in the ground-breaking Cybersyn system in Chile in 1972. In VSM, the core service (‘delivery-service’) is referred to as ‘System-1’, the coordination-services as ‘System-2’, and the direction-services as a collective of three distinct sub-services referred to as ‘System-3’, ‘System-4’ and ‘System-5’. The original for the generic validation-services in the Enterprise Canvas was a single function for audit and review in VSM, referred to as ‘System-3*’. These extensions used in the Enterprise Canvas were first described in my book The Service-Oriented Enterprise, in which the validation-services are referred to as ‘pervasive-services’.

• Stafford Beer, Brain of the Firm (Allen Lane, The Penguin Press, London, 1972) • Patrick Hoverstadt, The Fractal Organization: Creating sustainable organizations with

the Viable System Model (Wiley, 2008)

210

• Tom Graves, The Service-Oriented Enterprise: as above • Viable System Model: see Wikipedia, en.wikipedia.org/wiki/Viable_System_Model • Project Cybersyn: see www.cybersyn.cl/ingles/home.html and Wikipedia,

en.wikipedia.org/wiki/Project_Cybersyn The systems-principles referenced in various places throughout the text are derived and adapted from many different sources, such as Stafford Beer’s VSM and Peter Senge’s The Fifth Discipline. The predictability-model is adapted in part from work by Cynthia Kurtz and Dave Snowden on the Cynefin framework, but used more in line with an earlier model from my book Inventing Reality. The related methods for context-space mapping are derived from and described in my book Everyday Enterprise Architecture.

• VSM (Viable System Model): see above • Peter Senge, The Fifth Discipline (Currency, 1990) • Cynefin: see Wikipedia, en.wikipedia.org/wiki/Cynefin • Tom Graves, Inventing Reality: towards a magical technology (Gateway Books, 1986

/ Grey House, 2007) • Tom Graves, Everyday Enterprise Architecture: sensemaking, strategy, structures and

solutions (Tetradian Books, 2010) A common underlying theme that surfaces in some places – such as the service-flows model – is based on a Five Elements frame, adapted in part from Bruce Tuckman’s ‘Group Dynamics’ project-lifecycle model, together with the wu xing five-phase model that underpins much of traditional Chinese philosophy and medicine. Some other present-day business-applications of this theme are described in my book SEMPER & SCORE.

211

• Tuckman Group Dynamics: see Wikipedia, en.wikipedia.org/wiki/Forming-storming-norming-performing

• Five Elements (wu xing): see Wikipedia, en.wikipedia.org/wiki/Wu_xing • Tom Graves: SEMPER & SCORE: enhancing enterprise effectiveness (Tetradian

Books, 2008) There are probably many other sources for the underlying ideas in the Enterprise Canvas, some of which I have no doubt forgotten, but the above are the main examples.

Other resources Archimate: see Wikipedia, en.wikipedia.org/wiki/ArchiMate; also www.archimate.org and

www.opengroup.org/archimate/ Balanced Scorecard: see Wikipedia, en.wikipedia.org/wiki/Balanced_scorecard Barely Repeatable Processes: see www.thingamy.com Blue Ocean Strategy: see Wikipedia, en.wikipedia.org/wiki/Blue_Ocean_Strategy BMM (Business Motivation Model): see businessrulesgroup.org/bmm.shtml BPMN (Business Process Modeling Notation): see Wikipedia,

en.wikipedia.org/wiki/BPMN Causal Layered Analysis: see Wikipedia, en.wikipedia.org/wiki/Causal_layered_analysis eTOM (Enhanced Telecom Operations Map): see Wikipedia,

en.wikipedia.org/wiki/Enhanced_Telecom_Operations_Map FEAF ([US] Federal Enterprise Architecture Framework): see Wikipedia,

en.wikipedia.org/wiki/Federal_Enterprise_Architecture ITIL (IT Infrastructure Library): see Wikipedia,

en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library

212

Living organisation: see Arie de Geus, The Living Company: Habits for Survival in a Turbulent Business Environment (HBR Press, 2002)

OODA (observe, orient, decide, act): see Wikipedia, en.wikipedia.org/wiki/OODA_loop PDCA (plan, do, check, act): see Wikipedia, en.wikipedia.org/wiki/PDCA Porter Five Forces: see Wikipedia: en.wikipedia.org/wiki/Porter_five_forces_analysis Porter Value-Chain: see Wikipedia, en.wikipedia.org/wiki/Value_chain RACI (responsible, assists, consulted, informed): see Wikipedia,

en.wikipedia.org/wiki/Responsibility_assignment_matrix Root-cause analysis: see Wikipedia, en.wikipedia.org/wiki/Root_cause_analysis Shell General Business Principles: www.shell.com/sgbp Six Sigma: see Wikipedia, en.wikipedia.org/wiki/Six_Sigma SWOT (strengths, weaknesses, opportunities, strengths): see Wikipedia,

en.wikipedia.org/wiki/SWOT_analysis Taylorism: see Wikipedia, en.wikipedia.org/wiki/Scientific_management TOGAF (The Open Group Architecture Framework): see www.opengroup.org/togaf United Breaks Guitars: see Wikipedia, en.wikipedia.org/wiki/United_Breaks_Guitars Value-stream mapping: see Wikipedia, en.wikipedia.org/wiki/Value_stream_mapping VRMG (vision, role, mission, goal): see www.slideshare.net/tetradian/vision-role-mission-goal-

a-framework-for-business-motivation Wicked-problems: see en.wikipedia.org/wiki/Wicked_problem

Rethinking vision ‘bottom-up’ IndustryWeek, “Assessing Product Innovation Assets: What’s in your attic?”: see

www.industryweek.com/articles/assessing_product_innovation_assets_whats_in_your_attic_22147.aspx

213

Mars: see www.mars.com/global/index.aspx; also core-principles www.mars.com/global/the-five-principles.aspx

MyM&Ms: see www.mymms.com/; also history at www.businessweek.com/innovate/content/dec2009/id20091217_120646.htm

Nicholas Hayek: see Wikipedia, en.wikipedia.org/wiki/Nicolas_Hayek Nokia: see Wikipedia, en.wikipedia.org/wiki/Nokia; also www.nokia.co.uk/ and core-values

www.nokia.com/careers/nokia-as-an-employer/nokia-way-and-values Oceaneering: see www.oceaneering.com/; also www.oceaneering.com/advanced-

technologies/entertainment-systems/ and www.oceaneering.com/advanced-technologies/space-systems/

Play-Doh: see Wikipedia, en.wikipedia.org/wiki/Play-Doh; also www.hasbro.com/playdoh/en_US/, history www.ideafinder.com/history/inventions/playdoh.htm and original parent-company Kutol www.kutol.com/about_us.html

Swatch: see www.swatch.com/zz_en/about/history.html