Building Technology that Ages Gracefully

This is the second part of a two part post. The first part discusses the impact of legacy technology on an enterprise and means to incrementally renovate systems to reduce risks and costs. This part will focus on means to avoid renovated or green field technology from becoming legacy.

Creating Ageless Technology

Eliminating legacy out of a technology ecosystem using techniques such as strangulation is only a part of the challenge. A bigger challenge, perhaps, is to keep legacy from creeping back in thus enhancing its longevity and increasing the ROI (Return On Investment) on building new systems.

There are several reasons why legacy creeps into systems. Notably, a tightly coupled architecture with tightly coupled dependencies which makes the system less testable, extensible and flexible is the most common cause of premature obsolescence. Following are some strategies to help create technology where rejuvenation is essentially routine maintenance and not multi-million dollar initiatives. These build on the DIPSy framework described in an earlier post.

Build on a Platform

An enterprise technology ecosystem consists of a number of applications automating various aspects of the business domain. Hence, there is common technical and business functionality in these applications which can be integrated into a platform shared by the ecosystem. As a result, applications can leverage the platform to deliver their respective features.

Investing in a comprehensive platform allows most modernisation actions to take place on the platform and all applications based on it to benefit from those. While this optimises modernisation or a renovation initiative, a platform itself is still susceptible to becoming a legacy.

Independence

Decoupling platform and application components from the underlying technology and 3rd party dependencies provides opportunities to replace them without significant overheads and serious side effects. Optimal decoupling occurs when interfaces between dependencies and dependents are based on well defined domain models which are also decoupled from any of the domain specific 3rd party dependencies, e.g., maths libraries or computational frameworks. This enables dependencies of applications and underlying platforms to be upgraded or replaced with development effort only within the interfaces and not the platforms and applications.

A focus on independence should not end at the boundaries between technology and domain specific code. Vertical application features must also not be tightly coupled even though they may depend on each other. These features may in turn be implemented by a number of different services as in the case of the microservices architecture. It should be possible to replace or remove any feature completely or partially for optimisation or refactoring without causing side effects in the remaining application.

Comprehensive and Efficient Testing

Without adequate, efficient and automated testing in place, any change is risky and costly. Risks involve introduction of undesirable and unanticipated side effects. Manually testing systems to ensure that these side effects are not introduced is time consuming, error prone and costly.

However, with the right level of automated and efficient testing in place, systems can be quickly tested after making changes and resulting defects fixed in efficient and economical release cycles. The convenience of introducing change in the technology provides opportunities to modernise it with minimal risks and costs hence ensuring its longevity.

Frequent releases and deployments

Releasing software takes time especially if a release requires several steps that involve not just deploying software but also making infrastructure and configuration changes. After a release has been deployed, it needs to be tested to ensure that the system is ready for business post the release.

Manually releasing an enterprise application and then testing it for readiness is tedious and error prone. It is one of the major reasons for infrequent releases in legacy applications causing them to accumulate obsolescence. As the frequency of releases decreases, the number of prospective changes within each release also increase making a release risky. Hence, any change aimed at modernisation is given the least priority allowing obsolescence to set in.

By automating releases and deployments, these processes can be optimised and standardised. As their overheads and risks reduce, their frequency can be increased which allows smaller and more incremental changes to be released. Applications and their platforms thus benefit from frequent upgrades.

Ultimately, Legacy may be Unavoidable

These measures can provide significant longevity to a technology ecosystem. But evolution in programming languages and emergence of new languages and paradigms eventually forces obsolescence in technology. Presence of effective test suites on applications composed of granular and composable features ultimately always facilitates any future strangulation to drive corresponding modernisation in economical and effective ways.