architecture - COTS 与定制/构建与购买 : Decision Tree and Best Practices

Question

背景:

我在一家拥有大量 SAP 投资的公司工作，我们还有数十个大型 .NET 系统(主要用于内部工程系统)和 Java 平台(主要用于外部 Web 应用程序)。因此，我们在 ABAP、C# 和 Java EE 上拥有大型开发中心。

问题:

简而言之，我们需要一种更好的方法来确定何时应使用商业现成 (COTS) 软件，以及何时应利用我们自己的开发人员。

标准:

我想根据最佳实践构建一个决策树来帮助解决这个问题。

在最高层面上，Jeff Atwood 的相关帖子对此进行了很好的总结:The Best Code is No Code At All

再深入一点，我希望看到如下标准:

是否有可以满足大多数要求的 COTS 系统？(如果是，COTS 系统可能是一个不错的选择:(避免重新发明轮子))

• 如果有，是否有完全公开的 API可用的？ (这对于集成/定制)
• 如果有，源代码可用吗？(这对于深入集成/定制)

系统的设计是为了满足核心业务功能/创造竞争优势吗？(如果是这样，定制开发可能是一个不错的选择:See Joel Sposky's: In Defense of Not-Invented-Here Syndrome)

• 如果是这样，定制开发是否允许用于将来代码重用/其他系统？ (有很多优点重用现有代码)

定制应用程序与 COTS 产品的 TCO 是多少？

是否存在定制开发无法满足的时间限制？(如果是，COTS 系统可能是一个不错的选择)

Answer 1

我不完全确定您的要求，但我想我应该对多年来我在 COTS 与自定义开发选择中看到的一些事情发表评论:

1. 正确分析任何 COTS 系统的适用性都需要时间。无论是从需求角度还是技术角度。有多少定制开发可以代替分析？

2. 请注意 COTS 销售宣传中的“棒上月亮”的 promise 。有很多。唯唯诺诺的人会做出华而不实的演讲，他们会提出满足任何要求以达成交易。最危险的陷阱是 promise 目前 COTS 中没有的功能，但他们会为您添加 - 通常情况下，销售人员已经对您说"is"，甚至没有弄清楚他们的产品是否可以做到这一点它。

3. 检查 COTS 中的单元测试以及它们使用的开发实践。良好的质量指标。牛仔开发实践，缺乏测试和文档是 future 可维护性的难题。

4. 如果 COTS 供应商没有提供有关其产品技术方面的大量信息，请务必小心。

如果您想要的系统相当简单，那么您的 COTS 选择也将相当简单。但如果它是一个大型、复杂的系统，您可能会将其提供给 RFP(征求建议书)，为此您必须拥有全面且正确的需求规范。生成 RFP 需求所需的时间是否会比定制开发敏捷解决方案更重要？您必须非常严格地确定这些要求，以确保 COTS 系统能够交付，这将需要大量的时间和精力。

就我个人而言，我绝不会考虑 COTS，除非:

1. 源代码已提供，并且我已经让程序员对其进行了评估
2. 我看过并尝试过一个有效的演示，而不仅仅是华丽的销售宣传
3. 内部没有时间或人员来完成这项工作。

最终，我同意 Joel 的说法:如果它是核心业务功能 - 无论如何都要自己做。