Over the last years, I had to introduce myself as ‘The Architect’ quite a few times, which always felt a bit awkward. Sure, I’m the one guiding architectural choices but being referred to as ‘The Architect’ feels like a bit too much honor, because software architecture definitely is a team effort.

Why?

In Agile teams, we like people to be ‘T-shaped’ to make sure a task can be done by more than one person in the team. For architecture, this means everyone should have at least a basic understanding of software architecture. Then you can reason about your architecture with everyone involved, it becomes a team effort, which is beneficial:

• When people are involved in making a decision, they’re much more likely to support it.
• You teach your colleagues to become better architects themselves.
• When everyone is involved in why (are we doing it this way) ‘The Architect’ doesn’t need to be involved in all the how’s, since developers can make informed decisions on their own.
• In microservice-style architectures design tends to be more decentralized, happening within teams. That requires more architectural thinking within those teams.

Making it a team effort:

• Get everyone involved in architecture discussions and hear everyone’s opinion.
• Make sure your team documents all of its architectural decisions (e.g. Architectural Decisions Records) right next to the code. Someone who checks in code which affects architecture, is responsible to document it at the same time, in the same commit.
• Strive for ‘the student to become the master’; the ultimate compliment when teaching people (in this case, architecture) is them surpassing you.

Yes, I can come up with a fitting architecture for your project by myself, but I’d rather do it together with the people involved.