I’ve interpreted Value Proposition here as ‘offer’ – the products and services that I offer to the various Customer Segments. As can be seen, there are quite a few distinct offer-types, for quite a few distinct Customer Segments – and this is fairly typical for any independent consultant. (The ‘Online diagnostics’ offer is currently under (re)development, including a rewrite of my SEMPERdiagnostic/intervention toolset, for more widespread availability, and a toolset for the Enterprise Canvas model – but the other offer-types I do already deliver in some form or other every day.)

I won’t spell it all out – the typeface in the diagrams is somewhat small, but it’s readable enough. The main point from this diagram is the same as we’ve so often hit with classic Zachman and the like: it’s just a bunch of boxes, each with a bunch of labels inside, and it’s not actually much use for anything. It’s a pretty picture, a nice taxonomy, but we can’t build a story of the business – a story of how it ‘makes money’ and so on – from this alone. The two-letter codes inside [..] and <..> do a give a few hints that some things might be connected in some way with other things, but that’s about it – and the codes are a bit of a kludge anyway, to be honest.

As most architects would agree, the ‘boxes’ alone are not enough. To make sense of the story, we need to see the connections between the items. This is a set of connections for the ‘Book’ offer (i.e. write and sell books), with connection-lines patched in on top of the BMTBox image of the Canvas via a simple graphics-program:

And the same kind of connection-set for the ‘Consult’ offer:

Two more points that we can see from this. One is the different layerings of ‘business model’: although this all fits under the general heading of ‘what I do and how I make money’, there are also six distinct ‘business models’ here – one for each offer-type – that have different impacts on all the other parts of the Canvas. They’re related, obviously – which is why they also link together under the same overall umbrella – yet they call on different activities, resources and partnerships, and so on. So a ‘business model’ can also be quite dynamic, with different components emphasised at different times and in different contexts: for this kind of business at least, there is no ‘the business-model’.

The other point is that we need to know a lot more about what’s in the ‘boxes’ and the ‘lines’, because that deeper information about the activities, the flows, and so on will have a lot of impact on decisions as to whether any specific part of this overall ‘business model’ is viable. The current version of the BMTBox app does allow us to record some basic numbers for Customer Segments, Revenue Streams and Cost Structure, and make some rudimentary financial-type calculations for each – but that’s nowhere near enough information to describe the full story of what would need to happen to make it work in real-world practice. ‘The numbers’ may indeed be enough for the core business-architecture – but that’s precisely why and where we see the limitations of business-architecture on its own, and why we need an enterprise-architecture that would link it to structural aspects of all the other domains. In other words, all the other ‘architectures’ within the business context.

The Business Model Canvas is very useful for what it does, within a business-architecture: no doubt about that at all. Yet on its own, it is not enough to describe a functioning business-model – how it would actually work in practice. Sometimes – perhaps quite often – it’s the detail that kills the viability of an otherwise good-looking business-model: and we can’t know that detail unless we are able to do a deep-dive into selected areas of the model’s implementation. That’s where Archimate, UML, BPMN and all those other modelling-techniques come into the picture; and also where Enterprise Canvas fits in, too, as a structured intermediate between the coarse-grained abstractions of the Business Model Canvas and the fine-grained detail of BPMN and the like. More on that in another post that’s coming soon, anyway.

The final point here, and perhaps the most important, is that in terms of enterprise-architecture, ‘how I make money’ is not a business-model in any meaningful sense of the term. It confuses means with ends: ‘making money’ is a ‘How’, not a Why’. (Even within a possession-economy, ‘making money’ is always an intermediate step towards something else, and in most cases trying to use it as a ‘Why’ makes no sense other than as a form of addiction – 12-Step Programme for Money-Obsessives Anonymous, anyone? ) To find the the ‘Why’ that we need for this, we have to move to a level ‘above’ the Business Model Canvas and business-architecture – which, again, is where enterprise-architecture comes into the picture.

If we look back at the immediately-previous post, ‘Do enterprise-architects design the enterprise?‘, the ‘Why’ that we need as the real driver for the business-model – and to which everything in the business-model must demonstrably align – is the ‘vision’ and concomitant values of the broader shared-enterprise. That vision – whatever it might be – is, in a very literal sense, the motive power behind the entire shared-enterprise. It’s also the common theme through which each player connects with all the others in that shared-enterprise. In my own case, as I described in the earlier post on this, what excites me – what I’m passionate about – is finding ways in which things can work together more effectively, in ways that work well for everyone. A business-related term for that shared-enterprise is ‘enterprise-architecture’ – hence that’s what I do, the label (or one of the labels) that I use for my work and my business. That’s the enterprise to which I personally am committed – and hence to which everything in my business would align.

As in the earlier post, it’s true that I need to ‘make money’ in order to work within that business space. But ‘making money’ is not the reason that I do the work – and in fact if ever I allow it to become ‘the reason why I work’, that’s the moment at which I would have allowed myself to disconnect from the shared-enterprise that underpins everything here, and hence also the moment at which my own business would start to fail. And that’s what we see so often around us: businesses that forget their ‘Why’, the deeper reason why they’re in business, will often shoot upward for a while as they grasp for the short-term gains of ‘grab the money and run’ – but it’s only a shining, delusory prelude to an inevitable, painful crash-and-burn.

Making sure that enterprises can fly, and continue to fly, is to me what enterprise-architecture is all about. That’s my ‘business-model’. What’s yours?