I was discussing the notion most recently with some clients who stated that SOA has failed and that many of their SOA deployments were a failure. I probed to better understand the nature of the failure and could not reach any conclusions about the specifics. It’s rare to hear someone say that the remodeling of my house was a failure. In fact most people would say I had a bad contractor, the project was not done correctly, the project was under estimated or the remodel failed to meet my expectations. In fact one would cite any number of specific reasons but not say the remodel was a failure.
When one does a renovation of their house or a room in their house is the goal renovation or remodeling? I do not think that is the goal, the goal for remodeling the kitchen may be to enhance its look and feel, to introduce superior appliances or any number of specific measurable goals. But the homeowner would never describe the goal as remodeling.
In a like manner, SOA should never be the goal. SOA is a means to an end, an approach, a strategy, a way of doing things. So how can SOA be a failure given this context? What were business the goals or aspirations? Were the specific benefits of adopting SOA defined? Were they measurable? Or did the project assume benefits of SOA would magically come about because the project was classified as a SOA project. What makes the project a SOA project? Are all SOAs created equally? Do all SOAs bring about the same value? The answer is clearly no.
In fact it’s not correct or rigorous to describe or discuss SOA failures as architectures cannot fail, their application and means of adoption might fail. It reminds me of the discussions I have had with developers who describes Web services as slow. Really? Isn’t that relative? What makes a technology slow? Compared to what?
My message is we ought to as software engineers apply some rigor to our thinking about SOA. I will discuss more on this subject latter.