When to bring in a software architect?

Bringing in a software architect at the end of a project isn't architecture. It's archeology. 🤦

That’s not saying there is no value in the process, but much more value is offered from involving an architect at the early stages. It is much more expensive changing existing decisions than making new ones.

If you bring an architect into a project late on they will need to acquire context, and this will often involve learning what decisions have been made, and most importantly why. If this context isn’t something that has already been gathered and maintained then it can be a very time-consuming process. Context could come from conversations with the team, but the fog of time and staff moving on will often mean this becomes more of an archeological dig, gleaning information from chat histories, minutes, emails, git commits, source code, maybe even fin-ops reports. You will use any data sources you can lay your hands on.

The contribution is still valuable - it may take you from analysis paralysis to having light at the end of a tunnel - but the overall team's journey was more arduous.

Likewise, bringing in a software architect for only the start of a project is similarly challenging. At the start of a project we know the least about the problem. An architect will help you ask the right questions, and help you solve the right problems, but actually finding the right answers could take time. A bright and optimistic plan will likely need evolution or reconsideration in light of new information and learning. Will you have an architect involved in interpreting that?

So when should you bring in a software architect? In effect, you want architectural thinking at all stages of your product’s lifecycle. Architectural thinking is what helps us make better decisions. Decisions can easily be taken from within a silo. Architectural thinking is breaking that silo - understanding implications outside any single development team, taking into account multiple perspectives and the things that matter to stakeholders. Architectural thinking is also structuring and quantifying that thinking.

Does architectural thinking need to be from an architect? No. You can have no architect, but those perspectives and understanding of the things that matter don’t come for free, they come from breaking those silos. Can it come from a team leader? Yes, if you can balance delivery vs system quality drivers. Should it centralise decision-making? No. That’s not the point, you are looking to make the team feel more accountable for their decisions, and equipped to make better decisions.