《系统架构：复杂系统的产品设计与开发》——第3章，第3.2节系统中的复杂度

本节书摘来自华章出版社《系统架构：复杂系统的产品设计与开发》一书中的第3章，第3.2节系统中的复杂度，作者[美]布鲁斯·卡梅隆，更多章节内容可以访问云栖社区“华章计算机”公众号查看

3.2系统中的复杂度
3.2.1复杂度
如果系统中有很多互相关联、互相连接或互相混杂的实体与关系，那么该系统就是复杂的（complex）（参见文字框3.1）。笔者在当前所下的这个定义中，故意使用了一个含义较为模糊的词，那就是“很多”（many）。
文字框3.1　定义：复杂的系统

复杂的系统，是由很多高度相关、高度互联或高度混杂的元素或实体所组成的系统。
系统之所以变复杂，是因为我们对系统总是有“更多的要求”：要求系统有更多的功能、更好的性能，要求系统更加健壮、更加灵活。系统变复杂的另一个原因，在于我们要求本系统要能够与其他系统相互协作、相互连接，例如我们要把汽车与交通控制系统相连，要给屋子接入互联网，等等。
复杂的系统需要用大量的信息来指定并描述。因此，某些复杂度指标是根据系统的描述信息中所含的内容来制定的。此外，还有一些复杂度指标，想通过对系统所做的事情进行归类，来衡量系统的复杂性，这是基于功能的复杂度衡量法。
一个与复杂一词紧密相关的概念叫做难懂（complicated）。要认定某物是否难懂，应该考虑该物的复杂度是否超越了人类有限的观察和理解能力。第2章所说的那些系统都不难懂。我们只要研究几分钟，就可以较好地理解它们。难懂的事物具备较高的表面复杂度（apparent complexity）。它们之所以难懂，是因为其超出了人类的理解能力。
应对复杂度并不是新鲜的事情。实际上，在古罗马时代，人类就经常构建复杂的系统（例如大型的供水网络）。然而，在20世纪中，系统及其运作环境的复杂度出现了激增（对比一下1900年和2000年的电话）。这种极度攀升的复杂度几乎超越了我们对系统的理解能力。
架构师的工作是训练自己的思维，用它去理解复杂的系统，令那些系统不再那么难懂。我们应该努力构建易懂的架构，使得在该系统上工作的其他人员（例如设计者、构建者、操作者等）可以较为容易地理解这个系统。
设计一套良好的系统架构，实际上可以归结为：构建一套具备必要的复杂度同时又不难懂的系统。

3.2.2引入Team XT这一范例系统
本章以Team XT作为我们要分析的范例系统，该系统是针对第2章的Team X系统所做的扩展（extended，XT）版本。新团队的角色仍然是制作设计方案。对Team XT来说，Team X团队中的实体以及实体之间的关系同样有效，但是我们还要考虑更多的细节。笔者之所以选择一个较为复杂的组织作为研究案例，是因为许多读者可以把这种组织与自己工作时所在的组织联系起来，而且还可以把本章所述的系统思维经验，直接运用到这些组织中。
假设我们走进某公司的一间办公室，并结识了Team XT团队。那么，现在可以就运用第2章所说的方法，开始问第一个问题：“系统是什么？”这个问题的答案与第2章相同，Team XT系统也是由一组人员和一套过程所构成的，这套过程就是研发设计方案。接下来，我们要问该系统的形式是什么。对Team XT来说，其形式就是每位团队成员的总和。第三个问题是系统要完成什么功能。功能是指系统所要做的事情、活动或转换行为。Team XT系统的功能是研发设计方案。思考完这三个问题之后，我们就完成了系统思维的第一项任务（参见文字框2.3）

从Team XT的形式上来看，如果我们认定其中的实体是各位团队成员，那就要通过仔细的观察、广泛的经验或是与每位成员进行谈话等手段，来确定这些实体各自的功能。我们把分析好的成员功能列在表3.1的第3列中。每一个功能都具备操作数与过程。根据第2章中所说的步骤，我们用整体思维（参见文字框2.5）把对系统可能有重要意义的实
表3.1　Team XT系统全图。该系统是Team X的扩展版，它的角色是研发一套工程设计方案

体全都找出来，然后划定系统边界（参见文字框2.6）

图3.1　Team XT的功能及功能交互

表3.1最右方的那3列是形式结构。从地理位置上来看，某些团队成员在剑桥，其余的成员在莫斯科，这体现在右起第3列中。为了促进团队成员之间的交流，他们会使用一些软件工具及相关的数据库来进行沟通。这是一种连接关系，体现在右起第2列中。最右边的那一列呈现了一种报表式的结构。那些关系是人事关系，它们本身并不反映交互情况。形式关系可以分为很多种类，我们将在第4章中详细讲解。
系统思维的第四项任务是确定系统的涌现属性，下面几节将会讲解思考复杂系统所使用的工具，当我们选出适当的工具并将其运用到所要应对的系统之后，就可以更加清楚地判断它的涌现属性了。