System Architecture

DesignDev: you design it, you build it

TL;DR: software architects should be involved in the development process for their own designs. This will give them a good incentive to create simple and maintainable designs.

Before DevOps came along, there used to be a separation between development and operations. Developers would pack their applications and throw them over the wall for the operations team to run them. Eventually, it was noticed that this led to low quality, unreliable applications and the focus changed to a ‘you build it, you run it’ approach. If you want to understand why this approach works, you have to read Skin in the Game: Hidden Asymmetries in Daily Life by Nassim Nicholas Taleb. It’s all about symmetry and risk sharing.

Actors – per Taleb – must bear a cost when they fail the public. A fund manager that gets a percentage on wins, but no penalty for losing is incentivized to gamble with his clients funds. Bearing no downside for one’s actions means that one has no “Skin In The Game”, which is the source of many evils.


But what about the Software Architect? Where does s/he fit in the design and development process? I keep seeing the consequences of bad design over and over: systems are hard to develop and maintain, applications have to be discarded and re-done, deadlines are missed, etc. All this results in frustration for developers and increased costs for the company. 

The less the software architect is involved in the development stage, the worse the design/architecture tends to be. Yet, if the architect is involved with the system’s development from the start, the better the design turns out.

I think two reasons explain this phenomenon. The first is that software architects who can code, tend to be better architects. The second one, and more important, has to do with incentives. The way most companies are set up, if a project succeeds the software architects get the credit – if it fails, the blame and long hours fall on the development teams. This structure is the exact assymetry that Taleb was talking about: one actor gets the rewards, the other is stuck with the risks.

The solution? Simple: you design it, you build it. Or even better: you design it, you build it and you run it. Shall we call this DesignDevOps?

The comparison between software architects doing the coding and (real?) architects physically building a house is often made, but I think this comparison is wrong. I would say that a software architect doing the coding is like a general rushing into the battle with his or her soldiers as opposed to staying safe at the base. This is why I have no plans to stop coding any time soon.

System Architecture
Vertical Decomposition: Creating Cohesive Services
System Architecture
Integration Patterns for Microservices Architectures: The good, the bad and the ugly
System Architecture
Add git-like functionality to your application using Event Sourcing