How to Tackle Breaking Down a Monolith
As a PM, a lot of us have experienced asking engineers for a new fancy feature and getting the infamous answer “We can do it, but it will take ages: it is in the monolith”.
We would spend a lot of time trying to figure out how to be the most efficient, touching this monolith as little as we could, and still delivering a bit of value. We tried to split it into micro services, but eventually, we got to the end of the low hanging fruits, and the value was not there any more. So we needed more. We needed to break it down, and for that, we needed a plan.
Planning to plan
Quite a few times, PMs tried to gather the tech leads in a 1 or 2-hour long workshop. The outcome was always the same. We needed to break down the monolith into micro services. But no tech lead had a good understanding of the full scope, we couldn’t agree on what to tackle first and why, how to split the work. The one thing we knew is that it would be impossible to block a full year or so of development to do it all. After these workshops, no follow up was done, months went on, and we still didn’t have a plan.
So we decided to make time for it. For two weeks, all tech leads would be dedicating at least 90% of their time to that task, as well as two engineers who had been there since the creation of the company and had core knowledge of the monolith. As a product manager with good technical knowledge, I was picked to join the group. The outcome would be technical, but had to take into account business priorities. We planned these two weeks to be in a quiet sprint, as everyone was to ditch meetings and regular sprint work, to focus on this project.
We decided to do it over two weeks and have 90% of the time dedicated, but it could very well be adapted to be 50% of the time for a month, or half a day for a few weeks/months. That is up to you, and mostly depends on your priorities.
Once that was decided, and before those two weeks, we did a little bit of preparation:
- We agreed on the goal for those 2 weeks of workshops. We wanted to achieve a mapping of the current status, define what would be a good micro service state, and advise on how to get there.
- We agreed to dedicate our time and effort to do it.
- We agreed I would be the one driving the workshops. Retrospectively, definitely pick the most methodical person for this task. It doesn’t have to be a product manager.
The current status of our world
The first milestone was to make sure everyone had a good understanding of where we were at. To facilitate our conversations, we worked on Miro. It is probably worth mentionning this work happened during the Covid lock down, so we were all remote. In an ideal world we would have done that in person, but still in Miro to make no transcription post-session would be needed.
One week before the workshop, I asked to our group for a list of the domains we had in our company. I then added them as Frames in Miro. The two weeks would follow a simple cadence: some homework for everyone, and then a common session to discuss, sometimes with some debates.
On the Monday morning we assigned people to be domain owners, as the one(s) who had the best technical knowledge about it. One engineer could be the owner of one or more domains. Then, I asked them to take some time, offline, to add all functionalities in their domain, and to try to be as user oriented as possible in the naming. We then reviewed them all together for a couple hours. One would think that would be faster, but a lot of challenging was done, to properly define where were things. We ended up with a mapping of the domains and their features.
The next step, was to define the dependencies. To make sure they were not forgetting any, I asked them to add the depencies per feature. The domain owners worked on it on their own, and we gathered again to review, and agree. We made sure that each dependency was marked in both domains. The session together took a bit longer, and few more dependencies that had been forgotten were added.
The last step before starting to discuss our vision, was to understand what works well in the current architecture, and what doesn’t. For this step, as a product manager, I participated and added my own post its from a business/user point of view. Sometimes they were at the level of the domain, sometimes at the feature level.
At this point, we already had a very good view of our current system. As we were reviewing at every single step, all the group got to have a very good knowledge of domains they were originally not used to. Zooming out on the Miro board, it was also very easy to see which domains looked good (=very green) and which ones required a bit of work (=very red). The next steps were to discuss where we wanted to go.
Our ideal world
Before even starting about thinking design, architecture and drawing it on Miro, we needed to pin point what required changes. Again, we took a round of “homework”, led by all tech leads, before reviewing as a group and discussing together.
Having already listed cons, adding desired changes was a quick thing. However, we had two sessions of a few hours of conversation following this, to understand which domains had to stay as is, be extracted, divided, or merged into others.
At this point, we reached the design milestone. Techleads and specialists had a clear list of what to change in their domains. The next step was to draw what would be the future system, based on these changes.
To do this, they took some time on their own again to do this. Some of them had to meet and discuss in smaller groups, to make sure their new domains’ designs were coordinated. Then, we synchronised all together, and again, that session generated quite a few debates and took some time for everyone to align.
That was it, we knew where we wanted to go, we had our desired architecture. Having the final results, it was now obvious that the total amount of work represented way more than a year of work, probably closer to two. There was no way we could afford to put all development work on standy to focus on those changes.
Making a plan
In order to prioritise changes we wanted to make, we extracted all the ones already present in the domains, and made sure we were not missing any required to achieve the desired architecture. We copied them to another frame in the Miro. To then be able to order them in time, we needed to know if there was any advised order, for architectural or efficiency reasons. We simply linked those post its with arrows, then ordered them a little bit.
For a real system, you will likely obtain a diagram way more complex than the following one.
At this point, it was my turn to do some homework. I went to all the product managers and the CPO of the company, and together we discussed what plans did they have for the upcoming 2 years. What were the priorities? Which main feature did they foresee improving? I built a very global roadmap, not going into more details than at the quarter level, and then presented it to our tech leads and specialists group. That insight was very important to take into account. A technically prioritised order would not make sense. We then spent some time to discuss, and voted on what should be tackled first.
From this vote, the next step was to position changes onto a timeline. But to do that, we needed to have an idea of how complex they would be. We used T-shirt sizes to estimate everything (S, M, and L), then we started to position the changes onto a roadmap. That was a collaborative work done in a call as we wanted to take into account both business priorities and technical recommendations. We made a split by teams based on domain knowledge, to better understand how to coordinate the work amongst ourselves.
What next?
We presented our work to the rest of the engineers and the product managers. The map of the domains could be kept and adapted, with the upcoming changes. The desired state could evolve as the business needs were evolving. And then the mapping of the orders could be used, when encountering a business need, to pick what extraction to a microservice would be possible, and what would be the dependencies: the roadmap was a tool to guide a team, but always to be adapted to stay agile. (See how-to-build-an-agile-roadmap- article). If it was true at the time, it would then evolve with the business and the priorities.
Overall, these two weeks of work gave to the whole team a very good understanding of the ecosystem we were working with, and all the challenges we’d have to face to upgrade it. That on its own, was already a very good starting point for the upcoming months.
Disclaimer: this article was made from memory on a previous experience. It is a tool suggestion, and does not pretend to be the only approach to carve a monolith
Break down monoliths with reusable components
Bit’s open-source tool help 250,000+ devs to build apps with components.
Turn any UI, feature, or page into a reusable component — and share it across your applications. It’s easier to collaborate and build faster.
Split apps into components to make app development easier, and enjoy the best experience for the workflows you want:
