Metaframeworks in practice, Part 5: Enterprise Canvas

What frameworks do we need, to link across all domains and layers of the enterprise-architecture space? How can we create such frameworks?

This is the fifth and final item in this series of worked-examples of metaframeworks in practice – on how to hack and ‘smoosh-together’ existing frameworks to create a tool that will help people make sense of a specific business-context:

• Part 1: Zachman plus tetradian -> extended-Zachman
• Part 2: TOGAF plus PDCA plus US-Army AAR -> iterative-TOGAF
• Part 3: Chinese wu xing plus Group Dynamics plus VPEC-T -> core Five Element
• Part 4: Jung plus swamp-metaphor plus systems-practice plus Kurtz/Cynefin plus many-others -> context-space mapping -> SCAN
• Part 5 [this post]: Business Model Canvas plus Viable System Model plus extended-Zachman plus many-others -> Enterprise Canvas; plus Five Element plus Market Cycle -> Enterprise-Canvas dynamics

In accordance with the process outlined in the ‘Metaframeworks in practice‘ overview-post, each of these worked-examples starts from a selected base-framework – in this case, Alex Osterwalder’s Business Model Canvas – and builds outward from there, to support the specified business-need.

Enterprise Canvas

Business-need

Again no specific business-client on this one: the real driver was just my own repeated frustration at trying to find workable ways to link things together across the whole enterprise-architecture space, from IT to process to people to ‘things’, and from motivation to execution and all the way back again.

There are lots and lots of point-solutions and suchlike, many of which do work well on their own; but the whole space overall is so fragmented that it’s almost always a mess trying to make sense of anything that crosses almost any kind of boundary. Hence we really need something that works here… it doesn’t need to be wonderful, it just needs to be able to do it at all! 😐

Metaframework process

Start from Alex Osterwalder’s Business Model Canvas:

At first glance, it seems it could be usable as a link-frame across any aspect of enterprise-architecture.

Apply systems-principles such as rotation, reciprocation (balance) and recursion:

• the frame is obviously usable as a rotation – a set of ‘domains’ that provide a consistent and systematic suite of views into a context
• the frame is asymmetric (‘unbalanced’) in that the channels and interfaces on the ‘customer-side’ are not replicated on the ‘partner-side’
• the frame is not inherently designed for recursion – it aims to apply at the business-model level only (e.g. Zachman rows 2-3)

In short, it’s a very useful tool for business-architecture, but does not in itself appear to support a broader use. Yet for me there’s still a strong feeling that it’s a good place to start.

Move sideways somewhat: think about the ‘customer-side’ of Business Model Canvas, which seems more complete.

Think about the usual emphasis on transactions.

Connect that to the Cluetrain catchphrase “Markets are conversations”.

Link to that a later add-on comment by one of Cluetrain’s originators, Doc Searls, that markets are also built on relationships.

Link from there to the tetradian model (see Part 1 of this series), which would in turn suggest that markets are also held together by aspirations or shared-purpose:

Apply this as a model of the overall enterprise-space:

• physical and/or virtual (information): the transactions of the enterprise
• virtual (conversation) and/or relational: the market of the enterprise
• relational and/or aspirational: the promise of the enterprise

Or, in visual form:

Or, as a service-cycle, where trust is a measure of match to shared-aspirations:

Note that this splits into three segments: before, during and after the main core of what most organisations think of as ‘their market’. In SCAN terms, it’s what happens at the point of action (now: ‘transaction’), and either side of that point of action (future: ‘before‘ and past: ‘after‘):

Note that this also aligns quite well with the right-hand (customer-facing) side of Business Model Canvas:

• before: Customer Relationships
• during: Channels
• after: Revenue Streams

Stop there for the moment: let this brew for a while…

Think about products versus services. Business Model Canvas seems to emphasise products, but in essence products are just proto-services, a means through which we can deliver self-service.

Consider the idea that we could describe everything in the enterprise in terms of services.

By serendipity, come across an article that describes effects of global climate-change in terms of impacts on ‘ecosystem-services’ provided by rainforests and suchlike. It emphasises interdependencies across the whole ecosystem, describing all inter-relationships in terms of mutual services that balance overall across the ecosystem. Every service is a provider (‘supplier’) and consumer (‘customer’) of other services: inherently-symmetric relationships across either side of each service.

Cross-link this with Daniel Pink’s work on motivation in human enterprises: in particular, the importance of purpose – the ‘vision’ or ‘promise’ that holds the enterprise together and drives it into action.

If we link all of these together, this suggests that we could view everything in the enterprise in terms of services that connect ‘vertically’ in terms of shared purpose and associated values; and that connect ‘horizontally’ in terms of exchange of ‘that which is valued’, with relationships that link before, during and after the main-transactions. Or, in visual form, as the classic supply-chain:

Rethink the functions of the service in terms of a simple 3×3 matrix:

• supplier-facing, self, customer-facing
• before, during, after

Which, in visual form, gives us:

Apply the extended-Zachman from Part 1 of this series. Each service could be described in terms of any one of the extended-Zachman levels-of-abstraction:

And the service-content for each service in terms of a single row within the extended-Zachman frame:

And if we summarise the service itself visually as follows:

Then, if we rethink Business Model Canvas somewhat in terms of reciprocation (symmetry and balance), we would end up with a crossmap between Business Model Canvas and this ‘service-canvas’ somewhat as follows:

It’s a bit messy, but it works. Sort-of: enough for sensemaking about services at any level, anyway. Yet it still doesn’t quite feel complete…

Link across to work I’d done more than a decade or more ago on ‘viable systems’, based on Stafford Beer’s Viable System Model (VSM). If systems are to be viable, especially over the longer term, then there are distinct interrelationships that are needed between each ‘component’ in the system. Apply recursion and/or reflexion to go to any scale, and reframe ‘component’ as ‘service’: hence, in terms of an individual service not so much as ‘Viable System Model’ as ‘Viable Service Model’.

If so, every service-entity:

• delivers some kind of service (VSM ‘system-1’)
• coordinates with other services (VSM ‘system-2’)
• directs and/or is directed (‘managed’) by other services (VSM ‘system-3’, ‘system-4’, ‘system-5’)
• keeps on track to value(s) (VSM ‘system-3*’)

Or, in visual form:

Or, in terms of services’ relationships to each other, as described in my book The Service-Oriented Enterprise:

Note the limits of Taylorism, which often doesn’t acknowledge either cross-silo coordination or the need to link to pervasive values. For a viable model, we’d need to include those latter elements.

Add these relationships to a ‘back-of-the-napkin’ sketch of that ‘service-canvas’:

Note too that each service – especially at larger scale – is likely to have its own investors and beneficiaries, who interact via different forms of value than those flowing through the ‘horizontal’ supply-chain or value-web.

Add these too to a ‘back of the napkin’ sketch:

And if we bring all of these together, into expanded form, we have an Enterprise Canvas:

This can be used to summarise the content, relationships and interdependencies of any service at any level. Whenever we look at a Business Model Canvas, or an entity in a BPMN or Archimate or UML model, or a data-element in a data-schema, we can use this frame to bridge the gaps and link across all of the different views.

Useful, yet still not enough… what happens between services matters every bit as much as the services themselves.

Apply the tetradian to those flows or relationships:

What it indicates is the asset-types that are exchanged or linked across each of the ‘flows’ – the almost-infinite variety of asset-type combinations indicated or implied by the left-most column in the service-content map:

But what about the timing or sequence of those interactions? For this, we could crossmap the service-cycle above to the ‘not-quite VPEC-T’ frame in the Five Element model in Part 3 of this series:

Although each flow could carry any type of asset, the sequence does also emphasise different parts of the ‘canvas’:

• trust / values / policies: before – Value Proposition, Supplier/Customer Relations
• policies / events / completions: during – Value Creation, Supplier/Customer Channels
• completions / trust: after – Value Governance, Value Outlay, Value Return

So if we crossmap the whole Five Element set onto the Enterprise Canvas, turned round to a different view to distinguish ‘inside’ from ‘outward-facing’, we get a frame that summarises the full Enterprise Canvas dynamics:

Which, overall, is quite a lot. But it works. Sort-of. 🙂

Originator-relations

On Business Model Canvas, I’ve been careful to make it clear that Enterprise Canvas doesn’t purport to be a ‘replacement’, but a related yet definitely different frame that addresses a significantly different type of challenge: not business-models, but whole-of-context mapping and integration. Being careful and explicit about that point has made relations with Alex Osterwalder a lot easier. We do disagree in some areas – in particular, about the importance of ‘between the boxes‘, which I don’t think is addressed enough in Business Model Canvas – but otherwise it’s all easy, and mutually-supportive.

On this re-use of the extended-Zachman frame, it’s much as described in Part 1 of this series: we ‘agree to disagree’, but the core of it is that Zachman himself is a really nice guy who seems to go out of his way to make everything easy and comfortable for everyone.

On VSM (Viable System Model), Stafford Beer is sadly no longer with us: it would have been good to explore this with him. The core difference from ‘standard’ VSM here is that I’ve greatly expanded the role of the VSM ‘system-3*’, from ‘random-audit’ to full coverage of all values-issues. This does make sense, because the original VSM was designed only to describe information-systems and information-flows, whereas the Enterprise Canvas must cover all asset-types, flow-types and relationship-types – and an expansion of ‘system-3*’ fits exactly with the logic of the VSM. Some of the lead VSM practitioners – particularly Patrick Hoverstadt – do disagree with me on this: but it’s still a reasonably-amicable ‘agree to disagree’ rather than a full-blown ‘unhappy-originator’ problem.

On this adaptation of VPEC-T, it’s as described in Part 3 of this series: another careful emphasis that this isn’t the same as Nigel Green and Carl Bate’s original model. (See  ‘More on ‘Not-quite VPEC-T’‘ for more detail on this.)

The rest of it is ‘all my own work’, mostly. I do seem to argue a lot with myself, it’s true, but otherwise relations with that originator seem fine. 🙂

Applications

This is one framework that’s out there and being used in a lot of different ways.

It’s described in depth in my book Mapping the Enterprise, and the blog-posts here through which it was developed have been published as the ebook Enterprise Canvas: the Tetradian weblogs.

It’s also appeared here in quite a few other forms and variations, such as the ‘This game – see the post ‘Using the ‘This’ game in EA modelling‘ for a live example – and as the Enterprise Canvas service-viability checklist, using the simplified notation for Enterprise Canvas.

It’s starting to gain a much broader user-base: see the post ‘Tools in action‘ for an early example. I’d also recently visited a client who have been using it as a core framework across the whole of their enterprise-architecture for almost a couple of years now – exactly as I’d hoped and intended right from the start. Feels good. 🙂

Overall, quite a good advert for metaframework techniques, I’d say?

Lessons-learned

Probably the single most important lesson-learned here is that over the years – and like just about every other practitioner – I’ve accumulated quite a broad toolkit of frameworks and model-types: some very interesting and useful things can happen when we put them together in new and different ways!

—

That’s all of the metaframework examples in this series: over to you for any comments on this example, or on the series as a whole?