How do you Enforce Architectural Decisions?

"My best-architected projects were the ones that never had an Architect." I was recently told this by a former project manager who retired feeling unimpressed by colleagues over-eager to adopt the title architect. I can't blame him, on this blog I've documented a number of observations I've made of flawed attitudes towards architecture. That is, attitudes about the nature of software architecture and the work that should be expected of architects, not ideas about this-or-that architectural pattern. Indeed, it seems intuitive that a project could be seriously derailed by an architect with a particularly nonproductive attitude about their job.

This is the sort of architect my project manager friend seems to have found, and he told me how he stopped hiring architects: During interviews, he started asking one question to which he never received a satisfactory answer. With that, he refused to hire any more architects, and his projects were all the better for it. I happen to be very comfortable, though, professionally describing myself with the architect title, so I'm curious to answer this question. How do you enforce architectural decisions?

Imagine you've applied for an architectural position and you're asked this - what is your answer? It's really not straightforward; the answer depends a great deal on your conception of the practice of architecture. I can imagine a lot of potential answers, and it's not hard to figure how one could go years without hearing a satisfactory one.

For me, this is a trick question; at least, I'll answer it like it's a trick question. It's certainly a leading question by my reading, supposing that it's in the architects' nature to make and enforce decisions. This may be so, but I'd venture that most folks in our industry are going to adopt the model of the architect-as-superior; that architectural decisions are apart from and supercede engineering decisions. This is the trap.

I think it sometimes does our industry a disservice that we lean on a construction analogy to describe our roles. In building a house, the to-be homeowner consults with an architect over floor plans and renders which result in a final blueprint passed to builders who assemble the final, tangible house. It's right to forgive anyone who mistakenly thinks that the analogy with our industry maps the homeowners to the business, builders to software engineers, and the architect to software architects. This is completely wrong though, and that this mistake has tangible implications for millions of software professionals and the projects we're meant to steward is a serious fault. In fact, the analogy would be to map the homeowner to everyone with a stake in the software's quality, the building architect to the software engineer, and the house builder to our compilers.

Except for a very small number of cases, software is not developed by making a complete, abstract definition of the final product before writing all the code to fulfil the definition. Rather, software tends to be constantly created and recreated in an interactive process; typing is significantly less resource-intensive than constantly erecting and destroying walls and rooms and roofs. We iterate a bit, deploy that iteration for all stakeholders (clients/users are stakeholders too), they give us feedback, and we rejigger what we need for that new feedback. What part of the house-building process does that sound like? That's right, it's the consultation between the homeowner and the architect. Remember that from the analogy, the homeowner maps to the stakeholders, and the house architect maps to the software engineers. The code is the blueprint we're all consulting on, and it's trivially cheap to ask the house builders to build a brand new version of our blueprints - after all, the house builder maps to the compiler (which takes seconds to produce the built software).

I will reiterate - it's a grave mistake to think that the software engineering process is the analogy-equivalent of the house builders building the blueprint. If you will, close your eyes and imagine a small office with a house architect and a couple commissioning her to build them a new home. There's a blueprint on the desk and a big, red button that says "BUILD." The couple asks the house architect to make changes to the blueprint to accommodate some requirement they have, and the architect obliges and updates the blueprint. Let's imagine this office sits at the head of a long road, which we can look down through a window in the office. The road is lined with houses, each next house a bit different from the first, with addresses like "v1.0.101", "v1.0.102", and so on. The house architect hits her BUILD button, and within seconds a new house appears at the end of the row of houses - address "v1.0.103." This process repeats ad infinitum. This is what software engineering is, the process inside the office. Let's not let ourselves be distracted by any misdirections from the imperfection of the construction analogy.

So where does that leave Mr. Software Architect? It might look like we've squeezed him out of the picture, but that's not true. Well, not entirely; I want to very intentionally exclude anyone who draws diagrams before any code is written and berates colleagues for not implementing his diagrams. Software architecture is not brought into existence by diagrams or charts or whitepapers or anything like that; these are just tools which can help us to explain and teach an architecture after it comes into existence. Software architecture is made by the very process of writing the software; the architecture emerges from the code that is actually written (and for aggregate systems it is begat by the components that are deployed and the interactions that emerge between them). Software architecture is an artifact of the engineering process - remember the office before the row of houses.

If we're trying to think about software architecture as something abstract, separate from and superior to the code or the engineering process, we're completely missing the fundamentals. Software architecture might be better understood as subordinate to the engineering process, but really it's best understood as being one of the essential components of what goes into doing software engineering. Every software engineer is making architectural decisions, every day. Every software engineer is, to a greater or lesser extent, a software architect. Not because they've developed a separate skill, but because software architecture is an aspect of doing software engineering.

Where that leaves Mr. Software Architect then is that he is a sofware engineer all the same as his colleagues on his team. If we have somebody with the architect title, what we ideally have is an engineer who has a particularly good understanding of the architecture aspect of engineering, somebody who strengthens the whole team by setting a quality example of thinking and engineering architecturally. Other folks on the team will have other strengths like design or security or performance, which are all themselves aspects of software engineering. How does our colleague who's good at performance lead the team to deliver a performant product? This seems like a silly question because the answer is obvious: if they're a professional then they'll act professionally with the team on performance. All the same with our colleague who's good at architecture.

There's no doubt that architectural decisions come to be made during the engineering process, and likewise there's no doubt that such decisions should inform future development. Nonetheless, I object to the question how do you enforce architectural decisions because this question conjures an image of an individual architect making decisions and authoritatively holding them over an engineering team. If instead we want to have a conversation about how an architecturally-inclined member of the team can best contribute their skills, helping to find and bolster good architecture that comes out of the engineering process, then we can talk!