Not too long ago, IT organisations turned to service-oriented architecture (SOA) 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.
An example is Massachusetts Mutual Life Insurance, where the SOA project now incorporates around 40 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, manager of enterprise SOA at MassMutual.
"To us, SOA is not a technology. It is an approach to modernise our business — an approach to create an adaptable enterprise," Kim says.
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 and this determines which applications use the shared services.
When the company was considering revamping its SOA approach in 2007, the IT team realised that instead of changing the architecture model, they 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 programme ... and built out the services using well-known standards," Carten says.
Mike Gilpin, an analyst at Forrester Research, says, "SOA is moving into the mainstream, where it becomes a component of other things.
"Companies define web services, write the code and then deliver the [application] service."
He uses the telecommunications industry to illustrate the concept. SOA is the lingua franca that bridges all of a telco's services — landline, 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 retail outlets, where it would enable salespeople to see details of various 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 says. "Landlines 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 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 organisations were testing web services at the departmental level, Cigna rolled out SOA for large-scale, companywide systems. Deployments included new callcentre 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 says.
Because many business applications have overlapping features, it's important to define upfront the function that each service is intended to fulfil, and to govern each one's use accordingly, he says. Doing so will ensure that technology is used appropriately. Taking that step is "especially important as SOA is adopted across the enterprise".
Presently, 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 says.
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 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."
MassMutual's Kim agrees. "One reason we were successful was we standardised 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."
Challenge: Calculating ROI
Companies are still having a difficult time calculating ROI for SOA. In many cases, because large-scale service deployments have been in place for only a short time, it's impossible to show how they have saved money. Therefore, Manes recommends adopting different types of ROI metrics. For example, you could demonstrate how SOA initiatives require smaller development staffs or involve shorter development cycles, or you could show that SOA speeds time to market or reduces risk, she says.
"You should look at applications the way you look at the stock market. If it's not returning value, you drop it," she says. It's important to show this service could reduce downtime on the shop floor, speed up the billing process, cut the amount of time customer support people spend on the phone solving problems, or slash the number of items in inventory.
The more you use SOA, the more you have to track which services are in play in which parts of the organisation, which services are using which components, and which components are available to be re-used. Strong governance happens both at design time, when rules are applied, and at runtime, "which becomes more difficult because [then] the services are live", says MassMutual's Carten.
One way to think about this is to define which policies can be applied across business units.
Federation has become another key concept as SOA expands in scope across the enterprise. "With a federated approach to authentication and authorisation, a user in one domain can call into another and his credentials can be passed between those domains, even if one is built around Microsoft's Active Directory and the other is built around Sun's Identity Manager," says Gilpin.
Federation is not a new concept, of course, but as SOA takes on a broader role in enterprise IT, federation becomes even more important. Standards such as Security Assertion Markup Language establish interoperability, Gilpin explains.
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 is an alluring distraction."