There are so many myths about software architecture ...
- that it's done once and there's no further cost associated
- that if you do it properly, it will serve forever
- that there's "the correct way to do it" & you measure correctness with "software architecture" aesthetics
There's one more I find especially irritating: that architectural change can happen as a side effect (of feature work). That it's "free" - meaning that an architectural improvement is an "upgrade" over the original idea that doesn't require specific skills or additional effort.
Ain't no "free-ride"
Frankly, all the professional experience has taught me to avoid definitive statements, but ... I can't recall any single successful architecture change that happened that way. Quite the opposite - "architecture by chance" usually ends:
- with half-baked, unfinished, faulty products
- with Lava Flow effect - old and new co-existing, causing confusion and plenty of additional costs
- with increased accidental complexity
- with very rotten compromises, because something had to be sacrificed last minute (when there aren't that many options)
The healthy way for tackling architecture-related work is ... to treat it exactly just like a feature work. Architects should act as sort of Technical Product Owners, keeping (& prioritizing) their backlogs, tracking the risks, measuring the outcomes of introduced changes. Their backlogs should contain both small improvements & large architectural epics - big, system-wide transformations justified with the issues being solved, backed with proper business cases (potential value added), etc.
This work can be delivered only with a guaranteed capacity - dedicated teams working on clear, well-defined work items, in a transparent way - tracking & communicating their progress, effects, outcomes.
The value of such streams of work is unreasonably underestimated - that is the most natural way to tackle accumulated debt (technical or design one), fix Developer's Experience, address non-functional system property-related concerns or just enable future feature changes by building certain capabilities in.
"Fix your own shit"
Inexperienced, not sufficiently informed or delusional executives tend to think that professionals (and they expect professionalism from the engineers) fix their own "past mistakes" or "sub-optimal decisions" within some sort of "guarantee":
"Haven't we pay you senior-level money for senior-level work on that, one year ago? We expect high quality, but apparently you've done your job poorly (because you're saying it has to be fixed now) - why should we pay additional money for that?!"
It's one of the biggest challenges in software engineering business - to explain to non-tech people that building software doesn't work like that. In fact it's yet another similarity between the work of a traditional Product Owner and an Architect:
- they both address present AND (foggy, continuously evolving) future
- they both speculate in a reality of high uncertainty; making the contextual decisions based on their experience, but also limited data
- they both should iterate frequently, using data as a source of feedback
- in case of both of them, the solution range is near-infinite - there's no optimal solution, just a full spectrum of more or less flawed ones :)
If you respect your architects and want them to make a difference truly, make sure they get enough dedicated (wo)manpower to do their work. Otherwise, you'll end up with few highly paid, powerless & frustrated consultants, trying to navigate against the wind (of feature-work madness only).
