Non-technical reasons why your software architecture is a mess

What is software architecture? What is a software architect? These questions have been answered so many times by so many people. Furthermore, each enterprise represents unique ecosystems with their own internal reality, so every case is different. Rest assured; I am not trying to waste a lot of time on that subject for no reason here.

But I do believe there are some common situations that lead to bad software architecture. Some of them are technical. And typically, they are related to situations where good and well-known patterns and practices are simply not applied.

But other situations, and those are the ones I am addressing here, are more related to human behaviors and business mentalities.

No software architects

As a software developer, I had to deal with software architects for many years. I have always had a love-hate relationship with the architect role and individuals with that job. But what I have learned over the years is that it is better to follow an architectural plan that you 90% agree on rather than not having a plan to follow at all.

I experienced the situation where the architect role completely disappeared because of some employee’s departure. When this happens, there are no magic solutions. That additional, time-consuming, and difficult responsibility could be placed on the shoulders of the management layer (directors / VPs). Or it can be placed on the shoulders of a group of technical people (software developers). Or a mix of both maybe? I think all solutions can be a temporary viable choice depending on people’s backgrounds and the way they fulfill their new responsibilities.

But without good transition planning, the risk is having no continuity in business operations. An architecture (or target architecture) is something that can and must evolve each day/week/month/year depending on the maturity of your current architecture, your technical debt backlog, and your feature backlog. It cannot be printed on a wall and be static forever.

And without architectural planning continuity, what do you think can happen? When my 6-year-old kid is building a tower with LEGO blocks, he does not really understand that wrong initial choices in the way he builds his foundation (or when he builds each additional floors) can lead to a situation where his structure is not strong enough to continue building higher. He could of course take apart his project and restart. If he has the time and/or motivation.

The same thing can happen with software architecture. Without proper planning, you can just pile up new features until… you cannot anymore. This can happen not only in a typical monolith system, but even in a fully decoupled microservice oriented one too.

You can always rely on some strong technical individuals to prevent mistakes that lead to that catastrophic situation, but only if you empower them at the right time in the planning and execution of the work. And if you give them the chance to intervene before timeline engagements are made. Without that, each developer and/or each team (depending on your internal processes) will just add another LEGO block in the equation, as best as they could, without any guidance and without having the big picture in mind.

The absence of strong architectural guidance can scale if your business only has a few developers. I saw it scale for 5–10 developers. But it did not work for 50+ developers. Even less so if you double / triple the number of developers over a few years.

Splitting the problem resolution and the solution implementation process

Building an architecture is all about building a system that will answer and fulfill business needs in the long run. Coupling, testing, modularity, scalability, security, evolution, vision, etc. You have already heard about all this.

To be able to do that, you absolutely need to understand the problems you are solving and what you are trying to achieve. Here is an example I use when I want to illustrate that situation to my colleagues.

There is a significant difference between those two situations (I like non software examples because it is more tangible to non-technical people):

Situation A — You have a family with 2 parents, 4 kids and 3 dogs. They have an annual family income of 950 000$. The parents are working remotely. All family members are tired of doing a 45-minute ride to go to the gym, and they are all athletes. They have 3 cars, and they live in Canada with harsh winters. Build a house for them. And here is their phone number if you want to talk to them.

Situation B — Build a house with 8 rooms. With a garage to fit 2 cars. Here is my phone number if you want additional details about the purpose of those 8 rooms and where you must place them in the house.

If you work in a small business or startup, you are familiar with situations like A. Meaning that people implementing the code have a direct access to the problem to solve. You can imagine a multi-disciplinary team that tackles the problem together with all their own angle and expertise.

If you work in a big enterprise, situation B is more common. Of course, those examples are extremes. But the point is that the more you add roles/titles, processes, gates, the higher the chances that some people will not have access to all the information they need. More than that, each time you transfer information from one person to another, that information could be altered like a telephone game. After a couple of hops like that, it is easy to not tell the difference anymore between a problem to solve versus a requirement. And if that happens, you will just miss the big picture.

There is a huge difference between solving a problem with a multidisciplinary team having the big picture versus trying to solve the problem by breaking it into sub-problems and process gates with sub-teams solving them. The quality of the solution will not be the same, I can guarantee it.

How is it possible to build a software architecture that scales over time if your technical task force is not exposed to the business problems to solve? It is hard. One thing I learned over time is knowledge and problem-solving skills are not specific to certain job titles. The best way to solve a complex problem is to bring just enough people together, each being able to contribute to the discussion, no matter their background or job title. Of course, each person has their own expertise, and people handling the software architecture must have all the information in their hands to do their job correctly.

Lack of vision

Building a distributed ecosystem over a decade involves no start and end date when you think about purely technical concerns. It is more like continuous product development with new features to add, refactors to do, technical debt to manage, etc. And this is a reality even if corporations do trimestral or annual planning with or without traditional waterfall projects having start/end dates and scopes. Code and architecture stay year after year no matter how the project management works.

Building and maintaining an architecture over a decade requires insights to support the business vision. Where do we want to position ourselves against our competitors in 1, 2 or 5 years at a strategic level?

