This is always the shortest chapter in all my solution architecture documents! Why? Well, what’s there to say? The expected life span of the solution is N years!
But this is actually pretty architecturally significant! Because once you design work starts, it’s a seemingly endless battle against build-up of technical debt. Everyone wants to cut corners to save time and money, and meet other goals.
I have learned the my best argument for making hard but wise choices in the heat of the battle is to remind everyone of the expected life span. That helps put the usually manageable cost of refactoring now in perspective, when you weigh it against having to tackle the technical debt regularly while maintaining the solution in the long run.
Surprisingly, many projects start without knowing the expected life span of the investment. Or maybe the sponsor and the steering committee know, but don’t see why it might be of interest to anyone else.
Having this chapter helps you learn what they are expecting, and it can then help you balance contradicting design options going forward.