SOA (the term) is dead, but SOA (the architecture) lives on
April 25, 2012 —
(Page 1 of 3)
Related Search Term(s): APIs, cloud, SOA
SOA, according to analyst Jason Bloomberg, is a bad word.
“There’s perception and there’s reality,” he began. “The perception in the market is it’s yesterday’s news. It’s too difficult. Web services had too many complexities. We’ve moved on to the cloud, so SOA’s dead.
“The reality,” he continued, “is there is more SOA than ever going on. There are huge initiatives going on. But because of the perception, they’re being called something else: enterprise integration, regulatory compliance. But if you get architects together, they look at it and go, ‘Yeah, it’s SOA.’ ”
It wasn’t that long ago that SOA was the “it” buzzword, with its notions of cross-organizational communication that would make the Internet more than mere browsers and portals. Data could be exchanged, business could be executed, and this would all be done with a handful of standards: SOAP, WSDL and UDDI.
At first, companies created services and primarily used them in-house. Today, of course, the cloud is the dominant topic, and REST has supplanted SOAP as the de facto protocol for connectivity. In fact, any number of analysts and publications declared unequivocally that “SOA is dead.” So, does this mean that service-oriented architecture has lost its relevance?
Not according to several experts in the space. “Fundamentally, the thing that’s most relevant from the ‘SOA revolution’ is that it’s not a technology. It’s an architecture concept, and it’s alive and well and stronger than ever,” said Ian Goldsmith, vice president of product management at SOA Software, a company that provides governance software. “You can’t find a development initiative today that isn’t based on a services architecture.”
Paul Fremantle, CTO and cofounder of WSO2, which calls itself “the lean enterprise middleware company,” echoed Goldsmith’s remarks. “SOA is a mindset and an architecture, and not about which protocol you use.”
Where it began
The first generation of SOA saw implementations that were created internally (despite the business-to-business communication possibilities originally envisioned), as architects, developers and IT worked to gain an understanding of the processes.
“People didn’t know how to do it externally, and I think it was very ambitious at the outset to try to figure that problem out first,” said Hub Vandervoort, CTO of SOA Infrastructure Products at Progress Software. “More SOA is applied internally at the outset than externally.”
Vandervoort explained that when SOA first began, it was mostly inward-facing. As it has morphed to a more outward-facing paradigm, with inter-business-process connectivity growing, it has created problems.
“Years ago,” he said, “I used to ask people all the time, ‘How much of the content and functionality that you deliver to your end customer is in your direct control?’ Five to seven years ago, that answer was well more than 50%. People would say that most of what [they] deliver as an SLA to [their] end users, the thing they hold [them] accountable for 100% whether it works or doesn’t work on any given day, more or less all of it is in [their] direct control. Which says SOA is used on more of a departmental basis.”