Complicated as the technology is, the people problems that accompany a migration to SOA are likely to dwarf any technology concerns.
With SOA, "casting the discussion in business terms is the big opportunity, but it is also the big challenge," says Forrester Inc. analyst Randy Heffner. "Most IT people aren't qualified to have that business conversation. You need key people to drive the business and IT connection."
At the Hartford Financial Services Group Inc., John Chu, senior vice president for eBusiness and technology, helped sell the various lines of business on the benefits of SOA. The Hartford began experimenting with Web services within lines of business in 1999, according to Benjamin Moreland, assistant director of foundation services, who was hired in 2003 to create the foundationincluding the infrastructure and standardsfor the company's SOA effort. By 2004, the company had defined the reference architecturethe common set of guidelines and standards that all developers must adhere toand created an official Enterprise Architecture Group, which reports to CTO Gary Plotkin.
The Hartford is focused on two goals: reducing maintenance and day-to-day operations costs for IT systems, and making The Hartford a company that's easy for agents and customers to work with. "In the insurance world, an agent may select a particular carrier, even if it's a little more expensive, if that carrier is easy to do business with, when it comes to getting a quote or issuing a policy or processing a claim," says Moreland.
Enterprise architects now spend their time making sure newly developed Web services, which support a Web-based agent portal and the customer service center, among other applications, meet these business requirements. An architecture steering committee that includes both IT and business people reviews projects to ensure they comply both with the enterprise architecture and business plans.
"The committee scores every project as positive, neutral or negative on whether it complies with the architecture and is going in the direction of the line of business roadmap," says Moreland. "We don't want IT just to be order takers. We want the business side to understand the risks [associated with their requests], especially from a maintenance perspective."
Another concern involves the changes required by the IT staff itself. Forrester's Heffner sees mid-level managers as the employees most likely to struggle with a move to SOA. "The notion of [sharing services using SOA] is very threatening to middle-level IT managers, who have built their careers managing a particular silo." Part of that discomfort comes from giving up control. "Application owners and line of business architects are used to controlling the environment, the people and the priorities," Moreland says. "The culture was one of 'If I don't control it then I may not trust it.' Now these things are being shared."
Ron Schmelzer, an analyst with ZapThink LLC, a Waltham, Mass.-based IT analysis and advisory firm, predicts that in the future, many IT organizations will be organized around "service domains," or collections of services that are logically related, rather than around vendor products (databases, SAP, CRM, etc.), as they are today. One domain may handle all services related to parts inventory and procurement.
Another may handle all customer services. He also thinks the overall IT organization will likely be smaller. "Companies are realizing that if they can eliminate redundancies in software, they can eliminate redundancies in people."
Albert Hofeldt, vice president of technology strategy at Thomson Financial in New York City, agrees: "Architects and A++ developers will always have opportunities, but we'll need fewer average developers, especially developers based in the U.S." Perhaps that explains Liebow's advice for the IT graduating class of 2005: "Don't become developers. Become architects."
This article was originally published on 10-05-2005