SolutionBy Karen S. Henrie | Posted 10-05-2005
Service-Oriented Architecture: Efficient, but Threatening?
Getting software to do the actual work of business has never been easy. Perhaps the most aggravating limitation of business software is the seeming inability of applications to accurately embody the strategy and everyday processes of the business, and to keep pace with business-process changes.
To a large degree, this is because traditional, so-called "monolithic" applications are made up of individual business functions that were designed, developed and deployed to operate only in that particular application. In a manufacturing setting, for instance, the process of monitoring raw-materials inventory might support inventory replenishment as well as production scheduling and accounts payable.
The business functions that make up this process might include identifying materials, noting when inventory is used, sending an alert when inventory dips below a certain threshold, and so on. Each group has its own reasons, and its own application, for monitoring inventory, yet the process is essentially the same. Or at least it should be.
What's more, the developers of each of those applications may have had their own ideas about how a particular process should work, which means that a given business function would be defined inconsistently from application to application. Worse, a change made to one application may never be reflected in other applications. The proliferation of applications as businesses grow, acquire other businesses, and add new delivery channels, products and the like, only compounds opportunities for miscommunication and inefficiency. Fold in the growing number of digital interconnections with customers, suppliers and other business partners, and it's enough to make any CIO's hair hurt.
Meanwhile, in the mid-to-late 1990s, many organizations went on a spending spree, purchasing large packaged application systems such as ERP and CRM. Vendors claimed to provide the middleware and other software necessary to integrate plodding legacy and in-house applications with their shiny new packaged application systems, but those enterprise application integration efforts only exacerbated the problem.
Using EAI, IT organizations did manage to integrate disparately designed and developed applications, but the connections they set up between those applications are often inflexible, or hardwired, and difficult to change in response to business conditions.
"Many organizations are suffering from a 1990s hangover," says Michael Liebow, vice president of Web Services and SOA at IBM Global Services in Somers, N.Y. Liebow adds that the upshot of excessive investments in systems and the resulting integration efforts is that "80 percent to 90 percent of their IT budgets are going to maintaining the status quo."
The goal of so-called service-oriented architecture is to fix this growing problem. Applications built using SOA will support the same business processes that applications have always supported, but with some important distinctions. SOA's goal is to design and develop all the business functions that go into an application as independent "services," which can then be strung together in several different ways to complete whatever business processes the business requires.
And since different applications often share a single service, that service can be used and reused as often as needed.
The result: greater consistency across business processes and more agility in dealing with business changewith the added benefit of more efficient use of IT assets.
Redesigning an order process, for example, might require a change to a particular service, rather than an entire rewrite of one or more applications that contain the business function that service now performs. And improvements to one service, in security, reliability or performance, for instance, will accrue to every application that uses it.
SOA is no panacea. Overhauling the application systems of a large organization in order to employ SOA is a complex, multiyear journey. Companies that began that journey several years ago are now testing the limits of SOA. The software a company needs to manage a growing portfolio of services, for instance, is relatively immature. And while the technology is in place to share services over the Internet with external business partners, few organizations feel security is reliable enough to do so with anyone other than those they most trust. But the tenets of SOA contain an inherent simplicity and rational design that many, if not most, application portfolios sorely lack.
Don't pursue SOA before developing an IT/business master plan.
At the Guardian Life Insurance Co. of America, based in New York City, Executive Vice President and CIO Dennis Callahan (who reports to CEO Dennis Manning), was hired in 2000 "with a strategic imperative to drive IT to the next level." He views SOA as essential to that effort. Prior to his arrival, Callahan says, "Guardian made technology investments and then just went into maintenance mode for many years."
Guardian's IT portfolio was representative of the industry in its mix of new and legacy applications, which handle benefits plan administration, claims processing, policyholder administration and the like. Modifying legacy applications, say, to add a Web-based front end onto a mainframe-based benefits administration application, was exceedingly difficult and time consuming.
Working closely with Manning, who was then COO, and CEO Joseph Sargent, Callahan prepared his business case for the future direction of Guardian's IT organization. He included a target goal to deliver applications 30 percent faster and cheaper than in the past. Meanwhile, Callahan's chief architect, Jaime Sguerra, was busy devising an approach, dubbed the Guardian Enterprise Architecture, that would deliver those applications, in part by developing applications through a services model.
Callahan met with the heads of Guardian's various businesses to convince them of the benefits of the planincluding higher quality and more useable applications that would be delivered faster and at a lower cost than in the pastand he developed a consensus that this was a worthwhile investment.
Working with the heads of Guardian's various businesses, Callahan and Sguerra decided which applications to develop first. In retrospect, Callahan says this step was critical. "Doing the analysis of what applications Guardian would need [over the next several years], and what would be needed to support those applications, was key. It took a lot of effort and discipline."
A CRM application used by customer-service reps supporting group insurance plan customers emerged as a high priority, as did a Web application called Client Manager (used by general and independent agents to help them service and sell to customers), a self-service Web application called My Account Manager (used by policy holders to monitor and manage their portfolios), and an interactive voice-response application (used for self-service by policyholders).
The team initially focused on providing the support services those applications would require. Says Sguerra: "We knew these applications would need to access customer data back from legacy systems, and that we'd need services to retrieve that data." Guardian quickly began to realize the SOA benefit of reuse.
"Instead of coming up with dedicated services for each application, we determined that many of the services were the sameso we built those services once." Developers working on the CRM application used by customer service reps and the Web application used by agents may want both applications to allow users to download a document, such as a statement of benefits. Rather than each team having to write a function for that requirement, they can now simply invoke a service that's already been developed.
The shared infrastructure and the 60-plus services that currently comprise the Guardian Enterprise Architecture were implemented over two-and-a-half years by a team of 16 developers, though they did have additional outside help at certain stages. Callahan says he's met his goal to reduce development costs by 30 percent, and he expects that number to go higher in the future as his team builds more services.
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."