Legacy Platform as a Service - LPaaS
The impact of Web 2.0 development on legacy modernization strategies
Computing on the Edge – creating modernization pull
Cloud computing and Software as a Service (SaaS), are about to change the way we look at legacy assets and modernization initiatives. New IT development will be mostly delivered at the Edge of an organization, focused on providing new functionality to user communities and trading partners using Web 2.0 capabilities, delivered through cloud computing as a software service.
Platform as a Service (PaaS) solutions, provide development tools and frameworks for rapid cloud computing application development. PaaS solutions such as Force.com, Google App Engine and likely similar offerings from Facebook.com, Amazon.com and others provide a rich portfolio of application functionality in the form of services, and a cloud computing platform to host any applications developed using the PaaS framework. New application development will simply be a task of filling in the blanks and creating the specific logic required for the application being developed.
Oh yes it’s going to be a pretty exciting place out on the Edge. However, these new developments will always be limited in their value if they cannot interact with Core transaction processing applications in the organization. At the simplest level this will be about sharing data and the need for managed data integration solutions. At its more sophisticated level new cloud computing applications could be developed using a combination of PaaS solutions and internally created Legacy Platform as a Service (LPaaS) solutions.
LPaaS provides a new view of legacy application modernization. The goal is not to radically re-architect existing Core applications, but to allow demand from the Edge to drive the creation of a framework of Core computing services made available through the cloud to support Edge application development.
What needs to be in an LPaaS?
The important issue is that the LPaaS provides a platform of Core computing functionality through the cloud on an as needed basis. What makes up the functionality set should be driven largely by requirements of Edge. The LPaaS should not be a monolithic development project in its own right. Having said this, it is a reasonable assumption that any organization’s LPaaS should contain some basic service functions. This might include:
- Authentication ServicesSecurity and governance services
- Transaction processing and cross application referential integrity services
- Critical Business logic services
- Data mapping services
Unlike a PaaS which consists of a set of application services specifically created for cloud application development, an organization’s LPaaS will be a conduit to existing non-cloud computing functionality that already exists in the company’s Core applications. Therefore the LPaaS requires an enabling infrastructure that facilitates the LPaaS services to be made available through the cloud for new applications being developed on the Edge.
Service Oriented Architecture, SOA is the logical mechanism to facilitate the creation of a company’s LPaaS.
Using SOA and WOA enablement to create LPaaS solutions
There are two ways to look at SOA. The first and more common way of considering SOA is that it is an application development standard, the pragmatic answer to object oriented development’s weaknesses. This is of course correct, but only represents one aspect of the true value of SOA. The second, and in my view much more important, aspect of SOA is that it facilitates the integration of functionality at a granular service level, through the standards of Web Services and cloud computing. The most important part of this second point is that SOA as a web driven integration standard only cares about how the interfaces are exposed to be consumed, and not how they actually are delivered at the service level.
This means that SOA and the more easy to implement WOA, Web Oriented Architecture, have enormous implications for modernizing, or at least making available functionality buried in Core legacy applications. So long as the functionality can be exposed as a Web Service or WOA service, it doesn’t matter how the functionality is actually performed at the service level.
To enable an LPaaS, an integration framework must be created that enables Core data and legacy application functionality to be rendered to new Edge solutions as reusable services. A services approach provides the required abstraction from the legacy technology and the range of granularity that will be required by new application development assuming a PaaS like architecture.
Many Core applications, particularly Commercial Off the Shelf (COTS) packages will already provide some level of SOA enablement and there should be little difficulty to make services from these applications part of the LPaaS. Older, frequently in-house developed, legacy applications such as those running on the mainframe or departmental servers will need some form of SOA enablement in order to make services from these applications available as part of the LPaaS.
There are several ‘legacy to service’ enabling solutions available on the market which range from making services available using sophisticated screen scraping techniques, to wrapping legacy application programs to make them available to SOA adapters. Many organizations have already employed these products to enable legacy application integration.
When identifying which service enabling solution is right for your needs it is important to consider the nature of the LPaaS your organization is likely to require, both in the short term and over time. The following key factors should be considered in conjunction with obvious issues such as the availability of specific service integration adapters for your legacy technology stack:
- Range of service functions
- Data, Business Logic, Composite services
- Stateless transactions
- Service granularity required
- Invasive versus non-invasive adapters
- SOA versus WOA protocols
The LPaaS Strategy
So, what are the steps to creating an LPaaS for your organization?
First build the team. This could be called the LPaaS organization, or LPaaSO! The LPaaSO should have the necessary technical and business analyst resources to build the LPaaS and manage its further development. This is going to be an eclectic group consisting of members representing Edge computing initiatives and members representing the Core legacy applications.
- Recognize the initial ‘pull’ for LPaaS services from existing Edge initiatives
- Create the enabling SOA infrastructure. Recognize where applications and data can already be rendered as services. Identify solutions to enable other Core legacy applications and data to be rendered as services.
- Create LPaaS standards, incorporating mechanisms to presenting complex composite services made up of multiple legacy functions.
- Integrate LPaaS team into Edge computing initiatives with mandate to respond to pull from these projects
Developing an LPaaS strategy will not necessarily diminish the need for traditional large scale modernization projects, such has cost saving rehosting initiatives or legacy language conversion strategies, but an LPaaS strategy will compliment these other modernization projects and ensure adequate focus is being given to matching modernization steps to new Edge initiatives.