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
1 comment:
Its a very nice blog for...
architects in bangalore , architects in bangalore , interior designers in Bangalore , interior designers in Bangalore , architects in bangalore , architects in bangalore , interior designers in bangalore
Post a Comment