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."
John Webster is a freelance writer in Providence, R.I.