SOA, reuse and rabbit-holes
I've gradually become aware, over the past weeks, that I - and a lot of other people - have fallen down a bit of a rabbit-hole when it comes one aspect of SOA. I've been talking a lot about the value of SOA - and in my conversations with people about that, one of the key elements I've talked about is "reuse". I've seen a lot of other people talking about reuse in the context of SOA, too (see
here and
here for two blogospherical examples).
But last week I finally became convinced:
reuse is the wrong word for what people think about when they think about how services get published and consumed in SOA. A much better word is
sharing.
Why? Because
reuse is a loaded term, which makes people think of object-orientation or component-based development. It's associated with replication of software. If I'm reusing an asset, I copy the code, the libraries, the package, whatever; and I use a copy of it in a new context (quite possibly altered a little bit, if I'm going for "white box" rather than "black box" reuse). But this is not what happens (or at least, it's not what should happen) in SOA. What should happen in SOA, is that an overall requirement is factored to draw out opportunities to implement common services that are used in multiple contexts.
More seriously than that, though,
reuse is the wrong word because it's a term which allows us to be lazy, and focus exclusively on the technological and organisational details of how you build systems. [Let's face it, in the software industry we're all much more comfortable thinking about software development issues than we are thinking about other things (like how to make systems manageable, for example)].
Sharing is a better word because it forces you to think not only about the implications of SOA on developers - but the implications of SOA on the IT organisation, and indeed on companies as a whole.
Thinking about
sharing makes you start thinking in a more holistic way about SOA, which is much healthier in the long run. In particular, it makes you think properly about one of the critical success factors of SOA initiatives: getting a governance model in place. Specifically, as soon as you think about
sharing you realise that by having a consumer use an existing service, you are placing obligations on both the consumer and on the organisation as a whole. If I
reuse your code, then we both have a copy. Lovely. But if I
share your service, you need to know about that, because you need to ensure the service scales, and that your support for it can scale, too. I will probably need to be prepared to contribute to funding for these things.
Sharing of a capability implies sharing of benefit; but also it implies sharing models for cost and risk.
Of course, I have my own legacy to deal with now. I'm just trying to decide whether to go back to all our existing articles, reports and blog entries which refer to "reuse" in the context of SOA, and update them...
