Prompted by a rude comment about me that my pal Lawrence found on a Google group, I spent the weekend thinking about the title of this blog.
It's no longer just about Service-Oriented Architecture (SOA), if indeed it ever was. I have always spent a lot of space talking about business architecture and enterprise architecture, believing that these topics are important in their own right, as well as essential for getting SOA right. On the more technical side, I have talked about process architecture and event architecture, as well as service architecture and engineering - again with the belief that these topics must be linked somehow. There are architectures of trust and security, architectures of knowledge, learning and intelligence, and architectural issues going beyond the boundaries of the enterprise into the ecosystem.
So I'm going to try calling it Richard Veryard on Architecture. SOA fans will continue to find useful and thought-provoking ideas about service architecture and the service-based business, and I hope to reach a few more SOA sceptics as well. Meanwhile, you may also wish to subscribe to my other blogs: Richard Veryard on Computing for general stuff on the software industry, and Demanding Change for systems thinking and organizational transformation. And I am richardveryard on Twitter.
Monday, February 15, 2010
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.
For example, here are a few example principles from TOGAF 9 (section 23.6).
And here are a few from PeaF
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.
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?
How are principles supposed to be used? Here are some snippets.
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.
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 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 ...
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
(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 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 ...
- something that is always true
- something that is usually true (except when it isn't)
- something that is always good (or beautiful)
- something that is usually good (except when it isn't)
- a random thought that someone thinks is important
- something that good people believe or follow and bad people don't - a way of separating Them from Us
- something that ignorant people should believe and follow, and clever people don't have to - ditto
- 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
Subscribe to:
Posts (Atom)