什么是系统的本质问题?这是我们要明确讨论的最后一个关键设问。就题设来说，“系统”的本质是领域集。这是一开始就讨论过并强加在我们这里的讨论之上的。但其本质上的问题是什么，却是一个还没有被讨论的话题。

若以现实系统为各个领域的目标，那么系统只需实现目标需求即可，亦即本质问题将是“能或不能实现”的问题。但是这将会得到一个“死的”系统：从系统被完成的第一时间开始它就不再增删任何东西；也没有任何对外的接口，因为它不面向新的领域。这样的系统并非不存在，事实上它大量存在着，并且是“高可靠系统”的主要开发方式。这样的系统的一个主要特点是它在架构上的确定性，与之对应而又匹配的，则是其领域集中的运作模式也相对确定。

但我们是在讨论复合领域集的问题。尤其其关键核心在于：由领域集构成的业务模式(犹如产业链等)是可能变化的，甚至是变化频繁的。一如本章最开始所讨论的，我们将“面向时间需求与空间需求”来进行架构，以应对这种持续变化。更进一步地，“变化”本身也只是需求，背后真正的问题——架构的本质问题，其实是对系统性的维护。

总的来说，可以将此前提及的种种思想归于在这一问题下的求解。例如，以架构形成的一般过程为参考，或架构以平台或框架为方向，或架构对战略的响应，等等，这些无一不是在讨论这样一个问题：架构需要提供何种程度的持续性，以使得它能够应对系统在构建和应用过程中的变化——并在这些变化之下保持“系统整体的一致”?抛开上述这些具体方法，直面问题本身，那么架构规划也可能是另外的一种求解思路。仍以办公系统为例，从中长期来看，开发方推广该产品会存在一些明显的阶段。例如：□在早期可能应用方单一，所以系统功能明确，针对性强而定制性弱；□在一段时间之后，系统的应用方就多了，但缘于业务开展的情况，所以用户大多数都在类似行业当中，因此功能的定制性要求虽然强了，但其领域性仍比较单一，并且大体的使用流程和现场问题都类似；□再后，开发方可能要求该系统平台化——这基于两点要求，其一是业务推广开始面向通用领域，其二是功能的大量增加导致系统过于复杂；口最后，整个系统还可能走向跨平台的方向，例如面向不同的终端(如手机),以及加入不同的设施(如办公室签到设备),或者跨地域的办公等。

我们可以对这些阶段作出规划。首先，不同阶段的系统重点是不一样的，如表4-3所示。

□高可靠性，以及降低错误口战略推进与系处理成本统规划的同步□快速集成与完整的问题测试口丰富的接口，以应对基于平台的内部与外部开发当我们将当前系统的目标与上述规划对应时，就很容易锁定我们“应有的”架构意图，并且能够通过阶段规划，来促使当前的架构意图契合业务方向对架构的要求。例如，就办公系统而言，我们可能设定为：架构一期，快速实现的市场探针性产品。yipindushu.com

基于这样的设定以及对其后的持续性的考虑，我们就有了进一步的架构决策。例如：□宜通过使用现有的成熟系统来搭建运行环境，加强现场团队的实施能力来解决客户的现实问题；强化现场团队的反应能力、反馈能力，对发现问题的敏锐度，以便更加准确地收集与响应客户需求。

□宜通过敏捷开发团队的模式来实现产品功能，可以考虑让客户直接参与测试过程(例如试用或小范围测试),可以直接向客户提供alpha版本。可以考虑客户配合的现场调试环境。口简化产品化特性，例如说明书或安装包。

因此，在这个阶段的架构上，对集成性、重用性、移植性等的考虑就会非常少，类似集成架构、功能架构等的实施也可以很概略。

但是从架构的体系性上来考虑，即使在最初阶段的架构中，也不能缺少对后续架构阶段的设定。这至少包括两个方面：其一，后续架构阶段的启动条件；其二，后续架构过程“在当前架构中的”入手点。