One challenge in implementing SOA is the dilemma CIOs face regarding their legacy systems. Should they replace their current systems with new ones in an effort to increase efficiency, or should they extend what they already have? Many factors need to be considered when making this decision.

All too frequently, rather than extend legacy systems with a services-oriented approach, CIOs choose to rip and replace because it's the path of least resistance. For example, imagine inheriting a box of 2,000 strands of tangled, intermittently working, Christmas lights and being told you're responsible for having the tree set up in time for Christmas. We'd all be inclined to throw out the whole box and just buy new lights. However, it could take 15 months to purchase, configure, and test them—too long if Christmas is only six months away.

I use this example to emphasize the pain associated with legacy systems. Because services represent business capabilities, an alternate approach is to develop a tool to help sort through the tangle of lights. SOA could help prioritize which current software investments are ideally suited for the business capabilities and those that occupy a more supportive role to a service-oriented approach. As application investments are optimized for SOA and the business, the organization becomes more agile. Moreover, as the system design builds toward a more mature SOA model, these incremental changes provide value sooner rather than later.

Another challenge involves new technologies. Each time a technology emerges for business integration, it's usually layered upon older systems, creating interoperability problems. Solutions have generally been ad hoc, driving up enterprise architecture complexities and overall costs. Now, many CIOs are requiring future-proof justifications for new technology investments. That is, they seek ways to easily incorporate new technologies without significantly impacting their existing investment.

One of SOA's greatest strengths is its flexibility. Once an organization adheres to a service's contract, it's no longer tied to the service implementations. This means the only time the service contract should change is when the business capability changes—and the organization gains by not having to change the processes that use those service implementations.

Long term, an organization with a fully mature services-oriented approach can gain continuous incremental improvement in service delivery and achieve operational excellence. For example, in 1970, it took automakers two to five months to deliver a custom vehicle from time of order. Today, because of operational efficiencies in manufacturing and supply chain management, many automakers have reduced that time to two weeks.

The way to buy a custom vehicle didn't change; customers still had to select the base vehicle, color, seat coverings, carpet color, and accessories. The auto is still delivered through the same channel as in 1970—the dealer. What changed was the service implementation—the way the car was manufactured. Notice how this change didn't impact processes, but allowed for faster delivery.

To be sure, SOA will drive incremental advances in operational and financial performance. But deploying it clearly entails a multiyear journey requiring considerable planning. Start now to develop a set of services instead of a set of departments. Then define the contracts for those services. Finally, implement your services and redefine processes for optimal performance. This way, in spite of the proverbial advice, you'll begin fixing problems that probably weren't considered broken in the first place. But by doing so, you'll transform your business.

J.P. Morgenthal is managing partner at Avorcor.

What factors are weighing into your decision to deploy SOA? Tell us.

See Related Articles:

Web Services At A Crossroads, March 2006
Strategies For Successful Integrations, October 2005
Building An SOA Pipeline, August 2005