Principles, values, ends and means

What are principles? And are they ends or means?

This came up in a great conversation the other day with Kevin Smith, creator of the Pragmatic Enterprise Architecture Framework (PEAF). He’d been having a fairly intense online discussion with another EA colleague, who’d asserted that the set of principles in PEAF were not proper principles for architecture. But when I take a quick glance at the published principles in PEAF, they’re certainly part of what I would use in practice as architecture-principles: “think strategically”, “plan ahead and organise”, “have a sound business case”, and so on. It’s true that some are phrased more like tasks than principles – “manage enterprise debt”, “compliance”, “relationships and traceability” – but in general they conform well to the definition of the term ‘Principles’ in the TOGAF specification:

Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission.

In their turn, principles may be just one element in a structured set of ideas that collectively define and guide the organization, from values through to actions and results.

(Given the clarity of that definition above, I can almost forgive the TOGAF crew for the absolute howler of a mis-definition that follows a few paragraphs later: “Architecture principles are a subset of IT principles that relate to architecture work.” That one sentence alone epitomises all of the asinine IT-centrism that permeates almost every part of TOGAF, and that renders it all but unusable for anything other than IT-architecture. Oh well.)

One of the key points here is the interrelationships between principles. There’s structure here, part of which, as TOGAF suggests, is a straightforward decomposition-hierarchy:

These sets of principles form a hierarchy, in that IT principles will be informed by, and elaborate on, the principles at the enterprise level; and [IT]-architecture principles will likewise be informed by the principles at the two higher levels.

But it’s not solely a simple hierarchy – in fact it’s more like a meshwork of hierarchies of values and principles, all competing for our attention, and all of which, as architects, we must somehow sort out into an appropriate priority-order. What we might think of as ‘the organisation’ is, in practice, an intersection of many, many distinct shared-enterprises at many different levels: not just the enterprise to which the nominal ‘the organisation’ is aligned, but the shared-enterprise of accounting and every other professional-discipline, of health and safety at work, of state-security and social-security, and so on and so on. The selection, implementation and prioritisation of principles is where an organisation connects with an enterprise. So it’s a kind of multilayered Venn-diagram of “general rules and guidelines” where what might seem to be ‘values’ to one person are ‘principles’ to another, ‘policies’ to another, and explicit instructions to yet another person again. No wonder it’s confusing; no wonder it seems a mess…

To take just one theme – which seems to be the point of contention between Kevin and his colleague – would we say that principles are ‘ends’ or ‘means’? The standard Business Motivation Model (BMM) might seem to imply that it can only be one or the other; but in reality, even in the BMM, the right answer is “Yes”. (In the BMM, Principle is an Influencer is a Directive is a Means OR is a Desired Result is an End.) So principles are both ends and means, depending on which way we look at them:

• an enterprise-vision is expressed by one or more values
• in essence, a principle is a practical expression of one or more values
• looking ‘up’ in the values-hierarchies, a principle or value ‘above’ will seem to be an End, pointing upward to enterprise values and vision
• looking ‘down’ in the values-hierarchies, a principle ‘below’ will seem to be a Means, pointing downward to policies, procedures, work-instructions and specific activities (as per ISO-9000, for example)

So in effect, a principle is a bridge between Ends and Means. The TOGAF specification again gives some useful advice on how to specify principles:

• name: the essence of the rule in an easily-remembered form – typically just two or three words
• statement: a succinct, unambiguous summary of the rule – typically one sentence only
• rationale: typically a single paragraph describing the reasons and benefits of following this principle
• implications: a brief summary of typical practical impacts of this principle on tasks, costs, opportunities, risks, responsibilities and so on – and the implications of what may arise from not following the principle

(Note, though, that this doesn’t indicate how to identify and describe the relationships between principles – especially the complex ‘multiple-inheritance’ relationships that usually apply to the detail-level principles that we need for real-world implementations. We’ll need some kind of meshwork-model to describe those relationships, much like a thesaurus linked to a standard glossary.)

One of the key practical differences between principles and explicit Ends (such as goals or objectives) is the way in which the classic SMART criteria will apply:

• Specific: the principle and its context and applicability should be specified unambiguously, as above
• Measurable: the principle is usually not measurable in itself, but defines the reason and context for metrics, and performance in relation to the principle must also be measurable
• Achievable: the principle is never ‘achieved’ as such, but remains as a constant guideline or aiming-point
• Relevant: the cross-linkages ‘up’ the values/principles hierarchies define ‘relevance’ for the enterprise
• Time-bound: a principle is “intended to be enduring and seldom amended”, hence time does not apply in the same sense as for a goal or objective – but metrics in relation to principles should usually be time-boxed

Crucially, performance in relation to a goal is typically measured at the end of execution, when the goal is (or should have been) achieved; but because the principle or value does not actually have an end-point, performance in relation to a principle should be measured during execution, typically at regular time-intervals or other identifiable reference-points.

So to answer Kevin’s specific question, principles are both ends and means – and hence also neither ends nor means. Since both and neither are true, it’s the way we choose to view them, and also view them in relation to each other, that determines whether we would use them as ends or as means in any given context. And clarity on how we describe them and link them together will help a lot in making an appropriate choice in each case, too.

Hope this helps, anyway.

[Update: 01 October 2010] A reminder from Kevin Smith that part of our conversation touched on KnowledgeGenes. In that model, each entity has four dimensions: Why (leftward), How (rightward), What-is (upward), and What (downward). Given that framing, the ‘hierarchy’ from vision to values to principles and so on would be shown as a sequence from left-to-right (Why to How) or right-to-left (from How to Why). The same point as above would apply: a principle in itself is neither an End nor a Means, neither a Why nor a How, but an identifiable point between them.

I’m not sure that KnowledgeGenes is complete enough for all enterprise-architecture needs, but it’s certainly one way to help clarify our thinking on the bridges between vision, strategy, tactics and operations. Well worth exploring further.