I worked across a group of independent engineering organizations that all shipped differently. Different products, different release patterns, different technology. The obvious answer was sitting right there: standardize everything. One platform, one workflow, one way to build, test, and release.
It would have looked very clean. It also would have been wrong.
Those teams had legitimate reasons for most of their differences. The useful question was never how to make everyone work the same way. It was where they were duplicating each other, independently and badly.
We standardized where teams were solving the same problem over and over. Where their differences were real, we left them alone. The shared platform had to run across twelve independent engineering organizations without pulling any of them onto a common toolchain, and that constraint shaped the whole design.
Nobody was trying to make twelve organizations look alike. The point was to stop paying twelve times for the same problem.
Old is not the same as broken.
Old technology makes people uncomfortable, sometimes for good reasons. It may be expensive to operate. Changes may be slow. Reliability may be sliding. Maybe nobody understands it anymore, or it simply can't carry what the product needs next.
Those are reasons to change something. Age by itself is not.
I've sat in a lot of conversations where modernization was already the answer before anyone was specific about the problem. The platform is old, so we should replace it. Something newer exists, so we should probably be on it.
Maybe. But if releases take three weeks because of one bad dependency, replacing the platform is an expensive way to fix a dependency.
Some of the best technical decisions I've made were deeply uninteresting. Keep the thing that works. Use the managed service instead of running your own. More than once the right call was fixing the interface and leaving everything behind it alone.
None of that makes an exciting architecture diagram. It does make an architecture easier to live with.
Complexity has a bill.
Every service has to be operated. Every abstraction has to be understood. Every platform needs an owner. Someone monitors it, secures it, deploys it, debugs it, upgrades it, and eventually explains it to a person who wasn't in the room when it was designed.
I've seen good engineers design systems that required an organization the company didn't have.
The design may be technically sound and still be impossible for that organization to carry. A system that needs six specialized teams to run doesn't become practical because the diagram is elegant. A platform has to save more time than it costs to build and maintain. An abstraction that helps one team can simply move the work somewhere else.
None of that argues against sophisticated systems. It argues for counting the operating cost while you are still choosing.
Simple isn't automatically better either. "Keep it simple" can be exactly as lazy as "modernize everything." Scale may require a more complicated design. Reliability may require it. An organization may be spending so much effort working around the existing system that replacing it is the lower risk path.
The real question is whether the complexity is doing enough work to justify what comes with it.
For most of my career, I have not had the option of making a recommendation and leaving. The teams I led had to build it, run it, and change it when our assumptions turned out to be wrong. You learn a lot about architecture when you have to live with your own decisions.
And when the problem really does need something hard and complicated, good. Let's build that.
Just make the complexity earn its place.
