Our modulith in the collection business – How we fight for synergies across systems and countries

Introduction 

Riverty is owning collection businesses across Europe with major operations in Austria, Belgium, Denmark, Finland, France, Germany, Luxembourg, Norway, Sweden, Switzerland, The Netherlands and the United Kingdom. Traditionally, most countries were acting as separate entrepreneurial units with individual strategies, systems, operations, and more. 

As a part of Riverty´s mission to become the most human-centric fintech, all countries now follow the same strategy towards more consumer-friendly products, better service integration across business lines and countries, and a better more unified user experience. To finance these investments, cost synergies between the countries and systems shall be identified and implemented. 

Norbert Ebi is our tech lead for all collection businesses, being advised by our enterprise architect Oliver Süvern. 

Interview  

Gregor: Please describe concretely what challenge we are facing! 

Our challenge was and still is to optimise the IT of our collection businesses in 12 countries across the board. For core processes of the collection business we use four different applications, some of them self-developed, others licensed. So for many very similar problems there are different solutions, sometimes in up to four variants. Some challenges in our business are indeed very different per country, but for others there is no objective reason for different technical solutions.  

So first we had to identify the levers we wanted to use in a meaningful way. Then it was a matter of winning over the staff and management for a real stake. The possible abandonment of an own, local solution should be perceived as an opportunity worth participating in. And finally, the actual implementation of the ideas, of course. 

Gregor: How did you approach the decision-making process before the actual implementation? 

We knew from the very beginning that we did not want to transfer all countries to a central application. We had already gone through this process within Germany a few years ago and knew that if we now migrate all 4 systems / 12 countries into one application, we would be paralysed for years without directly delivering noticeable added value for our business. Moreover, neither our in-house development nor the licensed systems are out-dated: we use current programming languages, the code is maintained and documented, we test and deploy largely automatically. Only architecturally it was a monolith for the time being. 

So our premise was first of all: all countries should be able to continue working with their respective core applications. But clearly: we definitely wanted to leverage synergies, because the goal of the initiative was optimisation. 

Gregor: That sounds like squaring the circle.  

Oliver: Indeed. The expectation to leverage synergies, not to make disruptive changes, while maintaining a constant flow of new features for the existing business, is not easy to meet.  

We have put our focus on creating relative cost advantages. So if the operating costs remain constant, but we process significantly more transactions through the application or offers our customers additional features, then that benefits us as well. In order to roll-out these ideas to full our organisation with more than ~1500  internationally distributed employees, we first created transparency and focused on training. 

Gregor: But now let's be specific: What have you centralised, what have you left decentralised?  

We have developed our so-called 360-degree concept. The four existing systems remain in place for the core business. Our approach is  to centralise all applications around them, for example the archiving system, the unified messaging solution or portals for our customers. Why should you operate different solutions here? In these cases, standards not only bring down costs but often also improve the quality of the service itself. 

Gregor: You have consciously decided against microservices and are now pursuing the idea of moduliths for the self-developed core system. Why? 

Oliver: In our context, microservices bring more disadvantages than advantages, because we do not have the need for distributed transactions in this way. Let me give you an example: When we send a letter, it always consists of several process steps: booking our reminder fee, calculating the balance, composing the letter text and adding the layout with a company logo. If, after booking the fee, an error occurs during accessing the logo file, then the transaction has to be rolled back. In a common runtime environment, this can be done safely and without problems. But with distributed systems it becomes problematic.  

Therefore, after weighing the opportunities and challenges, we decided to use a modulith. There are clearly separated modules within the software, even with the interdisciplinary teams known from microservices for each technical function. In this way, we combine the advantages of decoupling with those of an integrated application. And finally: we don't really have the need to quickly replace a service like accounting with another one. 

Norbert: I would add: we have not made this decision easy for ourselves and have also experimented with more decoupling. For example, we started by taking out the service for address management. But it quickly became clear: we need an immense amount of time for that. Of course, the long-term benefits would be great. We could onboard new staff more quickly, optimise quality assurance and reuse it more easily in other countries. But it would take much more than 3 years for the benefits to outweigh the effort. 

Gregor: Okay, then let's go into the topic of synergies: at which points on the in the next 3 years do you expect the most effects? 

Norbert: We expect most synergies in the context of our consumer and customer front ends. We once counted how many of them we currently maintain and came up with a double-digit number. There we reduce the effort for development and operation and at the same time we can provide our customers with uniform but very capable front ends.  

