Joe McKendrick discusses SOA and reuse in a recent blog entry, essentially drawing on some comments from David Chappell that reuse didn’t do as well as predicted in the era of object-orientation, and that SOA isn’t faring well in this department either. Dave Linthicum, in his latest podcast, also discusses this topic.
I’m not sure I can comment that widely on the state of current SOA projects, and I would agree that SOA may suffer from similar management problems to that of object-orientation: if developers of SOA systems aren’t rewarded for saving time with a reuse strategy, they won’t be enthused to do so. This is an important part of any software project, and encouraging reuse is a best practice that shouldn’t be restricted to object-orientation or SOA.
However, whilst I agree that SOA has other benefits apart from encouraging reuse, I have a fairly high opinion of its potential in that respect. It’s important to understand what we mean by reuse. Reuse rarely means using an object or service as it is. There is often a mismatch between the interface offered by the service (object) being consumed, and the service (object) that needs to call this interface. Expecting anything else is unrealistic (even if future reuse plans are made). This is often solved using something like a façade pattern in object-oriented languages, and some form of mediation with services (such as that offered by WebSphere ESB). The latter is often easier, because there is a lower degree of coupling than inside a single programming language, and because programming code is not often needed, and this is why I believe SOA reuse is simpler - if done well. Of course, some work is still required, but this greater ease of reuse makes it a realistic strategy for more scenarios.
I would agree, however, that, as is often the case, the project management problems here are the greatest ones.