2.2 对变更进行推理和管理

        可变性——系统进行变更的容易程度——是一个质量指标（因此前文用变量来表示），因为它极其重要，所以我们把它放在了前文的十三个重要项里面。软件开发社区发现，典型的软件系统中，80%的成本发生在第一次部署之后。也即，在大多数系统中，人们的大多数工作都是在这个阶段。很多程序员及软件设计师的工作内容被限制在现存架构和已有代码的维护过程中。事实上所有软件在生命期内都会发生变更，可能是添加新功能，可能是为了适配新的运行环境，可能是修改Bug等等。但这些变化往往充满困难。
        每个架构部分都可能在三处进行变更：局部、非局部，以及架构本身。
        (1) 局部变更可以通过修改单个元素实现。例如，添加新的业务规则到定价规则模块。
        (2) 非局部更改需要对多个元素进行修改，但基本架构方法保持不变。例如，添加新的业务规则到定价规则模块，然后根据这个新业务规则需求添加新的字段到数据库，然后在用户接口中展示规则的结果。
        (3) 架构更改会影响元素之间交互的基本方式，可能需要在整个系统中进行更改。例如，把系统从C-S模块改成P2P模式。
        很明显，局部变量是最可取的，因此敏捷架构里面最常见的变更是局部变更，因此易于进行。
        决定何时变更是必要的，确定哪种变更路径的风险最少，评估提议变更的后果，以及仲裁请求变更的顺序和优先级，所有这些都需要对系统软件元素的关系、性能和行为有广泛的了解。
        这些活动是在架构师的工作描述中的。推断架构及分析架构可以提供必要的洞察力来对预期的变更进行决策。