Tom Graves / Tetradian

How do we use Alex Osterwalder‘s Business Model Canvas for the business of a not-for-profit organisation? Or, for that matter, the non-monetary aspects of a commercial organisation?

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…

Read more…

More enterprise-architecture stuff, this time about the relationship between trust, value and money.

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.

Read more…

There’s been a fairly lengthy argument on the LinkedIn business-architecture list about the role and meaning of ‘value’ in business-architecture. As usual, most of the US contingent leapt off onto the red-herring of ‘shareholder-value’, which to me is almost completely irrelevant to the actual design and structure of a business-architecture – it’s an outcome, not an input as such.

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?

Over on the Enterprise Architecture list on LinkedIn, Bala Somasundaram asked about the concept of value-trees as a means of tracking compliance to enterprise values, and thence as a means for validating the value of enterprise architecture.

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!