Feeds

Application transformation: Ready Steady Go!

Measure twice, cut once

Top 5 reasons to deploy VMware with Tegile

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. ®

Secure remote control for conventional and virtual desktops

More from The Register

next story
Microsoft to bake Skype into IE, without plugins
Redmond thinks the Object Real-Time Communications API for WebRTC is ready to roll
Microsoft promises Windows 10 will mean two-factor auth for all
Sneak peek at security features Redmond's baking into new OS
Mozilla: Spidermonkey ATE Apple's JavaScriptCore, THRASHED Google V8
Moz man claims the win on rivals' own benchmarks
FTDI yanks chip-bricking driver from Windows Update, vows to fight on
Next driver to battle fake chips with 'non-invasive' methods
DEATH by PowerPoint: Microsoft warns of 0-day attack hidden in slides
Might put out patch in update, might chuck it out sooner
Ubuntu 14.10 tries pulling a Steve Ballmer on cloudy offerings
Oi, Windows, centOS and openSUSE – behave, we're all friends here
Apple's OS X Yosemite slurps UNSAVED docs into iCloud
Docs, email contacts... shhhlooop, up it goes
Was ist das? Eine neue Suse Linux Enterprise? Ausgezeichnet!
Version 12 first major-number Suse release since 2009
prev story

Whitepapers

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.
A strategic approach to identity relationship management
ForgeRock commissioned Forrester to evaluate companies’ IAM practices and requirements when it comes to customer-facing scenarios versus employee-facing ones.
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.
New hybrid storage solutions
Tackling data challenges through emerging hybrid storage solutions that enable optimum database performance whilst managing costs and increasingly large data stores.
Website security in corporate America
Find out how you rank among other IT managers testing your website's vulnerabilities.