Good Software Architectures are mostly about Boundaries

Someone explained to me that for an architect, bad architecture is actually better.

One consequence of good architecture is that it is easy to change. When you want to change something, you pick the most easy place, i.e. the best architecture gets modified and the worst stays.

Long term, this is a kind of evolutionary pressure. Bad architecture will drive out good architecture. It will be costly, so the sunk cost falacy guarantees its continued existence. It just has to seem good enough, up to the point that it is too big to fail.

If an architect wants to build a lasting legacy, he or she just has to create software with some bait to give it a few starting years, entangle it with everything else, and give it a disastrous architecture so no one dates to change it. Voila, 10 year longetivity minimum guaranteed.

Design Rules, Vol. 1: The Power of Modularity [2000]

https://www.amazon.com/Design-Rules-Vol-Power-Modularity/dp/...

Formal definitions for interfaces and so forth. Completely changed my mental model for my work.

Paraphrasing from book (from memory): "Architecture" is the set of visible design choices.

Design Rules is to software methodology what Diffusion of Innovations is to product development.

There is some overlap between Design Rules and Diffusion of Innovations, of course. They're compliments.

I was told a surprisingly simple but deep definition of what Software Architecture really is:

It is the interface/protocols between the components.