The past decade or so has seen a huge shift in the way that we build software, thanks to movements such as agile, lean, continuous delivery, DevOps, containerisation, the cloud and more. Together these new approaches help us to build better software that better meets the needs of our stakeholders, while carefully managing time and budgetary constraints. But there's still more we can do because even a small amount of software architecture can help prevent many of the problems that teams face. Ask yourself the following questions:

• Does your codebase have a well-defined structure?
• Is everybody on the team implementing features in a consistent way?
• Is there a consistent level of quality across the codebase?
• Do team members share the same vision for how the software will be built?
• Is there an appropriate amount of technical leadership?

Software architecture is about technical leadership

It is possible to successfully deliver a software project by answering "no" to some of these questions, but it does require a very good team, and a lot of luck. Although most software projects/products start with the best of intentions, it's easy for them to veer off track without an appropriate amount of technical leadership; both at the code level, and above it. If nobody thinks about software architecture, you often end up with codebases that are too slow, insecure, fragile, unstable, hard to deploy, hard to maintain, hard to change, hard to extend, etc. I've personally seen (and worked on 😬) codebases that have exhibited the following types of problems:

• Components in a monolithic application were configured in different ways, depending upon the developer who built them. These different and inconsistent approaches were not discussed or documented, so deploying the resulting software required lots of "trial and error" to get everything configured correctly.
• Code in a monolithic application could use one of three different data access layers, each built using a different framework, to access data from the same database.
• The path of a HTTP request through a server-side web application varied depending upon the developer who was implementing the feature. In essence, every developer had a different idea of what the layered architecture should be, and this was reflected in the code.
• A software system didn't perform and scale as hoped when presented with the real-world data set. In this case, one of the key technology choices wasn't able to meet the desired quality attributes, and this was unfortunately not evaluated before making such a significant decision.

Additionally, without technical leadership, many codebases end up looking like the stereotypical "big ball of mud" or "spaghetti code". Sure, it has a structure, but not one that you'd want to work with! These seemingly chaotic codebases do exist in the real-world, and most of us will have one or more horror stories about the time we spent working on them. If you've never worked on such a codebase, you're probably in the lucky minority!

The benefits of technical leadership

Thankfully, most of these problems are solvable with the introduction of some good technical leadership, resulting in a team that therefore understands and thinks about software architecture. In summary, this can provide:

• A clear vision and roadmap for the team, regardless of whether that vision is owned by a single person or collectively by the whole team.
• A stimulus to talk to people (inside and outside of the team) in order to ask questions relating to significant decisions, quality attributes, constraints and other cross-cutting concerns.
• A framework for identifying and mitigating risk.
• Consistency of approach and standards, leading to a well structured codebase.
• A structure with which to communicate the solution, at different levels of abstraction, to different audiences.

Does every software project need software architecture?

Rather than use the typical consulting answer of "it depends", I'm instead going to say that the answer is undoubtedly yes. The caveat here is that every software team should look at a number of factors in order to assess how much software architecture thinking, a degree of which manifests itself as up front design, is necessary. These include the size of the project/product, the complexity of the project/product, the size of the team, and the experience of the team.

Summary

Every software team needs to consider software architecture; from a 1-person team building a startup in their garage, through to a globally distributed team with hundreds of developers. Creating a starting point and setting a direction provides technical leadership. A failure to do this tends to lead to chaos - poorly structured, internally inconsistent codebases that are hard to understand, hard to maintain, and potentially don’t satisfy one or more of the important quality attributes (e.b. performance, scalability, security, etc). In short, every software team needs technical leadership.