记得几个月前，两位以前的同事(现在一位在中兴，一位在迅雷)也问过我，软件系统架构好坏的决定因素是什么，我当时就告诉他们是非功能需求与约束、系统功能可能的变化与扩展点与趋势。当时他们有点吃惊地问那么软件系统架构不是主要研究功能或用例的吗？
是的，软件架构研究的主要内容可能主要是功能或用例，并且功能或用例确定的软件架构的大的方向如分层、MVC等，但实现功能与用例的架构方案有多种，而软件架构决定使用这种方案而不使用另外的几种方案，有的架构将软件项目引向成功与轻松、有的却注定失败，又是为什么呢？
我们来看我在任项目总监所在公司的一个算失败的项目。项目是这样的：博彩行业的一种产品，它从多个网站通过网页分析的方式取得水位信息，通过某种经验公式，提示用户可能盈利的盘口，用户决定下注后，系统用最少的时间按用户的某种策略尽可能多的下注，规避网站为平衡盈亏而调整水位导致跳水。以前公司利用C/C++开发了C/S系统，取得非常好的销售额；但由于网站为防止这种自动下注经常频繁改版，而且用户的经验公式、下注策略改动频繁，C/S程序已改得七零八落、难于维护；客户遍布世界各地，没有明显的聚集地，客户又没有实力自己进行升级部署，每次升级部署困难、成本很高；C/C++开发组的人员所剩无几，好的能适应该项工作的C/C++开发人员不易招到，而. NET开发人员工作量不饱满。而是公司决定重新规划产品使用.NET开发且解决部署问题。
如果仅从实现功能或用例的角度，该项目的软件架构方案有许多，无论C/S还是B/S都能达到要求；然而，显然决定该项目软件架构的有以下几点：1、适应网站交互(读取网页分析数据与下注)、特别是网站改版变化频繁的要求，2、适应用户的经验公式、下注策略改动频繁的要求，3、系统的性能，4、升级部署困难的挑战，5、开发人员能力的限制。其中前三点最重要，必须解决；而前两点包含两个方面：系统功能可能的变化与扩展点与趋势、可扩展性与可维护性的非功能需求，第三点是系统性能的非功能需求，第四点是安装部署方面的非功能需求，第五点是开发人员能力方面的约束限制。所有这些没有一个是功能与用例。
非功能需求一般指软件系统的质量属性和约束限制。质量属性是软件系统的整体质量品质，往往和绝大多数功能都有关，这些质量属性中一般会归结为少数几个对软件系统起着至关重要的决定性作用，就是这少数的几个质量属性左右着架构的风格选择；至于约束限制，前面讲到要么在设计过程中必须遵循，要么会转化的功能需求或质量属性。同时，从开发的角度，功能需求的缺陷是可以通过编程级的努力补回，而最终提供的软件系统能否达到非功能需求、特别是这几个少数至关重要的非功能需求的要求，是无法通过编程级的努力达到的，必须重新架构。所以非功能需求与约束是成功的软件架构必须重中之重关注的关键要素。
现在软件行业界有句至理名言：变才是唯一不变的真理。软件系统最具挑战的特点就是频繁的变化性，未来需求越来越不可预测，随需应变的要求日趋显著，而且技术的更新进步，也在促进需求的变化。如果不能驯服数量巨大且频繁变化的需求，软件项目还没有开发出来甚至架构还没有完成，软件系统就可能已经过时不适用了！因此，系统功能可能的变化与扩展点与趋势也是成功的软件架构的关键。需要提出的是，不是关注功能变化或扩展后的需求细节，而是关注功能在什么地方可能进行变化或扩展、变化或扩展的规律与趋势是什么。
另外，在进行成功的软件架构设计过程中，还必须重视以下两个方面，它们是成功软件架构的强有力的保证：
软件架构的目的是沟通，但沟通的对象不同，对软件系统的关注点也就不同。如果将软件系统的架构作为一个整体展现给所有沟通对象，则沟通对象会觉得系统很混乱、看不懂，也就不能从沟通对象的专长方面对软件架构予以指导与建议，也就失去了软件架构的本来目的；同时人类研究事物也不是囫吞枣、眉毛胡子一把抓的，而是从不同的角度立场、横看成岭侧成峰的观察、了解、认知的。因此软件架构也需要从各涉众人员代表关注的角度、视线进行设计表达。当然，在分角度、视线设计表达的同时，各角度、视线的相互对应、相互支持、相互影响也需要综合分析考虑。
现代软件开发非常注重尽早降低风险。软件架构是现代软件开发中最重要的一环甚至可以说是最为关键的一环。架构设计是否合理将直接影响软件系统最终能否成功。因此，架构验证的工作千万不能简甚至省！通过将软件架构设计方案尽快实现为一个小的原型，并通过对该原型的严格评审与测试，是成功软件架构的最有力的保证。
