This is required reading for all software developers. Any successful software system will end up as a Big Ball of Mud or other anti-architecture eventually. It's just the nature of the beast. And while we should fight the entropy, it will occur despite our efforts (there might be a few exceptions in the world, but for the most part it is inevitable)
In order for software to be successful it needs to solve a problem. In order for that software to be successful in the long term it will have to change and adapt to continue solving the problem. Architecture usually means abstraction. And abstraction is most always a tradeoff - you sacrifice flexibility to make something common, easier. But there is the rub. A successfully abstracted architecture that solves the problem today, will not be able to solve the problem tomorrow without big changes!
There's a very short chapter in one of the books I like, Working Effectively With Legacy Code, entitled "We Feel Overwhelmed. It Isn't Going To Get Any Better." The chapter offers little more than hope based on seeing turnarounds happen -- once you get some control over your code, you start developing little oases that are pleasant to work in, even if the rest is crap.
I see something similar with large software systems. A 'system' is something that can stand alone, but very large software is logically composed of many subsystems that could in theory stand alone even if presently they never stand apart from the full system or if their components are so intertwined that the logical subsystem is only a potential abstraction. While the full system might be a ball of mud, and you have little to no control over what Team X does with their subsystems and their relations/interconnects with the overall system, it is possible to rework your own subsystems in a way that they themselves aren't balls of mud and stay that way indefinitely. (I suspect this is part of some of the optimism behind microservices -- followed by pessimism when people realize the full system that interconnects everything can still easily become (or start as) a ball of mud, one even less pleasant to work in than in a monolith design.)
In order for software to be successful it needs to solve a problem. In order for that software to be successful in the long term it will have to change and adapt to continue solving the problem. Architecture usually means abstraction. And abstraction is most always a tradeoff - you sacrifice flexibility to make something common, easier. But there is the rub. A successfully abstracted architecture that solves the problem today, will not be able to solve the problem tomorrow without big changes!