Tripletex has proven to have an efficient code base. We have up to ten deliveries a day and new developers are up to speed very quickly. In fact, we have a requirement that a new developer (with the support of their team) should have their first delivery within their first week. In our experience new developers are able to independently implement complex features within the first couple of months.

Tripletex is growing quickly, both in terms of developers and end users, and we are not planning to slow down. For some time we have been discussing the fact that a code base which is efficient for 25 developers now, not necessarily is efficient for potentially many more developers in the future. It is clear to us that we must be proactive and do changes in the architecture to prepare our code base for whatever number of developers is needed to support our future business goals.

Our code base is a monolith and we have been asking ourselves if this in itself is an issue. If you have been following recent years trends in software development, it would be easy to conclude that this is a huge issue. In fact, you could easily jump to the conclusion that if you are not doing microservices, you are doing it wrong.

However, we have been hesitant to make the decision to go all in for microservices. We have instead explored if there is a middle ground between monoliths and microservices. We found our answer when we heard Axel Fontaine speak on a conference about the Majestic Modular Monoliths. His thoughts in this presentation was a perfect fit compared to our own discussions on the topic.

Axel Fontaine is the founder and CEO of Boxfuse and the creator of Flyway. He is an entrepreneur, a Continuous Delivery expert, an Immutable Infrastructure expert, a Java Champion, a JavaOne Rockstar, a regular speaker at many large international conferences, a trainer and an author. If you want to know more about Axel Fontaine, please visit his home page

We contacted Axel with the hope that he could assist us in exploring different strategies for restructuring our code. We were happy when he accepted to participate in a two day workshop. In order to get the most out of the workshop, we created a list on what to focus on, in prioritized order;

  • Do not think too far ahead. We will have a hands-on workshop that focuses on what we actually will do in the near future. We will shut down all discussions that are theoretical or ideologically of nature. We will never be able to plan for every possible issue. Our goal here is to stake out a starting point.
  • Prepare solutions before the workshop. The main benefit of the workshop is that we must think through our own suggested solutions and actually present them to an experienced third party.
  • A gradual approach. We must be able to deliver new features to our code base while we are restructuring it.
  • Value from “day one”. It is important that we can see beneficial results from the start. We will not be able to gain experience and adjust thereafter if we must wait three months to see the results.
  • Get advice from Axel. Axel has battle scars that we can learn from. Let’s pick his brain.
  • Gain confidence in our decisions. In our daily work it is easy to end up in a bubble. In this bubble you often have the situation where discussions is never ending, because of disagreements or uncertainty on some of the decisions. Axel can help by giving us assurances that we are on the right path.

When you have invited a renowned expert, it is easy to make the mistake of expecting them to give you the magical solutions. The truth is that the ownership and responsibility to find solutions must be our own.

In the first day of the workshop we picked the simplest module we could think of as a proof of concept. The focus was to get a clear picture on how the design of a typical module should be in the future. We had detailed discussions on patterns, layers, dependencies and frameworks.

The second day of the workshop we picked out two important domain areas in our code base, and had intense discussions on how we could extract them out of our monolith. It became evident that the most difficult part of the process is not necessarily the technical part, but rather finding the natural domain seams in our code. To include subject domain experts when taking decisions in the future will be critical if we want to succeed in creating a Majestic Modular Monolith.

The workshop with Axel was a great success. We are excited to get started on implementing our own Majestic Modular Monolith in Tripletex. The quick conclusion of the workshop with Axel is;
Could we have gotten the same result from the workshop ourselves? Yes, but it was quicker and we have more confidence in our choices with Axel involved.

I am grateful to Axel that he could join our workshop. As Tripletex is growing as a company, we also think it is important to give something back to the developer community in Oslo. Axel was nice enough to do a Tripletex hosted presentation for Oslo Software Architecture Meetup group (OSWA) at Teknologihuset. The meetup was fun with a full house and great discussions.

There are several more benefits from modularizing our monolith that I have not discussed in this post. We will to continue to share our experience in this blog.

Morten Vinje
Process Manager and Team Lead for A-Team in Tripletex

Prøv oss gratis i 14 dager!

Prøv Tripletex gratis i 14 dager - helt uten forpliktelser eller liten skrift.