Just like any other piece of a software system, a system’s architecture can accumulate dust, and turn into a form of technical debt. Sometimes this debt is non-prohibitive, or even useful, but if it is not considered and re-evaluated on a regular basis, it can jump up suddenly as a crushing debt, keeping you from acting on the business vision in a reasonable timeframe. Ideally, we would notice the trends sooner, before it becomes crushing, and make the smaller adjustments to come back into alignment, but that does not always happen. In fact, it rarely happens, because architecture, by definition, includes the things that are hard to change, we rarely look at them as things that may need to change. We end up not looking at them until it becomes very blatantly obvious that something needs to change here, and the conversation suddenly shifts to calculating how much it would cost to rewrite the entire system, or build something new, or other fairly ludicrous ideas.
Part of the trouble we get into by ignoring a regular evaluation of our architecture is that we really ignore it completely. We may set up an ideal, pristine picture of what it should look like, and perhaps even adhere to that for some time, but we do not measure how well we keep to that picture; we do not gather any metrics around the architecture. That simply makes it just that much more easy to ignore the architecture “debt creep”. Calculating and recording these metrics is the first step towards evaluating those small trends that can help you make smaller adjustments along the way, rather than waiting for things to pile up into an insurmountable stack.
What happens when you have been gathering these metrics, and begin to notice that pieces of your architecture are no longer up to snuff? Architecture pieces aren’t usually “small”, and again, are hard to change. So even if you identified something sooner than “the entire system is a pile of junk”, what can be done about it? The trick here is to really get to know the business, and what their needs are (and will be). That’s a big part of being an architect in general too, but even more so here. If there seems to be an issue in this one context, because your metrics are starting to become undesirable, and you know there are going to be more asks from the business that also affect this context, that is one to look at investing in. Perhaps pulling it out from the monolith is the right way to go. Perhaps just going in and solidifying the boundary inside the monolith is the right way, as you aren’t quite sure it needs to be pulled out into something standalone yet. Maybe combining two microservices is the right thing to do.
The smaller the pieces that you can track, the faster you will be able to work, and iterate, on those pieces, and avoid getting stuck in an undesirable situation where everything seems to be falling apart around you.