Keeping your code clean has been a focus in software development for a long time. Books by Robert C. Martin (Uncle Bob) and lots of other writers describe to developers how code should be written to make good and healthy applications. This is often incorporated in the development tasks, and also supported by tools like SonarQube for measuring the quality. But what about your overall architecture? Is there any focus on "Clean Architecture"?
Drawing by Manu Cornet (http://www.bonkersworld.net)
I my recent projects I have tried to be the advocate of clean architecture and the Single Responsibility Principle. You need to find a way to avoid having an architecture where each block of business logic is shattered into a lot of different components/modules/applications, if you want a maintainable and extendable architecture. When business logic is spread out on different modules or applications, maintaining, extending or changing that piece of logic will affect a set of modules, and might have big impact on testing, deployment and monitoring, in addition to development in all the modules.
Enterprise architectures typically consists of a lot of applications and layers. One of the key tasks of architects should be to make sure each application/layer has its own mission and clear boundary. Ideally let one application or module do only one thing, and give them a unique task in the overall architecture.
Problems often arise when one module has been created based on one particular technology or product, and that same technology is also needed for other kind of functionality in the architecture. The quick solution is to add it to the same module, and in many situations that is your only option due to licensing costs. As soon as you do this, you have broken the Single Responsibility Principle of the first module.
Another situation messing up your clean architecture, is where functionality is added to a module, because it "is easy to do it there". The reason why it might be easy to do it there, might be that this component is clean, and as soon as that is used as a reason it is reversed directly.
Basing your architecture on Microservices might help you quite a bit to achieve a cleaner architecture, but it can also lead you into even more complex situations. One of the concepts of Microservices is that each team manage their own application/module and hopefully this is done through DevOps as well. But this can easily result in inward thinking, and an attempt to solve a new requirement within you application even when it ideally should have been handled by another application managed by another team. It needs to be the responsibility of the overall architects within your organization to make sure this isn't happening, but are these things visible to them? I doubt it! In my mind strengthening your architecture governance and the architect's visibility in implemented functionality is required if you decide to base your architecture on Microservices.
A final warning: Advocating these principles will make people look at you as one of the grumpy old guys in The Muppet Show, since you are the one to say a big NO, every time someone comes up with a quick and simple solution to deliver some kind of requirement.
Statler & Waldorf (Wikipedia)