When is it acceptable to cut corners when moving from one architecture to another? I’m talking about things like architectural requirements, such as a requirement that all services integrate with an APM monitoring tool. When is it all right to cut corners when trying to get a service migrated from one architecture to another, and when should those corners remain crisp?
Obviously we put architectural principals and requirements in place for a reason. They are designed to help the application work as a whole, or be easier to debug, or conform to legal requirements, etc. Architects don’t just wake up in the morning and say “You know what, I really just want to enact rule ‘x'”. So, there must also be a reason for cutting corners. A reason bigger than just laziness. I’ve seen many corners cut just because of laziness. Usually these are meant to just be temporary things “we’ll come back around after product gets off our back for this next release and fix this”. Very rarely do the temporary things remain temporary (unless you take a very long-term view of the thing, and realize the temporary thing stays in place until the entire system goes through another architecture change).
Sometimes there isn’t a way to even get up to the corner, let alone cut through it. Migrating a few million lines of a legacy monolith to fancy new microservices isn’t going to happen in an iteration. The time to actually go and do that migration likely won’t be appealing for a business, nor is it likely to pay for itself. In cases like this there may be no corner to cut, and a new architecture only applies to subsets of the system, or a new feature, or what-have-you.
Maybe the architectural principle or requirement that was in force in a legacy system, or some interim time, is less valuable now in light of a new architecture, and it now makes sense to cut that particular corner. Conversely, maybe a previous architecture requirement was so enforced that a contradictory requirement in the new architecture makes less sense (perhaps something like an old reporting or auditing scheme vs a new one).
Of course, there is no clear-cut answer to a question like this. Each system, and component of a system will have different answers to this question. I think it is extremely important, however, to be aware of the architectural principals that were in place in a legacy system, in the ideal new system, and what corners are able to be cut as well as which ones must strictly stay sharp.
Originally Posted on my Blogger site September of 2017