Interoperability and substitutability

One of the benefits of interoperability is substitutability: the ability to take one software application from one provider and put in its place another application from a possibly different provider. Open standards enable interoperability and hence substitutability.

If I were an IT customer and I was looking at software, either open or proprietary, I would ask the usual sorts of questions about features, performance, license, scalability, security, training, and initial and recurring costs. I would ask about interoperability, but not just with products from the same provider. I would want to go beyond simply connecting to systems on other platforms, other operating systems. I would want that new product to be able to fully share the appropriate information with any other application that I might want to involve in the execution of any business process that I have. In my opinion, open standards are the way to get that kind of interoperability. Anything that locks me into software from a single provider is a strong negative.

There is another question that I would have that I would try to get answered, even though it might be an unusual query to pose to a salesperson or evangelist. That question is: “What are the features and characteristics of your software that will let me rip it out and replace it with software from another provider in 6 months, a year, 3 years?” Ouch.

Try putting that into an internal product plan: list of features that let users switch to software from other providers, possibly open source. Have you done that? If you are a J2EE implementor you have. If you provide an ODF-compliant application you have. Providers of software that implement open and non-vendor controlled standards are used to living with the higher level of risk that substitutability engenders. How do you keep users and customers? You just provide software with better performance, better UIs, lower cost, more reliable security, greater interoperability, better and more current standards support, and so forth.

I’ve tried to be generic in my language above to not slant the discussion toward providers of open source or proprietary software. Indeed, one of my arguments at the UN last week was that an open source adoption policy without the prior or concurrent creation of an open standards policy is likely to fail. Nevertheless, when you are negotiating with a commercial vendor, make sure you ask the substitutability/open standards question and make sure you satisified with the answer.

Open standards are at the core of what makes SOA work. You need these standards for protocols, APIs, and formats in order to push information to and from services. Substitutability is a goal of SOA. You want to be able to use any service that meets your quality of service, geographic, and cost requirements. If that service doesn’t do what you want, just make an arrangement to start using another one, using the same interfaces. If you need to add another service to meet your scalability needs, just build, borrow, or lease one. The nice thing about SOA is that the service is a black box: you don’t need and don’t want to know how it is an implemented. This is substitutability.

This entry was posted in Standards and tagged , , , , , . Bookmark the permalink.