News Stay informed about the latest enterprise technology news and product updates.

Legacy application modernization: Make SOA work for you

Service-oriented architectures can help enterprises modernize their legacy applications. Here are some ways to make them work.

For many years, numerous IT organizations developed applications within their own silos. Enterprises have received tremendous value from these assets -- which now can be considered legacy applications -- thanks to enhancements and feature enrichments.

These legacy applications, however, can become stumbling blocks when one considers the fast-paced market and ever-increasing demands of competition. In addition, they can cause major disruptions within a company's application ecosystem because they use outdated technologies, multiple user interfaces or multiple security frameworks. For these reasons, legacy application modernization is crucial if an enterprise wants to stay productive and competitive.

For the past several years, one trend has been to use a service-oriented architecture (SOA) to migrate and modernize legacy applications. SOAs are intended to support modern, distributed software demands, and are language- and platform independent. Those features make them optimal tools for a company moving to modernization.

Keep in mind that modernizing legacy applications is not the primary goal of an SOA implementation. Such an implementation is just one of many steps along the long road to an enterprise becoming services-oriented. Enterprise IT organizations have several optionms at their disposal when they modernize via an SOA.

Application silos require users to employ several legacy applications to perform the tasks within a given business process. That fact makes application redundancy an ideal point at which to begin overhauling user experiences and user interfaces. For example, take a prescription ordering system where multiple applications are used in the ordering process. Such legacy applications could be modernized to provide a single view into the entire system via social media software, business process management systems and business intelligence tools.

Multiple legacy systems can be integrated behind the scenes through a combination of Web services and a data access and services layer. This approach depends on a core principle of SOA technology: abstraction. When levels of abstraction are created, years upon years of legacy applications don't have to be redesigned.

Hiding legacy application system complexity

Many inventory and ordering systems are like the hypothetical prescription ordering system just used as an example. They continue to perform critical business functions, but it's appealing to modernize and integrate them with newer and even future applications. Enterprises can't simply rip and replace such systems, so some are modernizing legacy applications by hiding their complexity behind adapters or Web services.

Enabling SOA and Web services has become a requirement in today's competitive market, making it critical to service-enable legacy applications as well. Once candidate applications have been identified, their legacy code is copied into a common framework, and all the referenced data objects are placed into a common data interface. Once a business operation has been identified for reuse and documented, the next step is to "wrap" it. In that process, the component extracted from the legacy code is given a Web Service Description Language (WSDL) interface by each entry being transformed into a method, and each argument and parameter being transformed into an XML data element. Data structures become complex elements with one or more sub-elements, and both methods and arguments will be built into an XML schema.

The final step is to generate a proxy to link the Web services into the overarching business processes. The proxy is concerned with checking parameters and generating the required WSDL. Once the proxy is invoked, the legacy-code wrapper parses the XML input message and transforms the input data into the proper format. After the wrapped component is executed, the wrapper transforms the result into an accepted XML outbound message and sends it back to the Web client.

Ensure proper resources for legacy application modernization

Enterprises that embark on legacy application modernization initiatives often neglect the various resource issues. Undertaking such initiatives requires the proper mix of resources, talent and skills to ensure success.

It could be difficult to find professionals who understand not only the business processes and functions associated with legacy applications, but also their underlying code and platforms. Let's face it: Many of today's software and systems engineers are not familiar with legacy applications and platforms, such as mainframes, COBOL, CICS, IMS and so forth. So, you need professionals who understand these legacy applications, and team them with professionals entrenched in modern technologies.

Time is another resource issue, one that some enterprises seem to downplay. Their goal is to provide the business with new tools quickly, to help workers gain visibility into daily operations and stay competitive in an always-changing business climate. Nevertheless, they often get lulled into believing they will see the rewards of their efforts overnight. This is just not the case. It has been my experience that enterprises don't see positive results until a few months to a year later at the earliest.

In addition, some think that implementing an SOA (and using it for legacy application modernization) is merely another IT project that has a well-defined concluding date. The reality, however, is that becoming a services-oriented enterprise requires the business to define a strategy and a roadmap for SOA governance. The successful SOA journey will involve traveling from milestone (of which legacy application modernization is one) to milestone, project by project, along the roadmap. Only when all the desired outcomes have been realized and their corresponding milestones completed, will an enterprise's journey be complete.

Reuse capabilities for legacy application systems

I often have been consulted by colleagues responsible for operating and maintaining a human resources system for an enormous user base -- some 500,000-plus. The original HR system attempted to modernize some of the business processes associated with a legacy system. The modernization, however, consisted primarily of writing a new application from scratch on a modern platform. The intent of the modernization effort was to become services-oriented, but the result was far from it.

Revitalizing legacy application systems allows enterprises to offer clients modern tools without risking an expensive demolish-and-rebuild-from-scratch.

We began by maintaining the new application and ensuring its daily operation; in the meantime, we overhauled the user interface using Web 2.0 technologies, and began modularizing the original application with the goal of service-enabling the components that were deemed potential reuse candidates.

As maintenance requests and requests for new features come in, the project team considers each request's potential reuse capabilities as part of the requirements analysis. Doing this has allowed the team to develop several Web services that are or will be reused by other projects within the application ecosystem. So, at the core of the modernized system, the project team has used the approaches described earlier.

The team ran into a resource scheduling issue with one of the requests for a new feature, and as a result, used a third approach. The HR system retrieved data from a legacy database overnight; on certain occasions, however, an external application could take longer than normal to update the database, so a mechanism was needed to avoid resource-access issues.

The team had intended to generate its own messaging mechanism, but there was no need to create such an animal because the organization's SOA infrastructure included an SOA gateway that could provide the same capability. It was decided that a Web services interface to the gateway would be generated and that the gateway would communicate with a data access layer that communicated directly with the legacy database. This approach allowed the team to increase the application connectivity options that could reuse the data access layer and avoid resou rce conflicts on the legacy database.

Selecting the appropriate starting point and methods for a legacy application modernization is no easy task, but legacy modernization using an SOA just might be the sort of strategy that gives your company the means to meet the business's increasing demands while preserving its large investment in legacy systems. It also could be that initial step along the journey toward the ultimate retirement of antiquated systems.

Revitalizing legacy application systems allows enterprises to offer clients modern tools without risking an expensive demolish-and-rebuild-from-scratch.

Timothy Vibbert is CTO of Red Eagle Services, a consulting firm focused on SOA, cloud computing and business modernization. Let us know what you think about the story; email

Dig Deeper on Enterprise application development, DevOps and software agility

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.