在“ 浅谈Architectural Assumption（软件架构设计的假设条件）（1）”文章中谈到软件架构层面的不确定性信息的概念。软件开发中包含大量架构层面的信息，而这些信息在项目开发中（特别是早期阶段）往往无法确定（比如是否正确、合理等），但为了推进项目、完成预期的进度目标或其它原因，我们常常需要先暂时认可这些信息（如认可其合理性）。
之前在瑞典某公司做研究的时候，该公司的架构师举了个非常经典的例子：在对某系统架构的设计中，他采用了一个模块（外购），而且规定这个模块要达到某种性能。但是他当时并不确定这样的设计是否合理，比如是否一个规格稍低的模块也可以满足系统要求。尽管在他的脑海中知道这条不确定性设计的存在，但是他并没有对其进行管理，连最起码的记录都没有，更别提进行评审或者测试。随着项目的推进，他也忘了有这么件事。在后期系统的实现中，该公司按照设计采购了一批目标性能的模块，成本不好透露，但价格不菲。可是事后发现，该系统根本不需要这么高规格的模块，比如他们发现有一个价格在已采购模块十分之一左右的模块同样可以满足系统要求。
这些不确定但又被认可（接受）的架构信息在国外被称之为Architectural Assumption（或者Assumption)。由于国内对这类信息没有正式的中文名称，以下统一用AA代替。
AA可能是显而易见的，也可能是隐含的。就像上面提到例子，该AA只存在于该架构师的脑海中，而这在项目中是一种常见的情况。尽管架构师经常制定AA，但有时候甚至架构师自己都没意识到在项目中他们假设（猜测）了很多东西。
AA会随着项目的进行而演化，比如原来有效的AA可能变得无效，或者由于早期缺乏相关信息，而假设了一些错误的信息。未被有效管理的AA可能导致多种问题，如架构设计的不一致、对于系统产生误解等。
AA的本质在于不确定性：所有的AA都包含不确定性（如不确定其正确性、重要性、适应性等）。不确定性是分辨一条信息是否是AA的关键标准。但另一方面，AA具有相当程度的主观性，比如某条信息是否是架构层面的信息或者是否是不确定的，可能因人而异。这也是不同人可能对AA概念有不同理解的原因。
除了AA本身的重要性外，AA需要有效管理的另一个重要原因在于AA和多种类型的信息关联，如需求、设计、模块、风险等。比如某个设计决策基于某AA，如果AA本身出现问题（如变为无效），那么该设计决策可能也随之产生问题。其次AA和其他类型的信息之间可以相互转化，比如假设待集成的第三方系统应提供自动纠错功能。在项目早期，可能开发者无法确定该系统是否需要提供该功能，所以认为这是一个AA。随着项目推进，当开发者能够确定该系统确实需要提供该功能时，这个AA则转化为需求。
前面在“架构起源”的文章已经谈到目前大牛们（比如Jan Bosch）取得的共识是：
软件架构(software architecture) = 一系列的设计决策(design decisions) + 决策背后的原理 (rationale)
也就是架构理论体系v3.0。
在此我斗胆提出一个设想：如果我们将软件架构不确定性提升至等同于设计决策的地位，是否可以得到以下的体系：
软件架构 = 一系列的设计决策 + 一系列的架构层面的不确定信息 + 这些决策和不确定性信息背后的原理
AA这个概念的产生本质上还是对软件架构中存在的不确定性的信息的一种重视，希望将其从传统的架构设计中独立出来进行研究。比如David Garlan在1995年发表于IEEE Software的一篇文章：Architectural mismatch: Why reuse is so hard。IEEE Software是企业非常偏爱的杂志。
当然我可以非常肯定地说，这个设想的抛出具有很大的争议性。可以预见有很多人不会同意这种观点，比如可能有人认为不确定性根本就不重要，或者不需要独立出来管理，直接和现有的东西一起管理即可。我在公司工作的几年里，也从来没有接触或者考虑这种层面的理论。虽然在软件架构的领域里呆了很多年，也读了大量的理论文章，但是仍然不敢断言AA（架构不确定性）以及其管理存在的实际价值到底有多大。只能说在此抛砖引玉，希望更多的人来完善这套理论，或者证明这套理论并没有多少实际意义。