Reusing interfaces

Richard Veryard has some interesting things to say about reuse in the SOA world. It's a problem I've been thinking about, too - but from a very different direction. Reuse isn't just about using the same piece of code again and again across your business' many applications. It's also about ripping and replacing code without affecting all the applications that use it. In the past reuse has been avoided as this element of the philosophy could have undue effects on key business operations... SOA changes the status quo. The key seems to be that effective SOA demands what I think of as "interface first" design. Often thought of as "design by contract", this approach fixes the properties, methods and events offered by a service. What it doesn't do is define the code that delivers the service elements. If an application only needs to be aware of a service's interfaces, then an application instance can be switch from using service V1.0 to V1.1 without affecting operation, as long as V1.1 offers the same service interfaces as V1.0. A major change, V 2.0 could still offer V 1.0 interfaces at the old service URI, with new functions at an alternative service URI. Rip and replace without affecting consuming applications. A definite benefit of the SOA world.