Thinking about upgrading digital platforms? Here are your options...

In today’s digital era, keeping up with shifting consumer expectations and providing them with the low-friction and straightforward experiences they crave is a massive challenge that most public and private organisations face. Often, the problem lies in the fact that due to platform constraints, many companies are slow or even incapable, of deploying the digital technologies that consumers already expect and have adopted in their day-to-day lives. Many citizen transactions are still supported by old systems and platforms that lack the flexibility, scalability, extendibility and interoperability to deliver the digital channels needed for 24/7 citizen access as well as ensuring that customer interactions are not only more efficient, but also have a strong focus on delivering exceptional experiences. Therefore, in order to meet the increasing demands and expectations of more experienced digital users, organisations need to go beyond digitising processes and services, by leveraging the power of digital technologies and data to improve efficiency and transform their business models. The starting point of upgrading digital platforms begins with exploring these three options:  

Option 1 - Do Nothing – What are the Risks?  

Doing nothing may be tempting to CxOs in some scenarios where legacy systems in use can still provide most of the required functionality as this option doesn’t require an investment in new systems. However, the cost of keeping legacy systems “alive” may outweigh that of platform modernisation while carrying a much higher risk. Sooner rather than later, a misalignment with business requirements will be identified and the risk of legacy systems not being able to provide the required functionality to adapt to new requirements will more often than not, be very high.  

When carrying out a TCO analysis, CxOs should take every single aspect of a system into consideration, including the cost of keeping the system “alive”. As much as 80% of public organisations internal IT resources are dedicated to maintaining legacy applications, working in firefighting mode and being unable to take on higher value tasks that add value to the business.  

Relying on IT resources that have become experts on legacy systems is not something a CxO should be happy about. Particularly when those resources are paid very high salaries – not because of the value they bring to the business, but because they are the only ones in the organisation, capable of keeping that “30 year old mainframe” up and running.  

Another major risks with legacy systems is the inability to provide the necessary functionality to comply with new regulations (i.e. GDPR). Other risks associated with a “Do Nothing” approach are:  

• Difficulty or not possible to provide secure self-service web-based channels for customers to complete their transactions online – no reduction in cost and reliance on customer service 
• Higher infrastructure and maintenance costs  
• Higher security risks as legacy systems don’t have the security mechanisms needed to protect against cyberattacks 
• Risk of not being able to scale the systems to cope with increase demand  
• Incompatibility and/or lack of interoperability with other systems/platforms – no agility and flexibility – Not possible to integrate systems with other government agencies’ systems.  

While there is generally a high risk and high cost involved with the “Do Nothing” approach, sometimes the best option is to maintain a legacy system as part of a platform and focus on reducing maintenance costs and infrastructure associated risks (Containerisation) – being a sensible first steps towards entire Platform Modernisation. 

Option 2 - A Big Bang Approach  

Stefan van der Zijden, research director at Gartner, says:  

“If you’re faced with a legacy challenge, the best approach depends on the problem you’re trying to solve. Replacement isn’t the only option. The key is to understand if your problem is caused by technology, architecture or functionality of the application, and how each modernization approach improves those aspects”.  

An approach with broadly scoped projects where the goal is to deliver functionality several years after the project starts. This approach is often too long, ineffective, and incompatible with the rapid evolution of IT and carries a lot of risks, for example:  

• Highly likely to rebuild/renew deprecated or redundant functionality  
• Modernising/Replacing all the systems users use to perform their daily activities would most likely be overwhelming and lead to very poor end user adoption 
• Modernising/Replacing all the systems required to carry out a business - not being able to continue business as usual for an extended, unpredictable length of time 
• Risk of losing project sponsors due to lack of business value realisation  

A Big Bang approach requires a big investment up-front and most often than not ends up with only a small percentage of the systems being successfully modernised while other systems’ modernisation fail or require additional investment and an extended effort to get completed.  

Option 3 - Phased Platform Modernisation  

An incremental approach aligned with the business vision where the driver in progressing with each phase of the project is dictated by the business strategy and the business value that the phase will deliver.  

Organisations should start by inventorying all their existing systems/applications (no exceptions, regardless how insignificant an application/system can appear to be) and identifying the business function that each of them serves. With a complete inventory, business can then assess which ones are still needed, which could be merged into a single system and which are not needed any more (i.e., they were built to serve a purpose that is no longer present).  

Once systems that are still needed have been identified, organisations should carefully analyse what the best modernisation strategy for each of them would be:  

Encapsulate 

Leverage and extend an application’s functionality encapsulating data and functions in the application and making them available as services via an API.  

Rehost 

Redeploy an application component to another physical, virtual or cloud infrastructure without modifying the application code, features or functions.  

Replatform 

Migrate an application component to a new runtime platform. Modify the code slightly to adapt it to the new platform, but don’t change the code structure or the functionality it provides.  

Refactor 

Restructure and optimise existing code without changing its external behaviour to remove technical debt and to improve the component’s features and structure.  

Rearchitect 

Modify the application code so you can deploy it to a new application architecture and fully leverage new and better capabilities of the new platform.  

Rebuild 

Rebuild or rewrite the application component from scratch while preserving its scope and specifications 

Replace 

Eliminate the legacy application component altogether and replace it, taking new requirements and needs into account.  

Build PoCs to assess if the selected strategy delivers the expected result.  

Create a roadmap for all of them that:  

• Delivers value in increments. 
• Prioritises the ones that have a better balance between delivering value and risk.  
• Considers training requirements and aligns delivery with them to ensure end user adoption (not overwhelming the end-user with a lot of changes at once).  
• Maintain simple design and good technical hygiene.  
• Automate testing and integrate that into your development process. 

Once each of the above options have been explored then it is time to create the business case.