'Lunchroom' Web services: thinking too small for SOA?

An SOA journey should start with one small step -- or shouldn't it?
Written by Joe McKendrick, Contributing Writer on

An SOA journey should start with one small step -- or perhaps one large step.

I stopped by the SOA Institute events being held as part of this week's Brainstorm conference in New York, and wasn't disappointed. Avacor's JP Morgenthal, ZapThink's Ron Schmelzer, BearingPoint's Greg Lomow, and Yankee Group's Tom Dwyer all painted compelling pictures of the challenges that lay ahead in moving to service-oriented architectures.

The takeaway messages: Web services are easy; but SOA can be a back-breaker. Quality is more important than quantity; two well-managed services may be better than 5,000 point-to-point Web services.

Speakers seemed to be painting different pictures about where to exactly begin the SOA journey, however.  The predominant advice was to start small and scale up as ROI is proven and issues are addressed. Morgenthal suggested, however, that this idea is misguided, since SOA is an enterprise-scale project.  He bemoaned the approach of starting off with some "lunchroom" Web services -- such as creating a Web service that makes the daily menu available to employees (though I like that idea).  "Whoop-de-doo -- I can deploy 5,000 lunchroom Web services in one afternoon," he remarked.

However, deploying all these services into an enterprise architecture is a different story. "SOA is not easy, and doesn't scale unless you understand scalability, redundancy, backup, change management, and governance," Morgenthal said.  The same deliberate methodologies and processes that go into managing mission-critical mainframe or data center applications need to be applied to SOA.

ZapThink's Schmelzer agreed, but noted that the SOA journey should start small, with quick, referenceable projects that can show immediate ROI. "Focus on the smallest problem you can and apply the SOA approach," he said. 

Typically, SOAs can be rolled out on top of systems and software that are already in place. But the business case will likely occur in steps, starting with tactical deployments to shorten the length and expense of integration projects, or reuse of software assets. The next phase of rollouts will bring benefits such as business agility, Schmelzer said.   

Yankee Group's Dwyer also talked about the divide in SOA benefits, and agreed that most organizations will see internal efficiencies first, and increased agility later. He noted that survey work he had conducted finds most SOA investments are occurring in "edge" technologies  (remote  sites, Web servers, mobile applications, etc.).  Interestingly, he observed, while most CIOs are in the midst of checking out Web services/SOA solutions on the market from leading vendors, few, if any, are using the service offerings of the same vendors.

Some pundits were saying 2005 would be the "year of SOA." Dwyer says 2007 is the more likely year. 

Morgenthal also made the observation that everyone is rushing to SOA -- no matter what their business needs -- because of a mob psychology that has overtaken the market. "Some people think bungee jumping off the Empire State Building is a good idea, but that doesn't mean you should do it," he remarked.

Hmm. Is there a cryptic reference to ESB in that statement?


Editorial standards