架构评估的三个时机与利益相关者原则

架构评估的一个突出优点是可以在架构生命周期的任何阶段进行，通常分早期、中期、后期三种时机。早期评估发生在完成高层次架构和部分高优先级架构决策的初期阶段，此时可以评估初始决策、查找不好的决策，不要求架构内容已完全确定；有的组织推荐早期用”发现性评审”——针对原型架构的小型评审，目的是找出较难实现的需求并划定优先级，要求系统需求尚未最终确定但设计师已比较清楚方案、利益相关者中有权做需求决策的人在场、评审结果给出一组按优先级排列的需求。中期评估发生在架构设计实施部分精化之后，架构精化是迭代过程，评估可以在任一迭代点发生，此时应有一个相对完整的架构设计（完整度取决于精化程度），可以据此发现存在的问题。后期评估发生在系统已被完整设计实现并部署之后，此时架构和系统都真实存在，可以检测两者是否匹配、还可以检测”架构漂移度”——即与原始架构设计相比系统是否已发生巨大变化。一条实用的判断原则是：应该在开发小组开始制定依赖软件架构的决策、修改这些决策的代价已经超过架构评估本身代价的时候，实施架构评估——这条原则把”什么时候评估”从一个模糊的时间点问题，转化成一个可以比较的成本问题。评估的另一个关键要素是利益相关者：软件架构涉及很多人的利益（用户要易用功能丰富、维护组织要便于更改、开发组织要容易构建并最大化利用现有资源、出资方要不超预算按时完成），架构设计师必须权衡这些利益，而这项工作之所以困难，一是因为很多利益并未以实际系统需求的形式表达出来（需求文档只表达了好架构必须满足的一部分条件），二是因为不同利益相关者的诉求本身经常相互冲突（如用户对速度的要求与维护人员对可修改性的要求相冲突）——因此”软件架构利益相关者的积极参与是高质量评估必不可少的要素”这条原则，本质上是承认架构评估不能只依赖系统需求文档，必须主动把隐藏在文档之外的诉求挖出来。