Evolving mobile architectures towards the company organisation
It is very common to observe companies where there is a conflict between the business perspective (and how to tackle all the new functionality and updates the company wants to bring to the customers) and the engineering team (worried about the project and legacy areas in it).
This is just a symptom about the maturity of the company. When a company is getting mature, the alignment between engineering and product management happens and the conflict disappear because both point of views understand that they need to satisfy their necessities in parallel.
In this article, I will cover how a complete clean architecture pattern can be introduced in a monolith mobile project step by step depending on the company necessities with a hypothetical company as example from a high-level perspective.
The golden rule: The boy scout rule
There is a first thing a company can do, specially the ones that commit to agile thoughts: if they consider to do minor improvements in each business iteration they are performing, code might be lightly better without considering strong changes.
Robert C. Martin actually has collected that idea:
Always leave the code a little better than you found it
That mindset should be always in all of our heads so we can avoid introducing technical debt but also we can take care of minor clean ups which will contribute to reduce already existing one.
Many people can ask themselves: can we make sure our app won’t become legacy with just a boy scout rule? The answer is not just a yes or no, but a bit more complex.
In one hand, business has to consider that each step we are doing should include the boy scout rule and considering that we are improving our project by little steps.
But on the other hand, engineering has to understand the balance between the technical improvements a business ticket might include. For example, the estimation cannot be just the double, because then we are not performing as an agile company at all.
So then, how to act when major changes are required?
Step 0: Understanding where we come from
Each engineer will have a moment where he doubts about if previous engineers did a good job on the project or not. The main reason might be that we can see the app still as a monolith which is no longer scalable, or not well structured, not well tested…
I had that feeling as well in the past, but then I started thinking on the why (why previous engineers did like this?, why they went on a particular scenario which is now legacy?, why they didn’t choose another approach?…). All those questions ended up on just one single question: how was the company performing at that time? When I tried to answer that question by collecting data about the companies, I noticed that in all cases the architecture they decided to go with was just a reflection of the status of the company at that moment.
Then, what was the problem? Companies are always evolving, growing up, taking more and more maturity but the project sticked to survive to the business requirements without considering that the project wasn’t evolving with the same speed that the company.
Is that a failure? Absolutely not. It is a learning where we can get benefits from in order to be ready for the future and try to avoid it next times.
Let’s check it with an example.
Step 1: Fitting a success company by breaking the monolith
It is very common that start-ups have a very small project which is built as a monolith (because actually the start-up organisation is a monolith where only a few people are working on). Then, that project makes a huge succeed, so suddenly there are quite more requirements and necessities to release things faster in order to avoid giving chances to competitors. Is that a failure that company just try to commit to the market necessities compromising a bit their technical evolution? Some people might think yes, but maybe if they do the opposite and do not commit to the market, they might fail as a company, what is worse. At all time, we need to avoid to:
Die because of success
In that example, we ended up on a situation where a monolith application is on the market, but maybe the start-up has grew up and now it is not that start-up, so the project is becoming the limitation.
Then, the engineering and architecture team consider that a migration to clean architecture is the perfect way to go to mitigate the issue and they spend some time performing that migration after agreeing with the business people as well.
By building this new clean architecture, the project has reached the same status than the organisation so they fit together again.
So, are we done? Of course, NO!
Step 2: Understanding the necessity to satisfy company requirements on a dynamic way
In our case, let’s consider that the company has succeeded once again and due to that success it grows up a lot becoming almost a multinational company. Now, then company is splitting into different departments and all departments are asking for new features to be on the market.
Even we have set clean architecture, finally one of the three modules (presentation, data and domain) end up in a huge presentation module which is difficult to handle with parallel development. Isn’t it another monolith?
Now what? We might enter on another “technical intervention” to align the project and the organisation, specially if we have not teach each others in order to change the company mindset and the alignments between business and technical people. We might say that it will be just once, but won’t happen in the future…
Do we really know it won’t happen again? For sure, it will happen many more times and this is the main reason for us to put the focus on working on the company mindset in order to ensure we are capable to take up technical changes on our daily work. Actually, there will be even cases where it is impossible to do it on another way because we must take into account one rule all the time:
Show must go on.
In other words:
We need to keep satisfying our business/customers demands
A commitment to this rule is forcing us to think on a change which cannot take so long as a huge single release. For that, it is very important to align the priorities towards how to tackle the project update. In fact, if we are adapting our project to satisfy our company and its organisation, isn’t worth it that business will influence in the way and order we tackle it? Of course.
Step 3: Defining the never-ending target architecture
For being able to have that sync between tech and business people we need to have a plan in place which we can share. For that it is very important that architects and engineers have to work on the target architecture they want to achieve. That step is very important because will enable an overall vision to everyone apart from supporting to avoid fake steps.
But we have to notice that the target architecture will be evolving as well, otherwise it will be deprecated soon. The main idea is that we won’t be able to reach that architecture ever, because there will be always missing things in order to be up to date to the company and the new technologies and when we are, new ones will appear. Remember that company is always evolving, as technologies.
Imagine we agree that for our hypothetical company we notice that we would love to split all the presentation module (which became a monolith) by features, so we can serve all the different departments from the company with no collisions.
This could be one possible target architecture to start with:
Let’s point out that this architecture is giving the chance to build features by other features which will support to reuse some components when required. There is also a base where base code is shared into the whole project.
Why is domain not split? It could be break also by features or subdomains, but in case there is relation between different subdomains maybe splitting it is more complex than keeping as a single module for now (which can have an internal organisation in subdomains anyway). Remember:
We are here to satisfy our company requirements, not to modularise just because we love it
Knowing the previous rule, as target is always evolving, domain or even data might be split when we do consider so: ¡Target architecture should be dynamic!
In this case, app module will be providing the support to connect navigation flows between features, knowing that we understand a feature like a black box:
We can even introduce a design system module (customisation), but as always, depending on how it fits to a UX department in case we have it.
The most important question then is: how can we move from the basic clean architecture to this complex version without dying?
Step 4: The ongoing-plan
The previous suggested changes are not affordable on a real environment as a one thing to release. Here, that “technical intervention” won’t work at all. So we need to agree on a plan.
One possibility would be for example extracting the base modules which will be shared later. Or even splitting already the different data sources in order to have the whole data module ready.
Another possible approach (maybe after first one or even before) would be modularising some features (the ones are not depending on others) and later iterate from that point.
It doesn’t matter which order we go, the important thing here is that we are doing small steps which we can release quickly to the market. What’s the benefit of this approach? We can react to any situation in the company, even stopping for a period the architecture migration because of an urgency. Why? Because all the steps we did are already live.
I normally recommend three actions for achieving a change like this:
- Validation action: we get a complete feature and we make it work towards all the layers to validate the target architecture.
- Implementation action: this is the main action, where we are iterating feature by feature, step by step.
- Polish action: we have to revisit and restart the process with a new evolutions
But there is a trick on the previous actions. All actions will be live at the same time. In other words, even we have validate with one feature that the architecture will work and we are in the middle of the implementation, as world is changing we need to be adapting, so if new things come up we can revalidate things in order to be always adapting. And that is only doable by continuously polishing our project.
The most important thing here is to align the order we are tackling it with business so they would get benefit from all the changes we are performing from the very beginning. E.g. if there is a feature we are never modifying, that feature won’t be the perfect feature to start with.
Step 5: Feeding the eternal sync between business and engineering
If we do keep this mindset and we do feed the synchronisation between business and engineering, then we might end up on a situation where our project is always aligned to the company requirements, because as soon as a new one come up, that will be reflected in our tech path to go.
I know it is difficult, but I also know that it is feasible and you will enjoy when achieving it.
And you, don’t you want to be there?
