什么构成了总体拥有成本 (TCO) 呢？这很难说，每个人都有不同的答案。通常取决于他们找到的最方便解决问题的方法。大多数人都同意 TCO 并不只是组成系统各零件价格的总和。最初是这样，但到最后大部分成本来自支持环境中的系统的成本。一种受欢迎的减少 TCO 的方法是尝试集中管理独立系统、客户台式机或这两者，但这也只是答案的一部分。最好将通信量减到最小，但实际上是什么导致需要管理呢？当然，答案是变更。但不在于它本身。孤立的变更只会影响变更本身。我们都知道变更系统的一部分会导致遍及整个系统的支持需要。
普通的计算机系统通常会导致“熵死亡”，即成本超过预期值，而有序的简易性会变成互连复杂性。治愈这种症状的方法可能是集中管理，实际弊病将避免具有依赖性的复杂网络放在首要位置。Java 和 XML 通过帮助排除系统、软件和数据之间的自动互相依赖性来避免这种情况的发生。
一个新世界
大多数支持和管理的需求来自由计算机上的软件交织成的具有依赖性的网络。要重新获得简易性，我们需要除去依赖性。依赖性都存在于何处呢？有以下几种分类：
要解除这些依赖性的束缚并不容易，但十年来逐渐发展起来的计算新世界最终日趋成熟并使之成为可能。
让我们首先考虑已经在忍受的计算模式。当计算处于起步阶段时，很容易做出选择。我可以获取任意一种有限范围的计算机，编写在这种计算机上运行的软件，并创建用来存储数据的文件格式。麻烦是软件和数据只能在这种计算机上工作，使用另一种计算机时，就必须使用另一种软件，或者在同一种计算机上使用另一种软件时，就不能使用相同的数据，而且必须了解新的用户界面。
通过两个标准化步骤可以解决许多问题：许多人开始使用 IBM PC，最初使用 DOS，然后使用 Microsoft Windows。一定程度的简易性回来了。但随着时间的流逝，却越来越清楚地发现许多范围的复杂性仍然悄悄地混了进来。特别是，对平台的认可并没有打破软件的平台依赖性；这恰恰意味着它完全是互相依赖的。因此当更新发生时，一切可能破裂！另外，数据世界的垄断力量并没有标准化。就像软件依赖于特定级别的平台，数据也与特定级别的特别品牌软件相关。于是就交织成具有依赖性的复杂网，在其中任何一点所做的更改都可能导致不稳定，也许还会引起整个网络的崩溃。
互相依赖性
计算的头号敌人是无心造成的互相依赖性。在构建计算机解决方案时，它们都涉及到软件、硬件、平台以及开发工具等之间的关系。它们之间都通过看不见的具有互相依赖性的连接线索连接起来。随着时间的推移，拥有任何解决方案的成本与所支持的各部分间的依赖性数量成正比。但因为有了许多无心创建的互相依赖性，成本将以指数级增长，而不是线性增长。其结果就是更多的互相依赖元素所引出的附加成本可能会不成比例地增加终身成本。这种不成比例增长的起始点叫做冲刺点，而冲刺点以上的情况就叫做熵死亡。在冲刺点之前，就已经通过选择具有互相依赖性的系统原理、系统中一部分对另一部分的无意依赖（可能是由其它元素引起的）为熵死亡打下了坚实的基础。最常见的无意互相依赖性存在于软件和其宣称的操作系统之间。
这并不是说可以或者应该避免所有互相依赖性；有一些互相依赖性是不可避免的。但在现代系统规范和设计中，应该用与其它成本驱动因素相同的方法来标识和调整它们，请注意图 1 中不仅显示了直接成本，还显示了连接到具有依赖性的网络的终身成本。通常，需要将软件与使用它的环境隔离开。在某些情况下，使用本机接口和二进制是不可避免的，但在这些情况中本机代码外围的平台无关的“封装器”几乎总是有价值的。
图 1. 成本 vs. 节点数量
例如，假设一家公司使用办公套件的宏语言作为办公自动化系统的基础。一天，公司的 IT 小组安装了另一套软件，并无意中更新了办公套件所使用的一个 DLL 文件。他们发现有一个宏不能使用了。经过了大量工作以后，他们设法使这个宏再次工作，但新版本要求使用电子表格程序的更新版本。为了使用该程序，他们不得不安装办公套件的全新级别，而在那以后所有宏都不起作用了！接着，他们逐个调试所有宏，更新并修复它们。在这些修复所涉及的其它部分中，他们发现需要使用一个数据库驱动程序的新版本。可悲的是，那需要使用最新版本的数据库。于是，他们升级了数据库，并且……，哎，您可以猜得出其余部分。
本类阅读TOP10
