分布式应用软件的优势在于这项技术是如此的灵活，使得几乎所有的公司都可以与其他公司进行挂钩，并创建对双方都有用处的数据交换。它的不足在于这样的应用软件出现故障的几率则要大得多。
为一个ERP环境设计健全的应用软件是很困难的，在这里多个数据源都被用于为用户即时创造实时记录。要将应用软件在商业领域中进行扩展并超出公司的界限就更加地困难。设计并实现一个让国内和国外的用户都感到满意的应用软件，特别是一个实时应用软件，是一个相当大的成就。但是如果你没有考虑到出现故障的可能性，你就只做到了一半的工作。
有没有人还记得Tinkertoys？他们设计了一套很棒的木制建筑部件和塑料的连接插头，孩子们可以用它们来建造出任何东西。这种灵活的部件可以让你在你所建造的东西上不断地增加部件，直到它无法承受自身的重量而倒下来。
J2EE，Web服务，.NET和所有相关的事物都存在着类似的问题。现在，创建一个独立于平台的应用软件，将其分布在所有公司的商业伙伴之中，让它服务于多种数据源，给每个用户提供一些完善的功能，这样做已经是可行的事实。而要建构这样的一个应用软件，所需的成本只比在五年前建构一个单用户，单数据库的应用软件所需的成本稍高一点。
就像Tinkertoys玩具一样，为此我们所付出的代价是，太多的地方会出现故障。这造成了一系列的问题，其中每一个都比在传统形式的应用软件中的问题更加严重：
这个结果确实很糟糕。我们该怎么办？这里有一些办法，不过你必须事先对他们进行考虑，而且最好与其他相关的团体进行协作（特别是用户）。
还记得一个叫Get Smart!的老电视剧嘛？里面有个叫Don Adams的特工人员，他要穿过一系列的门进到电话亭中才能被带回到特工人员的秘密总部。在一个分布式应用软件中，特别是存在于互联网上的那种，数据就要穿过这样的一系列的门。如果任何一个门没有能够打开，数据就无法到达，应用软件就会出问题。因此你必须对每个门进行确认并将其视为一个可能的障碍。
当面对不熟悉的数据传输技术或依靠于外部的服务供应商时，这一点并不是很容易做到的。你要做出额外的工作，深入探查什么样的问题会影响你的应用软件。如果你使用行销商所提供的软件，你无法对其进行控制，你也可以进行类似的工作并找出它所存在的弱点，同样列出这些可能的故障点，故障点的跟踪应该包括从源数据库的起始点到用户端之间，数据出现的每一个点。
