News Stay informed about the latest enterprise technology news and product updates.

Vendor-oriented architecture hampers SOA – Zapthink

SOA, as a concept, pre-dates any of the current SOA products, but IT has now put the cart before the horse, buying SOA infrastructure first, argues ZapThink's Ron Schmelzer.

Service-oriented architecture (SOA) is now touted by vendors as a new approach to business computing, but Ron Schmelzer, senior analyst with ZapThink LLC., likes to point out that the concept first surfaced in 1996.

I think it's the vendors who are actually preventing SOA adoption, whether they know it or not.
Ronald Schmelzer
Senior AnalystZapThink LLC.

Of course, there were no SOA tools or other related products in 1996, but some organizations began doing SOA anyway, which the analyst sees as a good thing. It is something that SOA proponents, architects and developers might do well to keep in mind as they are inundated with pitches from SOA product vendors, he suggests. SOA is now at the point where it needs to prove itself, Schmelzer says, and it doesn't need more technology.

He sees a disconnect caused by vendors marketing products for Web services integration and their customers who think they are buying SOA.

"SOA as a concept was first defined in the 1990s," Schmelzer says, noting that Gartner Group Inc. outlined the concept in 1996, which pre-dates the coining of the term "Web service" in 2000. He believes this is significant for several reasons.

"First, SOA predates Web services," he said. The architectural concept does not depend on Web services, as advocates of building SOA with Java Messaging Services (JMS) are quick to point out.

"Second, people who were doing SOA [circa 1996] were obviously doing it without the products that are currently in the market," Schmelzer said. "So are these products providing any value?"

The answer he said is that with the exception of tools for composing and consuming services, providing security and management, and registry/repository tools, most of the products being marketed today under the SOA banner, are "traditional integration middleware with a veneer of Web services."

He is particularly adamant about the fact that SOA has been successfully done using existing infrastructure and does not require an enterprise service bus (ESB).

"Who needs an ESB?" Schmelzer said. "Ninety percent of the successful SOA implementations that are truly architectural and not just Web services integration are using the infrastructure they already had. There is no reason to buy a new messaging infrastructure because you're re-thinking the way you're exposing your assets. That's where the big disconnect is."

He suggests that architects who want to advance SOA in their companies need to stop looking at products and focus on the basics of the service-oriented approach.

"The concepts of service-oriented architecture are very basic," Schmelzer says. "It's not that complicated. Can you build a service that is composable with any other service without you having to know how that service is built? That's the whole idea of loose coupling, composability and heterogeneity. In that vein, Web services are not really relevant. You can use any technology you want as long as you reach the SOA goal."

If SOA fails to reach the tipping point, cross the chasm and become ubiquitous best practice, Schmelzer believes the SOA product vendors will be guilty of being part of the problem rather than the solution.

"I think it's the vendors who are actually preventing SOA adoption, whether they know it or not," the analyst said.

While acknowledging that it is a software marketer's job to tie products to the current hot technology – the practice known as "buzz word compliance" – slapping on an SOA label is also contributing to the lack of real SOA success in many organizations, he argues.

What might be characterized as a buy SOA products now and architect the SOA implementation later approach may sell software, but it doesn't advance the cause of SOA. Schmelzer calls this the backwards approach.

"The right way to do architecture is to come up with the model for the business and use that to determine what services to build," he said. "Then you think about how to build and run those services, in that order.

However, ZapThink is finding business doing it backwards, Schmelzer said.

"They buy the infrastructure first," he explained. "Then they think about what services they are going to build. And then they think about how the services are going to meet business requirements."

For more information
JMS-based SOA monitors CERN particle accelerators

ZapThink: SCA and JBI bring nothing to the SOA table

At ZapThink training events, when he explains this audience members look chagrined and say: "Uh, oh. That's what we did."

Schmelzer said the prevalence of this vendor-oriented architecture is part of what fellow analyst, Anne Thomas Manes, research director of Burton Group Inc., was talking about earlier this month when she concluded: "It has become clear to me that SOA is not working in most organizations."

Like Diogenes searching for an honest man, Manes has been looking for SOA success stories and not finding very many.

Schmelzer says the problem is that too many IT departments are buying products with the SOA label, so once the product is installed they believe they are doing SOA. What they are usually actually doing is an updated version of 1990s enterprise application integration (EAI), which Schmelzer calls Web service integration done on top of EAI 2.0. Manes calls it service-oriented integration (SOI). Whatever they call it, both analyst agree it is not SOA.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.