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!