Software Architecture: Why a Little Formality Goes a Long Way

Even without a dedicated architect on your team — maybe you’re a small startup or you don’t yet see the need — you’re undeniably already “doing software architecture” in some form.

Architecture is just the high-level structure we create to reason about a software system. It’s something that gets created anyway, whether shared formally or just within the heads of each developer as they approach the task of writing code.

But architecture is also a part of the continuum that runs all the way from the decisions we make over individual lines of code, to how we group them into methods, build class structures and packages, combine them into components & services, run them alongside one another in processes, distribute them across communicating hosts and even geographically separate them across data centres.

At each stage, there are decisions to be made: Whether to structure things at this level, and how, or whether to expose or hide them via adjacent levels.

In software teams, we make 1,001 decisions like this every day, but we keep many of them in our heads.

Admittedly, the lines may blur a little: Where do less formal decisions about coding structure end and architectural decisions begin? Where do architectural concepts turn into deployment and operational concepts? However we classify them, they are all just decisions on that structural continuum.

So if we’re all doing architecture anyway, what are the benefits of formalising it a little?


It’s really about whether we think we’re effectively explaining and reasoning about the software we’re building, as a team: The abstractions we create, the names we use to describe real-world concepts, the lines we draw between them, and how we choose to arrange them as interacting components and systems to form the end product.

Our reasoning tends to start with business concepts and terminology — we need to name things consistently, before anything else — then we figure out how we might best structure it and flesh that out until we can see whether we’re creating something that will solve the problem we started with… which is, after all, all that matters. But some point, we tend to internalise this process and to stop explaining it to others… and sometimes too soon, way before we hit the code.

Instead, if we formalise the architectural portions of our thought process a little, and get them out of our heads, what our reasoning leaves behind are human-digestible artefacts — documents, diagrams, pictures, descriptions — that we can use to explain what we’re building, and what we’ve already built, rather than just pointing at the end result (the product) at one extreme, or source code at the other.

These architectural artefacts, no matter how informal, are tangible manifestations of our investment in building the software. Just like the product and the code, they have real value when we expose them outside of our heads.


Proponents of “lean” methodologies tend to shun architecture for its similarities with “Big Design Up Front” (BDUF), somewhat understandably, but taking the approach of using “just enough” architecture doesn’t have to mean cumbersome wasted efforts and it has a real place and practical value in the rapid and bumpy journey from an idea to a Minimum Viable Product (MVP).

Unlike the architecture of physical buildings, software architecture must evolve with the software it represents and that includes lean products as they grow and change to fit the experiments we are running. This dictates a lighter form of architecture, with less formal artefacts that add value rather than merely documenting for documentation’s sake.

Why produce a neat PowerPoint component diagram when it changes every week during the pre-launch phases of a project? A photograph of a whiteboard, uploaded to a Wiki or just left visible on that whiteboard, is much more appropriate.

Prior architectural decisions may need to change frequently, and lines we drew on that structural continuum get redrawn, along with the artefacts showing them. Yet more reasons to keep those artefacts light and less formal.

Evolving architecture is about noticing tipping points that dictate change; points at which old decisions need revisiting, and times when sensible choices are clearly no longer sensible: Single services need to become distributed and to communicate with one another. Bespoke first versions of components become more general to cope with a wider use case, and perhaps turn into a framework. Individual efforts get refactored into one coordinated effort to remove duplication. Old decisions get revisited, and some no-longer stand up to scrutiny.

Crucially, when we’re making and remaking architectural choices, we need to remember not to over-structure things: Creating a sea of micro services, for its own sake or because it’s the latest tech fad, may be tempting… but it isn’t practical until the architectural need for a few of those services becomes real; a decision we may make now and revisit again several times later… with a different conclusion each time.

If we’re building an MVP, there is still a place for light architectural lines to be drawn, on a whiteboard, in a diagram, or just in code comments and via sensible naming. You can still separate concepts logically in code, even if you choose not to form them into distinct services. You can still briefly document where lines might fall in future, or how you assumed the current structure might evolve later.

None of this is onerous, but all of it can help an MVP grow into a scaled system when further directions become clear, or to adapt when it needs to change or pivot.


Far from being rigid and fragile, use of light architectural artefacts, shared amongst a team, can provide the terminology, diagrams and tools necessary to react to the need for change, to discuss it, and to act on it.

Rather than doing all this informally in developers’ heads, it doesn’t take much to coordinate those efforts: A few diagrams, a few docs, a few whiteboard discussions. No one is asking for volumes 1–5 of an architectural tome… and no one should be paying for that.

Architecture greases the wheels of innovation by providing obvious talking points, things to point at and reason about, and ways to plan the next steps.

With a little shared architectural formality, imagine how much coordination that would bring to a team’s efforts. Imagine what you could do to lead and direct the coding efforts of junior developers by providing a little more structure, by pre-drawing a few lines, by suggesting where things might go. Imagine the gain in efficiency, the conversations, the avoidance of mistakes and rework.

A little architecture, when we choose to formalise it outside our own heads — whether assisted by an architect or just as a group of developers — really does go a long way.