Elephant in the Architecture
- Architectural decisions should primarily be made based on business value, not technical concerns.
- Say a system that’s processing orders isn’t fault-tolerant, and improving this area of the system is going to cost a few 100k, this decision almost entirely depends on the value of the orders flowing through the system relative to the cost of the change + ongoing maintenance.
- Foundational work can/should be brought to the business by reframing as a business question. For example, “does this database need to be replicated” becomes “if we could guarantee that the database won’t go down on black friday, how much is that certainty worth to the business?
- Things like the CAP theorem could be business decisions too. Hotels are happy to double-book and figure things out later, but don’t want to miss taking orders in the name of correctness.
- Architecture decision records can be placed adjacent to source code, explaining how the architecture came to be what it is; this sort of thing should include the business-side arguments for these decisions too.
- It’s a shame that the “technical side” is walled off from the “business side”; there should be more interplay, and much of an architect’s job is to break down these barriers.
- This is obvious once pointed out, and makes this sort of role much less appealing to me; architecting systems based on technical decisions sounds very appealing, but meeting with a dozen executives to base architectural decisions on is not my thing.
- I’d want to figure out how this applies to smaller companies in their infancy. There isn’t much money flowing through the systems yet, so the main architectural driver is agility over stability. Not sure if/how the business side of things comes into play here.
- “Engineer” is something of a misnomer for software/technical work in general; basing our industry on “lawyer” is a much better fit!