What is Proprietary?

I have been thinking a lot about this subject lately (a lot is all relative). Two subjects that are getting a lot of air time these days are Open-Source software and SOA's. One word that seems to come up a lot in any conversation about SOA's and Open-Source software is "Proprietary". So I asked myself, what is proprietary and should I care? I am just going to talk about SOA's for now. I will address Open-Source at a later time. You can hardly wait, I can tell.

Some of the new upstart SOA proponents warn against using proprietary technology in your SOA. The finger is quick to point to the evil expensive proprietary traditional EAI vendors as what is wrong in the world. Standards based solutions are the way to go, otherwise you get locked in and interoperability becomes an issue. These vendors typically also point out that there solution is 100% standards based and they do not use any proprietary technology.

So what's the truth to that claim? Are you going to get locked in with a traditional EAI vendor? Are interoperability issues going to plague your until retirement and be passed on to your children? The answer is yes and no. So let's add another concept, it is called the provider. Let's use Java's JMS (Java Messaging Service) as an example. JMS is really nothing more than a series of interfaces and api's with no real meat. It is up to a provider (SonicMQ, webMethods, Tibco, MQ Series, etc) to provide the meat for JMS. The interfaces and api's are contracts that more or less bind the provider into providing a set of services that are standard across the board.

Just like in life however, contracts are open to interpretation. Each vendor selects and interprets which set of api's and interfaces they are going to implement and support. So your nice JMS client over here may not be your nice JMS client with a different provider over there. So while the idea of standards sounds nice, the reality is a little more complicated. It is really up to the architect and the developers then to know the standards very well and know when the provider is deviating from them. Otherwise your highly touted portable service becomes something more akin to an anchor.

This brings me to my point (you thought I would never get there). Underneath the covers there is always a provider. And swapping out providers is almost never an easy thing to do. Spending more time on the principles of loose coupling, abstraction and common data models regardless of the technology provider will pay off in a much bigger way than spending time chasing ever moving standards and the vendors that are touting them. There are no bad standards, just bad providers. Okay I was trying to use the dog analogy but it doesn't really work because there are some bad standards. The point is, standards are a good thing but they are just a part of the total solution.