自定义自动化vs商业现成的，或者两者都有?

如何自动化和何时自动化同样重要。习俗不是一个简单的词。权衡COTS和定制解决方案的好处，而不是将自动化项目的视图限制为COTS或定制解决方案。不要认为自定义解决方案很糟糕。请参见图解。

通过科里Stefanczak 2013年8月21日

在过去的十年中，系统集成业务一直在向“通用一切”的方向发展。客户正在寻找一种简单的“一刀切”解决方案:易于购买、安装和维护。普通现货或商业现货(COTS)产品延续了一个解决方案来满足所有需求的想法。COTS提供了一行购买项目，承诺可以轻松满足客户所需的所有功能。

不幸的是，这个承诺不能通过“通用一切”的方法或者仅仅通过COTS来实现。除了简单的系统集成项目之外，这种方法通常是不可行的，并且可能导致为了通用性而做出糟糕的决策。通常，缺乏对成功的系统集成项目的理解是导致这些决策的原因。

因此，“定制”一词在业内名声不佳。顾客会因为各种各样的原因而放弃任何定制的东西——其中许多都是毫无根据的。本文研究了这些原因，试图说明所有的系统集成项目都需要一定程度的定制，并且定制产品和工作是成功的必要选择。

我们是怎么走到这一步的?

纵观工业自动化的近期历史，当前的共性趋势可以被视为对过去市场状况的回应。20世纪80年代和90年代充斥着专有软件和硬件，迫使客户在没有追索权的情况下做出决定。客户必须选择一个特定的平台并坚持使用它，因为竞争对手之间没有互操作性。如果您选择的产品线中没有提供您想要的功能，那么您就不走运了。而且，由于基础设施已经到位，无法与不同的平台兼容，因此更换竞争对手的产品成本太高。

这些条件导致了客户的强烈反对，改变了该行业走向市场的方式。客户需要竞争对手产品之间的互操作性。产品供应商建立并采用了通用的开放协议来支持这项工作。在20世纪90年代后期，OPC(用于过程控制的对象链接和嵌入)的发展创造了一种相对便宜的选择，允许在专有系统之间或之间进行通信。

客户现在可以为工作选择合适的产品，并确信新产品可以与基础设施的其余部分以及任何先前的投资进行通信。不幸的是，这种开放性导致了意想不到的副作用。

首先，顾客可以选择任何满足他们需求的产品。于是他们照做了。现在，一个设施可能有十几个或更多的产品平台需要使用不同的工具来支持。这给操作和维护部门带来了异常沉重的负担。

最成功的系统集成项目使用COTS和定制方法来最好地适应客户的即时需求和未来需求。

其次，任何人都可以编写自己的软件来与任何过程控制产品进行通信。于是他们照做了。客户开始在内部开发软件，或者从无法得到支持和维护的不合格的开发人员那里购买软件。

2005年左右，钟摆开始向另一个方向摆动。客户通过使用一个可以由内部员工维护的平台来纠正这些错误，并且只购买在该平台上工作的COTS产品。客户开始这样做，而不管产品是否能满足相关应用的功能需求。更重要的是维持可持续性的“共同一切”愿景。

在下一页，了解更多关于“定制”的误解，并看到两个图形示例

对习俗的误解

这些行业事件导致了今天共同关注的方法。然而，人们并不很清楚为什么“普通”与“习惯”不同，甚至不清楚这些术语的含义。随之而来的是对COTS和定制的误解。

FALSE: COTS表示非定制。这可能是系统集成最大的谬论之一。客户相信通过购买COTS产品，不需要执行任何定制的工作。这很少是正确的，即使是简单的项目。

没有任何COTS产品可以在没有任何定制的情况下完全“开箱即用”。供应商经常使用“配置”这个词来代替“定制”，以减轻与定制相关的恐惧。无论如何，这仍然是专门为客户执行的自定义活动。在简单的情况下，定制工作可能包括修改产品参数。对于更复杂的用途，这个过程通常要复杂得多。这可能包括为监控和数据采集软件编写脚本，为可编程逻辑控制器开发逻辑，或为桥接系统编写自定义通信组件。

基于产品供应商提供的产品，COTS产品的定制显然是必需的。几乎每个主要的COTS产品供应商都维护一个系统集成组，其唯一目的是定制产品以满足集成需求。

FALSE: COTS表示标准和可支持。几乎所有的客户都能回忆起这样一个例子:一个积极的员工生产了“定制”的软件，提供了巨大的价值，但没有原来的程序员就无法维护或升级。这将导致不可避免的操作崩溃，当程序员是不可用的，无法联系到支持软件。

