Not too long ago, IT organizations turned to service-oriented architecture primarily as a way to integrate enterprise applications. But now large companies are using SOA to create components that can be combined and reused as services across multiple applications.
This makes application updates easier and faster, reduces development time, improves service to customers and partners, and saves money.
It's still SOA, just all grown up.
"You don't get high marks anymore for simply writing Web service wrappers around existing applications," says Hamesh Yadav, lead systems architect at Wells Fargo & Co. in San Francisco and co-chairman of The Open Group's service-oriented infrastructure working group. "SOA is more problem-based now."
While this broader use of SOA does lead to management challenges, including the need for "building in governance so you have a way to register and share services," Yadav says, "the end result is a reduction of complexity" by making things more interoperable.
Massachusetts Mutual Life Insurance Co.'s SOA project incorporates about 100 services, including distribution management, premium collections, customer information management, new business and underwriting.
These services integrate applications across business units, each of which markets different products. Instead of replacing an existing application wholesale, business units select an appropriate combination from the company's array of shared services, says Kinam Peter Kim, vice president of enterprise SOA strategy at the Springfield, Mass.-based insurer.
"To us, SOA is not a technology. It is an approach to modernize our business -- an approach to create an adaptable enterprise," Kim explains.
Well-designed SOA services are reusable for both business process automation and systems integration. For example, MassMutual's shared business functions, such as security, are placed into repositories. These shared functions conform to the IT department's governing policies, which in turn determine which applications use the shared services.
When the company was considering revamping its SOA approach in 2007, the IT team realized that instead of changing the architecture model, it could use one model across all business units.
"We asked questions like, What does SOA mean for our business?" says Don Carten, assistant vice president of enterprise technology at MassMutual. "We thought about the approach, what funds to lay out, practices, what services do we use. Then we built a team that was core to the program and built out the services using well-known standards."
"SOA is moving into the mainstream, where it becomes a component of other things," says Mike Gilpin, an analyst at Forrester Research Inc. "Companies define Web services, write the code and then deliver the [application] service."
Gilpin uses the telecommunications industry to illustrate the concept. SOA is the lingua franca that bridges all of a telco's services -- land line, Internet, mobile, television and more -- so they can be delivered in a unified manner on a carrier's Web site. This setup could even be extended to the company's retail outlets, where it would enable salespeople to see details of service packages on a monitor.
With SOA, all of that could be more tightly integrated, allowing a company to market, provision and create bills for combined and bundled services from all sources.
Each of those systems could run on different underlying technologies, Gilpin explains. "Land lines might live on a mainframe, while mobile services are running on a Java platform. SOA is the enabler, and this lowers cost."
Similarly, in the financial services industry, SOA could enable banks to process loans faster or offer speedier service with fewer hassles, he adds.
At Cigna Corp., SOA evolved differently than it did at MassMutual, but it yielded similar results. The Philadelphia-based health insurer got started with SOA around 2001, jumping into the technology wholeheartedly. While many other user organizations were testing Web services at the departmental level, Cigna rolled out SOA for large-scale, companywide systems. Deployments included new call center software and a consumer accounts management application.
"We built out the existing hardware and software infrastructure, and now there are pieces of SOA in nearly every mission-critical application," says Stephen Bergeron, senior director of architecture at Cigna.
The company relies on SOA for process orchestration, data services and business services, among other things, he says.
Cigna has rethought -- from both a business and an IT perspective -- how different business units will access and use shared applications, Bergeron explains.
Because many business applications have overlapping features, it's important to define upfront the function that each service is intended to fulfill, and to govern each one's use accordingly, Bergeron says. Doing so will ensure that technology is used appropriately. Taking that step is "especially important as SOA is adopted across the enterprise," he adds.
Today, Cigna's shared-services registry and repository promote greater data sharing. The registry contains information about which applications are integrated with the SOA, and which reusable code each uses. The repository stores the reusable code.
Expansion Strategy The use of services for mission-critical applications represents a shift. It's different from an application made up of services, or one that uses services that are separate from the SOA, Forrester's Gilpin explains.
The use of SOA typically expands in this manner: Companies first use Web services for small, one-off projects and then, as those smaller initiatives succeed, start deploying SOA across the entire enterprise.
To be successful, such an expansion needs to be accompanied by a shift in thinking about what SOA requires from a business process standpoint.
Elevating Web services from application integrators to enterprisewide SOA adds complexity, which creates challenges. These include figuring out which applications ought to consume services, and how they should do that. For this shift to occur successfully, IT managers need to ask different questions than they did during the technology's earlier days.
"The broader view of SOA is that it's an application and system design environment" that can enable greater business agility, says Sandra Rogers, an analyst at IDC. But this broader role requires the services to be well designed and well thought-out, both as representative elements of the business and as components of business processes.
One approach is to base SOA on "dynamic" services that can be reused and built to work with multiple business applications. But to do this well, IT staffers need to pay close attention to how the code is managed. Management tools and repositories are key.
Whatever you do, don't skimp on planning. Companies that have changed the way they think about and present SOA as a suitable technology have more successful SOA rollouts, says Anne Thomas Manes, an analyst at Burton Group in Midvale, Utah.
She advocates an interesting way of doing that. "Discussion of SOA should move underground. IT groups should stop trying to sell SOA to the business. Instead, they should just apply SOA principles to specific projects they execute," says Manes.
In other words, IT groups need to exploit SOA's more subtle advantages. These benefits "ensure that the software is more manageable, more maintainable" and easier to integrate, which in the long run makes IT more cost-effective and agile, she says.
Her bottom line: Don't just talk about SOA; show that it works.
MassMutual's Kim agrees. "One reason we were successful was we standardized the architectural process five or six years ago. The architects must also understand the business, and we had that foundation -- both business and technology at the company. The board of directors paid attention, and we had the executive support."
But IT managers need to be careful. "As you build out your SOA, you have to continually remind yourself that SOA is not about the technology," Cigna's Bergeron says. "All too often, IT gets caught up in the 'technology for the sake of technology' trap and loses sight of the business objectives that need to drive our work. With all the products, technology and standards that are available to support SOA, it's an alluring distraction."
Webster is a freelance writer in Providence, R.I.