Non-drivers for SOA

When people are establishing their SOA elements one of the important set of elements that gets captured are the principles and drivers for the architecture. What is sometimes over looked, but is equally important, are the non-drivers and non-principles for the adoption of SOA in the organisation. These things fall into two broad groups firstly the common myths of the organisation, and secondly the implementation details that need to be either factored in during implementation, or factored out.

The idea here is to establish the things that either aren't important, or just aren't actually an issue that needs considering. One common one I've found in the last few years is performance, the only times I've seen actual performance issues is when the application has been badly designed or implemented, the capacity of most hardware today really does make performance a secondary concern. If you don't currently have any performance issues then performance is a non-driver for your SOA, this doesn't mean its not something to look at during implementation, but that you shouldn't be optimising your SOA for performance. Another example of these myths is "we can't do that sort of thing here" this is often brought up because some previous IT elements have failed. You really can't afford however to have a driver which is basically acceptance of failure, its something to lob on the risk log but you shouldn't be looking at SOA from the perspective of lowest common denominator.

The second group are the things to worry about later "Our project Management approach doesn't handle services", "I'm not sure how our procurement rules would work", "Our use-case templates don't mention services", "We don't have a services document in the project portfolio and others of that ilk here. These are again non-drivers for the architecture as they are about the things that happen next. This doesn't mean that you sit in an ivory tower appart from implementation but that these are exactly the things that you need to look at once you have a proper service architecture and are looking at how to roll it out across the organisation, these are the operational challenges rather than fundamental barriers.

The point of having these lists of non-drivers is that it helps to close down discussions once you've agree what they are. This helps you to focus on the real drivers and principles and to shutdown pointless avenues that don't deliver any value.

There is a phrase that half of being smart is knowing what you're dumb at, there is an equivalent here, half of good SOA is knowing what is important the other half is knowing what isn't.

Technorati Tags: SOA, Service Architecture