The choice of which approach to take depends on the specific requirements and technical limitations at hand. While the programmatic approach seems best, since it allows access to the functionality and information directly, in many cases the APIs are inaccessible or inappropriate for direct access. Many companies must therefore resort to screen-scraping. Fortunately, as Gentry points out, “screen-scraping has changed dramatically over the last five or six years. We can take a multi-screen user session and expose it as a service, allowing for sophisticated modernization projects.”

Bottom-Up and Top-Down SOA
Now, these integration approaches are familiar to most data integration specialists. The new twist to the story is that we can leverage them as we move to SOA. The first step to leveraging legacy within SOA is to wrap those systems with service interfaces. However, simply exposing legacy assets as services—what you might call the bottom-up approach—does not by itself provide SOA. Basically, all we’ve done is turn a box of random toys into Lego blocks, so that now they all fit together nicely. But give that box of blocks to some three-year-olds, and there’s no telling what they’ll create. To build that big Lego Godzilla you always wanted, you’ll need a plan and the discipline to follow it. When we let those Legos represent service-enabled legacy assets, the plan—as well as the discipline—constitute SOA.

In fact, you need a high-level plan that can guide the whole SOA initiative, so that you can evolve your technology in a way that meets ongoing business needs, rather than heading off into the weeds. The best way to build SOA involves combining a top-down approach with the bottom-up one. The top-down approach starts with the architects on the project putting together a long-term architectural design. It’s important to have the right level of detail in this plan, since too much detail can slow down the project, and too little can lead to poor architecture. SOA, however, should be bottom-up, as well. If you only take a top-down approach, you’re likely to recommend building Services that are too technically difficult or complex to implement. On the other hand, solely taking a bottom-up approach can yield unnecessary or redundant services.

SOA is no magic cure-all, but if you take the correct combined top-down/bottom-up approach to creating and rolling out the new architecture, then you can achieve dramatic business value, and one of the primary sources for such value is the legacy assets in the organization. Indeed, most large organizations are well on their way to planning and implementing SOA initiatives of one sort or another—and most of these initiatives depend on legacy systems. According to Theo Beack, chief SOA architect at Software AG North America, “In the last 18 months, 80 percent of Software AG customers in North America pursuing integration and modernization projects have centered on SOA. They’re beyond the learning phase now. Instead, they want to know about the ‘how’ and how SOA can help.” In fact, there are no viable alternatives to SOA on the horizon: It’s not a matter of “SOA or what?” but rather, “SOA: when and how.” SOA, therefore, is no flash-in-the-pan IT fad. It’s challenging, to be sure, but there’s no question SOA is here to stay.