You've identified a key issue - when you buy you still have work to do, and potentially lots of it. Having said that my overall leaning every time is towards buy. Writing code is hard, debugging code is much harder - when you buy, you're not just buying the code/application you're buying the fact that it works - the latter is 90% of the benefit.
However, as your needs are pretty common, why not go with open source. This has two stand out benefits.
1) As you have access to the source, you can bend it to your will - ie no need to lash single sign on over the top of an existing system. Tailor the login modules to use your already existing infrastructure, therefore no need to keep things in sync, time savings, clean approach etc etc. Much open source acknowledges the real world by componentising (?) those aspects which are environement specific anyway. They're often DB/Identity agnostic.
2) If you choose wisely you will have a ready band of top tech staff who already understand the system ready to help - the only problem is they don't work for you (yet!).
My advice would be pick one of your easy targets - the ticketing system seems like the one, analyse whats out there that in the open source world that meets most/all of your needs. Evaluate and put out a request on Rent A Coder for any changes that are required. Sit back and await the results, which are hopefully excellent. You've lost a little time, and gained a lot of experience.
Open source does not equal Linux/Unix - lots of good stuff for .Net out there too.
One data repository(i.e. the Database) Easy way to link each system together, do cross referencing. No need to build intermediate importer/exporters/sync-ers
Allows for single log in. This is very useful in businesses to make sure everyone know where to find the right information. So more "what was the site for the bug tracking again..." Not everyone will use all the tools the majority of the time, and they will forget how to access and even use.
Everything has the same look and feel Saves on training
Maintenance is cheaper. Everything is the same to update. Admins dont have to specialize in hear separate system.
But... obviously you're stuck with what you buy. Make sure to get a system if you can that you can build your own addins for, to match it to your busienss' model.
Obviously "it depends." My general rule is that if it's internal we buy it and integrate if required. Our corporate sys admin has a support line to someone external to our organization if she has issues and it isn't a huge project burdening our developers.
If it's part of a product I'm shipping, I build it or take bits of source as needed from open source libraries. There's nothing worse than someone else's black box code breaking your product. The fewer the dependencies in a shipping product the better, IMHO.
I'd lean toward buy for a support product like you mention. The good ones offer great integration points to shared authentication systems, user facing theming, and probably a boatload of features your customer service team hasn't realized they want/need yet.
But, what to analyze. The biggest thing for me when it comes to 'managerial' projects like this is opportunity cost. What else could my team be working on that will make our company significantly more money, get us more customers, etc? Of course these projects have some positive impact on the bottom line, but nothing compared to new products, improved products, etc. How long over time, including maintenance, will developers/pm's/testers spend on this managerial project? If you buy, integration points don't change often, but if you build, your customers (in house people) will be asking for new features constantly and you'll be in the position to maintain this project for the rest of your tenure.
Buy? What is this buy of which you speak, stranger?
Seriously, I haven't had to buy a piece of software for my own projects for a long long time. All my development tools are free, all my third-party libraries are free (not GPL). Even my OS is free. I have to pay for Windows for testing purposes but the majority of work uses tools that are cross-platform.
Anything that requires code not immediately available from free tools or libraries, I either write from scratch (all the algorithms are available for free on the web) or use my (huge since I'm so old) snippet library which I've been adding source code to for many years.
It's almost always quicker to buy ("obtain") than build unless the bought stuff is so crappy that integration is a nightmare. This can be mitigated by avoiding the latest whizz-bang stuff from suppliers that have little track record.
The more 'standard' your requirements, the better buying fits (Or to put it another way, don't reinvent the wheel). Conversely, the more unique your requirements the more you might consider building.
You quite rightly point out that even when buying there tends to be some customisation. Bear in mind that any customisation will cost you at each upgrade/patching time. I suggest that if your requirements are close to the business model supported by one of the tools you might buy that you serious consider realigning the business process to the vendors standard. If this is not possible ask if you are buying the correct tool.
I would suggest that if someone suggests building it for cost reasons run screaming. In my experience the cost of buying is well known and the cost of build is well hidden. Remember that you will be making a decision to keep coding for the life of the App (average of 7 years for a business app) but may be considering only the initial development cost when deciding between buy and build.
I have a strong preference for a single monolithic database but sometimes this is not workable. More important is to have a 'single source of the truth'; if you have multiple databases holding like data, pick one as the authoritative source of a given piece of data and have a process to maintain all others in agreement with that source. Preferable this will be automatic.
The monolithic system that does everything is the the Raison d'être for so many Enterprise applications. What I've found, however, is that if you're not willing to pay a buttload of money, you're going to have integration issues.
The 'best' solution is quite subjective, and any answer is as right as it is wrong, but if I were king, I'd probably go with the entrenched open source solution where it fit, and wrap web services around the items that needed to talk to each other. If I were king.
As a tangential point, there are free ticketing systems like RT (et. al.) that you need not worry about buying.
发布评论
评论（6）
您已经发现了一个关键问题 - 当您购买时，您仍然有工作要做，而且可能还有很多工作要做。 话虽如此，我每次的总体倾向都是购买。 编写代码很困难，调试代码则更困难 - 当您购买时，您购买的不仅仅是代码/应用程序，您购买的是它可以工作的事实 - 后者带来了 90% 的收益。
然而，由于您的需求非常普遍，为什么不选择开源呢？ 这有两个突出的好处。
1) 由于您有权访问源代码，因此您可以将其按照您的意愿进行调整 - 即无需在现有系统之上进行单点登录。 定制登录模块以使用您现有的基础设施，因此无需保持同步，节省时间，干净的方法等。许多开源通过组件化（？）那些特定于环境的方面来承认现实世界。 它们通常与数据库/身份无关。
2) 如果您明智地选择，您将拥有一支由顶尖技术人员组成的团队，他们已经了解该系统，随时准备为您提供帮助 - 唯一的问题是他们不适合您（目前！）。
我的建议是选择一个简单的目标 - 票务系统似乎是一个，分析开源世界中满足您大部分/所有需求的内容。 评估并在租用编码器上提出请求，以进行任何所需的更改。 坐下来等待结果，希望结果会很好。 你损失了一点时间，却获得了很多经验。
开源并不等于 Linux/Unix - .Net 也有很多好东西。
You've identified a key issue - when you buy you still have work to do, and potentially lots of it. Having said that my overall leaning every time is towards buy. Writing code is hard, debugging code is much harder - when you buy, you're not just buying the code/application you're buying the fact that it works - the latter is 90% of the benefit.
However, as your needs are pretty common, why not go with open source. This has two stand out benefits.
1) As you have access to the source, you can bend it to your will - ie no need to lash single sign on over the top of an existing system. Tailor the login modules to use your already existing infrastructure, therefore no need to keep things in sync, time savings, clean approach etc etc. Much open source acknowledges the real world by componentising (?) those aspects which are environement specific anyway. They're often DB/Identity agnostic.
2) If you choose wisely you will have a ready band of top tech staff who already understand the system ready to help - the only problem is they don't work for you (yet!).
My advice would be pick one of your easy targets - the ticketing system seems like the one, analyse whats out there that in the open source world that meets most/all of your needs. Evaluate and put out a request on Rent A Coder for any changes that are required. Sit back and await the results, which are hopefully excellent. You've lost a little time, and gained a lot of experience.
Open source does not equal Linux/Unix - lots of good stuff for .Net out there too.
一个系统更适合以下用途：
一个数据存储库（即数据库）
将每个系统链接在一起的简单方法，进行交叉引用。 无需构建中间导入器/导出器/同步器
允许单点登录。这对于企业来说非常有用，可以确保每个人都知道在哪里可以找到正确的信息。 因此，更多“再次进行错误跟踪的网站是什么......”并不是每个人都会在大多数时间使用所有工具，他们会忘记如何访问甚至使用。
一切都有相同的外观和感觉
节省培训
维护费用更便宜。 更新一切都一样。 管理员不必专门研究单独的系统。 维护
但是......显然你对你所购买的东西感到困惑。 如果可以的话，请确保获得一个可以为其构建自己的插件的系统，以将其与您的业务模型相匹配。
One system is better for the following:
One data repository(i.e. the Database)
Easy way to link each system together, do cross referencing. No need to build intermediate importer/exporters/sync-ers
Allows for single log in. This is very useful in businesses to make sure everyone know where to find the right information. So more "what was the site for the bug tracking again..." Not everyone will use all the tools the majority of the time, and they will forget how to access and even use.
Everything has the same look and feel
Saves on training
Maintenance is cheaper. Everything is the same to update. Admins dont have to specialize in hear separate system.
But... obviously you're stuck with what you buy. Make sure to get a system if you can that you can build your own addins for, to match it to your busienss' model.
显然“这取决于”。 我的一般规则是，如果是内部的，我们会购买它并在需要时进行集成。 如果我们的公司系统管理员遇到问题，并且这不是一个给我们的开发人员带来负担的庞大项目，我们可以为我们组织外部的人员提供支持热线。
如果它是我要交付的产品的一部分，我会构建它或根据需要从开源库中获取一些源代码。 没有什么比别人的黑匣子代码破坏您的产品更糟糕的了。 恕我直言，运输产品中的依赖项越少越好。
我倾向于购买您提到的支持产品。 好的产品为共享身份验证系统、面向用户的主题以及可能是您的客户服务团队尚未意识到他们想要/需要的大量功能提供了很好的集成点。
但是，分析什么。 当涉及到这样的“管理”项目时，对我来说最重要的是机会成本。 我的团队还可以做哪些工作来让我们的公司赚更多的钱，为我们带来更多的客户等等？ 当然，这些项目对利润有一些积极的影响，但与新产品、改进的产品等相比，这些都不算什么。随着时间的推移，包括维护，开发人员/项目经理/测试人员将在这个管理项目上花费多长时间？ 如果你购买，集成点不会经常改变，但如果你构建，你的客户（内部人员）将不断要求新功能，并且你将能够在你的剩余任期内维护这个项目。
Obviously "it depends." My general rule is that if it's internal we buy it and integrate if required. Our corporate sys admin has a support line to someone external to our organization if she has issues and it isn't a huge project burdening our developers.
If it's part of a product I'm shipping, I build it or take bits of source as needed from open source libraries. There's nothing worse than someone else's black box code breaking your product. The fewer the dependencies in a shipping product the better, IMHO.
I'd lean toward buy for a support product like you mention. The good ones offer great integration points to shared authentication systems, user facing theming, and probably a boatload of features your customer service team hasn't realized they want/need yet.
But, what to analyze. The biggest thing for me when it comes to 'managerial' projects like this is opportunity cost. What else could my team be working on that will make our company significantly more money, get us more customers, etc? Of course these projects have some positive impact on the bottom line, but nothing compared to new products, improved products, etc. How long over time, including maintenance, will developers/pm's/testers spend on this managerial project? If you buy, integration points don't change often, but if you build, your customers (in house people) will be asking for new features constantly and you'll be in the position to maintain this project for the rest of your tenure.
买？ 陌生人，你所说的这是什么东西？
说真的，我已经很长一段时间没有为自己的项目购买软件了。 我所有的开发工具都是免费的，我所有的第三方库都是免费的（非 GPL）。 甚至我的操作系统也是免费的。 我必须为测试目的支付 Windows 费用，但大部分工作都使用跨平台的工具。
任何需要无法立即从免费工具或库中获得的代码的东西，我要么从头开始编写（所有算法都可以在网络上免费获得），要么使用我一直在添加的（巨大的，因为我太老了）代码片段库源代码已经存在很多年了。
购买（“获得”）几乎总是比构建更快，除非购买的东西太糟糕以至于集成是一场噩梦。 通过避免从没有什么记录的供应商那里购买最新的炫酷产品，可以缓解这种情况。
Buy? What is this buy of which you speak, stranger?
Seriously, I haven't had to buy a piece of software for my own projects for a long long time. All my development tools are free, all my third-party libraries are free (not GPL). Even my OS is free. I have to pay for Windows for testing purposes but the majority of work uses tools that are cross-platform.
Anything that requires code not immediately available from free tools or libraries, I either write from scratch (all the algorithms are available for free on the web) or use my (huge since I'm so old) snippet library which I've been adding source code to for many years.
It's almost always quicker to buy ("obtain") than build unless the bought stuff is so crappy that integration is a nightmare. This can be mitigated by avoiding the latest whizz-bang stuff from suppliers that have little track record.
您的要求越“标准”，购买就越合适（或者换句话说，不要重新发明轮子）。 相反，您的需求越独特，您可能会考虑构建更多。
您非常正确地指出，即使在购买时也往往存在一些定制。 请记住，任何定制都会在每次升级/修补时花费您的费用。 我建议，如果您的需求接近您可能购买的工具之一支持的业务模型，那么您应该认真考虑将业务流程重新调整为符合供应商标准。 如果不可能，请询问您是否购买了正确的工具。
我建议，如果有人出于成本原因建议建造它，请尖叫。 根据我的经验，购买成本是众所周知的，而构建成本却是隐藏的。 请记住，您将决定在应用程序的整个生命周期内继续编码（商业应用程序平均为 7 年），但在决定购买和构建时可能只考虑初始开发成本。
我非常喜欢单一的整体数据库，但有时这是行不通的。 更重要的是拥有“单一事实来源”； 如果您有多个数据库保存类似的数据，请选择一个数据库作为给定数据的权威来源，并制定一个流程来维护所有其他数据库与该来源的一致。 最好这是自动的。
The more 'standard' your requirements, the better buying fits (Or to put it another way, don't reinvent the wheel). Conversely, the more unique your requirements the more you might consider building.
You quite rightly point out that even when buying there tends to be some customisation. Bear in mind that any customisation will cost you at each upgrade/patching time. I suggest that if your requirements are close to the business model supported by one of the tools you might buy that you serious consider realigning the business process to the vendors standard. If this is not possible ask if you are buying the correct tool.
I would suggest that if someone suggests building it for cost reasons run screaming. In my experience the cost of buying is well known and the cost of build is well hidden. Remember that you will be making a decision to keep coding for the life of the App (average of 7 years for a business app) but may be considering only the initial development cost when deciding between buy and build.
I have a strong preference for a single monolithic database but sometimes this is not workable. More important is to have a 'single source of the truth'; if you have multiple databases holding like data, pick one as the authoritative source of a given piece of data and have a process to maintain all others in agreement with that source. Preferable this will be automatic.
包揽一切的整体系统是存在的理由这么多的企业应用程序。 然而，我发现，如果你不愿意支付一大笔钱，你就会遇到整合问题。
“最佳”解决方案是相当主观的，任何答案都既正确又错误，但如果我是国王，我可能会选择适合的根深蒂固的开源解决方案，并将 Web 服务包装在需要的项目周围互相交谈。 如果我是国王。
顺便说一句，有一些免费的票务系统，例如 RT （等），您不必担心关于购买。
The monolithic system that does everything is the the Raison d'être for so many Enterprise applications. What I've found, however, is that if you're not willing to pay a buttload of money, you're going to have integration issues.
The 'best' solution is quite subjective, and any answer is as right as it is wrong, but if I were king, I'd probably go with the entrenched open source solution where it fit, and wrap web services around the items that needed to talk to each other. If I were king.
As a tangential point, there are free ticketing systems like RT (et. al.) that you need not worry about buying.