Over the past while have been asked by quite a few folks – Shawn Callahan, Alan Rodriguez, Robert Phipps and others – about how to use the Business Model Canvas in an NGO, government or other non-profit context. (Shawn’s client was a well-known international charity; I understand that Alan does architecture work for an independent but government-sponsored energy-trading exchange or something similar; Robert does data-architecture and other architecture-work in a government department in the social-services sector.) Hence seems that this might be a useful excuse to do a brief how-to, also linking Business Model Canvas to enterprise-architectures and business-process management via the Enterprise Canvas model.

‘Brief’ will likely be a relative term here, so continue after the break…

Osterwalder’s Business Model Canvas – first described in the book Business Model Generation – has rightly become a staple for business-architecture worldwide:

Business Model Canvas [(cc) Osterwalder/Pigneur]

Its strength is in its simplicity: it’s easy to describe a commercial business model in these terms, easy to understand, easy to engage people in business-model design and redesign. It’s also implemented in Osterwalder’s BMTbox iPad app, making it a powerful tool for ‘cafe conversations’ about business-models. For ‘conventional’ commercial business-models and their related business-architectures, it’s excellent.

Business Model Canvas for commercial organisations

Typically, we would start from either Value Proposition or Customer Segments, and move outward from there. What is our offer to the market? Who are the customers for this offering? and so on. The Business Model Generation book includes quite a wide range of standard strategic and tactical frameworks to get us started, such a Blue Ocean, Porter Value-Chain and so on.

We then wander around the model, iteratively, looking at the implications of each option, its impacts on everything else. For example, given these Customer Segments, through what Channels would we deliver our Value Proposition? Through what means would we create Customer Relationships to connect each of those Customer Segments to our Value Proposition? What returns – Revenue Streams – would we expect from each of our Customer Segments? What are the Key Resources we need to create and Deliver our Value Proposition? What are the Key Activities through which we would do this? What supplies do we need from others, or could we outsource some of those activities? – in other words, who would we need as out Key Partners? And what impact would each change have on our Cost Structure?

We can also support multi-segment business-models, such as the classic three-way free-newspaper-as-intermediary model used in modified form online by Google and the like, with its distinct value-propositions for three distinct customer-segments: the content-providers, who are paid to provide meaningful content for the ‘consumers’, who get the product for free, all of it paid for by advertisers, who get their messages embedded in the content.

And one of the great things about the model is that we can literally start anywhere. Round and round we go, trying out all the different options, building up a picture of the whole with wads of little Post-It® notes and scrawled connection-lines.

