So what does this principle (and requirement) actually state?
It states that we should choose components and software systems that has the best cost/benefit over its lifetime. That is nice. What we all need. Problem solved, right?
The main problem is that we do not know the answer of either of them; we do not know the lifetime of the technology we choose, and we do not know the lifetime of the business we are supporting. We probably know more about our business overall; tax-systems are here to stay, and certain elements are fixed (someone must pay their tax). But we do not know the details on how our processes will be in 20 years, neither on the details on how to calculate and what type of tax we will be imposing (CO2 footprint tax?).
We must make sure that the important stuff for us - requirements (see: Requirements), data, code base, and business state (as discussed in other blogs) - is handled and stored in a way that makes them versatile. Requirements by themselves are interesting, because the systems in which we store requirements actually must last longer that the systems they define. Just think about it; what system would you trust your requirements? (Systems Architect, Troux, Mega, Qualiware) Which will be there in 20 years?
When we have defined our target architecture it must have certain capabilities to support our domain; but it also must comply to the lifetime principle. Distinct domains define systems that cooperate (they could be called mega bounded contexts, just to extend the Bounded Context of DDD. In our case they would be Party, Tax calculation and Money, which in turn have smaller Bounded Contexts), it is the most important feature; then these can be exchanged as time flies by. Well this is not Lego, we should add "with as little effort as possible". This also helps in isolating custom functionality from COTS. In both cases we find Domain Driven Design to be a great EA approach.
The overall architecture must adapt to continuous change in technology and business. Surely it is a hard nut to crack, but it still is the main goal for the target architecture. It must support continuous change, that is the normal case, we as an organization must support and endorse change.
With the lifetime principle posed on our systems, the overall effect is that:
The architecture must support a condition of continuous change.
Lifetime principle. Continuous migration by Tormod Varhaugvik is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
