Tuesday, February 02, 2010

What's Wrong with Principles?

Lots of people in the SOA / EA world think that principles are very important. So in this blogpost, I'm going to take a contrarian view.

(Before I start, let me cheerfully admit that I have probably done some of the things that I'm complaining about here, and if you catch me doing any of them in the future, please feel free to give me a sharp dig in the ribs.)


There are four reasons why I think principles (especially lists of principles) are overrated.
  • Purpose / Value - uncertainty about what the principles are supposed to achieve
  • Form - uncertainty about what a principle should look like
  • Source / Material - uncertainty about what a principle should be based upon
  • Process - uncertainty about how a principle should be used.

Form

Let me start with the way that principles are expressed. Lists of principles often include a mixture of assertions, commands, preferences and goals.

For example, here are a few example principles from TOGAF 9 (section 23.6).
  • Requirements-Based Change Only in response to business needs are changes to applications and technology made. (command)
  • Common Use Applications Development of applications used across the enterprise is preferred over the development of similar or duplicative applications which are only provided to a particular organization. (preference)
  • IT Responsibility The IT organization is responsible ... Each data element has a trustee ... (organization structure)
  • Data is an asset ... that has value to the enterprise ... (assertion)
  • Data is shared ... and accessible and defined consistently ... (goals)
  • Maximize Benefit to the Enterprise Information management decisions are made to provide maximum benefit to the enterprise as a whole. (wishful thinking)

And here are a few from PeaF
  • Strategic planning is at the heart ... Relationships are the key to understanding ... (assertion)
  • Adopt a service oriented approach. Adopt architecture best practice. (command)
  • Reusable applications will be favored. ... Reuse will be considered first. (preference)

This kind of confusion is not unique to SOA and EA, but appears in other domains as well. For example, Dave "Cynefin" Snowden's seven principles of knowledge management are generalized observations, which are true except when they aren't. He then adds four organizing principles, which are more like guidelines.


Okay, so there is some variation in the way that principles are expressed. Why should this be a problem? Because it reflects some confusion as to whether a principle is supposed to be true or useful. If we are going to accept a set of principles uncritically then maybe that doesn't matter, but if we are going to evaluate principles and apply them intelligently to a particular situation then the difference between truth and utility is rather important.

At least the TOGAF and PeaF principles have been worked on to achieve some degree of objectivity and verifiability. In other discussions on the Internet, I've found slogans like "Think Strategically, Act Tactically" being described as principles (or perhaps "guiding principles"). These might be useful reminders to the self, but not much use for governance.


Source / Material


Where do principles come from? What is their authority? If everything is supposed to be guided by a core set of principles, then we need to be confident that the principles are right.

I am particularly suspicious of principles that are supposed to be obvious or self-justifying, or are based on majority opinion. If this is something that everyone believes, it is probably either false or not worth stating at all. And anything produced by a committee of experts usually has all the interesting content leached out in order to achieve a bland generalized compromise they can all agree to.


And I am very irritated by websites such as OWASP that publish lists of "proven principles" without the slightest indication of the proof underlying any of these principles. (As far as I can see, any member of OWASP can add anything at all to the Principles page on the OWASP wiki, so the only verification consists in the fact that no other member has bothered to challenge any of them.)

TOGAF 9 (section 23.4) identifies five criteria that distinguish a good set of principles: understandable, robust, complete, consistent and stable. But in my view, the most important criterion is missing here. Principles are like policies, they should be based on robust evidence, they should be monitored for ongoing effectiveness, and subject to revision if the evidence shows they aren't working. This is one of the key differences between a science and pseudo-science - see my post Is Enterprise Architecture a science?



Process


How are principles supposed to be used? Here are some snippets.

  • "Guiding principles drive the IT architecture and the service model, which in turn dictate how the enterprise IT infrastructure services may be defined." (Tilak Mitra, IBM)
  • "The principles of service-orientation can be applied to services on an individual basis, allowing a reasonable degree of service-orientation to be achieved regardless of the approach." (soaprinciples.com)
  • "Each enterprise should have a set of guiding principles to inform decision-making." (Open Group SOA Sourcebook)
  • The purpose of these principles is not to constrain, but to provide a broad cultural framework in which work will be carried out. (PeaF)
  • "As projects begin to define solutions to problems they are assessed as complying with these principles or not. For a project, if all principles are complied with - no problem - no Enterprise Debt is created." (Kevin Smith, PeaF, via Linked-In). 

So there is some variation here - do the principles work as hard policies, dictating and controlling a set of relevant processes and practices? Or do they merely work as soft guidelines, informing decisions and providing a basis for estimating some relevant metrics such as "enterprise debt"?

And if the principles are not so bland as to be meaningless, we should expect occasional tension between different principles. So how do we resolve conflicts between different principles?

The answers to these questions depend on our earlier discussion. If the principles can be traced to robust evidence, then they have visible authority and weight, which gives them particular force in a particular situation. But if they are only bland generalizations, then they will be ignored as soon as they become inconvenient - in which case, you might as well not bother having them at all.


Purpose / Value


So in the end, what are these kinds of principle actually worth?

Principles may be helpful in creating a common narrative about what we are trying to achieve - but if that's all they are, then we don't have to take them too seriously. Some people seem to regard principles as rules that others should follow religiously but they themselves are free to deviate from if they feel it necessary.

To the extent that it is worth having a consistent approach to something, then a set of evidence-based policies should help achieve some degree of consistency. But most lists of principles fall way short of this idea. Instead, a so-called principle may be any of the following ...
  1. something that is always true
  2. something that is usually true (except when it isn't)
  3. something that is always good (or beautiful)
  4. something that is usually good (except when it isn't)
  5. a random thought that someone thinks is important
  6. something that good people believe or follow and bad people don't - a way of separating Them from Us
  7. something that ignorant people should believe and follow, and clever people don't have to - ditto 
  8. something that everyone should always do, except when it's inconvenient

So that's my argument against principles - they may have some limited use, but they are not strong enough to bear the weight that is commonly put on them. I know many of my friends will disagree with me, and I look forward to some robust discussion.

See also What's Wrong With Principles 2 and The Power of Principles (Not)

6 comments:

  1. Well Richard, I believe you have fallen into the trap... First of all: I agree with you 100% on what you say in your post. But... even though many call the examples you give 'principles', they are, in fact not! They are just rules that those who made them up found so 'wise and important' that they erroneously typed as 'principle'.
    As a behavioral scientist I use this (simple) hierarchy of behavior (be it individual or organizational): Principles -> Insight -> Rules -> Behavior. It is called the value-chain of behavior, also used in learning environments. The majority of the examples you gave are rules: for single-loop learning (while true principles provide triple-loop learning and insight).
    Instead of abolishing principles in architecture, lets abolish the mis-use of the very word principle...

    ReplyDelete
  2. I don't see any trap. I'm just responding to the prevailing use of the word "principle" in SOA, EA and other domains.

    And I'm not asking for principles to be abolished, merely arguing that they provide a weaker foundation for architecture than some people seem to believe. Engineers know how to build stable structures on unstable foundations (e.g. earthquake zones) but it helps if you don't have false illusions about the solidity of the rock.

    I'm not familiar with the Principles - Insight - Rules - Behaviour hierarchy. Are you saying that behaviour is driven by principles? That's only plausible if we include inferred principles (POSIWID) for which we have no independent evidence. However, your hierarchy may be useful as an analytic lens.

    There is a lack of consensus about what "triple loop learning" actually means, but if it involves reflecting critically about principles, then that's great. I want architects to think more deeply about principles and where they come from, but at the same time not to expect everything to be derived from a small set of principles.

    ReplyDelete
  3. I think we have to be careful not to say principles in general are bad as opposed to saying that certain sets of principles are bad. And don’t worry I have no problem with the word bad.

    I don't think anyone would argue that having principles is a bad idea so long as those principles are correctly defined and have a good chance of achieving what they set out to do.

    When I set out to write a set of principles, I also saw a mass of rhetoric out there and vague statements. This is why I created the PEAF principles with structure; Rationale (Why does the principle exists? What is the “pain” it is trying to alleviate?), Implications (What will it mean to the organisation), Metrics (How can we measure the effects of the principle) and Tasks (What tasks are required to implement the changes necessary to operate that principle.

    So - since I am always wanting to apply things and move forward in concrete ways (be pragmatic you might say), rather than just have esoteric discussions (which I also like but only while I have a supply of alcohol in one hand and a supply of carbohydrates in the other)I would love to have you and Paul go through the PEAF principles and tell me where you think they fall short or how they should change to be more useful.

    This is not a challenge but a real invitation to make some existing "principles" true principles. So they can be used as a standard bearer to others if they want to define principles correctly.

    You can mail me on Kevin@PragmaticEA.com

    ReplyDelete
  4. Kevin

    I've already said that TOGAF and PeaF principles are a lot better worked-up than some others. The point is not whether these principles themselves could be improved, but whether it makes practical sense to base all architectural reasoning on a relatively small set of simple principles.

    In a lot of cases, I think the principles are useful maxims, but there are too many exceptions and complications for them to be considered as universal truths. You might want to consider documenting counter-indications for each principle - in other words, when is this not true or useful. Or you might consider altogether downplaying the importance of theoretical principles within a pragmatic approach.

    ReplyDelete
  5. Example (edited version of my comment to the Linked-In discussion)

    One of the principles Kevin cited at the start of the Linked-In discussion was "think strategically act tactically". This is expanded in the PeaF documentation as "Decisions should be made to provide maximum benefit to the organization as a whole." A similar principle can be found in TOGAF.

    There are three difficulties in demanding that projects should conform to this principle. The first is that each project may argue that it is thinking strategically; architects disagree; and we just have a difference of opinion generating more heat than light. The second difficulty is that it is not the responsibility of individual projects to maximize organizational benefit. Surely it's the job of architects to assign different benefits to different projects, rather than having each project trying to do as much as possible. If an individual project attempts to maximize organizational benefit, it will probably fail.

    The third difficulty, which I think links to a comment made by Tom Graves, is the fact that what counts as "maximum benefit to the organization as a whole" is highly problematic. Who is calculating the benefit to the organization - the CFO?

    The trouble with trying to govern a complex situation on the basis of a set of simplistic "principles" is that it trivializes the challenges of architecture, and conveys the impression that the people who made up these principles just don't appreciate the devil in the detail.

    ReplyDelete
  6. In his blog, Awel Dico tries to defend the importance of architectural principles.

    I completely agree with the importance of his rhetorical question “Where do these principles come from?” - but he hasn’t answered this question. He tells us what the principles must do (support objectives/goals), but why should we believe or adopt these principles if we don’t know where they come from?

    In agriculture, the principle of crop rotation developed over many centuries, from a three-field rotation in the Middle Ages to the four-field system popularized by “Turnip” Townshend and George Washington Carver. Such a principle has a detailed history, supported by a wealth of observation and measurement and empirical science.

    In mechanical engineering, design principles are soundly based on the laws of mechanics, the properties of materials, and so on.

    By contrast, the principles that are popular in SOA and enterprise architecture often lack any visible grounding in fact, and are justified by appeal to pure reason and the consensus of experts. But the consensus among experts shifts over time, and this encourages a degree of scepticism among those of us with long memories.

    ReplyDelete