Response to Rockford Lhotka’s SOA rant

Here is his rant., the SOA Elephant in the room.

It’s strange to hear myself commenting on SOA at all honestly, but for a variety of reasons, Udi Dahan’s blogging not least among them, my mind seems to have turned a corner on SOA. SOA puts a line in the sand about how to divide up large domain models along business lines and that is a very good thing. But this is not what Rocky wrote about.

This is an excellent post, ranting about the over hype of SOA while at the same time putting forward a nice definition of both syntax and semantics as it applies to SOA. I do have a counter point though about his dislike of the semantic coupling. The point of SOA is *not* to standardize services between providers. There was an effort some time ago to build industry vertical schemas and that has failed in almost every case. That’s the syntax standardization! No, SOA should probably be looked at instead as a way to “explain” your business clearly and what is unique about it via the services you have to offer. If your business is not unique, that defines it as a type of commodity business, and that is not a good thing for many many types of business.

While speaking at SD Best Practices in September I had a chance to sit and talk with the always engaging Christian Gross and his adventures into the SOA world. He observed the same point as Rocky but came to a different conclusion. He was interfacing to a service provided by a high end brokerage and started down a typical path where he thought he should abstract out the specifics of that brokerage. He made two mistakes in his view. He set off coding away the abstraction to minimize the semantic differences between his need of the brokerage and how the brokerage actually worked. Then he exposed it via a service to the rest of his application. What he realized was that 1st, he now had two abstractions, the interface in the code and the service, when all he needed was one, the service. Second he realized that if the abstraction was at the service level, he could code the service to go against the brokerage api exactly as it needed to be used. If he would change brokerages he would just start over with a new implementation and his (internal) consumers would be none the wiser.

To answer Rocky’s point then. Yes, services will and should provide different semantics. Because you will typically not have lot’s churn with the partners you interface with the impact of the change should be small. If you’re find struggling with this issue, you may be expecting the business to be a commodity when it isn’t.


Comments are closed.