First there were SOA principles, then came anti-principles. While SOA architects and developers are still arguing what those really mean and how to apply them, in his new post Steve Jones presents a third concept - non-principles. According to Jones, while creating SOA (or any other software implementation for this matter) you typically have to deal with:
- The principles - what good looks like and is measured against
- The anti-principles - what bad looks like and is measured against
- The non-principles - what you really couldn't give a stuff about ...
As Jones explained in his post:
... [while] the non-principles... might sound like an odd concept... it’s one that has really paid dividends for me over the years. While Principles say what you should do and anti-principles say what you shouldn't, the non-principles... is something that you don't give a stuff about. You are explicitly declaring that it’s not of importance or consideration when you are making a decision.... While you can evaluate something against a principle to see if it is good or against a non-principle to see if it is bad the objective of the non-principles is to make clear things that shouldn't be evaluated against.
Translating this in a familiar terms - non-principles is something that is explicitly defined as a non-goal for a given implementation. The introduction of non-principles provides the ability to deliver on time and on budget by ignoring some of the quality requirements, which are not part of the stated goal of a given implementation. According to Jones:
... the non-principles are very context specific and are really about documenting the perceived wisdom that is wrong from the programme perspective. The non-principles are the things that will save you time by cutting short debates and removing pointless meetings... Non-principles clearly state what you will ignore, they don't say what is good or bad because you shouldn't measure against them...
To prove his point Jones gives several examples from the projects he participated in where the use of non-principles was instrumental for project’s success.
Although it is hard to argue about the importance of principles and anti-principles in an SOA implementation, the introduction of non-principles seems slightly artificial. The issue here is that in reality there are no non-principles, but rather implementation goals and consequent architectural tradeoffs. If we take Jones’ first example - "performance not an issue", it does not mean that performance does not matter. What it means is that performance is not the most important architectural goal of the implementation, but there is typically still a performance constraint for a given implementation which has to be met (although the actual number can be relatively high). His next example - "data quality is not important" - again, it does not mean that a new system can contain inaccurate data. It really means that data quality improvements were not stated as direct goal of the project.
It is extremely important to understand what the overall goals of an implementation are and to make appropriate tradeoffs, but it does not seem to qualify as a completely new category - non-principles. Rather, it seems that we need to realize what is really important for a given program and focus on that.
