News

SHARE: SOA Knocking on Exec Doors

• By Kathleen Ohlson
• August 29, 2005

Because service-oriented architecture is catching the eye of CEOs and other senior executives, mainframe pros should expect to have SOA plans ready to go. That’s the take-away from one of the sessions on SOA at SHARE’s recent user conference in Boston.

“Some IT [staffers] think they’re at the point where their systems can’t get any better,” says Diana Donnellan, manager of the WW business development and client relationship management, IBM Software Group. “They’ve had the same system for over 18 years, and they think they can’t come forward.”

As an example, Donnellan cites a government agency with five billing systems that is uncertain about who is using these billing systems, but it maintains regardless because the agency is unable to migrate to a common billing system.

An SOA comprises loosely coupled, interoperable application services. Many of the services interoperate over Java, .NET and other development technologies, making these components reusable. SOA is an independent framework that supports integration and consolidation. The goal is an adoptive, agile IT infrastructure, but the road to SOA is tricky.

SOA isn’t about technology; rather business operations and IT’s best practices, Donnellan explains. Both sides need to agree on their SOA strategy, defining a set of policies and practices, and the framework, she says.

With communication between departments lacking, IT builds services specific to the apps calling them. In one case, the result was a client of Donnellan’s that built 19 versions of the same app, causing headaches for business users.

According to Donnellan, SOA is a means to different goals for different enterprises. For example, business analysts view SOA as part of business processes and want to expose services to partners. The chief concerns of programmers are how SOA will affect the database and the data model, and what standards and tools to use.

Business operations must work with IT to devise the shared processes, and they can’t assume IT will develop the correct specification, she says. Conversely, IT can’t prioritize business goals based on assumptions of business needs.

“SOA fixes the line of communication between business and IT,” Donnellan says. In the worst-case scenario for IT and businesses, there’s this option: “Put people in a room, slide pizza and beer under the door [and keep them there] until they agree,” she says.

Companies and IT must implement SOA in increments because the Big Bang approach can stop operations in its tracks. “Find the one project that needs help, spend time [on research and planning], and get the architecture right,” Donnellan says.