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!

We’d been having a detailed discussion on the internal structure of TOGAF 9, when the following comment came from one of the other participants:

“I see TOGAF 9 as an SDLC method with a bit of knowledge management. Am I missing something?”

It was clearly meant as a snarky putdown, but it’s worthwhile answering at face value.

TOGAF is a method, a framework and various other components that, together, form a quality-system.

As a metaphor, or a very approximate analogy, every quality-system is “an SDLC method with a bit of knowledge management”. COBIT is. So is ITIL, Deming’s PDCA, ISO-900x, Six Sigma, the US Army’s ‘After Action Review’, and many many other examples.

Beyond the metaphor, TOGAF is a (much larger) superset of “an SDLC method with a bit of knowledge management”. In some cases software may be involved in the end-result, but it’s not about development of software as such – it’s about development of the enterprise as whole (hence ‘enterprise architecture’, not ‘software architecture’). There is quite a bit of knowledge involved, but also a strong emphasis on business purpose (i.e. emotional/relational/aspirational, not virtual), and also on dialogue, emergence and ecosystems – i.e. proactive rather than solely reactive.

When assessing the quality concerns within a quality-system itself, the devil is in the detail. Hence there’d been a lot of reference to detail in that LinkedIn thread [and hence the putdown - he couldn't be bothered to read the detail, so he decided to heckle instead]. Once we’ve identified and cleaned up the flaws and inconsistencies in the detail, we can simplify, clarify: simplicity is a desirable characteristic for an SDLC-like quality-system.

At the end, we’re after simplicity without being simplistic. Describing TOGAF as “an SDLC method with a bit of knowledge management” is a usefully simple analogy; but unless there is awareness of the detail behind that simplicity, it risks being dangerously simplistic.

By analogy, trying to build a house with virtual bricks and imaginary girders is not a good idea: looks good on paper, perhaps, but doesn’t work in practice. Likewise, trying to develop an enterprise with a software-development method is not a good idea. That’s the real distinction here.