[An aside: from an enterprise-architecture perspective, one of the really serious limitations of the current version of the BMTBox app is that it doesn't support those connection-lines - in fact to me, as an enterprise-architect rather than solely a business-model designer, that one absent-feature can sometimes render the app itself almost useless in practice. I had a long argument with Alex about this during the early development stages of the app, and lost: oh well, it is his app, after all. I didn't succeed in explaining that whilst the connection-lines are implicit on the physical Canvas - because people simply draw them in as required with a whiteboard-marker or whatever - they need to be explicit on an app, especially for any kind of multi-segment model. The point is that whilst the 'boxes' on the model describe the activities and resources, in architecture we're every bit as concerned with the 'lines' - the flows that connect between the 'boxes'. I gather that the BMTBox app will eventually support explicit connection-lines: so if more of us can nag Alex about this, perhaps we can get it to happen sooner? - because it is essential for architecture-work, as will become clear later.]

Change the building-block labels for non-profit organisations

Yet there are practical problems that arise as soon as we move outside of a commercial scope. There is still always a ‘business model’ – the means by which the organisation achieves its aims, ‘the business of the business’. Most of the ‘left-hand side’ of the model in Business Model Canvas is much the same in a for-profit and not-for-profit context, but the ‘right-hand side’ is often radically different in a not-for-profit context, where terms such as ‘Revenue Streams’, ‘Customer Segments’ or even ‘Value Proposition’ may make little apparent sense. So for a non-profit, that’s the first thing we need to fix.

This part isn’t hard. The BMTBox app does allow us to change the building-block labels as appropriate. And it’s straightforward enough to hack the standard BMCanvas template: Osterwalder generously released it under a Creative Commons licence, so it’s freely available in various formats such as PDF and PPT. (The BMTBox allows us to edit the labels, too.) Given that, we can change the labels to whatever we might need. For example, for Shawn’s strategic-review for a large charity, a few months back, we changed the labels and the supporting-text as follows:

• Customer Segments to Co-creators (using CK Prahalad’s term ‘Co-creators‘ as a generic for all ‘provided-to’ relationships and roles)
• Customer Relationships to Relations (generic to include non-customer relationships)
• Cost Structure to Value-streams – outlay and costs (to include non-monetary costs, such as investment of effort or potential costs to reputation etc)
• Revenue Streams to Value-streams – returns (to include non-monetary value, in particular success in terms of the charity’s social/environmental aims)

In essence, the process for business-model development remains much the same as above: we identify the groupings of Co-creators, and the offerings (Value-propositions) to those respective groupings of co-creators, assessing Costs and Returns in the respective forms of value. We go through the same iterative assessment: for example, how do we connect with the respective groupings – our Relations with them? Via what Channels do we deliver the respective offerings? What are Key Resources and Key Activities do we need, to make this happen? Which Key Partners do we need, assisting in which activities and resources? Round and round, iterating through all of the different options.

This is enough for a first-level review of a non-profit business-model. Yet this still doesn’t resolve the fact that some of the core concepts behind the respective business-models can be very different to those in a commercial context: and in those cases, we do need to go deeper.

[Another aside: It's perhaps important to remember here that Business Model Canvas is designed for, and optimised for, one specific purpose: developing and mapping business-models for commercial business enterprises. It is a very powerful tool for that purpose. The moment we move outside of that commercial scope, though, or if we try to use it for enterprise-architecture rather than business-architecture, we need to remember that we're asking the Canvas to do something that it wasn't designed to do. In other words, those adaptations that we need to do here are our own responsibility, not Alex's - and we can't complain about it, either!]

Connecting to vision

For government or other non-profits, the emphasis on monetary revenue is obviously an important limitation for the Business Model Canvas. Yet in going deeper, we soon discover that the Canvas has several other structural assumptions that really start to get in our way. The first of these relates to enterprise vision.

In effect, Business Model Canvas assumes that the vision – the ‘core question’ – that drives the business-model will always be ‘how do we make money?’ Hence its Value Proposition will always tend to be forced into those terms: the ‘value’ is qualitative – better, cheaper, faster – but is ultimately expressed as a monetary value. (The BMTBox app at present only allows value to be expressed in monetary terms.)

In enterprise-architectures, though, we need to lift the understanding of ‘value-proposition’ up a notch or two. (This is actually true for commercial organisations as well as government or non-profit.) We need to know what ‘value’ means within the shared-enterprise, before it gets converted to monetary terms – if it can be converted into those terms at all. Before we go any further, we need a better understanding of that shared-vision and the values that derive from it. (See, for example, the slidedeck ‘Vision, role, mission, goal‘, and the summary in slide 20 in this presentation.) In those terms, the organisation exists to satisfy some aspect of the tension between the desired aims and what actually exists at present:

Chris Potts’ aphorism is a useful reminder here: “customers do not appear in our processes, we appear in their experiences”. The vision describes the reason to connect with the organisation, and the expectations for those experiences. It’s not just a supply-chain about ‘bigger, faster, cheaper’: instead, the meaning of value – ‘that which is valued’ – is defined by the shared vision, and everything that flows around the ‘value-network’ of the shared-enterprise is assessed both in terms of its direct value to the next person in the flow, and in terms of the values of the enterprise. In that sense, everything in the enterprise is a service that works towards the same shared desired-ends.

That then has a two-fold impact on the model’s Value Proposition.

First, the focus of the value-proposition shifts to how this activity or product or service delivers value to the entire shared-enterprise – not solely about ‘bigger, faster, cheaper’ and the like. It is first about how it contributes to the non-profit’s aims, or the government-department’s Results Logic [PDF], and then the qualitative concerns such as ‘bigger, faster, cheaper’ – in that priority order. The concept of offer as ‘value-proposition’ remains: but if it does not demonstrably contribute towards the enterprise-vision, it will not be perceived as a ‘value-proposition’.

Second, it implies that the service needs some kind of value-proposition for every stakeholder-group in the shared-enterprise – even those with whom it does not have direct transactions. For a non-profit, reputation and trust are the keys here – particularly in relation to non-clients or, especially, anti-clients, who will hold the organisation to account on those values. For a government department, these will be citizens and voters, who may not have direct interactions with the department, but who will certainly influence on or react to nominal policy – even as misreported in the media. The ‘market model’ is a useful way to summarise the relationships here:

The related ‘market cycle’ helps to summarise the dependencies:

And:

Relationships with non-clients and anti-clients connect primarily with values, policies and trust – the latter in essence being a metric of the organisation’s perceived alignment with its declared or implied vision of the enterprise.

Business Model Canvas sort-of deals with this on the ‘Customer’ side: if we think of non-clients and anti-clients as ‘customers’ of the idea or ideals that the organisation purports to represent, in its association with the shared-enterprise, then we could see Customer Relations as taking on that role of interaction, yet without ever reaching the point where main-transactions occur. The real complication with the Canvas for this, though, is that it’s asymmetric: there’s no equivalent of Customer Relations on the ‘supplier-side’ of the model. It’s at this stage in modelling that we may be forced to part company with Business Model Canvas.

Asymmetry of service

The structure of Business Model Canvas is somewhat asymmetric: its focus is firmly on the relationship between the organisation and its Customer Segments, without much attention paid to the ‘supplier-side’ other than the reference to Key Partners. That’s often a fair-enough short-cut in many types of commercial business-model. Yet even in business, a business-model can make-or-brake on the supply-side as much as on the customer-side; and in non-profits and government the distinctions between ‘customer’ and ‘supplier’ are rarely clear-cut.

Instead, it’s often best to think solely in terms of value-flows – before, during and after each main-transaction – and then identify the respective ‘customer’ or ‘supplier’ roles after that assessment. In this view, the organisation is and/or provides services that deliver value in relation to the aims of the shared-enterprise – and we model the service in terms of the value-flows between players. A ‘supplier’ is thus another service from whom we primarily receive some form of value in the main-transaction flow; and a ‘customer’ is another service within the enterprise to whom we primarily provide value, much as described in the market-cycle. In that sense, ‘customer’ or ‘supplier’ is not a person or organisation, but a contextual role that any person or organisation may take – and may switch between those roles, according to context.

We can then partition our own service in terms of those relationships, on the ‘supplier-side’, ‘customer-side’, and our own activities for value-creation and value-delivery.

Given this, we can then do a cross-map from Business Model Canvas to this extended ‘Enterprise Canvas‘.

Note too that we place a strong emphasis on the flows between our service and the ‘supplier’ and ‘customer’ services – which we can’t do so easily in the ‘block’ structure of the Business Model Canvas. (This is where the lack of support for flows in the BMTBox app becomes a serious shortcoming in practice.) Nigel Green’s VPEC-T – Values, Policies, Events, Content, Trust – is a particularly useful framework through which to assess those flows (though see the post ‘More on “Not-Quite-VPEC-T”‘ for some caveats on how to use that framework with Enterprise Canvas).

Investors and beneficiaries

Finally, there’s a collection of relationships that are usually implied or glossed-over in a commercial business-model, but are often extremely important on non-profit and government business-models: the relationships with investors and beneficiaries.

Investors are a bit like suppliers, but the main flow goes the opposite way: they put value into the service, rather than retrieve it on the backchannel (the ‘after’ flow). We often need investors to ‘prime the pump’, putting value in so as to start up the relationships with the main-transaction suppliers. Further up, they also help to provide credibility – ‘trustworthiness’ – to establish the respect of prospective clients, non-clients and anti-clients.

Beneficiaries are a bit like customers, but again the main flow goes the opposite way: they retrieve value from the backchannel, rather than putting it in, as customer-roles do.

In Enterprise Canvas, we model these as roles attached to the respective side of the backchannel – investors on the ‘supplier-side’, beneficiaries on the ‘customer-side’.

An investor is anyone who invests some form of value into the organisation, in terms of the values of the shared-enterprise. So this includes employees, who invest their time and commitment; it includes the community within which the organisation operates. For a non-profit, it includes donors, volunteers, fund-raisers and the like; for a government-department, it includes, voters, citizens, often also related government-departments that work kind of in-parallel rather than with our own department. It’s a supplier-like relationship, but that which is supplied is some kind of value, usually in a fairly ‘pure’ (abstract) form.

A beneficiary is anyone who retrieves some form of value fron the organisation, in terms of the values of the shared-enterprise. For example, a community may gain a sense of pride, of satisfaction, or simply the fact of having gainful employment within a money-based economy.

In this context, it’s often very important to not view ‘value’ solely in monetary terms – otherwise many of the business-crucial investor or beneficiary relationships will not make sense, or may not even be visible at all.

One of the key concerns in modelling these relationships is that two types of relationships do need to balance somehow – otherwise anti-client problems will be created or exacerbated. There is often additional complexity in that investors and beneficiaries are not necessarily the same people, and that the forms of value in each flow may be different – for example, a community invests effort and trust, and receives a stronger sense of community in return. Again, the VPEC-T frame provides a very useful set of ‘lenses’ through which to view and assess these flows and relationships.

There’s no obvious means to model these relationships in Business Model Canvas as such: you would either do so by attaching the respective extra ‘blocks’ below Cost Structure (investors) and Revenue Streams (beneficiaries) respectively. Another, perhaps more practical option is to do preliminary modelling in Business Model Canvas, and switch over to Enterprise Canvas once the limitations of the former are reached.

Summary

Business Model Canvas, in its current form, is a very good framework on which to develop business-models for commercial organisations. It’s not such a good fit for the requirements of business-modelling for non-profits and government departments: the main limitations are in its built-in assumptions about the nature of value, its inherent asymmetry in terms of relations with customers versus suppliers, and its lack of support for modelling relationships with investors and beneficiaries. The Business Model Canvas has huge advantages in terms of simplicity and ease of understanding, whilst the Enterprise Canvas model provides a useful and largely-compatible alternative for the aspects of modelling that Business Model Canvas cannot reach.

[In the next post, I'll describe how to use Enterprise Canvas to extend a business-model in Business Model Canvas into the more detailed-modelling needed for enterprise-architecture assessments of implementation and execution of the business-model.]

This starts from a Tweet by Swedish consultant Oscar Berg, which triggered off a back-and-forth flurry:

• oscarberg: The main currencies of business have always been information & trust. They let us exchange favors, goods/money etc <yes!!!
• erikproper: @tetradian @oscarberg 200grams of trust in exchange for one espresso?
• tetradian: @erikproper @oscarberg ‘pre-currency’ might be better term: monetary-type currency build _on top of_ trust etc
• oscarberg: @erikproper I’d need to know (info) that you sell espressos (incl price) & trust that you do good espressos to buy from you cc: @tetradian
• erikproper: @oscarberg Ah yes. But how are you going to pay for the espresso …
• oscarberg: @erikproper If I recommend your espresso to others, can’t you give me one for free?
• erikproper: @oscarberg You would, as long as eventually I get “paid” in a “currency” that allows me to “hire” co-workers, “pay” the coffee supplier, etc
• oscarberg: @erikproper you will get paid, if people trust you and have the info needed (like my recommendation) to buy your espresso
• tetradian: @erikproper @oscarberg monetary payment represents _lack_ of trust in overall economy – to understand economics, focus on trust first?
• erikproper: @oscarberg But in what …
• tetradian: @erikproper “But in what …” – sometimes paid just in thanks! – a currency is only a proxy for/in economics, not the economics itself!
• thoughttrans: @tetradian lack of trust in economy by the everyday person. hedge fund and corp execs are happy
• erikproper: @tetradian @oscarberg Monetary payment represents equalized trust? Enabling easier exchange of goods and favours by a unified value system?
• taotwit: @erikproper @tetradian @oscarberg interesting – what other Trust equalisers exist in business? Should we model them explicitly?
• erikproper: @taotwit @tetradian @oscarberg Really makes sense to more explicitly study value exchanges, and equalised notions of value and trust
• taotwit: @erikproper @tetradian @oscarberg ok that sounds like Value Network Analysis or do you think VNA is lacking?
• erikproper: @taotwit @tetradian @oscarberg Well. Is VNA in practice VN Modelling, or really critical VN Analysis, from a brdr prscptv, incldng non money
• jdevoo: @erikproper @taotwit @tetradian @oscarberg in an e3value model, exchanges can modeled that way I believe. That’s not VNA-related though.
• tetradian: @erikproper @taotwit @oscarberg @jdevoo re money and trust: getting too tangled for Twitter, will do blog-post instead!

Hence this blog-post…

To me there’s a fair amount of going-round-in-circles in the conversation above, though the point about Value Network modelling is certainly relevant. This is not unusual… And the reason why there’s so much circularity is that it’s starting from the wrong place – currency, or money – rather than where a transaction-economy actually starts, in trust and value.

Perhaps the simplest way to illustrate this is with what I call the ‘market-cycle’: trust and reputation enable relationship, which enable conversations about need and value, which enable transactions, which – when completed to the satisfaction of all parties involved – reinforces trust, in a virtuous-cycle.

In a currency-based economic model, currency changes hands at the end of the transaction: ‘completion for self’, from the perspective of the business. But if one or more of the parties are not satisfied by the transaction, trust is lost – often leading to a vicious-cycle in which transactions quietly fade away to nothing. So trust is actually the core here: not currency. The common over-focus on currency – or distant proxies such as ‘shareholder-value’ – will cripple an enterprise-architecture, especially when combined with the equally common ignorance about the centrality of trust.

All transactions start and end with trust. A currency is just a proxy for that trust at a societal level. It is not the trust itself: architecturally speaking, we must be careful always to keep the two apart, and to ensure that the focus ultimately remains on the trust itself, and not merely on its various proxies.

In a sense, a currency is actually a mechanism to transcend lack of trust. Many people have real difficulty in understanding systems or networks: they’re most comfortable with point-to-point transactions, direct reciprocal balance, ‘this for that’, ‘quid pro quo’, ‘double-entry life-keeping’ and suchlike. But that isn’t how real systems work: instead, Joe needs a loaf of bread, whilst Ben needs a hug, Kurt and Lina need timber for the barn, Mary needs someone to look after the kids while she leads the barn-raising, after which everyone needs a beer. Everything balances out somehow over the entire system, the entire value-network, but will rarely do so as such across at each point-to-point transaction.

So a currency forms a useful bridge for people who can’t or don’t or won’t understand and trust those whole-of-system flows: I don’t get a straight barter-balance in this transaction, perhaps, but I get these tokens called ‘money’ which supposedly entitle me to other resources from someone else within the jurisdiction that these tokens apply. It’s a useful kludge, a workaround for lack of trust – and it’s really important that we understand that it’s nothing more than that.

More seriously, it’s a kludge that has some very severe limitations. One is that it really only works in practice with ‘exchangeable’ items – tangible goods and services, and a limited subset of non-tangible services (knowledge-work’ etc). With anything else, it tends to induce some serious delusions: for example, as the old song puts it, “money can’t buy me love”, or hope, or freedom from fear – though it can sometimes buy simulations of such things, which is not the same at all, and which itself creates further serious societal problems…

Another limitation of most (perhaps all?) currency-models is that there are always people who are left out, because they don’t have access to appropriate ‘exchangeable items’. Parents, children, the elderly, the sick – these are often the people who most need resources, and yet in a currency-based model they may well be the people least likely to receive them. (This is true for everyone, actually. If you take the stereotype lifecycle – childhood, teenager, first leaving home, partner, then kids, middle-age, kids leaving home, retirement, old age – and map it the likely resource-needs at each stage of that cycle against the likely resource-availability ['income'] in a currency-based economy, you’ll note that it’s an almost perfect mismatch: whenever the needs are highest, the resource-availability is lowest, and vice-versa. In short, our ‘normal’ currency-based model, is not merely a poor system, but almost the worst that could possibly be devised.)

Even more problematic, most modern currencies are virtual-only (no longer connected to anything tangible, such as the old ‘Gold Standard’), and hence potentially infinite; yet the most of the resources that purport to be obtainable via currency-based transactions are finite. This leaves the system wide-open to a vast range of ‘price/value mismatch’ games – hence inflation, scarcity-pricing, most resource-’bubbles’, most of the present ‘financial system’, and most of the current ‘financial crisis’. In terms of the resources and capabilities that it provides, the value of a house really hasn’t changed much in the past fifty years; but the price has changed enormously, including – now – the amount of life that one is expected to assign to someone else in order to obtain it. (The effective price of a house had been stable for a hundred years or more, at about three times the respective annual salary; but in the 1990s that ‘life-price’ suddenly leapt to five, seven or even ten years, for no actual increase in value at all. It therefore becomes interesting to ask where all that ‘excess value’ went…)

Much the same mess occurs with several related key business-concepts such as ‘shareholder-value’. There are huge problems with price/value-mismatch – hence ‘asset-stripping’ on one side, the ‘DotCom bubble’ on the other. There’s no actual linkage between share-price and real share-value (or even much understanding of what ‘value’ actually is, in the literal sense of ‘that which is valued’). And even the price itself is based on complex emotive responses to other complex, mostly non-linear, mostly non-reversible transforms from transactions acting on complex mixtures of ‘exchangeable’ items (physical goods and services, and some types of non-physical services) and ‘non-exchangeable’ items (goodwill, relationship, brand and, above all, trust): hence the ‘double-entry balanced accounting’ so beloved within the entire economic is little better than somewhere between wishful-thinking and outright fraud.

So as enterprise-architects and the like, what do we do about this? A lot: for example, we definitely need to map each enterprise at a whole-of-system level, tracking the value-transactions and value-transforms at each point in the network. Perhaps the single most important point, though, is to remember that every currency is a mere fiction, a kludge to get round people’s inability to trust: and it’s not the fictional currency, but the real trust that lies behind it, that is the true basis of any real-world economics.

Update: Take a look at Wim Rampen’s blog-post Destroying Customer-Value for a really good first-hand example and analysis of how currency [money], value and trust interact in the business-relations between a telco [cellphone service-provider] and a long-term customer.

Yup. But they don’t like the results of simplistic, which is what we’ve got at the moment.

Note first that transaction-taxes are a _method_ to tackle a _symptom_. If we go straight to impose taxes without exploring the underlying issues, we’re likely to fall into the classic IT-industry trap of pre-packaged ‘solutions’ looking for a suitable problem – the cart-before-horse’ syndrome. (For US folks especially, there are also some serious concomitant questions about where that money will go once it passes into government hands. )

This is not trivial: an unexpressed, unreleased value will keep on building until it eventually explodes, destroying not merely the business-model but at lot else whilst it’s at it. A colleague, for example, was once at a creditors’ meeting which very nearly became a lynch-mob: traders, you have been warned!

Since the previous post on ‘Values-architecture 101‘, the discussion on LinkedIn on values-architecture and values in business continues happily unabated. Still seems worthwhile, and also seems useful to re-post some of it here to make it more generally available.

I know I tend to write long, so perhaps unsurprisingly one person commented:

@Tom You asked for suggestions.

Keep it simple. Keep it brief. That is what business people want.

Yes, true. But business-folks also don’t like the results of simplistic, which is mostly what we get at the moment.

Condensing the simple out of the complex is darned hard work, which is perhaps why most people prefer simplistic. Even though it doesn’t work.

The path from complex to simple necessarily goes through something called ‘work-in-progress’ – which invariably and inevitably is going to be somewhat messy, tangled, confusing and the rest. And long-winded, too. Hence, my apologies, ‘cos this is indeed a work-in-progress…

Anyway, for those who don’t mind things that only halfway towards simple, more after the ‘Read more…’ link.

Value versus price

One of the points this whole conversation has stuck on is the confusion between values and price. Almost all of the business-oriented folks, especially in the US, seemed to echo the view of one contributor, Cliff:

Price equals value at equilibrium, so a price should reflect a value.

The short answer is that No, it doesn’t. In that context, he’s using a circular definition in which ‘value’ is described solely in terms of price. Which we’re welcome to do if we wish; but if we do so, we also need to be aware that there are very serious consequences, one of which is that it forces us to measure every possible value in monetary terms (hence the political philosophy called ‘monetarism’, popularised by Reagan and Thatcher amongst others). Since some values – religious faith, for example – make no sense at all in monetary terms, we either have to invent spurious metrics which can seem to make monetary sense, or ignore the value altogether – neither of which choices are viable in the medium- to longer-term.

Cliff then expanded on his position:

If a person buys stock and becomes a shareholder, then yes, they have paid a price. However, if they sell the stock, they realize a value.

And again the answer is No, that’s the same circular definition: “value = realised/realisable difference in price”. In effect, ‘value’ here is ‘potential to obtain resources exchangeable within the transaction-economy’. To quote a famous example, “money can’t buy me love” – it can buy a simulation of it (ie. a transaction) but not love itself (ie. a value – the feeling of loving and being loved). Likewise money can buy the simulation of attention (it’s called ‘advertising’) but it does not actually guarantee the real committed attention of the attention-economy (the underlying value). The fact that the underlying need is not satisfied in each case leads to addictive behaviours that may seem very profitable on the surface (‘sex-industry’, anyone?) but cause serious problems elsewhere, via complex-system feedback loops as per the ‘United Breaks Guitars‘ example.

‘United Breaks Guitars’ is a good illustration of why values-modelling and whole-of-enterprise modelling is crucial for business-architecture. United’s complaints-resolution system was ‘designed’ (by default, not by deliberate intent – see POSIWID) to deny attention and frustrate claims. This reduces the direct impact in the transaction-economy (don’t pay the $1200 repair-claim) but triggers a value-response (‘not being heard’, in the attention-economy) leading to feedback-return via the reputation/trust-economy by someone who knows how to work the transactions of that economy (a musician-songwriter with some skillful friends). In strict finance terms, the company spent perhaps $500 or so (in customer-service staff-time) to avoid paying $1200, so appeared to be in-pocket in the simple transaction-to-transaction value-chain there; but the end-result is a huge reputation-hit with a direct cost of literally millions in staff-time and PR-agency response, on top of a huge hit in stock-price (some $180million, apparently), all of which loss is directly attributable to the nominal ‘gain’ in the customer-service channel.

If you don’t model the value-trails, you have no control and no choice as to how you get hit via the non-transaction economies. That’s why I keep hammering on about values-modelling, and modelling it as value, not solely as price.

A value is based in a feeling. The only link between price-based ‘value’ and value in the broader sense is that the actual or potential availability of funds creates the feeling of certainty that transactionable resources will be available as and when required. That feeling of certainty (or desire for it) is only one amongst many values in play in an organisation’s enterprise: if we stick to the delusion that ‘value = difference in price’, we are forced to attempt to model a complex multi-dimensional context in only one dimension. That would be a guaranteed path to failure in any other form of business-analysis: so why on earth would we think it would work any better in this one?

So again, I do insist that it’s essential to think broader: to understand value in business, we need to model it as value, not via a crude kludge that tries to force it into a price.

Keep the focus on values, not politics

One of the most serious booby-traps is getting confused between politics and values – political views and ‘solutions’ are outcomes of values-themes, not the values themselves. And although politics and the like definitely do have impacts in business, it’s the values themselves that we need to track, because they’re the lead-indicators that matter: by tracking them, we can pre-empt potential problems long before they surface in the political milieu. In the discussion itself, this came up, for example, in another comment from Cliff, which started as follows:

A side comment, just to show that I have feeling for the social issues that Tom has raised.

So I perhaps need to reiterate that my point about the social-issues is in terms of their business impact, not about the issues themselves. In that particular case, I was trying to keep all of the discussion strictly to the theme of the thread: “What is value in business?”

To illustrate what’s really going on here, it’s useful to do a business-oriented value-analysis starting from the next part of Cliff’s comment:

I am a big believer in transaction taxes/fees that encourage investors to hold investments for awhile – even for market insiders or “specialists” who currently can perform stock trades without any fees of any kind. There is currently no “impedance” in the system and I am very worried about the direction that speculation is headed and how unstable it might make the entire world economy. Capital markets are needed but they are currently set up as a scam by the trading community to skim money from the entire capital market environment, much as the US “federal” banks (which are not actually US banks at all) skim a percent off the top of the entire US money supply creation process.

Note first that transaction-taxes are a method to tackle a symptom that we interpret in systemic terms as ‘lack of impedance’. But if we go straight to impose taxes without exploring the underlying issues, we’re likely to fall into the classic IT-industry trap of pre-packaged ‘solutions’ looking for a suitable problem – the cart-before-horse’ syndrome. (For US folks especially, there are also some serious concomitant questions about where that money will go once it passes into government hands. )

If we do a conventional business-architecture from the traders’ point of view, our business-model would use a conventional organisation-centric view of the enterprise, and hence would cover only those stakeholders directly engaged in the transactions: the trader, the client, and various ‘middle-men’ roles. It would cover only the monetary aspects of the value-propositions and the like. It would also be built in accordance with current law, and hence would assume zero-tax transactions. Zero-tax is clearly preferable for all the direct players in the transaction: it’s more profitable for the trader, and (probably) cheaper for the client. Within that closed circle, everyone’s happy – probably.

But the point is that the real enterprise in that context does extend beyond that closed circle. Whilst everyone’s ‘making money’ within the circle, there are huge externalised costs (in many different senses of ‘cost’) in the broader ecosystem: local ‘efficiency’ ends up destroying whole-of-system effectiveness. But these costs are invisible from within the circle, because we’re only modelling the direct-transactions.

It’s probable that the core social value in play here is ‘fairness’, which in practice is expressed in a variety of different forms, some of which are very well described in Cliff’s comment above. But note that this is nominally external to the closed-circle – yet their existing business-model depends on zero-taxes. If transaction-taxes are introduced, that business-model becomes non-viable. Which for them is a very serious business-architecture problem – yet it’s one which, at present, they have no way to see.

So if I’m a business-architect working for one of the traders, how do I ‘surface’ that critical dependency? The answer is to do what I’d been describing in all of my posts to that discussion:

• extend the architecture-model to the whole enterprise, not just the client/prospect border
• model the cross-dependencies between transaction-economy, attention-economy and reputation/trust economy
• include values as values (not solely in monetary form) within business-architecture models

This is not trivial: an unexpressed, unreleased value will keep on building until it eventually explodes, destroying not merely the business-model but at lot else whilst it’s at it. A colleague, for example, was once at a creditors’ meeting which very nearly became a lynch-mob – stock-traders, you have been warned!

After much back-and-forth – and a constant struggle to detach the discussion from the US obsession with ‘shareholder-value’ – I finally managed to get at least some of the contributors to understand that values are some of the key inputs to an architecture. At this point, one of contributors tossed in what I can only describe as a lame attempt at a justification for architectural incompetence:

In my work I usually don’t create the many-layered value model that you do. I go right to the heart and relate tactical decisions to tangible value.

I’d have to say that I was shocked but not surprised. Three instant comments:

• it’s talking about price, not value;
• it’s going to the head (analysis), not to the heart (value); and
• it’s describing business-strategy and/or business-tactics, not business-architecture.

What’s still needed is a solid focus on the actual topic, namely value in business-architecture - in other words, the values-architecture that underpins the business-architecture itself.

To illustrate this, consider that statement “I usually don’t create the many-layered value model that you do”. A simple question: would you trust a purported architect who said “I’m going to use metal and glass in your building”, without any explanation or analysis as to why those materials would be used? Or what calculations underpin the choice of properties for the metal, or solar and other characteristics of the glass? Would you be concerned that there’s no ‘many-layered model’ behind the design, for example no apparent awareness of the need for resilience against earthquake or severe-storm, because though those are relatively rare in the short-term, they are highly likely in the medium to longer term? Would you trust an architect who regarded a many-layered, multi-faceted model of the building as irrelevant to the architecture-development and subsequent design and implementation? Would you trust an ‘architect’ whose only concern was price? I would hope that the answer would be ‘No’…

Which is why, like any real architect, I do insist on models that demonstrably assess all of the key factors in play in an architecture design.

So: some suggestions towards a Values Architecture 101:

#1. Values are subjective, not objective; they are feelings, not things.

#2. Values are the literal drivers for a business-architecture: they are the winds that blow across it, the rivers that flow through it, the forces that shake the ground beneath it. Values are the actual links in any value-chain or value-web. As with a physical building, the business-architecture cannot ignore those forces – it must be designed around them.

#3. Values are primarily qualitative, not quantitative. Where it is necessary to describe values in quantitative terms, it is usually best to use simple 1-5 scales or the like; anything else is likely to introduce ‘spurious precision’, which is both misleading and dangerous.

#4. Any attempt to ‘objectivise’ values – such as by ‘valuation’ into a price – will always be based on hidden assumptions. Because of those hidden-assumptions, transforms to price etc are non-reversible, making it impracticable or impossible to derive the underlying value-factors by reverse-engineering from the valuation itself. Hence in architecture it is always best to model the values as values, in order to surface those hidden-assumptions.

#5. An enterprise (or extended-enterprise, reaching far beyond the ‘enterprise’ of the business itself) coalesces around a core value (the ‘vision’) and a cluster of related values and derived principles. These values represent the choices – conscious and unconscious – of the stakeholders in the enterprise, and are context-dependent. These enterprise-choices describe and define the ecosystem within which the business will operate. Amongst many other possible stakeholder-roles, a business will typically place itself in a ‘supplier’ role within that enterprise.

#6. The core of the business’s relationship with other stakeholders is its set of ‘value-propositions’ – which, by definition, incorporate key concepts of value to and with the respective stakeholders. The business-model, operating-model, organisation-model etc are artefacts that are derived architecturally from the value-propositions and their underlying values.

#7. A business has a value-relationship with every stakeholder in the enterprise, whether or not this is made explicit via a value-proposition. It is extremely dangerous – especially in the longer-term – to ignore the implied relationships with enterprise-stakeholders not explicitly referenced in value-propositions.

#8. Pseudo-values such as ‘shareholder-value’ may be derived from the architecture, but usually play no direct part in the architecture.

Enough to start with, I hope?

Value-trees are a key theme in the model I’ve used for describing the service-oriented enterprise. More specifically, they are the trails of ‘pervasive services’ that ensure compliance to enterprise values. In effect, they are the vertical, management-oriented analogue of the horizontal value-chains of the enterprise. But whilst the value-chains traverse through a single layer of the enterprise – the operations or service-delivery layer – the value-trees, must, by definition, pervade every part of the enterprise, from top to bottom, from abstract strategy to each individual process-step, each line of code. To give one example, we know from painful experience that quality-based themes such privacy or security or business-continuity cannot be patched on as afterthought once the design is complete: to make it work, we must include them right from the start. A key aspect of the value-tree is the trail of relationships and requirements that devolves downward from the enterprise values, and upward as confirmation that the value-requirements have been met.

In short, value-trees are the means by which the so-called ‘non-functional’ requirements are made functional in a business sense.

For the most simplistic example, assume that the only value in the enterprise is profit. (I did say it was a simplistic example. ) A suite of principles devolve from this value: for example, that the outcomes of value-chain processes shall be measured in monetary terms; that costs of all activities shall likewise be measured in monetary terms (hence Activity Based Costing, for example); and that verifiable mechanisms shall be used to contrast these two sets of measurements, to derive a measurement of the value in its specified terms – i.e. profit, in this example. To do this, we’ll need to aggregate (‘roll up’) all the outcomes and costs; and for management purposes, we’ll probably need to be able to disaggregate (‘drill down’) through the business-units and groups and clusters, all the way back down to individual activities. The connections and transforms for aggregation and disaggregation are the branches for the value-tree.

A classic PDCA (plan, do, check, act) approach to quality-management – i.e. management of the value-tree – means that the tree itself needs to be supported by four distinct types of activities:

• develop awareness of the value itself, and of the need to monitor the value
• develop capability to enhance monitoring of and improvement against the value
• measure compliance of activities against the value
• verify and audit to monitor and enhance compliance and continual improvement

(Note that some of these may be required to be kept separate, by law or other regulation – for example, financial reporting versus financial audit.)

Next, extend the example to a slightly more realistic set of values. This leads us to something like Balanced Scorecard, which defines enterprise value in terms of four distinct themes: together with the existing financial measures as above, we add perspectives for Customer, Internal Business Processes, and Learning and Growth. Each of these themes has its own value-tree. (One reason why Balanced Scorecard implementations sometimes fail to give the desired results is that the value-trees don’t reach down far enough into the enterprise: if we take a service-oriented view of the enterprise, every activity has a ‘customer’, has its own ‘internal business processes’, and its own capability and need for ‘learning and growth’.)

To extend this further, each of the ‘-ilities’ trails of ‘non-functional’ requirements implies a root-value – for example:

• quality (in terms of the delivered business services or products)
• security (in all its multitudinous variations)
• privacy
• trust and reputation
• health and safety
• environment and waste-management
• transparency and ethics
• efficiency and effectiveness

As described well in TOGAF, each of those themes devolves outward via a set of principles, which ultimately need to link to everything. But on its own, a principle does nothing: it must be applied in practice (hence the importance of governance), and needs to be testable – and that testability must likewise ultimately link down to everything. (Testability isn’t described as such in TOGAF’s definition for the structure of principles, but is described well in Volere, the requirements-modelling process recommended in TOGAF.) The requirement-trees are the means by which the ‘develop awareness’ of the value-trees devolves downward; the tests in those requirements form part of how ‘monitor compliance’ of the value-trees rolls upward.

So a value-tree consists of the following:

• explicit value or ‘theme’, as topmost anchor for the respective tree
• principles that express and describe the value in practical terms (upper branches of the requirements-tree)
• requirements and tests, all the way down to the finest-granularities (both goal-oriented [end-point] and mission-oriented [continual / continuing])
• measurements, with tree of transforms and identifiers for roll-up and drill-down
• support-processes (‘pervasive-services’) for ‘develop awareness’, ‘develop capability’, ‘monitor compliance’ and ‘verify’

Each tree is fairly straightforward in itself: the complications arise from the fact that many of them will present conflicting requirements (e.g. security versus trust, safety versus efficiency). Because of this, there needs to be a tree of relative priorities, some of which may be imposed from ‘outside’ (e.g. legal requirement for priority of health and safety before profit). Ideally, there needs to be one single ‘master-value’ which acts as the ultimate arbiter for priorities – hence the importance of an unchanging enterprise vision.

Better stop there for now: but as usual, comments/suggestions would be most welcome!