Service Oriented Architecture has become a mainstream IT approach that is redefining the look of enterprise applications. Moreover, SOA has become a requirement for staying alive in a turbulent market.
While the benefits of SOA are well documented, they do not take into account the massive existing inventory of older applications. These legacy assets are eminently reliable and highly valued, but they weren’t designed to participate in SOA.
The Legacy Integration Challenge
When SOAs are being built in a given enterprise, it quickly becomes apparent that their legacy systems don’t share a common technology – and more important, an architecture for tying applications together. To the typical SOA application developer, legacy applications are just an unknown black box of business functionality hidden in a monolithic stack.
To get past this perceived roadblock, legacy systems need to be represented as sets of SOA services. This is an integration effort that’s most successfully solved through service wrapping.
An assumption of SOA is the use of granular reusable services that can be made into composite applications. And the good news is that almost any user can wrap legacy applications so that the broader enterprise sees them as just another set of reusable components. Using the right legacy integration tools, this can be a non-invasive, risk-free process that delivers measurable results in a fraction of the time it takes to modify or build new solutions.
Legacy Integration Solutions: What to Look For
When evaluating legacy integration options, narrow the field down to those that support a wide range of industry standards. This is critical because SOA is not a set of web services; it’s a set of services. The ultimate goal is more about aligning your legacy architecture with an SOA than building services using a specific technology.
How you build your services and the technologies you use should be dictated by your desired business outcome. A tool that supports the definition of a service as an abstract that can be turned into any appropriate technology (such as a web service) will have a longer life than one that’s technology-specific.
Here are some capabilities to look for in the ideal legacy integration solution:
• A rapid approach for creating abstract services from legacy functionality.
• The ability to expose services as any type of component or technology.
• A simple point-and-click process for abstracting required functionality in component form, without disrupting the underlying legacy application.
• A design environment that insulates developers from the intricacies of legacy technologies.
• Creation of clear layers of abstraction, so solutions don’t require re-engineering of existing applications to access underlying functionality.
By adding modern legacy integration software to the SOA technology mix and planning, companies can create new opportunities to innovate with fewer technological constraints.
Guidelines for SOA Implementation With Legacy Assets
Using legacy components as lower-level operations or as services in an SOA puts the burden of understanding the legacy application’s workflow on the SOA developer. It alleviates the need to know legacy technologies, but not the legacy application. To ensure a successful outcome, developers with SOA initiatives that use legacy assets can refer to these guidelines:
• Focus on architecture rather than technology.
Envisioning everything that can be done to a legacy application with SOA technologies is not the road to success. The focus should be on changing the legacy monolithic stack into a visible set of components.
• Anticipate change.
If the legacy application is mapped directly into an SOA technology, the services will be useful only for the duration of the implemented technology. As the big and important work is breaking the legacy application into components, allow for an abstraction layer between the component definitions and service generation. This step will ensure better reuse through improved technical agility.
• Understand the needs of the application.
This is true of the legacy application and the consuming services that will be the SOA application. An understanding of the correct business context for the services is critical. Too much context curtails the basic SOA benefit of reuse; too little necessitates an understanding of the legacy limitations to the SOA consumer.
• Collaborate across teams.
Cross-departmental understanding, especially with the legacy application architects or developers, is essential. Involved groups should broadly and deeply span legacy expertise and SOA skills.
• Account for legacy assets.
To succeed with an SOA in most enterprises, legacy assets need to be correctly accounted for. That requires engaging resources with a working knowledge of the involved legacy applications; then leveraging the readily available yet unique set of tools that create the services from the legacy assets.
Service-oriented legacy integration software is the key to successful SOA adoption. By leveraging legacy integration solutions with existing SOA integration and web services technologies, you can decentralize legacy resources. You can also develop connected systems, services, and composite applications. The result is that legacy data and applications participate on equal footing with modern technologies.
