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.