Using SOA in just about every app
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.
Rethinking service delivery
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.
The use of services for mission-critical applications represents a shift. It is 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.
Asking different questions
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 the planning phase. The more successful SOA rollouts have occurred at companies that have changed the way they think about and present SOA as a suitable technology, 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."