Overcoming paralysis in financial services modernisation

There are several different ways to approach a modernisation project, from updates to the platform, to a complete overhaul of all systems and technology. The approaches are: Rehost (also known as “Lift and Shift”, or “Redeploy”), Replatform (“Lift and Reshape”, Redeploy), Rearchitect (Reengineer, Refactor), Rebuild (“Rewrite”, Redesign), Replace (“Repurchasing”, “Drop and Shop”). These modernisation approaches differ in their ability to change the technological, architectural or functionality aspects of the application**:

• Rehost and replatform allow changes to the technology platform on which the application is running. These approaches can solve problems caused by the technology.

• Rearchitect allows changes to both the technology platform and the code structure of the application. These approaches can solve problems in the technology and architecture domains.

• Rebuild and replace allow functions and features to be changed or added. These approaches can solve problems in the functional domain and provide the opportunity to change technology and architecture.

** Data source: How to Choose the Right Approach for Application Modernization and Cloud Migration, 23 January 2023 - ID G00772600, GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.

To answer the questions of why so many modernisation projects fail and what can be done to help more succeed, we spoke to two of Nearform’s modernisation experts, Joe Szodfridt, Sr. Solutions Principal, and Shaun Anderson, Field CTO. 

Joe Szodfridt: “Well, there can be lots of different reasons why a project is seen as a failure. Sometimes, if all of the stakeholders haven’t gotten together and discussed what outcomes they’re all looking for, then the final product might not meet all of their expectations.”

Shaun Anderson: “A lot of times, it comes down to the fact that different people have different outcomes that are important to them. So, what meets one person’s expectations might not meet a different person’s, because they each have different things that they want to achieve with the project. And when it’s all said and done, they might realise that they don’t have the right resources in place - meaning both technology and personnel - to create and maintain the business results they expected. Even sometimes when a project starts, there’s a kind of ‘paralysis’, because they get their approach the wrong way around. To me, organisations fail because they take a bottom-up approach, where technology is at the bottom and they work up to the top, which is business. They fail because they take a ‘technology-first’ approach vs understanding ‘how the system wants to behave’.”

Shaun: “Understanding how your system wants to behave is about grasping the purpose, the logic and business capabilities that it’s created to meet. Being clear on what it’s doing, and grasping how it is helping the business. It means grouping the system into different capabilities, organising its functionality and features based on what they do. When you do this, instead of thinking about the software only in terms of its technical components or modules, you’re focusing on the high-level goals or outcomes of the software.”

Joe: “A system is a set of tools to help people execute a business process efficiently. Their use is continually evolving. The creators are often constrained by the technical limitations of the implementation. "How the system wants to behave" removes those limitations and allows the thinking about optimal paths, and innovation. Beyond just focusing on trends, leaders should spend time determining how their critical systems "want to behave" and what technologies will be needed to enable the transition. Simply watching trends may lead to a reactionary mode of "shiny new toy syndrome" rather than being proactive and identifying technologies and solutions that will enable their products to move forward to be more efficient, modern and innovative.” 

Shaun: “And it’s important not to forget about the people who maintain the system you’re modernising. Modernisation is not just a technical exercise — it goes beyond changing/amending software within a system and extends to the people supporting it. Consider the capabilities of their technical staff — are they equipped to deal with the technical changes needed to make the system behave as it needs to? Do they need additional training or expertise? We have to remember, the outcome of any modernisation project will affect these people and, just as importantly, these people affect the outcome of a modernisation project. It means that these questions need a positive answer for a modernisation project to be successful.”

Shaun: “When we’re working with a client, we ask some very purposeful questions. We want to ask things that make everyone involved really think about what capabilities they want to achieve, and beyond that, what is possible to achieve. We’ve mentioned that the outcomes of a modernisation project affect the user, which in this case is the business, as well as the system and the technical staff. For the project to be successful, financial services companies need to gain a consensus that works for all of these elements. It’s important to ask the questions: "What are the outcomes that are needed for the business?" "What are the outcomes the system is demanding?" "What are the outcomes that the technical staff can manage?" Gaining consensus is about establishing where these things meet. Basically, when everybody answers all of those questions, they kind of derive how the system wants to behave together. Then, no one needs to work to drive consensus. It happens automatically when you get agreement on the capabilities that are needed to serve the business.” 

Joe: “Exactly, It goes back to what Shaun was saying about making sure to check in with the people who work on and maintain the system, about the importance of considering the people. Some of the key topics to align on is what technologies, skills, and expertise will be needed to help systems behave the way they want to. It’s about being proactive vs. just implementing the latest technology.”

Shaun: “We've got the base skills here to do a wide range of projects. But more than just having the right skills, we want to help a client break free of any constraints they think they have, based on how their current system behaves. We tell people in these engagements, “The first rule of fight club is you don't talk about existing systems.” Eventually, we’ll talk about them, but when we first get started, we want them to see the art of the possible. So we talk to our customers about how to put all our expertise and practices together to solve their problems, determine how to measure success for them, understand their end goal, and maybe even find something that goes beyond what they think the goal is.” 

Joe: “We try to help expand their thinking. Sometimes people are so close to a problem, they don’t realise that if they think just a little bit differently, they could not just hit their goals, they can disrupt the market.”

Shaun: “Right. There's outcomes, but the step past outcome is impact. And that impact can be something like "I want to gain market share", not just something like saving a little money. You can have an incremental impact, beyond the basic goal outcome. That’s what we aim for, to think of the possible exponential benefits. First by helping them look beyond their existing situation, then understanding how the system wants to behave, and then applying those constraints to understand where those exponential impacts might be.”

Joe: “And we can move fast because our method of asking these questions in a specific way allows us to spot the patterns that we've seen across many industries, because they repeat. That’s what we do, we help them find solutions to take them beyond their initial goals into that disruption area, and we do it fast.”

Joe: “It’s basically what we were just talking about, to be open-minded, to think beyond your goals. Don’t be constrained by what your current systems can do.”

Shaun: “Modernising a system is a journey. You have to go on that journey so you can see the possibilities beyond what you might have envisioned at first. After you have your initial conversations about how the system wants to behave, create a system model. With modelling, you can pilot several schemes at once.

When we did a project with a nonprofit association of insurance companies, they had tried before to modernise the legacy systems that were slowing them down, but hadn’t been successful. They were stuck. When we came in, we created a model with all the information we gathered about business needs and behaviours. The visualisations from the model helped all the major stakeholders from the business and IT teams who hadn’t communicated well during other modernisation attempts better understand what could be, and needed to be done. This led to a clearer strategic direction. Over the course of six weeks, we were able to analyse the wider operational context, and the model produced a series of business domains that intersected with each other, revealing a vision of the overarching operations, services, and data flows. This was the first step in producing a roadmap for bridging the old and new systems, where the old system was gradually phased out as the new one took over. And the process had the benefit of not only meeting the base goal of being more efficient, it allowed them to go beyond that and really be more customer-centric.”