CMMI 1.3经历过数次升级，但过程架构一词仅局限于术语定义层次，从来没有在实践描述中出现过。CMM是这样定义软件过程架构的：

软件过程架构是一个组织标准软件过程的概要（总结性）描述。它描述标准软件过程元素的次序、接口、相互依赖关系和其他关系。它同时也描述了软件过程元素和其他外部过程（如系统工程、硬件工程、和合同管理）之间的关系。

（2）过程元素和外部过程的接口、相互依赖关系和其他关系。

我看软件过程架构，没有人质疑软件系统架构的重要性，软件过程架构在很多方面继承了其理念和方法。这也是Humphrey一开始给出的方向，可惜大师及后来者没有进一步深入研究并总结业界优秀实践。

CSWP（Common Software Process）软件过程架构，印象深刻，至今还记得雷神软件过程架构师在黑板上给我们展示各种过程的视图，让我见识了过程之美。

这20年来，断断续续一直在思考软件过程架构的问题，可惜共识者甚少。在咨询、培训过程中，也很少在这个领域深入展开。我接触到的许多国内导入CMMI的软件组织的软件过程架构鲜有活力，基本以摆设为主。

说到软件过程架构就离不开两个重要概念，一是过程结构（structure），二是过程视图（view）。

但软件开发具有不确定性的特点，这种结构其实并不适用。结果明确，过程灵活应该是我们追求的目标。核心过程活动模块化、标准化支持多种开发模式，保证质量底线也是软件过程结构的重要考虑。

- 为软件过程改进和软件开发提供了一个很好的基础；

- 有助于过程在项目中的落地，减低过程培训成本；

- 有效支持过程的可扩展性；

- 帮助理解过程活动的价值点，引导过程执行者的正确行为规范；

- 有助于跨团队、跨领域协同作战，拉通活动和目标的关系；

一个软件组织的过程架构是由一组相关联的过程结构组成，通过关键干系人的视图，清晰展示在视图中过程结构中内容的价值，结构之间的关键属性关系（依赖、反馈、支持、目标等）和接口关系（接力棒接口等）。