The number of times I've seen the following in a "business" case for SOA in the last 8 years has been immense
- We need to adopt Web Services
- We need an ESB
- We need a business rules engine
- We need a BPEL engine
- We need to do "agile delivery"
- We need to do REST
- We need to do Web 2.0
By doing this we will increase our agility, flexibility and costs and it will only cost double what you currently pay in a year for two years to get it done.
Let me sum up what any sensible business hears when the business case says that....
There is a load of new technology that we want to play with, just like last time we will promise you lots of improvements but when asked won't actually be able to give you any real detail beyond handwaving, and lets face it the last 10 times you gave us the cash we delivered bugger all actual benefit.
Pitching REST, WS-*, ESBs etc is exactly what SOA should not be doing. Its about time that IT started looking at genuine business cases and signing up to explicit measures. Who cares if you use REST, WS-* or flying monkeys to do something, if you've committed to delivering a 10% increase in sales then the choice is yours.
By continually pitching a technology centric view of the world IT will continual to marginalise itself and prevent any genuine progress being made.
Technorati Tags: SOA, Service Architecture
5 comments:
I always come back to your InfoQ post on SOA anti-patterns and in particular "The people's republic of IT" anti-pattern... again and again and again I see organisations that have fallen into this trap, even when they haven't started out that way, over time the tail has started to wag the dog!
Your focus on the why of SOA is refreshing given the seemingly myopic focus of most of the IT community on how a SOA might be implemented. Thanks for sharing your insight on this interesting topic Steve.
I agree. The technologies themselves are neat and cool, but what gets done with them for just their own sake is always a disaster.
This is true of most 'new technologies' since the incremental gain in efficiency, if there is any, never outweighs the cost, or unintended consequences, of their implementation.
WS I think was a sufficient leap from the older but still perfectly workable RPC/COM/CORBA stuff to be worthwhile. WS*, REST, jini, etc. are mostly just complicating factors.
Hi Steve and others. I wrote the InfoQ blog that triggered this criticism. My opinions have been shaped by engagements over the last couple of years in mid-sized companies that are typically well on their way to implementing SOA infrastructure software (rightly or wrongly). I certainly see great value in communicating the big picture, in which software is a small part, and a later part, in moving towards SOA. The technology is the "last mile" of SOA, after the appropriate organizational and process transformations have taken place. Thanks, Steve, for helping make this clear.
I've added a comment to the InfoQ article here here. I'd love to hear opinions on the definition of a "service", and also the pitfalls of letting business process definitions drive the definitions of services ("services" they way I define them, I should say ;-).
The process point is one of the most dangerous ones IMO. Equating a service to a step assumes that a service offers only a single capability and that all business elements are done via processes. Not only have value chains been replaced by value networks, meaning that process orientation is less business centric than previously, but also large amounts of organisations do not operate on simple step oriented business processes. I have seen POA (which is what you are proposing) work reasonably well for package extension work where process is the dominant metaphor, but I have seen this literally destroy complex programmes due to the lack of flexibility that it gives.
Technology isn't, IMO, the last mile of SOA its more like a part of the infrastructure. In the same way as a Telco could replace the exchange without you caring so you could replace the EAI with ESBs and the business wouldn't care. The last mile is the mentality shift from thinking in terms of processes and steps into thinking about services and interactions. It is the mentality shift of doing services that represents the change.
It might be true that smaller businesses find the technology oriented approach reasonable, but as you say the problem gets exponentially larger and more complex with larger businesses and I'd say that from experience a technology centric approach will deliver at best a minor incremental benefit, will normally deliver no noticeable benefit and on a reasonably frequent basis will leave the organisation worse off.
I have regularly advised people to cancel SOA programmes which have focused purely on the technology and judging by the results of those that take the advice over those that don't I'd say that technology centric SOA delivers less benefits on average than not doing it!
In terms of what I'd recommend to do.... Read the InfoQ book
Post a Comment