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 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.
*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 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*.