Should SOA be run more like open-source projects?

Is SOA best left to a small cabal of "experts"? In the early 1990s, leading technology thinkers and doers recognized that enterprises needed to install a service layer that would abstract needed services from various, sundry, and mostly incompatible back-end systems. (Sound familiar?)  Thus, CORBA (Common Object Request Broker Architecture) was born.

Now, of course, we seek the same integration and interoperability through a service layer with SOA. But what happened to CORBA? And will SOA face the same fate? At least one industry scientist argues that CORBA suffered the fate of "too many cooks spoiling the broth," and advises that final say over software standards be left to a small, focused group of experts -- as is the way open source projects are administered.

To illustrate, Michi Henning takes us through the rise and fall of CORBA, a great idea that suffered from lousy implementation. (Thanks to Radovan Janecek for surfacing this article.) Basically, complexity, vendor overpromising, and political in-fighting choked the life out of CORBA, he says. And, new, simpler paradigms quickly overtook the creakiness and brittleness of CORBA:

"During CORBA's growth phase in the mid- and late '90s, major changes affected the computing landscape, most notably, the advent of Java and the Web. CORBA provided a Java language mapping, but it did nothing to cooperate with the rapidly exploding Web. Instead of waiting for CORBA to deliver a solution, companies turned to other technologies and started building their e-commerce infrastructures based on Web browsers, HTTP, Java, and EJB (Enterprise JavaBeans)."

"In addition, developers who had gained experience with CORBA found that writing any nontrivial CORBA application was surprisingly difficult. Many of the APIs were complex, inconsistent, and downright arcane, forcing the developer to take care of a lot of detail. In contrast, the simplicity of component models, such as EJB, made programming a lot simpler (if less flexible), so calls for a CORBA component model became louder and louder. A component model was a long time in coming, however. Work was started in 1996 on a CBOF (Common Business Object Facility), but that effort got bogged down in political infighting and was eventually abandoned, to be replaced by the CCM (CORBA Component Model). A specification for CCM was finally published in late 1999 but turned out to be largely a nonevent..."

What a mess. Henning says the lessons that we can take away from the CORBA experience is that there should be stronger, more centralized control over developing standards, a la open source projects. These include standards consortia adopting "iron-clad rules" to ensure standardizing existing best practices -- "There is no room for innovation in standards." In addition, he adds, no standard should be approved without a reference implementation. "This provides a first-line sanity check of what is being standardized." He also advises that a small "cabal" of experts or individual call the final shots over a standard to "preserve the original architectural vision and stops the proverbial too many cooks from spoiling the broth."

Yet, these seem to be the same scourges that plague SOA and Web services development -- too many vendors and competing interests. 

"It is naïve to put competing vendors and customers into a consortium and expect them to come up with a high-quality product—commercial realities ensure that cooperation and trust are the last things on the participants' minds."

There are parallels between CORBA and SOA, yet, SOA brings us something new that CORBA did not. There are other issues that quashed CORBA. Posting his reaction to Henning's article, Janecek says what doomed CORBA was the way the architecture was used, not the technical or political aspects. Namely, the fact that CORBA an IT project, used singularly within specific application silos. "Nobody can reuse created CORBA objects because they were not designed and/or deployed for reuse. Nobody knows about them. Nobody cares. Failure." 

Through resuse across the enterprise, SOA can break free from such perceptions. As stated many times in this blogsite, SOA is an enterprise-wide effort, and should not be "owned" by the IT department. SOA is about organizational transformation, a level of thinking CORBA never reached.