我看到很多关于构建与购买的问题和讨论，但大多数人都坚持简单的方法，您可以简单地做一个或另一个。大多数时候，您必须购买和集成或自行构建。无论哪种方式，你都在做一些工作。
在接下来的 30 到 60 天内，我需要实施几个管理项目，以防止每个人都扯掉头发并互相残杀。其中最大的是票务系统（电子邮件、支持请求、自助服务等）。
不乏选择，但最终我们必须购买我们决定使用的任何东西，添加我们所有的客户及其用户，并确保我们随着时间的推移保持同步。我们还必须提供单点登录并进行一些设计工作，以使其看起来像是我们从头开始构建的。
如果我们构建我们可以跳过集成的痛点，尽管功能集有限（但重点突出）。
在做出这样的决定时，您通常会分析什么？如果有 4 到 5 个系统可以很好地完成一项特定的工作，还是有一个可以完成所有工作的单一系统更好？
【问题讨论】：
标签： estimation
您发现了一个关键问题 - 当您购买时，您仍有工作要做，而且可能还有很多工作要做。话虽如此，我每次的总体倾向都是购买。编写代码很难，调试代码要困难得多——当你购买时，你购买的不仅仅是代码/应用程序，你购买的是它可以工作的事实——后者是 90% 的收益。
但是，由于您的需求非常普遍，为什么不使用开源。这有两个突出的好处。
1) 由于您可以访问源代码，因此您可以随意使用它 - 即无需在现有系统的顶部添加单一登录。定制登录模块以使用您现有的基础设施，因此无需保持同步、节省时间、干净的方法等。许多开源通过组件化（？）那些无论如何都是特定于环境的方面来承认现实世界。它们通常与 DB/Identity 无关。
2) 如果您明智地选择，您将拥有一群已经了解系统的顶尖技术人员随时准备提供帮助 - 唯一的问题是他们不适合您（现在！）。
我的建议是选择一个您的简单目标 - 票务系统似乎是一个，分析开源世界中满足您大部分/所有需求的内容。评估并在Rent A Coder 上提出任何所需更改的请求。坐下来等待结果，希望结果很好。你浪费了一点时间，收获了很多经验。
开源不等于 Linux/Unix - .Net 也有很多好东西。
【讨论】：
一个系统更适合以下情况：
一个数据存储库（即数据库）
将每个系统链接在一起的简单方法，进行交叉引用。无需构建中间导入器/导出器/同步器
允许单次登录。这在企业中非常有用，可以确保每个人都知道在哪里可以找到正确的信息。所以更多的是“再次用于错误跟踪的站点是什么......”并不是每个人都会在大部分时间使用所有工具，他们会忘记如何访问甚至使用。
一切都具有相同的外观和感觉
节省培训
维护成本更低。一切都是一样的更新。管理员不必专门研究单独的系统。
但是……显然你被你买的东西困住了。如果可以的话，请确保获得一个可以构建自己的插件的系统，以使其与您的业务模型相匹配。
【讨论】：
显然“视情况而定”。我的一般规则是，如果它是内部的，我们会购买它并在需要时进行集成。如果我们的公司系统管理员遇到问题，并且我们的开发人员负担不是一个庞大的项目，我们的公司系统管理员会向我们组织外部的人提供支持。
如果它是我要交付的产品的一部分，我会根据需要构建它或从开源库中获取一些源代码。没有什么比别人的黑盒代码破坏你的产品更糟糕的了。恕我直言，运输产品中的依赖项越少越好。
我倾向于购买您提到的支持产品。好的功能为共享身份验证系统、面向用户的主题以及您的客户服务团队可能尚未意识到他们想要/需要的大量功能提供了很好的集成点。
但是，要分析什么。对于像这样的“管理”项目，对我来说最重要的是机会成本。我的团队还能做些什么来让我们的公司赚更多的钱，让我们获得更多的客户，等等？当然，这些项目对底线有一些积极的影响，但与新产品、改进产品等相比没有什么。随着时间的推移，包括维护在内，开发人员/产品经理/测试人员会在这个管理项目上花费多长时间？如果您购买，集成点不会经常更改，但如果您构建，您的客户（内部人员）将不断要求新功能，您将能够在您的剩余任期内维护该项目。
【讨论】：
买？你说的这个买的是什么，陌生人？
说真的，我已经很久没有为自己的项目购买软件了。我所有的开发工具都是免费的，我所有的第三方库都是免费的（不是 GPL）。甚至我的操作系统也是免费的。出于测试目的，我必须为 Windows 付费，但大部分工作都使用跨平台工具。
任何需要免费工具或库中无法立即获得代码的东西，我要么从头开始编写（所有算法都可以在网络上免费获得），要么使用我的（因为我太老了）sn-p 库多年来我一直在添加源代码。
购买（“获得”）几乎总是比构建更快，除非购买的东西太糟糕以至于集成是一场噩梦。这可以通过避免来自几乎没有业绩记录的供应商的最新奇闻异事来缓解。
【讨论】：
您的要求越“标准”，购买就越合适（或者换句话说，不要重新发明轮子）。相反，您的要求越独特，您可能考虑构建的越多。
您非常正确地指出，即使在购买时也往往会进行一些定制。请记住，任何自定义都会在每次升级/修补时花费您。我建议，如果您的要求接近您可能购买的其中一种工具所支持的业务模型，那么您认真考虑将业务流程重新调整为供应商标准。如果这不可能，请询问您是否购买了正确的工具。
我会建议，如果有人出于成本原因建议建造它，那就尖叫吧。以我的经验，购买成本是众所周知的，而建造成本却很隐蔽。请记住，您将决定在应用程序的整个生命周期（商业应用程序的平均 7 年）内继续编码，但在决定购买和构建时可能只考虑初始开发成本。
我非常喜欢单一的单体数据库，但有时这并不可行。更重要的是拥有“单一的真相来源”；如果您有多个数据库保存类似的数据，请选择一个作为给定数据的权威来源，并有一个流程来维护与该来源一致的所有其他数据库。最好这将是自动的。
【讨论】：
处理所有事情的单一系统是用于许多企业应用程序的Raison d'être。然而，我发现，如果你不愿意支付一大笔钱，你就会遇到集成问题。
“最佳”解决方案是相当主观的，任何答案都是正确的，也可能是错误的，但如果我是王者，我可能会选择适合的根深蒂固的开源解决方案，并将 Web 服务包裹在需要相互交谈的项目。如果我是国王。
作为切线点，您无需担心购买免费票务系统，例如 RT（等）。
【讨论】：