Architects VS Chaos

This is going to be a tough topic. It’s a very powerful dilemma in modern software engineering. It’s complicated because it also reflects our everyday lives. We all live in a world where there’s no absolute freedom and a government is considered vital by most people. Ok then, how does this apply to a software company?

We don’t need no architects!

As you should already know, we used to have enterprise architects sitting in their ivory towers and doing a bunch of software design up front. With the advent of Agile things seem to have changed for the better. Designing everything up front looks like a no-go in today’s world. But did things really improve?

A lot of companies fell into the Agile marketing trap and started using it as a religion rather than what it really is, just a tool. For these reasons most companies building software are not looking for software architects anymore. They’ve been deprecated and, instead, everything should be built, evolved, and rebuilt as necessary, by working in quick iterations.

The sad truth is that usually only the first iterations are quick and over time things might get slower. Sometimes it’s just technical debt that can be easily addressed, but at times it’s something more profound. We might have forgotten to consider using one of the other tools at our disposal: software architecture.

Let democracy decide

Here’s the starting point of the dilemma: would talented developers rather work under the guidance of an architect or design their own software?

They will definitely opt for the latter. The sense of accomplishment when designing a software solution is usually far greater than actually writing the code for it. Different people with a variety of technology backgrounds can bring a lot of ideas and solutions to the table.

Let the talented developers decide then, problem solved, right? Well, this might work with small teams, but what happens at scale? What happens when a few of these talented developers need to work together and their opinions diverge? Who’s going to decide how to proceed?

The answer here could simply be the consensus of the majority. In an ideal world, everyone would just compromise and agree on a solution. But what if the majority has just opted for a suboptimal solution due to the presence of inexperienced developers in the room?

Using a different perspective, who says we should even agree on a solution? I’ll do my thing, you can do yours, and everyone is happy. What’s the worse that can happen?

You can see the issue here. This gets quite political very quickly. Democracies around the world recently behaved unpredictably. US citizens voted for Trump, British citizens voted for Brexit, and in Turkey, the majority voted for what looks like a dictatorship. For some, these decisions might look like nonsense, for others, it was the right way to go. The same principle could apply to software companies with no central governance.

Avoiding anarchy

One of the common pitfalls of the democratic approach is that people and teams might start shifting apart. In this environment, no one has the role of coordinating, so nothing really dictates a meeting should take place to make a shared decision.

We could quickly end up in a place where technology decisions are not aligned with a well-defined strategy. Maybe teams are reinventing the wheel all the time. Ownership of shared parts of the system becomes unclear. Security ends up being a second class citizen. Building a great solution to a problem and sharing it with the larger team becomes pointless because everyone will probably just rather build their own. The overall system might become untestable end to end. The source of truth gets harder and harder to find. And technology sprawl grows stronger every day.

Some engineers might leave the company and, because of lack of supervision, no one will ever know why certain decisions were taken. Smaller business units might be able to patch or build workarounds in their part of the system without actually addressing the underlying architectural issues.

The lack of strategy could end up creating a chaotic environment, where no one really enjoys working in the end. This also promotes a “we can fix it later” attitude, which can become extremely dangerous to the maintainability of the software over time.

One viable solution to the above problems could be agreeing on regular meetings or forums between teams to share knowledge, avoid reinventing wheels and share issues that can be tackled together. The most important ingredient we need for this is having engineers that actually care about having a healthy software system running in production.

The role of software architecture

When engineers encounter issues that sit outside their scope, they usually look up to find some sort of figure they could ask questions to. Who knows about this business process and how it has been implemented? Without an architecture team, there’s no straightforward answer. You’ll need to broadcast the question and hope that someone replies back, and usually, the answer is inconsistent and scattered across a group of people.

Let’s try to outline how an architect or an architecture team could help here. They could identify commonalities between various teams and promote reusability. Additionally, they could be responsible for increasing the teams’ efficiency by enforcing a set of technology standards and policing them. They could also be responsible for managing the budget for parts of the technology department . They could advocate for a set of building blocks that could be used to build 95% of the solutions needed by new projects. They could be the ones accountable for security breaches.

