Application transformation: Ready Steady Go!

Measure twice, cut once

Intelligent flash storage arrays

Old software never dies, it just functionally decomposes. When applications reach the end of their lifecycle, they can hang around, ghostlike, creating support and infrastructure costs, or they can be made useful again. Application transformation is a key part of that process, but what is involved?

The driver for application transformation lies along two axes: functional quality (what it does), and technical quality (how easy it is to maintain). Hopefully, when an application is first released, both of these are relatively high. It does what it says on the tin, which is highly relevant to the business using it. It also does it with relatively low support costs.

Over time, the business changes, and the application's function doesn't necessarily match what the business needs any more. The support cost involved in modifying the software goes up. Eventually, it reaches an end of life scenario, where its value to the business is minimal, and its support cost is high. At this point, the application is either retired and replace with a new one, or rebuilt, Frankenstein-like, and reanimated.

As opposed to simple replacement, application transformation involves taking elements of a software application and modernising them. It is a more intricate process then a simple forklift job, but it can yield rewards because it enables reuse of critical components.

There are various approaches to application transformation, each of which involve different levels of complexity. For example, modernisation may be as simple as inserting a web-based portal server in front of a legacy application portfolio, aggregating their functions into a single new interface.

At the other end of the scale, you may choose to completely re-architect a legacy application, rewriting it in a new language, and changing its underlying design in a bid to support new hardware, operating systems, and software frameworks.

Your transformation may also involve a level of service enablement, in which an application is modified to become part of an enterprise service layer, providing key functions to other software and perhaps drawing on software services presented to it. This route takes you down the service oriented architecture path, which is certainly advantageous, but can also entail a fairly hefty strategic shift.

There are several stages involved in transforming an application. The first is the assessment and planning phase, in which you evaluate the software, understand its relevance to the business, document any specific requirements that the application has (such as specialised hardware, or software interdependencies), and then develop a transformation plan.

The second involves modelling the application formally. You need an understanding of everything from the front end to the backend. What functions does the user interface have? What use cases does it support? What business rules does the application codify? What datasets does it use?

This formal definition of the application’s function serves to create a list of assets that form the application. You can then use this list as the basis for redesigning the software. It helps you to understand what you can reuse, and what has to be modified or replaced. If you do decide to modify elements, such as the user interface, for example, use cases can help you to understand how those elements can be remodelled. The hope is that some components can be reused with minimal modifications.

Once the application has been redesigned, any pieces that need to be modified or created from scratch can be built and tested as part of the transformed software. Once this is done, it can be redeployed as a high-value, low support application at the start of a new software lifecycle.

There are several details that must be decided when redesigning the software. The presentation model is a key part of the decision process. How will the application be presented to consumers? Is it designed to be consumed by end users, or is it a backend batch application? If end-users will be using the application, will they be web-based? Is user mobility important, and if so, what devices and mobile interfaces will you support?

The hosting model for the application is of course a crucial component of the transformation strategy, and this will depend as much on the application’s existing profile as on your broader hosting strategy. Some applications may have specific requirements that make them difficult to post in certain ways. For example, it can be challenging to move applications with very low latency requirements into a cloud-based environment.

When transforming an application, an organisation will rarely be able to flip the switch and have a new one working the next day. Instead, it will be a gradual process with many steps. It is important to have an architecture in place to support this transition. This involves a roadmap, which will dictate which new pieces of functionality are introduced to which groups of users as the transformation happens.

Depending on the presentation model, it may be worth introducing a front end that delivers an updated interface to users before rewriting backend modules. Introducing a front end web interface that shields users from existing legacy code at the backend can serve as a stopgap until code can be rewritten behind-the-scenes.

Some users may need functionality sooner than others, and the business impact of introducing it will likely be greater. Some transformations may best be scheduled at times when their potential negative impact is lower, such as before peak periods of seasonal activity, rather than during.

It is also important to have a plan to help manage the risk of transformation. If any disruption to business processes occurs, it would be useful to know that things can be rolled back or some other contingency introduced to minimise the impact.

And finally, amid all of these design considerations, pay some careful thought to process. When designing an application, the savvy company will take the opportunity to introduce standard models and procedures that will yield rewards later on.

For example, standard software governance models will help to introduce well-understood ways of managing and documenting software assets over time. As much as possible, using common reference architectures for application transformation will help software development teams to leverage software components over time as more applications are transformed.

Putting these basic layers in place during transformation processes now will make it easier to adapt and revitalise software further down the line. But it takes planning and foresight: measure twice, cut once. ®

Providing a secure and efficient Helpdesk

More from The Register

next story
UNIX greybeards threaten Debian fork over systemd plan
'Veteran Unix Admins' fear desktop emphasis is betraying open source
Netscape Navigator - the browser that started it all - turns 20
It was 20 years ago today, Marc Andreeesen taught the band to play
Redmond top man Satya Nadella: 'Microsoft LOVES Linux'
Open-source 'love' fairly runneth over at cloud event
Chrome 38's new HTML tag support makes fatties FIT and SKINNIER
First browser to protect networks' bandwith using official spec
Admins! Never mind POODLE, there're NEW OpenSSL bugs to splat
Four new patches for open-source crypto libraries
prev story


Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
Why and how to choose the right cloud vendor
The benefits of cloud-based storage in your processes. Eliminate onsite, disk-based backup and archiving in favor of cloud-based data protection.
Three 1TB solid state scorchers up for grabs
Big SSDs can be expensive but think big and think free because you could be the lucky winner of one of three 1TB Samsung SSD 840 EVO drives that we’re giving away worth over £300 apiece.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.