Tom Graves / Tetradian

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!