You could argue that no talented engineer would work in such environment, and that’s probably the case. They don’t usually like to be told how to do things, but would it makes sense to accept trade-offs for the greater good?

Architects should be great leaders, able to find a common ground, increase efficiency and unify goals. They should enable the company to reach agreements faster and ensure they are followed by the involved parties over time. Not an easy task, and not something someone can really do in his spare time, or while being responsible for building some parts of the system.

Mistakes in the architecture are going to be the most expensive ones to fix, or they might turn out not to be fixable at all. Without architects, who would be accountable for these screw ups?

A sound architecture enables agility, not the other way around.

With a good architecture, problems just fade away, with a flaky one, problems are behind every corner.

The impact of Bad Architects

Bad governance in software can also cause irreparable damage. Architects should enable software and innovation, not strangle it. A lot of engineers have worked with bad software architects before, so they will have a hard time trusting others in the same position.

The impact of having an incompetent architect is pretty much limitless. It can be comparable to the impact of having an incompetent CEO or an inexperienced politician running a country.

This can only be avoided by having people in this position that are not only domain experts, but also trusted and inspiring technologists with a long track record of success. Needless to say, these individuals are not really easy to find.

The importance of domain knowledge

One of the toughest lessons I’ve learned over the years is that you can be the most talented software engineer in the country, but if you start working on a completely new domain with zero experience, you will most likely fail to build a great solution.

The most successful architects are masters in one or maybe a couple of domains. They’ve worked for a series of companies and built a strong backbone of experience in those industries.

In general, the more domain knowledge you acquire the closer you get to a better solution in the problem space. Engineers will usually join the company having a variety of backgrounds. The solutions for their previous products might not fit at all with the new domain. Moreover, having a lot of engineers with different backgrounds will make it harder to agree on a common approach.

Finding a middle ground

If you’ve managed to follow me so far, you should start to realise how hard it can be to find the right balance when choosing whether or not architects should be part of modern engineering teams or not. I will need your help later on.

My current state of mind, which is subject to change at any point in time, is the following: architecture is essential for software to be sustainable in the long-term. At the same time, everyone should have the opportunity to provide input to the architecture.

Ownership and accountability of the software architecture by a small group of people can turn out to be critical. This group of people should trust and be trusted. Ideas developing outside of the architecture team should have a place to live and be visible by the architects and the rest of the company. Discussions should be enabled by default. Architects should not become the bottleneck, being the ones validating all solutions and ideas, but rather be the people that promote knowledge sharing, scrutiny of solutions by the wider team and offer advice based on their extensive experience. Ideally, architects should still write code, do pair programming, and jump between teams to help when things are looking gloomy.

Soft skills are a critical piece of the puzzle to keep everything together. If architects enable technology and innovation, but also trust, inspire and listen, they won’t need a mandate or authority. Engineers might just accept that they’re only part of the team and architects hold one of the necessary roles within the company. Architects, like developers, can’t know everything.

Another very important thing to keep in mind is that a more invasive and complex governance becomes less likely to be accepted by the wider team. The shared set of standards and rules should be simple and effective. No one will follow two-hundred pages of guidelines, and no architect will ever be able to verify that they are being applied correctly either.

If you decide not to have an architecture team, a good way to start would be by hiring talented engineers with architecture experience without creating architecture roles as such. This will work just fine with smaller teams and simpler domains. With larger teams and more complex domains though, this approach could become cumbersome. More people would mean an increased necessity for coordination.

Wrapping up

Finding the right balance between allowing creativity and freedom while trying to achieve a sound software architecture with the use of a centralised governance is still one of the greatest dilemmas in my software engineering career.

This relates to great extent to our everyday life in modern societies. Would you rather live in a world without governments?

We all play by the same rules every day, to some degree. It can feel limiting at times, but we do tend to feel more comfortable when we have a set of rules we can rely on.

Why doesn’t it feel as simple in a software team?

Have you made up your mind on the topic? Please, share your thoughts and help other readers understand your point of view. Open discussions are the first step towards finding the right balanced approach for such a controversial topic.