Q: How much reuse can I expect from services? And what does that mean in real dollars?
A: Reuse of services can vary widely and depends on the rigour of the design, which in turn depends on the abilities and experience of the developers and project managers, says Heffner. Reuse also depends on the level of architectural planning that surrounds the specific service. For example, a service has more chance for reuse if it is developed as part of a broad SOA strategy that includes uniform development methodologies, a centralized architecture planning staff and business analysts who can examine processes across the company and incorporate the unique needs of the business units into the design of the service. "If a service isn't designed with knowledge of how other parts of the organization may want to use it, it's unlikely that those groups will adopt it," says Gleason. Worse, designing a one-off service could lead to duplication of effort down the road. "You may need to create a second service to complement it because you don't have time to modify the first, or perhaps you're going to have to rebuild the thing because now it doesn't meet your requirements," says Gleason. "In the long run, there's no hope for business process integration, or business process management, if I don't look at services from an architecture perspective."
But if a service can be reused even once, it can have an exponential effect on savings, according to Heffner. Even though services require more up-front design work, reuse means there will be no costs for design, coding or unit testing the next time around. Together, these steps account for about 40 percent of a software project cost.
Veterans caution that it's difficult to predict the reusability of services. Sizing the services properly (known as granularity) so they don't try to do too much or too little is an art. "We have challenges with granularity," says Howie Miller, VP of integration architecture for IBM's internal IT group. "I'd say 30 percent of our assets drive 90 percent of the return because they are sized better," says Miller. Heffner agrees: "At one auto company I've talked to, they had some services that were used 20 times and others that were used only once."
Q: I need to show value to the business for everything I do. How do I balance the architecture planning with the need to prove value to the business quickly?
A: Architectural planning is time-consuming. Service-oriented development, drawing upon well-known programming principles and widely available technology standards (such as SOAP, HTTP and so on), can happen a lot faster. But the two need to happen in parallel, say experts. "We do development projects as needed and then on the side we have a longer multiyear project of mapping out the processes and building enterprise-level services," says Kurt Wissner, managing director of enterprise architecture and development for American Electric Power (AEP). "People need to see the benefit of SOA pretty quickly. That's why I like the project route, because otherwise you don't have anything tangible to sell to anyone about why you're doing this."
While it would help to have the architectural plan and the process mapping in place before building the services (to improve the chances for reuse), architecture planning has no short-term payback, which can be devastating. "I tried to boil the ocean at another company and I failed," recalls Wissner. "We did a big multimillion-dollar architecture plan that duplicated what we already had. It didn't provide much value over traditional point-to-point integration, and we had nothing to show for our efforts. If you start with the entire enterprise, there are too many risks you might fail."
By taking the enterprise planning in smaller chunks at AEP, Wissner can more easily recover from setbacks. "We've had hiccups but could take corrective action because the issue wasn't that big," he says. "If you break it into simpler pieces, it's more easily digestible."
"Business processes change all the time," adds Praveen Sharabu, director of enterprise architecture and infrastructure for transportation company Con-Way. "Nobody can wait for two years while you document everything, and it will be obsolete by the time you finish."
Q: I can't afford to build a million different services. How do I know which services will provide the most value for my investment?
A: When in doubt, start with processes that involve customers, directly affect revenue and address a specific pain point in the business. A 2006 survey by the Business Performance Management Institute found evolving customer needs and preferences to be the top driver in business process change or the introduction of new applications, followed by competitive threats and new revenue opportunities. (Cost savings was a distant fourth.) "Externally facing applications are the ones that provide the most business value, and they have a good set of change requirements that come up very often," says Gartner's Sholler. "If you can improve those applications by 10 percent, it's better than improving lower-level applications by 50 percent." Of course, adds Sholler, SOA may not provide more value than, say, a good packaged application. "But if it's something you would have to build yourself anyway, you need to do it service-oriented," he says.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.