Architecture

Architecture is frequently overcomplicated with reference to frameworks and distinctions between different types of technical architecture. Most of this can safely be ignored if we are just interested in building and maintaining good software.

When building software to solve a problem we must properly design the solution at high level before diving in to build. It is easy to go over the top with specifications and details, but a clear plan showing the various components (frontend, backend, database etc) will go a long way to reducing the risk of rework.

When working in Agile, the various engineers will need to know what they need to achieve (the acceptance criteria) and also understand how their part fits into the bigger picture. Having an architect closely involved will avoid the wrong thing being built, will unblock engineers when they are uncertain of the overall solution, and will provide stakeholders and delivery management with confidence that the plan is on track.

‘As individual technical problems arise, he invents solutions for them or shifts the system design as required’ is how Brooks describes it in The Mythical Man-Month, 1975. Sometimes the engineers will do the job themselves, but without an architect who is aware of the whole technical plan, it is easy to find that the pieces don’t fit together.

If you are planning a new project or a major refactor and don’t have an experienced architect involved, it would be worth considering involving one.