软件架构管理过程

上一篇博客谈到架构的起源，也就是Dewayne E. Perry 和 Alexander L. Wolf在1992年发表的“Foundations for the Study of Software Architecture”，也说到了目前架构已经到了3.0版本，即架构 = 一系列的架构设计决策 + 这些决策背后的原理。这次来聊聊软件架构管理过程。

我认为目前来说，大部分的架构设计或者方法都有其生存的环境，比如项目环境、企业环境、行业环境等，适合你的不一定适合就适合我，很难找到一套通用的解决方案来应对所有变化，所以目前的架构解决方案呈现多样化。但是在各种各样的架构解决方案背后，却有着相同或者相似的架构管理过程。

架构管理过程的元素是活动，最初只有三个，由Christine Hofmeister, Philippe Kruchten, Robert L. Nord, Henk Obbink, Alexander Ran, 以及 Pierre America提出：

Architectural Analysis（架构分析活动）：该活动用于定义一个软件架构必须解决的问题。

Architectural Synthesis（架构合成活动）：该活动用于建议能解决目标问题的潜在解决方案。

Architectural Evaluation（架构评价活动）：该活动用于评估潜在的解决方案，并确保架构决策的正确性。

这三个活动构成了最初的软件架构管理过程：

在2010年，Antony Tang, Paris Avgeriou, Anton Jansen, Rafael Capilla, 以及 Muhammad Ali Babar，扩展了软件架构活动到五个。Architectural Analysis， Architectural Synthesis， Architectural Evaluation仍然在列，同时他们增加了：

Architectural Implementation（架构实现）：该活动用于实现设计的架构，是一个从架构设计到详细设计的过程。

Architectural Maintenance（架构维护）：该活动用于维护架构，比如通过修改架构来解决发现的错误等。

于是软件架构过程演化为：

随着架构的发展，我们发现架构活动还可以包括架构演化、架构恢复、架构描述、架构理解、架构影响分析、架构复用以及架构重构，但是以上五个活动我认为是架构的核心活动，而其他活动则是一般性活动，这些一般性活动可以出现在整个架构生命周期的任意阶段，用以支持以上五个核心活动。