SOA upends development traditions

While moving toward a service-oriented architecture (SOA) often means radically changing how a company uses software applications, some of the most vexing issues associated with SOA aren't technical -- they involve the challenge of managing people and policies during the shift.

That was the message from several speakers at Georgetown University's SOA Summit in Washington, D.C., this week. Their goal is figure out how best to embrace SOA as a way of breaking down rigid business applications into dynamic pieces that can be tied together on the fly to meet changing business conditions.

Steve Wolf, senior enterprise architect at Marriott International, for example, said that one of his company's biggest hurdles is retraining developers to think of composing applications as an iterative approach rather using the traditional waterfall method. That older development process from beginning to end often lacks collaboration and can be highly compartmentalized.

"The hardest part is we're talking about an entirely unfamiliar development environment, and you can't be using a waterfall approach," Wolf said.

The entire development process, including gathering requirements, testing and managing IT operations, has to be revised to support an SOA, he said. Developers in different departments might need to learn to reuse a service that, for example, can calculate a hotel room rate, instead of recreating it each time they build a new application that involves those calculations. But developers don't typically like to rely on others for that type of work.

As part of its move to SOA, Marriott is adopting IBM Rational's unified process as part of a project to standardize its use of Web services by the end of 2007, Wolf said.

Harvey Reid, chief engineer of the U.S. Air Force's Global Combat Support System (GCSS), said that one of the SOA challenges he is grappling with is how to placate program managers -- who are used to owning and operating their own applications -- when they're asked to share services with other departments.

"Program officers are king, and determining who is going to do the coordinating [of services] is a tough problem," Reid said. "Once you start breaking apart those systems...you have to participate in some process you likely will not own and hope you get what you need."

GCSS, which is charged with integrating all of the Air Force combat IT systems used to support deployed forces, is tackling that problem by hammering out agreements so that "when someone is intending to make a change, people can be notified and brought into the discussions," Reid said.

Daud Santosa, chief technology officer at the U.S. Department of Interior, said that one of the problems he sees looming on the SOA front is that while IT staffers may be well versed in Java, Microsoft .Net and Cobol, many don't have the "across-the-board" skills needed to move to an iterative development approach.

"A lot of my time is spent in education," Santosa said.

Join the newsletter!

Error: Please check your email address.

More about HISIBM AustraliaMarriott InternationalMicrosoft

Show Comments

Market Place