Feeds

Application transformation: Ready Steady Go!

Measure twice, cut once

Combat fraud and increase customer satisfaction

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

SANS - Survey on application security programs

More from The Register

next story
This time it's 'Personal': new Office 365 sub covers just two devices
Redmond also brings Office into Google's back yard
Oh no, Joe: WinPhone users already griping over 8.1 mega-update
Hang on. Which bit of Developer Preview don't you understand?
Microsoft lobs pre-release Windows Phone 8.1 at devs who dare
App makers can load it before anyone else, but if they do they're stuck with it
Half of Twitter's 'active users' are SILENT STALKERS
Nearly 50% have NEVER tweeted a word
Internet-of-stuff startup dumps NoSQL for ... SQL?
NoSQL taste great at first but lacks proper nutrients, says startup cloud whiz
IRS boss on XP migration: 'Classic fix the airplane while you're flying it attempt'
Plus: Condoleezza Rice at Dropbox 'maybe she can find ... weapons of mass destruction'
Ditch the sync, paddle in the Streem: Upstart offers syncless sharing
Upload, delete and carry on sharing afterwards?
New Facebook phone app allows you to stalk your mates
Nearby Friends feature goes live in a few weeks
Microsoft TIER SMEAR changes app prices whether devs ask or not
Some go up, some go down, Redmond goes silent
prev story

Whitepapers

Securing web applications made simple and scalable
In this whitepaper learn how automated security testing can provide a simple and scalable way to protect your web applications.
3 Big data security analytics techniques
Applying these Big Data security analytics techniques can help you make your business safer by detecting attacks early, before significant damage is done.
The benefits of software based PBX
Why you should break free from your proprietary PBX and how to leverage your existing server hardware.
Top three mobile application threats
Learn about three of the top mobile application security threats facing businesses today and recommendations on how to mitigate the risk.
Combat fraud and increase customer satisfaction
Based on their experience using HP ArcSight Enterprise Security Manager for IT security operations, Finansbank moved to HP ArcSight ESM for fraud management.