How do I balance the need for architecture planning in SOA with the need to prove value to the business quickly?

How do I balance the need for architecture planning in SOA with the need to prove value to the business quickly?

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."