I’d word it as “keeping the cost of changing software low over the long term”.
I don’t think you can reduce that to a quality goal of “modifiability” because it’s not negotiable like other quality goals.
I don’t think you can say it’s just cost reduction, but that is closer.
It’s an existential thing. Architecture is about retaining the ability to change your software (avoiding the big ball of mud). If you lose the ability to change within time and resource constraints then the project, product or startup is dead.
For typical web / IT systems I largely agree with focusing on modifiability as a heuristic because on those kinds of systems it's typically the biggest risk.
But, have you seen this kind of mistake / failure? A system is built so flexibly that it can handle all kinds of future needs, but it's slow. Maybe it's a shopping cart that takes 5 seconds to update. So start with modifiability as the primary heuristic but keep an eye out for other failure risks.
Meta-commentary:
This is an example of why it's so hard to discuss architecture. My book talks about "failure risks", which is pretty abstract or generic. There's no easy heuristic for avoiding "failure risks" like there is for web / IT systems.
Software architecture is a discipline that's bigger than just web / IT systems. Some systems must respond with X milliseconds, otherwise the result is useless, so the architecture should make that possible -- and preferably make it easy.
>> cost reduction
> fulfil the quality goals
I’d word it as “keeping the cost of changing software low over the long term”.
I don’t think you can reduce that to a quality goal of “modifiability” because it’s not negotiable like other quality goals.
I don’t think you can say it’s just cost reduction, but that is closer.
It’s an existential thing. Architecture is about retaining the ability to change your software (avoiding the big ball of mud). If you lose the ability to change within time and resource constraints then the project, product or startup is dead.