SOA- Buzz jargon or?

Post date: Mar 28, 2012 7:53:48 PM

During last decade we have seen lots of buzz words, jargon and new technology innovations. Idea behind all those initiatives was to improve quality of services, quality of software development. People were trying to achieve this by making processes better to produce better quality, reduce cost or by better taking care of non functional requirements.

Lot many of these initiatives really disappointed developer community and business community (end users who spent money on software solutions) .

Reason behind this disappointment is big promises and attempt to make money out of everything, every buzz-word, every jargon. Big vendors started making money without standardizing things and started implementing standards in non standard way or proprietary way.

(see my post "Open Source - Innovations and a bitter truth" for more detail).

Confusion

Now sometime people ask me whether SOA is also similar buzz-word, a jargon and an attempt by big vendors to make money out of it. Let us try to analyze it.

1. Is SOA an architectural style ?

2. Is SOA a way of implementing software so that you can expose business functionality in a standard way, as a service ?

3. Is SOA for integrating existing systems in a standard way? By exposing standard interfaces of business functionality as a service.

4. Is it for a new system being developed from scratch? We should create new business functionality as SOA services ?

5. Is SOA a tool, and IDE, a server???

If answer to first four questions is yes then you may ask "what these vendors are doing here and what they are trying to sell?"

Real value of SOA

1. By its definition and its concept it should not be bounded to a vendor.

2. It should not be specific to a vendor

3. It should not have vendor specific implementation other wise what about interoperability. seamless integration, integration between two business partners having their businesses running on different platforms, softwares etc.

4. Concept of SOA is really good. It has worth considering it.

Why is confusion then?

1. To make money vendors are trying to suggest that SOA is something they have implemented in their tool and it is specific to their tool. If you will get their suite of software then only you can implement SOA.

2. Vendors are not talking about standards. They are not convinced on a single specification. And even people (big vendors) want W3C to keep a distance from SOA and focus only on web.

3. Some effort is going on in open source, vendors are making their own tools on their own specification. It suites their business.

Even if answer to question 5 above is yes (which is not correct) then to make it standard based tool (is it a tool at all?) it should have exactly same standards and specification. So then what different vendors will sell if tools will be based on standards? That is why they (vendors) try to create impression that SOA can only be implemented by their server and IDE.

People may argue that vendors are making SOA simple or its implementation simple by providing tools. But let me know if they are trying to make it simple then are they following same specification. If I have created half of my work with one vendor's tool can I continue with other vendor's tool. No not all.

Solution

It is similar to development methodologies. People were trying to sell a development methodology (by giving Unified Process a proprietary name) as their tool or product. You know very well you need to adopt process or methodology. Tool is not so important. Same was the case with development tools or IDE's. Some time back people were trying to sell IDE's too at very high price. But specific thing in their IDE was really not a necessity and it has been proved by open source IDE's

Vendors should sit together and seriously consider standard specification and its implementation.

Vendors should contribute in standard specification and research, should not take interest only in selling anything half cooked.

Community should reject proprietary things and focus on standards and specifications.