The money quote is here:
Actually, our approach is not that different in principle, to most architecture guides.
This whole article is basically clickbait. The author appears to be arguing against some ill-defined strawman, but in the end even concedes that that isn't true. They are doing architecture, they just aren't doing it according to "the software architecture literature". Whoop de freaking doo. That statement could be applied to probably 99% of companies out there.
The important thing to realize is that all software has an architecture. The difference is, some software has a good architecture that makes it easy for it to meet its requirements, and some of it has shit architecture that makes it brittle, failure prone, impossible to maintain, and generally scary to look at. And also that some software has an architecture that is clearly defined and well understood and (gasp) documented in some way, where other architectures can only be understood by a massive reverse engineering effort.
You can choose either approach, and all of that is orthogonal to whether or not you use UML, 4+1, Design Patterns, DDD, event sourcing, microservices, or whatever buzzword you want to rail against.
Actually, our approach is not that different in principle, to most architecture guides.
This whole article is basically clickbait. The author appears to be arguing against some ill-defined strawman, but in the end even concedes that that isn't true. They are doing architecture, they just aren't doing it according to "the software architecture literature". Whoop de freaking doo. That statement could be applied to probably 99% of companies out there.
The important thing to realize is that all software has an architecture. The difference is, some software has a good architecture that makes it easy for it to meet its requirements, and some of it has shit architecture that makes it brittle, failure prone, impossible to maintain, and generally scary to look at. And also that some software has an architecture that is clearly defined and well understood and (gasp) documented in some way, where other architectures can only be understood by a massive reverse engineering effort.
You can choose either approach, and all of that is orthogonal to whether or not you use UML, 4+1, Design Patterns, DDD, event sourcing, microservices, or whatever buzzword you want to rail against.