①领域产品、客户项目、通用应用与自用系统，这些都因涉及的系统对象(及其用户、用户的认识)的不同，而导致对它们的架构过程不同。在这里讨论的主要是：当我们需要去提供一些领域产品，而对该领域又并不十分清晰的情况下，我们可以依赖哪些“信息”来构建事实并进一步地提出架构意图。这其实也可以应用于当前系统与现实系统由于高速发展而暂时性地失去方向的情况——它们都处于一种类似“三岔口”的局面中，需要重新的选择与定位。

②就是这样日复一日，行走得如同一具木偶?木偶总是在“一如既往”地满足着需求，但它并不清楚这究竟是带来了提线人的快乐，亦或是观众的快乐，或者他们是否真的快乐。然而，这就是“行进于一个过程，而忽视目标”的工程活动的本相。

我们的软件开发活动向来是从对需求的分析开始的，经过设计、开发等过程，最后交付和维护。这一过程是如此的自然，因而我们将它从历史的开发活动中“识别”出来之后，立即被看成是软件工程作为一个成熟概念的标志①。然而在上述场景的后半段，我并没有立即陷入对“(能或不能，以及具体如何)满足需求”的挣扎之中，我从Soul的需求中回溯到整个系统所面临的问题：“要一个苹果”是因为饥饿吗?②如果真实的问题是“在这个早晨，Soul饿了”,那么饼干、馒头甚至一杯早茶都可以解决他的问题。为什么一定要去满足“一个苹果”的需求呢?可见，我在这后半段中所经历的，其实是图4-10所示的另外一种思维模式。亦即是说：我们可以暂时将“满足系统需求的急迫性”放在一旁，而去寻求“究竟是什么问题导致了这些需求”。当我们看到了问题，也就同时看到了解的抽象。

煮一枚鸡蛋真的是一个需求吗?当我们把煮鸡蛋视为一个系统的时候，一切前设都既成定局：我们只关注于一枚鸡蛋的生熟与安全，而并不关注“究竟是什么”导致了我们要去煮一枚鸡蛋。同样的问题被放大无数倍之后，我们也只是关心一锅鸡蛋与一枚鸡蛋的煮法的异同。我们往往在做一些具体行为的时候，忘掉了它的源起，这便如同《大道至简》中谈到的愚公一家，数百年的移山工程结束之后却不得不去筑关自守。

需求不是问题，但需求是问题的表现。例如，Soul的问题是饥饿，而表现却是需要一个苹果。我们所关注的系统大致也是如此，它可能表现为一系列直接的需求，因此我们可以从需求中找到事实或直接获得战略设定；它也可能表现为一些看似无关的间接需求或间接问题，在这些表面现象的背后，总会有一些核心的问题是它们的真实动因。yipindushu.com

“真实动因”是一个关于“找到问题”的极佳设问。通常，我们对需求的描述都①由W.W.Royce在1970年于论文《管理大型软件系统开发》中提出的、从需求开始的、基于“瀑布模型”的软件工程活动，他事实上是提供了软件开发的基本框架。②正确的问题是：要一个苹果的“原因”是什么。而“是因为饥饿吗”则是对该问题求解的一个设问。

是“谁，做什么”,接下来是一些限制条件，例如“在哪里做，如何做”①—这是我们一般性的需求分析方法。而在这些行为中，提出“原因”这个疑问，就是为这一需求找到它的动因。当我们的多个需求都指向相同的、相类似的动因时，我们就已逼近核心问题——我们最终缺乏的，仅仅是将这些动因归纳成问题而已。

什么是问题?问题有两个形态：其一，若系统存在某种“一般过程”,则阻碍这个一般过程的，必然是核心问题；其二，若系统存在一个确定的观察者，则所谓问题，就是这个观察者的期望与现实之间的差异②。换作精炼一点的描述：所谓问题，要么是系统与其要素之间的矛盾，要么是观察与其预期之间的矛盾。我们在系统中引入了一般过程与观察者，前者是“导致问题”的内因，后者则是其外因。系统的不变性，一般来说是由前者决定的，所谓平衡，即是在这个一般过程的要素之间的、时间与空间上的权衡；系统的变化往往是后者导致的，亦即观察者——例如经营角色或主管—-对于系统的期望缺乏一贯性。