对这种情况的恐惧常常驱使客户使用COTS产品，并相信产品本身将提供标准化和可支持性。不幸的是，事实并非如此;COTS产品是高度可定制的，并且可能导致所描述的相同问题。

Microsoft word就是一个简单的例子，它是使用最广泛的COTS产品之一。如果没有用户的输入，它什么也不做。用户必须自定义其输出以生成任何有价值的文档。例1和例2是同一文本。

第一个示例说明了文档的标准格式。第二种是没有标准的文档。Word的哪个部分禁止用户生成这两种文档?绝对没有。这表明像Microsoft Word这样的COTS产品实际上不能提供标准化或可支持性。

事实上，标准化和可支持性更多的是过程和规程的功能，而不是执行开发的产品。使用标准模板、指定的指导文档培训和评审过程实际上会产生标准的和可支持的输出——而不是COTS产品本身。

组织需要适当的过程和程序来支持任何系统集成工作。这同样适用于定制开发的软件应用程序和COTS产品。

歧视SE:定制意味着专有。唯一一个比“c”字更让顾客害怕的词是“p”字:专有的。“定制”和“专有”通常被认为是密不可分的。在过去，这可能是正确的，因为使用开放和标准通信提供定制解决方案的能力是困难的。但是，自从采用开放协议和OPC以来，很少能找到建立在专有基础上的定制解决方案。

关键是要确保定制软件和COTS产品的非专有产品是相同的。客户必须确定这是他们需求的一部分，无论是采购开发还是购买产品。

专有系统之所以令人担忧，主要是因为客户可能会被锁定在特定的产品上，而无法切换到竞争对手的产品。在过去，这是一个与技术相关的限制。今天，合同在限制客户改变平台或增强系统的能力方面发挥着至关重要的作用。在大多数情况下，理解COTS产品的这些方面比理解定制的解决方案要困难得多。客户必须评估许可和支持合同，以确保COTS产品不会禁止系统或平台的扩展。

在最后一页，了解恐惧如何影响决策，以及如何利用COTS和定制

恐惧会导致糟糕的决定

这些谬论会使客户仅仅基于对“定制”的恐惧而做出糟糕的商业决策，并允许客户被COTS产品所做的承诺所诱惑。基于cots的项目失败有两个主要原因。首先，客户要么不理解COTS产品的限制，要么愿意接受这些限制，以坚持“通用一切”的愿景。客户通常在他们最初的、相对较小的部署中看到成功，但是发现将系统扩展到具有不同需求的其他功能区域或设施是具有挑战性的。

系统集成商应该评估组织的需求，并根据这些需求提供最佳解决方案，而不是根据他们销售的产品。

其次，客户没有为COTS产品所需的维护和支持做好充分的计划。同样，这个问题在第一次部署时并不明显。然而，随着系统的发展和COTS产品的定制部分需要修改和配置管理，客户开始看到版本控制和支持方面的问题。

利用COTS和定制

最成功的系统集成项目使用COTS和定制方法来最好地适应客户的即时需求和未来需求。为了实现成功的系统集成，客户及其顾问必须:

理解COTS和定制是可行的和必要的选择。在不了解组织当前和未来需求的情况下，不要将系统集成项目限制为COTS。一定要认识到任何COTS部署将如何针对这些需求和与产品所有方面相关的支持需求进行定制。如果需求是唯一的，那么就评估定制解决方案的优点。
决定什么是通用的，反过来，什么是可定制的。每个系统都应该有一组每个人都能获得的特性和一组每个部署都应该遵守的期望。根据业务需求预先定义这些。然后，决定功能区和设施之间的哪些特征可以不同。允许标准特性支持不同领域所需的“自定义”特性。
找一个技术倡导者。当寻找系统集成商来协助、部署和编程解决方案时，一定要找到技术倡导者，而不是产品供应商。系统集成商应该评估组织的需求，并根据这些需求提供最佳解决方案，而不是根据他们销售的产品。

通过将“定制”视为一个可行的选择而不是一个令人恐惧的词，客户可以做出更好的系统集成决策。将定制理解为项目的工具和必要部分，无论是COTS还是其他，客户都可以权衡COTS和定制解决方案的好处，而不是将他们的观点限制在COTS或定制解决方案上。

- Corey A. Stefanczak，高级系统架构师Leidos工程．他的主要关注点是帮助客户在大型分布式环境中统一自动化基础设施和信息系统。Stefanczak拥有16年的集成经验，通过在COTS组件和定制开发之间找到适当的平衡来帮助客户取得成功。CFE Media内容经理Mark T. Hoske编辑，控制工程，设备工程,Consulting-Specifying工程师,mhoske@cfemedia.com．

在线

www.saic.com/engineering

关键概念