Another area is our unified messaging system, which we now use to send messages for all our units, whether by letter or email. r the already mentioned example of archiving systems. Our idea is to encapsulate the four core systems via an API layer and to standardise all surrounding systems. 

Oliver: APIs in particular play a very big role in our transformation. On the one hand, we are creating a 360-degree API ring around our four core systems and can thus control and develop their communication with the peripheral systems much better. On the other hand, we want to combine all outward-facing interfaces in the so-called "Riverty Collection API". In the past, we were very use-case-based and built an own solution for each customer. With a well-documented, uniform and secure API to the outside world, the customer can now realise a connection himself most quickly. 

Gregor: So in some places I perceive a lot of management attention. Are there issues where you consciously allow individuality or even inefficiency? 

We definitely allow decentralisation. In the areas of bookkeeping and accounting, for example, because this is always country-specific. There are a lot of national legal requirements, and centralising logic and interfaces would be pointless here.  

It is similar with the details of case processing. The masks for the colleagues are very system-specific and the underlying processes are again strongly dependent on the respective country. German claims are usually processed in Germany by German-speaking staff in accordance with German law. In Sweden, for example, address determination plays a much smaller role than it does here, because by the usage of the social security number a higher grade of digitisation is enabled. In some countries like Switzerland there are “Genussscheine”, in others there is no concept of compulsory enforcement. 

And as a final point: many of our agents have been with us for over 20 years. If we tried to harmonise the interfaces internationally, we would lose months of efficiency in the operational processes. 

Gregor: How are you approaching the transformation process and how far are you? 

We started about two years ago, but initially with a focus on Germany. At that time, we started to think about New Work in a core team and brought the idea of interdisciplinary teams to life. At that time, the change was based on the concept of "employee self-selection". In other words, we provided a framework for the new team structure, and the employees were then free to choose their own team. 

Gregor: Exciting! Were there teams that no one wanted to be in? 

There are teams that are less crowded, yes. I don't think we had an empty team. But in retrospect, of course, you realise that objectively it wasn't optimal. For example, we have a team that consists only of juniors. We would never decide that top-down but in the meantime it has been adjusted together. 

Gregor: But you thought the effect of self-motivation through self-determination was greater than that of a theoretically ideal cast? 

Nobert: Following one's own motivation and also the satisfaction of being involved in something is definitely a strong lever for employee´s happiness. As I said, the structure was developed by the core team, and it wasn’t subjected to further discussion. But what we also talked about together were the boundaries of the respective areas of responsibility. Sometimes it only turned out through dialogue that another team was much more familiar with a certain feature than the one originally planned. All in all, this staffing and re-sharpening process was very beneficial for everyone. 

Gregor: What was the most difficult decision you had to make in the course of the transformation? 

The hardest decision was the one about the organisation. What were the major alternatives? We could have gone for a functional organisation or separated according to the applications used, but I decided on a mixture. Some basic topics like infrastructure, security and architecture are organised functionally, other teams are organised according to the four platforms Cosima, Ikaros, Focus and Nova. Basically, this decision follows my expectations of where optimisation effects can be leveraged in the future.  

Gregor: We do come from a culture of local intrapreneurs who are fully responsible for business, organisation and IT. But now it's about bringing technology together across international borders. How well does the associated cultural change work? Where could it work even better? 

Well, I think it's working better and better. Why? Because we have been working on transparency and communication for one and a half years. That's the classic way to start bringing organisations together. The second is that initiatives like our current efficiency programme or the "Most human-centric Fintech Matrix" help us to create transparency and talk about things in a more neutral way. Something along the lines of "Hey, we all want to become more efficient, how do you do that?" That's a good cornerstone for collaboration: approaching each other through better understanding of contents, systems and processes. For me, it sometimes seems less difficult for the technicians to leave their local than for us managers. 

Gregor: Looking back, what lessons have you learned? What were the biggest mistakes? What would you do differently now? 

To put it bluntly: lifting synergies hurts. So that is actually the big learning. 

Even if you sometimes don't realise it, when you try to bring things together and optimise them, someone always gets hurt at some point. Even today, I still don't have a patent remedy for how to avoid this completely. Apart from talking, communicating, talking, communicating, and coming to terms with the content. Why do you do something? And it's not bad if you do something differently than before or take over someone else's idea.  

But what would I do differently today? I would show more stringency earlier. Even if it hurts. I would try to present the situation transparently, like at the doctor's office: It hurts now, but it's necessary. 

Gregor: Norbert and Oliver, thank you for your time!