Legacy applications are a necessary burden for most organizations: They function as important line-of-business...
applications but hold back technology advancements. The time comes, nevertheless, when legacy applications or systems must be replaced or modified because of changes in a business process or to integrate them with new systems and services. Then an application transformation plan becomes necessary.
Application transformation presents both a challenge and an opportunity. The challenge stems from the costs of re-engineering the application; the opportunity arises from the improvements to the application's productivity and usability the re-engineering will create. It's necessary to balance challenge against opportunity to determine whether re-engineering the application is a viable choice.
Luckily, there are many ways businesses can transform or migrate an application. Although each option has its own nuances and advantages, it can be vetted with some common IT practices. That will help to reduce the uncertainty associated with a given choice.
Methods for application transformation
First and foremost, IT directors can use the system design lifecycle (SDLC) approach to determine the viability of an application transformation. At its simplest, this approach dictates that an IT system, process or application be upgraded or replaced once its maintenance costs outweigh its replacement costs.
SDLC is a simple concept to understand, but it can be difficult to apply. In the realm of application development, SDLC calculations entail tangible and intangible costs. The tangible costs are dictated by man-hour expenses, the systems required for functionality, and other support elements. The intangible costs usually amount to productivity gains.
An application upgrade or replacement also can be justified for other reasons, such as legislative requirements (compliance); workforce transformation (virtual offices, mobility, contract employees); and re-engineered platforms (server changes, database enhancements, desktop operating system refreshes).
With the information that's readily available, it's easy for a savvy IT manager to justify the expense of an application transformation. The process itself can be challenging, however, and real-world results can differ from the predictions. To avoid unnecessary surprises, it's important to understand the process and identify potential pitfalls.
One of the first steps in an application transformation is to decide on the application presentation model: Will the application be on a desktop; or will it be hosted or Web- or cloud-based? Another important consideration is whether the application will be available over the public Internet; a private intranet; or hosted on a public, private or hybrid cloud. All these decisions will be used to determine how an application transformation should progress.
For most enterprises, the decision will involve two options: Self-host a Web application or turn to a Software as a Service (SaaS) provider. Initially, SaaS hosting seems the more financially attractive method to adopt. After all, SaaS hosting eliminates most of the costs associated with applications: application servers, database servers, storage systems and so on: All those become the responsibility of the SaaS provider. What's more, other costs, such as for backup, business continuity and disaster recovery solutions, can be greatly reduced as well.
SaaS challenges during the transformation
Moving to a SaaS solution is not done without having to deal with some challenges, concerns and costs, however. The obvious primary concern is whether the SaaS-offered application meets the needs of the business. Many enterprises have customized or modified line-of-business applications to meet particular business requirements. These include special inventory handling, pricing controls, route definitions and customer histories. Simply put, SaaS solutions must meet the needs of the business without requiring it to change common business practices or procedures such as these. If changes are needed, modifications to an off-the-shelf SaaS product can be costly.
In some cases, on the other hand, a transition could be easy. Take, for example, a contact management or sales application. With these, customization usually is not necessary, and moving from the internal application to a SaaS solution might require little more than migrating data and retraining users. Because of embedded inventory control procedures, assembly tracking and so on, a complex warehouse management application, on the other hand, might not be moved over to the SaaS model so easily. In other words, some line-of-business applications simply are not suitable for the SaaS model because extensive customization can be needed. In those cases, re-engineering the application and self-hosting may be the preferred alternative -- if it's merited.
In most cases, application transformation from an aging app to a SaaS-delivered one is a sound business decision that delivers increased productivity and flexibility that weren't possible previously. Examples abound where a SaaS solution was the right one, as evidenced by hundreds of success stories found on leading provider sites. Failures and unexpected problems nonetheless can arise. The trick is to learn from others' mistakes and fully vet the process before you commit to SaaS technology.
Primary areas of concern include:
- Security: How will data be protected, how will access be controlled, and which auditing tools are available to validate the security of transactions and data?
- Reliability: What service-level agreements, or SLAs, are in place to guarantee unfettered access to applications and their associated data?
- Safety: What protections are in place for preventing data corruption and meeting backup and disaster recovery requirements?
- Vendor viability: How viable is the SaaS vendor, and what protections is it offering against business interruption, failure and so on? Will the application and data available if a primary vendor suspends operations?
- Performance: Will the SaaS product offer the level of performance users need to ensure acceptable productivity? How does the product scale?
- Pricing: What pricing controls are in place to prevent costs from growing exponentially? Are there hidden fees, support and scaling costs, or other expenses?
- Support: What level of tech support is offered? Is training included? Are dedicated support reps available? Is there documentation?
- Customization: Can the SaaS offering be customized? Who does the customization? Is it in-house, contracted or self-service?
Asking these questions and getting complete answers should provide customers with peace of mind and help them vet the vendor's commitment and validate its SaaS product's suitability. Of course, many of the above issues should lead customers to research their application transformation options in greater depth -- validating who owns the data, for example, as well as confirming the legal protections being offered and which compliance requirements are being met.
Frank Ohlhorst is a technology journalist, professional speaker and IT business consultant; email email@example.com.
Legacy application modernization: Make SOA work for you
Taking a modern approach to modernizing legacy applications