Software Architecture is more than Boxes and Arrows

I watch many software architecture talks (on-site and virtually), and I am starting to think that my understanding of software architecture differs from that of most speakers.

I see a lot of talking about bounded contexts (as in Domain Driven Design), layers (as in Clean /Hexagonal/Onion Architecture), and dependencies (between classes, up-stream/down-stream contexts). Don’t get me wrong; these concepts are important.
However, they are just a small part of all the aspects a software architecture must address.

The above concepts are about structure, how we decompose the whole into parts and how to integrate these parts to build a whole again.

Some presentations discuss how these parts should interact and show pros and cons of concepts like synchronous vs. asynchronous communication, events, messages, service buses, event streaming platforms, etc.

Only a few go a step further and discuss consistency—consistency as a whole, not just “make everything eventually consistent.”

There are also presentations specific to security, telemetry, and how to persist data (CRUD, event sourcing), but they are rare, too.

But, I miss topics like

  • Archiving: how to get rid of old data and replace it with reduced placeholders so that the system still works
  • (Almost) zero downtime releases
  • Data migration: how to migrate data – especially in (almost) zero downtime environments
  • How globalisation (translations) impacts the architecture: where to translate (backend, front-end), support for nested languages (a German user operating on French data).
  • Business rule based permissions: how to implement performance efficient permission handling based on business rules and business data – not just roles and tokens.
  • Trade-off discussions between throughput, latency and simplicity regarding user scaling, data growth and pricing.
  • Dealing with time (time zones, calendars, bi-temporality, etc.)

There are a couple of talks on these concepts, but compared to the number of those regarding structure, there are far too few, IMHO.

And I guess, these concepts are more likely to impact how your users perceive your application than pure structure concerns.

About the author

Urs Enzler

Add comment

Recent Posts