Everybody should be aware of that vision. Everybody should put effort toward those short / medium / long term goals all year long. Like any iteration, over time and milestones, retrospectives should be done about those objectives. Are we on target? Does the plan change? Does everybody know why the plan changed and what is the new plan?

Architecture can then evolve over time. It can adapt to support the business vision. But it has its limits. It is easier to change a vision than changing an architecture. If a business struggles to keep track of those short / medium / long term goals and after each trimester or fiscal year, the business loses track of the objectives they fixed in the past and they put too much emphasis on new and immediate goals, the architecture will collapse. Vision is important.

As a famous hockey player once said, “A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be.” If the vision is dictated by the competitors, and you always try to be reactive by forcing things quickly, your architecture will never catch up. It is a never-ending race that you are going to lose for sure.

Team reorganization without paying the architecture shift tax

There are several ways you can organize and split your teams (by domains, by technological expertise requirements, by business units, by change rate, by security clearance requirements, etc.). Each enterprise is different and tries to solve different problems so all approaches can work at some point.

But in the end, an ideal and typical goal is to avoid the nightmare of planning dependencies between teams when building a roadmap. That is why microservices combined with domain-driven design is becoming increasingly popular, and why Team Topologies is algo getting a lot of traction.

But at some moment, enterprises evolve, and team reorganization happens. Just imagine a small bank shifting from credit cards and personal loans to personal and enterprise services. It is probably a bad example; I really do not know much about banking systems! That is a major strategic shift that will involve the reorganization of your internal teams. And guess what, architecture tends to follow organizational structures.

Team reorganization is not just about shuffling the teams and reorganizing a roadmap. There is an architectural tax to pay. By reorganizing the teams and not the architecture, some code ownership will just shift overnight. And the different boundaries of your ecosystem will not match your new organization matrix. That is just a fact. And there is nothing you can do to avoid that. It is some instant technical debt that just lands in your backlog.

There are not a lot of ways to reorganize the architecture after you reorganize an enterprise structure. I have never seen it with my own eyes, and I do not think it is even possible, but you could just stop all projects for months and let technical people refactor the architecture and the code to match the new structure. Of course, it makes no sense to take such a drastic approach in real life.

A better approach is to accept the fact that you will go through a transition, even if you do not like it. So instead of doing a big bang reorganization of the architecture, you plan and maintain a new target architecture. And each time a new project kicks in or new features are planned, you plan and pay an additional tax to address that technical debt. In the first months of a reorganization, business is typically all-in with that approach. So, initiatives are a bit longer, but technical debt is being solved.

The biggest issue is the difficulty of evaluating the complete cost of fully addressing the technical debt. And it can vary a lot depending on your initial technical debt before the reorganization. At some point, some people get tired of paying that extra tax in all initiatives because they did not anticipate it would take so much time, or they switch their focus to new short-term objectives, forgetting about the implications of past decisions. Over time, if the culture about technical debt management is not strong enough, there is a big chance that the code and the architecture stay in a hybrid mode for years. Functional scopes and release dates can become rigid, and time for technical debt resolution can disappear. And this is a tipping point. Everything is harder to implement, troubleshoot and refactor. Bringing value is becoming hard and you can even get to a point where adding developers to accelerate the roadmap just does not work. The impact of that on the business is being less and less competitive.

And sometimes, to shake things up, new visions can emerge. And those visions and ideas can lead to other team reorganizations, while the previous one is not yet completed. Again, it is a never-ending race that you are going to lose for sure. Handling technical debt is one of the hardest things to do properly. A subtle thing about it is even if you deprioritize it (or do not plan it at all), it will stay there and bite you. It should be exposed for what it is: a consequence of short-term investments.

So how can we succeed?

There is no magical recipe. 20 years ago, people still had the right to say that software development was a new field of expertise that was going through substantial changes. But it is not the case anymore. Software development companies learned a lot during the last decades, and they still make mistakes. It is even harder for non-pure-software-development companies that do some software development because they need to.

Bad software architecture can happen because of wrong technical choices. But situations causing the biggest negative impacts on architecture are typically not driven by wrong technical choices but driven by inadequate behaviors, mentalities, strategic choices, and non-adapted processes regarding software development.

I honestly believe a lot of the problems can be avoided by trusting people, being transparent with them, respecting their expertise, breaking the silos between them, and educating them on good software development practices that have existed since many decades.

If people try to do the job they are not qualifying for, you will fail.

If people do not listen to the warnings of experts, you will fail.

If people who can contribute to solve problems at the right moment are not involved, you will fail.

If people solving problems work in silos, you will fail.

If people spend more time talking about technical debt than getting time to actually solve that technical debt, you will fail.

If people do not talk about technical debt, you will fail.

If people do not genuinely take time to introspect their past decision and see how they can be better in the future, you will fail.

If people are too opportunist and improvise all the time, you will fail.

If people cannot accept that there are no shortcuts in the long run, you will fail.

If people are only focused on the long term, you will fail.

If people do not learn about software development good practices, you will fail.

I really hope reading that opened your perspective about software architecture and will trigger hard (but respectful) discussions with your colleagues about how to deal with your architecture processes. Software architecture is all about finding the right balance between needs fulfillment and technical debt accumulation.