Thoughts on the SOA Workshop

Last week, I attended an SOA workshop presented by SOA Systems and delivered by “top-selling SOA author” Thomas Erl. It was two SOA-jammed days + the drive to Vancouver and back primarily discussing SOA with Dale. In other words, it was a lot of SOA. I went up expecting to take Erl to task for his “Services are Stateless” principle. However, that turned out to be a misunderstanding on my part about how Erl uses the term stateless. However, while Erl and I agreed on optimizing memory utilization (which is what he means by stateless), that wasn’t much else when it came to common ground. As I wrote last week, Erl’s vision of service-orientation is predicated on unrealistic organizational behavior and offer at best unproven promises of cost and time savings in the long run via black box reuse.

Erl spends a lot of time talking about service reuse. I think it’s safe to say, in Erl’s mind, reuse is the primary value of service orientation. However, he didn’t offer any reason to believe we can reuse services any more successfully than we were able to reuse objects. Furthermore, his predictions about the amount of reuse you can achieve are completely made up. At one point, he was giving actual reuse numbers (i.e. 35% new code, 65% existing code). When I asked him where those numbers came from, Erl admitted that they were “estimates” because “there hasn’t been enough activity in serious SOA projects to provide accurate metrics” and that there is “no short term way of proving” the amount of service reuse. In other words, Erl made those numbers up out of thin air.

This whole “serious” or “real” SOA is a major theme with Erl. One the one hand, I agree that SOA is a horribly overused term. Many projects labeled SOA have little or nothing to do with SO. On the other hand, it seems pretty convenient to chalk up failed projects as not being “real” SOA so you can continue to spout attractive yet completely fictional reuse numbers. I asked about the Gartner’s 20% service reuse prediction and Erl responded that low reuse number was because the WS-* specs are still in process. While I agree that the WS-* specs are critical to the advancement of SO, I fail to see how lack of security, reliable messaging and transactions are holding back reuse. If anything, I would expect those specs to impede reuse, as it adds further contextual requirements to the service.

While I think Erl is mistaken when it comes to the potential for service reuse, he’s absolutely dreaming when it comes to the organizational structure and behavior that has to be in place for this potential service reuse to happen in the first place. I’m not sure what Erl was doing before he became a “top-selling SOA author,” but I find it hard to believe it included any time in any significantly sized IT shop.

Erl expects services – “real” services, anyway – to take around 30% more time and money than he traditional siloed approach. The upside for spending this extra time and money is the potential service reuse. The obvious problem with this is that we don’t know how much reuse we’re going to see for this extra time and money. If you spend 30% more but can only reuse 20% of your services (as Gartner predicts), is it worth it? If you end up spending 50% more but are only able to reuse 10% of your services, is it worth it? Where’s the line where it’s no longer worth it to do SOA? Given that there’s no real way to know how much reuse you’re going to see, Erl’s vision of SOA requires a huge leap of faith on the part of the implementer. “Huge leap of faith” doesn’t go so well with “corporate IT department”.

Furthermore, the next IT project I encounter that is willing to invest any additional time and money – much less 30% – in order to achieve some theoretical organizational benefit down the road will be the first. Most projects I’ve encountered (including inside MSIT) sacrifice long term time and money in return for short term gain. When asked how to make this 30% investment happen, Erl suggested that the CIO has to have a “dictatorial” relationship with the projects in the IT shop. I’m thinking that CIO’s that adopt a dictatorial stance won’t get much cooperation from the IT department and will soon be ex-CIO’s.

In the end, I got a lot less out of this workshop than I was hoping to. As long as SO takes 30% more time and money and the primary benefit is the same retread promises of reuse that OO failed to deliver on, I have a hard time imagining SO making much headway.

PS – I have a barely used copy of “Service-Oriented Architecture: Concepts, Technology, and Design” if anyone wants to trade for it. It’s not a red paperclip, but it’s like new – only flipped through once. 😄

Comments:

Ouch!
> PS - I have a barely used copy of "Service-Oriented Architecture: > Concepts, Technology, and Design" if anyone wants to trade for it >It's not a red paperclip, but it's like new - only flipped through once. :) I have a similar experience with his "Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services" :) Arnon
It came to me a while back that half the time I talk to someone about SOA, we aren't even talking about the same objectives. Working for an ISV, we try to think about service-oriented application design rather than the target implementer's enterprise architecture. They are different things. I agree you can't expect reuse in SOA to materialize any differently than you would for objects. Cohesion is cohesion. But if you can design an application to at least minimize the invasiveness required to deploy that app into someone else's enterprise architecture, you can get some economy back reminiscent of "reuse". Anyway, I wrote up some thoughts along these lines over the weekend on the 'ol blog.