Observations on the practice of software architecture - II

"Two weeks of coding can save you an hour of planning" — Unknown

In part one of this series¹ I tried making the argument that some degree of software architecture is required, and explored how a naive reading of agile software development practices coupled with organizational incentives create a toxic mix where software design is not valued, leading to a lack of clarity and coherence, viability crushing technical risks being ignored, and creeping and crippling technical debt that slows down software delivery.

In this second part I will briefly explore some of the anti-patterns that give Software Architecture a bad name.

So, why does Software Architecture, and by extension architects, get a bad reputation?

The stereotypical software architect is the gray bearded bloke - let's call him the Ivory Tower Architect - that thinks very hard on problems and produces documents with pretty diagrams and varying degrees of adherence to reality. This is a stereotype, and as all stereotypes it is unfair, however it also captures some hard truths.

The Ivory Tower Architect figure has fallen to the siren song of "the big plan": the idea that a non-trivial system can be fully captured by extensive documentation² and it is essentially the sum of its parts. And this perspective, based on a platonic ideal of the system, serves as the mental model that guides his action, ignoring that a lot of interesting behaviors (including failure modes) are emergent, no matter how well the boxes and arrows are drawn.

If we scratch the surface and question how a particular view of a system is constructed, we will often find that people construct their view based on their preferred modeling techniques and a lot of gut feeling - I'm no different, I regularly use Domain Driven Design³ and Wardley Mapping⁴ and I'm actively looking into incorporating STAP/STAMP⁵ and Residuality Theory⁶ into my toolbox - however it's important to understand that the choice of methodologies reflects the range of modeling techniques that people know and are familiar with. This can easily lead to an overreliance on particular techniques/tools/viewpoints to make sense of the world, forgetting the fact that "all maps are wrong, some are useful", and therefore no matter what, important details from a certain point of view will necessarily be missed.

These inevitable epistemological⁷ limitations become glaringly obvious if our Ivory Tower Software Architect is not actively engaged in actually building software. By not having skin in the game, the software architect is in a very comfortable position where he is shielded from the negative consequences of his decisions. Human nature being what it is, it will be exceedingly easy to blame failure on a team's inability to build according to what has been outlined, and at this point our Ivory Tower Architect friend has become a bona-fide Intellectual-Yet-Idiot⁸. Fundamentally operating in an open loop, misses critical implementation details that may derail the whole architecture (as well as potential improvement opportunities), on top of which the Ivory Tower Architect's technical skills will inevitably atrophy.

At a more fundamental level, a style of top-down architecture-by-decree limits the opportunities of teams to build up their architectural muscle, limiting their autonomy - which can be detrimental to their motivation and engagement - but hey it may grant a modicum of job security and brings some nice status perks, since after all it is a fancy title.

As I mentioned in my previous post, coordination of joint action, framing important technical initiatives in the wider business context and generally bridging the gap between technical and non-technical stakeholders is absolutely crucial. A lot of this will intersect with the practice of software architecture and, for the cases where there are dedicated architecture roles, it's very easy to fall into the trap of becoming an Ivory Tower Architect, where one is perpetually creating nice documents and dealing with organizational fuckery⁹.

In the next post of this series I will dive into some of the practices that I find valuable in my own software architecture practice - and how those help build a more resilient and healthy engineering organization.

---

Footnotes

1. I did a minor update to last week's article to mention the fact that agile software delivery practices offer precious little guidance about the practice of sofware design. In addition to this I also expanded a bit more about how technical risks (depending on the nature of the project/product) need to be considered. ↩

2. The map is not the territory, and the effort to fully capture any non trivial system reminds me of this short paragraph by Jorge Luis Borges: On the exactitude of science ↩

3. Domain Driven Design ↩

4. Wardley Mapping ↩

5. STPA Handbook ↩

6. An Introduction to Residuality Theory - Barry O'Reilly ↩

7. I think software design - thus architecture - of large scale systems is also an epistemological problem: How do we "know" a system? What kinds of facts are possible to know in the first place? Is there a risk of projecting unfalsifiable beliefs into our designs - thus having a mental model that is wrong but very hard to disprove? ↩

8. "The IYI pathologizes others for doing things he doesn’t understand without ever realizing it is his understanding that may be limited." - Nassim Taleb, link ↩

9. Architects, anti-patterns and organizational fuckery ↩