I’m going to post the contents of a gist I wrote (2 years ago?!), because Theo is right, some gists are better as posts. The context for this was a debate on Twitter (which, as always, is about as elegant and pleasing to read as a turtle trying to breakdance). 

Summing up contextual influence on systems architecture

1. Monolithic applications and architectures can vary in their monolith-ness. This is an under-specified description.

2. Microservice applications and architectures can vary in their micro-ness. This is an under-specified description.

3. Both microservices and monolithic architectures have both benefits and disadvantages that are contextual.

4. Successful organizations will exploit those benefits while working around any weaknesses.

5. Success of a business is a large influence on the exploitation of benefits and implementation and costs of workarounds.

6. All benefits and work arounds are context-sensitive. Meaning that they are both technically and socially constructed by the organization that navigates them.

7. Path dependency is a thing. History matters and manifests in these architectural decisions and evolution in an organization.

8. Patterns exist to inform practice, not dictate it. Zealous adherence to an architectural pattern brings peril when it is to the exclusion of cultural and social context in actual practice.

9. Architectural patterns will expand, contract, evolve, and change in multiple ways to fit the trade-offs that an organization perceives it has to make, at the time they make them.

Much has been said about this, including some more by me, since then, but apparently it is not a dead topic and I figured I should grab it off of the gist system. 🙂

In the end, I consider architectural patterns to be folk models. Meaning that in popular dialogue, they tend to:

Substitute one label for another, rather than decomposing a large construct into more measurable specifics (how do I know when I say ‘microservice’ to you, we can be sure your understanding of the term is the same without being more specific?)

…are immune to falsification (how do I look at an architecture and decide when it’s no longer a monolith in a way that is universally true?)

…and easily get over-generalized to situations they were never meant to speak about. (when we talk about microservices, how do I know when we are no longer talking about technical specifications and when we start talking about organizational design?)