The inspiration for this post came after we were requested to deliver a new feature in the General Ledger area. We began analysing the requirements and we started with the idea that the implementation will be done in the Mambu monolith application. This seemed an obvious choice, because the business and technical complexity was not high and we could have delivered the feature in a month. Things changed when we began thinking about the scalability and the performance of the feature in one year, we realised that our current storage system could be overloaded as the amount of data would be too large and could degrade the overall application performance.
The following step was to explore the other option of having a separate capability that would deliver the requested functionality. We began our journey by investigating the organisational level:

• Do we have the right team to achieve this? As the team is a mix of colleagues with different expertise and experience the answer was ‘yes’.
• Does Mambu have the support for new capability development? Yes, because the teams are working in close collaboration and we are able to connect to other disciplines (e.g. Infrastructure) in order to achieve our goals.
• Was there another capability from which we can learn? Yes, there are several other capabilities who shared their experiences.

Going forward, we began defining the architecture of the new capability. Our analysis showed that the needed inter-process communication patterns were already used by other capabilities and we could reuse the same components. As our most important component was the storage system, the next step was defining the criteria for exploring the available storage systems. We chose the evaluation criteria mostly by non-functional requirements, split into the following categories:

• Business driven requirements: performance, scalability etc.
• New system requirements: portability, reliability, robustness, maturity, rate of adoption, active development, operational costs, offered as a service in the cloud vs maintenance by our team, consistency, availability, extensibility, monitoring, alerting etc.
• Security requirements (as the financial field is a highly regulated one we must ensure all components are passing the security and compliance standards): auditing, data recovery, disaster recovery, data encryption etc.

Using the defined criteria, we chose a list of five storage systems that were performance tested using simulated data. Based on the test results we decide the storage system for our capability.
After making the final decision of the architecture and the components to be used, we continued by starting the actual implementation of the feature. About four months later the alpha version of the implementation was ready.
The development phase took longer than the time it would have taken if we had chosen to implement everything in the Mambu monolith. But the long term benefits of having a dedicated capability overcome it as the capability solution is more robust.

As a side benefit, on team development level, I noticed that working on this capability increased the team cohesion as it involved a lot of mob and pair programming sessions in order to overcome all the technical uncertainties. I also noticed that the team was enthusiastic because this implementation allowed us to discover new architecture, new technologies, new ways of looking at a problem and enabled us to learn new things.

In software development, as in everything else, the shortest road isn’t always the best one and having a broader perspective on things could lead to a new path that offers many learning opportunities.