Not too long ago, IT organizations 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.
“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-chair of The Open Group’s service-oriented infrastructure working group. “SOA is more problem-based now.”
At Massachusetts Mutual Life Insurance Co., in Springfield, Mass., 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 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, they could instead 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: Broadening and deepening
“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,” he says.
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 explains. “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.
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.
On the whole, companies are using more SOA — but it’s not universal happiness, according to a recent survey.
Enterprises of all sizes using SOA or that will by year-end – 68%
Enterprises of all sizes increasing SOA usage – 52%
Enterprises of all sizes cutting back on SOA – 1%
Enterprises ‘struggling’ to get the SOA benefits they expected – 18%
Enterprises not planning on using SOA – 32%
Forrester Research, Inc., based on 2,227 respondents in the fourth quarter of 2009.
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.”
In other words, IT groups need to ride to success on the more subtle advantages of SOA. These benefits “ensure that the software is more manageable, more maintainable” and easier to integrate, which in the long term makes IT more cost-effective and agile, she says.
Her bottom line: Show that SOA works, don’t just talk about it.
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.”
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 that 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.
Given the tightness of current budgets, organizations are likely to be more successful securing funds for specific projects with concrete ROI opportunities than they would be with more abstract architectural initiatives, she adds.
At MassMutual, justifying massive SOA deployment required a new way of talking about the technology, Carten says. It became a matter of talking about how SOA can standardize the business, he says.
It can be a difficult process, because you first have to agree on standards and then actually develop some that work in a reusable format.
Even with all of that, though, Carten says, “We never had to make the business case per se; it was made through transformation.” In other words, success came from doing it, not just talking about it. “You need to get out of the gate and do a number of services,” says Carten.
Governance even more crucial
The more you use SOA, the more you have to track which services are in play in which parts of the organization, 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 authorization, 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 (SAML) 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’s an alluring distraction.”
