5 ways to reduce advertising network latency

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

5 ways to prepare your advertising infrastructure for disaster