Danny Greefhorst of Netherlands enterprise-architecture consultancy ArchiXL emailed me with a query about my book Doing Enterprise Architecture:

I was especially interested in the part where you talk about architecture principles given that I am currently writing a book on that topic. You specifically mention the relationship between values and architecture principles. Do you have specific examples of these values and architecture principles that were derived from them?

The key distinction between values and principles is that values are about emotion - a feeling about something – whereas principles are expressions of thought – a rationalisation, followed by decisions about what to do about that something.

A value is often expressed as a single word, such as ‘safety’ or ‘trustworthiness’ or ‘fairness’.

A principle is usually expressed as a more considered structure: for example, the TOGAF section on Architecture Principles suggests the following:

• an assertion or label such as ‘Business Continuity’
• a descriptive statement (in that example, “Enterprise operations are maintained in spite of system interruptions”)
• a more detailed rationale (e.g. see that TOGAF example)
• a summary of architectural and design implications (ditto)

In thiscase, the principle of ‘Business Continuity’ devolves in part from the value ‘Trustworthiness’: to ensure that we can trust the business to deliver what it says it will deliver, one aspect is that we will need to plan and design for business continuity. The practical implications include concerns such as design for fail-safe and safe-fail (‘brown-out’), monitoring for failure, real-time or near-real-time failure impact-analysis, failover process-choreographies and so on.

(TOGAF v9 ch.23 asserts that “Architecture principles are a subset of IT principles”: this might make sense for IT-architecture, but makes no sense at all for a true whole-of-enterprise architecture. More accurately, architecture principles and IT principles are orthogonal sets which intersect in IT-architecture principles; courtesy of its unhelpful IT-centrism, TOGAF unfortunately treats higher-order architecture-principles and IT-architecture principles as if they’re at the same level in the values/principles hierarchy, which they’re not. This can be seen most clearly in the first principle in TOGAF’s example set, ‘Primacy of principles’: it should be immediately obvious that this would have a broader scope than solely IT.)

Note that there may be a many-to-many relationship between values and principles – for example, ‘Business Continuity’ also has some links to the value ‘safety’ as well as ‘trustworthiness’; the TOGAF principle ‘Compliance with law’ links to both ‘fairness’ and safety’; and so on. Some principles may also have only indirect links to values: the principle ‘Primacy of principles’ is one such example, which in effect applies more to the way in which all principles devolve from values.

Back in March I wrote a fairly lengthy post on ‘value-trees’ in enterprise-architecture‘, which includes this general theme. The example I gave there was a simplistic one about profit as a key value for a commercial organisation:

A suite of principles devolve from this value: for example:

• the outcomes of value-chain processes shall be measured in monetary terms;
• costs of all activities shall likewise be measured in monetary terms (hence techniques such as Activity Based Costing);
• 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
• 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.

There’s more detail on this and how to work with value-trees in practice in the chapter on ‘pervasive’ services’ in my book The Service Oriented Enterprise. If anyone wants me to do a reference-sheet on this, please let me know?

Key point is that:

• vision/purpose is the emotive (literal?) ‘wake-up call’ for the overall enterprise, the means by which we connect with or belong to the enterprise
• values are what we feel about/from that purpose
• principles are what we think about those values (i.e. what we think about what we feel); which in turn lead to
• missions, goals and objectives, that describe what we intend to do to express what we think about what we feel.

Obviously, there is some interaction between those dimensions – what we do challenges what we think and feel, and so on – but there is a sort-of hierarchy here that’s best expressed in that sequence of ‘belong > feel > think > do’.

Hope this helps for now?

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!