In my last article titled “Strategies for developing a roadmap for your SOA initiative”1 I discussed laying out a roadmap that shows how to get from the current state to the envisioned future state. One method many companies use when planning their SOA journey is to create a new presentation layer while leaving the legacy backend systems in place. This practice can be called modernizing or rejuvenating legacy systems.
Before we get too far into the discussion, let me state that the end game for SOA should not be to modernize old systems. Instead, it can be a stepping stone that a company uses on its long journey to become a service-oriented enterprise. The strategy here is to quickly give the business new tools and user interfaces by leveraging modern technologies like Web 2.0, business process management systems (BPMS), business intelligence tools, etc. These tools can help automate business processes, eliminate redundant data entry points, and provide more visibility into the daily operations. All of this and more can be delivered to the business in a much shorter time frame than if entire legacy systems were to be rebuilt from scratch.
Many IT shops have built a collection of application silos over the years. These applications typically run well within their silo through years of enhancements and feature enrichment. However, these applications can create havoc within the application ecosystem because they use different technologies, have very different user interfaces, feed disparate data sources, and even have totally different authentication processes causing users to login multiple times. This can create a frustrating experience for users and even hinder productivity.
A good first step might be to give the legacy systems a “face lift” by building a composite user interface that looks like a single system but actually integrates with multiple legacy systems. I worked on a project where we modernized the order-to-sales process. We delivered a wizard based user interface that looked like one system. Under the covers, the user interface was driven by a BPMS engine and we integrated with over half a dozen legacy systems through a combination of web service calls and a data services layer. We were able to roll-out out new features in months instead of years and started creating value within the first year of the initiative. We didn’t have to redesign years worth of legacy applications. Instead, we created a layer of abstraction above our legacy systems which acted as a bridge from our old application silos to our new wizard based system. This layer can take the form of an adapter or a collection of legacy-enabling web services.
What I described above is a very common approach for companies with a huge investment in mainframes who are undertaking SOA. Many of these companies have very old inventory and order control systems that work like a champ, but there is a strong desire to build more modern interfaces and integrate these systems with newer applications. It would be crazy to toss these systems out since they still perform their core functions very well. Instead, these companies choose to modernize their legacy applications by creating adapters or web services that hide the complexity of the mainframe systems from the new user interfaces.
Here is a classic example for the case of modernizing legacy systems. Company X runs a warehouse that ships products. All of the current applications reside on a mainframe and the user interface is a collection of amber screens written in IMS. Company X’s customers have to call Customer Support or an IVR system to find out the status of their shipments. Company X’s competition is killing them because their customers are able to track shipments on the web and use cool mashups like Google Maps. Something needs to be done fast. Rebuilding the warehouse and shipping system would take years, and besides, it works very well. Instead, Company X can abstract the key inputs and outputs and deliver them as web services or create an adapter that handles data transformations. Company X builds a brand new web interface using the newest technologies and leveraging various mashups. When an order is placed, the new website passes the order information to the mainframe system via web services or the adapter. The order data is transformed into a format that the mainframe system expects. The only thing the web developers need to know about the mainframe system is the formats to send and receive messages. The end result is Company X has now rejuvenated its legacy systems and improved customer satisfaction. The beauty of this approach is if the day comes to replace the warehouse and shipping system, the new system already has a well defined interfaces integrate with the existing web site. The new system can be swapped out with little to no impact to the user experience.
In summary, modernizing legacy systems using SOA can be a key strategy that helps a company meet the increasing demands of the business while maintaining its large investment in legacy systems. It can also provide a stepping stone within the roadmap for the eventual retirement of outdated systems. SOA does not have to be an all or nothing proposition. Rejuvenating legacy systems can help companies provide modern tools to their customers without taking on the risk of a long term and expensive “rip and replace” approach.
1 M. Kavis. Strategies for developing a roadmap for your SOA initiative. SOAInstitute.org. April 13, 2009.
