包定制

IT 部门的一个常见问题是，是否应该通过构建定制软件或购买软件包来提供功能。自从我开始编程以来，关于如何做出这种选择的争论就一直存在。我对这个问题的基本立场是基于 实用性与战略二分法。简而言之，这意味着，如果您的业务流程是您的竞争优势的一部分，您应该构建定制软件；如果不是，您应该购买软件包，并调整您的业务流程以适应软件包的工作方式。

尽管我的观点非常出色，但似乎并没有很多公司这样做。他们经常忽视这种二分法，这是一个问题。但我在这里想重点关注的是，当他们购买软件包时会遇到的一个常见陷阱。

您会注意到，我在上面说“购买软件包并调整您的业务流程以适应”。我这样说的原因有两个。首先，如果您购买软件包是为了支持实用性业务流程，那么业务流程中就没有差异化——因此，您不妨以适合软件包的方式执行该业务流程。当然，这是一种非常以软件为中心的观点。尽管团队没有做差异化的工作，但他们仍然宁愿以自己的方式做事，而不是以一些愚蠢的软件包想要的方式做事。作为相信人胜于流程的人，我自然对这种观点很有同情心。

但这种自然行为的结果是，公司开始对软件包进行大量的定制……而这就是麻烦开始的地方。事实是，大多数软件包的设计并非真正适合定制，至少在很大程度上不适合。它们通常缺乏我同事 Scott Shaw 所谓的“可交付性”——比如对版本控制、测试和部署管道的支持。这使得更改变得脆弱且难以控制。

如果您的定制很小，您可以忍受这一点，但在许多情况下并非如此。最近，一位同事遇到了一种软件包定制，其定制代码达到了 300KLOC。这比我们 Studios 产品套件的整个代码库还要多，是我们在过去十年中为大型客户项目运行战略性业务的代码库的两倍。一旦达到这种规模，您就无法指望在没有用于定制软件的工具和流程的情况下进行管理。

当供应商发布您软件包的升级时，这个问题往往会变得更加突出，您会发现进行升级需要付出大量的努力，因为定制会随着升级而失效。Gartner 最近估计，将企业系统升级到最新版本需要 5000 亿美元（到 2015 年将达到 1 万亿美元）。这是一个很大的数字，但真正的成本是，有多少资金浪费在不值得的定制上，或者如果采用纯定制路线，这些定制的成本会更低。

那么您该怎么办呢？首先，我认为对于实用性业务功能的软件包定制，要保持一定程度的强硬态度。软件方面的成本真的值得吗？虽然敏捷方法对于实用性功能的影响较小，但采取小步骤的概念很有价值。您是否可以在最初不进行定制的情况下使用该软件包，并尝试看看它在实践中运行得如何？人们自然会对这种改变感到不舒服，因为人们天生就是这样。但经过一段时间后，他们可能会发现，他们认为很重要的事情现在变得不那么重要了。

我们可以更认真地研究如何进行定制。有些方法比其他方法更难交付。寻找其他人，他们在软件包的旧版本上做过类似水平的定制，并了解他们升级需要做什么。这可能有助于更真实地了解成本。总的来说，对于软件包，我们应该将可升级性视为一等跨职能需求。

当您让供应商定制软件包时，很难让他们遵循客户的交付实践。他们不遵循这些实践的风险很高，应在您的风险规划中予以考虑。

许多组织试图限制他们使用的语言或框架的数量。我们必须记住，许多这些可定制的软件包实际上是另一种语言或平台。因此，针对采用另一种语言提出的任何论点都同样适用于软件包定制工作。

事实上，反对引入新语言的一个常见论点是，这使得很难找到使用该语言的开发人员。这个问题通常在软件包中尤其突出，因为这些软件包通常提供的就业机会范围很窄。此外，许多软件包定制工作的性质会阻止有能力的人，这使得找到更习惯于多语言编程的优秀人才变得更加困难。可能是，雇用人员的难度所带来的成本可能高于使用软件包而不是在主流编程平台上进行定制开发的任何成本节约。

与其定制软件包，不如看看该软件包是否可以通过有效的 API 公开数据和功能，并为定制功能编写定制应用程序。人们通常不喜欢这样做，因为这意味着他们必须使用单独的应用程序来完成同一工作流程的不同部分。这可能是一个较小的负担，并且可以通过 Web 界面来减轻。供应商可能会让这变得很困难，因为它会减少锁定，但协作的便利性应该是选择与哪个供应商合作的重要因素。

但这里存在一个陷阱。定制的一个主要来源是在不同的供应商软件包之间进行集成。这是一个更喜欢单个供应商提供多个软件包而不是选择最佳供应商的重要原因。选择单个供应商可以更容易地进行集成，因为他们有兴趣将其做好。如果这是一个实用性业务功能，那么最佳供应商软件包的价值本来就很有限。

归根结底，软件包环境通常为软件开发提供了一个非常糟糕的平台。与许多人认为的相比，定制和维护这些软件包的成本要高得多。