1. Rethinking monolithic architecture
Monolithic architecture is one of the biggest challenges we faced before redesigning the system. As for now, we are putting a vast effort into making things more decoupled. We now know that thinking about the long term is crucial - we need a system with components that can be easily changed or modified when the time comes. To achieve this, we implemented Domain Driven Design, which helps us to build the domain knowledge for the future. In addition, analysing reference architectures in the market enabled us to benchmark and construct a target architecture. Finally, to succeed with these changes, we had a significant shift in our ways of working – we became more agile and risk-driven.
2. Changing the business perception
Changing the business' perspective towards the problem might save you time, money and improve customer experience. For example, a huge challenge that comes with a legacy platform is understanding what the requirements are. A common expectation we hear from the business side is to "make the system work like it used to work". The way we view it as developers - if we make it work like it used to, we will have the same problems we used to have on our end. That's why we are willing to challenge some old practices and push limits - we seek to have clear requirements helping us to come up with suitable and innovative outcomes for all sides.
3. Overcoming the dependency hell
Payments are at the core of the bank, where most teams are either executing payments (upstream consumers) or using our data (downstream consumers). Combine it with hundreds of teams and thousands of developers working simultaneously for multiple years, and you end up with a project which is close to impossible to execute unless you stop all the bank for a year or two which, as you could have guessed, is not an option. For upstream consumers, we found Pareto principle (80/20 rule) works the best. For downstream consumers though, we must ensure bare minimum compatibility allowing existing interfaces to work as expected and decoupling them from our project.
4. Keeping it people's business
People play a crucial role in changing something as complex as a payment engine. It does not help to find out that key subject-matter experts are already busy, although very much needed, as we move from the old technologies and train actively to acquire new skills. Natural resistance to change also comes into play here. Agile transformation helped us to overcome these aspects by building dedicated teams based on our domains. We believe that a hybrid engineering program enabled us to retain the best talents in the process – we upskilled engineers to become comfortable working with both Mainframe and Java.
5. Building the new infrastructure
Of course, an extra complex challenge is building a new infrastructure itself. It started by introducing a team of dedicated platform engineers, enabling the rest of the teams to move faster and have more end-to-end responsibilities. Next, early testing gave us confidence that we were on the right track. Then, to avoid gaps in our skills and speed up the process, we hired external experts to conduct training sessions.
Finally, the public cloud can help here a lot since you can test it early without a large upfront investment in hardware selection and capacity planning, which might become irrelevant by the time you go live. This is something we experience ourselves too. As a result, we are now looking forward to implementing our public cloud first strategy.
To get more in-depth examples, look at the recording of Audrius' presentation during the Technight event bellow.
