This analysis brings to the front a personal frustration, and I imagine it&#x27;s not unique to me.<p>This article discusses some architecture techniques, but moreover, it buys into a Culture of Architecture that we don&#x27;t have a word for yet. This CoA is predominant among Java engineers who worked at large, slowly-dying companies (e.g. IBM).<p>The issue with the CoA is that it cares more about buzzwords than quantifiable claims or objective measures. CoA was once addicted to microservices, when that model failed it&#x27;ll be &quot;all about&quot; another, and so on. Rife with academic good-sounding CoA words that nobody can argue with like &quot;SOLID&quot; and such.<p>To be a little more concrete, &quot;Broker topology&quot; is a 25-cent word for a 1-cent idea (and it&#x27;s not the only one, see every keyword in bold in the page, it&#x27;s almost like a college textbook). There seems to be an implicit assumption in CoA that there is a finite number of architecture patterns and they must be learned by name.<p>Again, to be more concrete, &quot;layered&quot; architecture is an oversimplification of a fundamental idea (abstraction) in engineering.<p>This textbook-esque presentation also really misses the spirit of coding. It presents a UML (another CoA must) of &quot;Event-Driven&quot; architecture, then one of &quot;Layer&quot; Architecture, without really explaining if these can be combined or are mutually-exclusive (of course they could be combined). But by treating them as named nouns it creates a misleading and complex language around fundamental ideas.