Commercial off-the-shelf (COTS) applications are wonderful if they match your business process. Many of these applications incorporate process models which are based on industry best practices and thus if you can match your business processes to industry practices, you can benefit from an industry's collective wisdom. Plus you have many more users testing "your" code for you. Your company may use a small percentage of the available features of a given solution, but the economies of scale a vendor leverages in creating a COTS application make a 10% value proposition worth the full investment in the product.
Note I said "if they match your business processes." If they do not then you have two choices. You can change your business process to match the tool (much easier said than done) or you can customize the tool.
Customization. Traditionally, when we've needed to make a change to a COTS application, we've customized the tool. It's so easy to do! You don't have to worry about buying new equipment, testing new configs, installing new baselines, testing in staging, etc, etc, etc. You just do some simple "configuration" (read: write code) and publish the changes out to production in the tool that's already been pushed there. It's typically that easy.
But is it worth it?
Firstly, you can rarely build what you'd REALLY like to build with the simple customization tools available in a COTS application. If you can live with vanilla then the simplicity in using these configuration tools can be worth it in the short-term.
So what happens when you upgrade? That's when you feel it in your pocket book. We've been riding the upgrade train of our ERP system for years. We've made many, many customizations. They're necessary customizations, but they make our upgrade to new versions of our software very painful. At some point you start to wonder if it wouldn't have been smarter to write the software yourself instead of purchasing an expensive COTS application. I'm coming to the conclusion that the answer is no for many COTS applications.
Here's the credo we're developing at the Church wrt COTS applications.
- Buy over build when possible, but only if we're willing or able to bend our business process to match the tool we would be purchasing. When customizing, abstract code from the COTS application (and especially the DB tables) when extensions are necessary.
- We look carefully at the number and severity of customizations we'll have to build and if we determine that they will pass a certain threshold, we decide to build.
This approach isn't always a popular one:
"We've already got an ERP system! Let's use it!"
"The vendor promises a smooth upgrade path!"
"The tools are soooo simple!"
But we think it's the best one for us.
I have been involved in software development for 20 years and have seen a lot of changes in philosophy over the years. Since ERP systems have become so popular over the past 10 or so years, many companies elect to install the canned package and then customize it. During my years of ERP implementation consulting (JD Edwards), I have been involved in hundreds of new ERP implementations. The first thing that most people want to do is customize everything. Even if they say they don’t want to make customizations, they still do it. At the very first meeting that I had with the client I would always tell them that almost every client that I had regretted making customizations within a year of going live. I felt it was my duty to point it out and then help them make the right choices on how to properly customize the applications.
ReplyDeleteMost companies spend millions of dollars on ERP implementations and then pay a lot of money on maintenance each year but can’t do much because of the custom code. The last company that I was with had customized the Order Entry application and it was impossible to upgrade. After a few years there, we started a project to completely rewrite the application using the JD Edwards tool set, but outside of the standard application, just using the underlying database. Once this was completed, we were finally able to do much needed upgrade to the system. Now there is a path for future upgrades and the Order Entry system really works they way it should.
In the current company that I work for, they implemented JD Edwards 10 years ago and have not done a major upgrade since then. It is just too much work. What I find amazing is that the company has paid maintenance costs, which I agree must be done, for the past 10 years and hasn’t taken any new major releases. The amount of the maintenance agreement with JD Edwards is about 10% of the yearly IT budget. (All maintenance agreements are about 27% of the yearly budget.)
So the point is what would have happened if the company would have built their own system 10 years ago, got what they wanted, and would have save millions is maintenance costs over the years.
In today’s complex environment there is a place for COTS applications, but there is also a place for custom developed software. Each company and industry is unique and must make the decision based on the best available information at the time.
"Buy over build when possible AND when we’re not willing or able to bend our business process to match the tool we would be purchasing."
ReplyDeleteYour losing me here. Sounds like you're saying to buy instead of build if your business process will not match the tool you're going to buy. Doesn't make sense. Typo maybe? The tool has to meet your needs or there's no point in purchasing it...
[Joel: Sorry I wasn't clear, Gene.
Buy COTS if you can, but only if the tool matches your business process or you're willing to change your business process to match the tool. When you do large customizations then do so in an abstracted way which doesn't tie you to the system.
Otherwise build.
I've updated the post a little for clarity. Thanks!]
Hi, I actually just a suggestion rather than a comment related to your post. Would it be possible to integrate the Google Maps API with a geocoding program and a ward membership database so that we could map home and visiting teaching routes more effectively? Has this ever been explored? It would be one of the most useful tools ever.
ReplyDelete[Joel: Not only possible, but likely. Stay tuned...]
If you buy off the shelf, how can you distinguish yourself if you run the same software that everybody else does?
ReplyDeleteFor a commercial company, I think doing your own thing is usually the best way to go - except maybe for business processes that can't be improved anymore.
Daniel,
ReplyDeleteOthers can correct me if I'm wrong, but I believe that TempleReady information is about to be or already is available on familysearch.org. I believe that was announced in the latest GC. The idea is that the Church knows definitively which persons have had work done (with the exceptions of ambiguous names and dates, which will always be a problem). It's just that in the past the TempleReady "database" as it were has been disconnected from the family research side of things.
COTS software has a place, you just have to know what it is. Like the wise man once said, "If the only tool in the box is a hammer, every problem looks like a nail." You can't always do what you want with 'standard' software, and for those issues there's a developer out there somewhere earning a paycheck.
ReplyDeleteUnfortunately most businesses are not open to changing their processes and it doesn't always make sense to do so. Some industry experts suggest purchasing a COTS framework that you can build on. The framework would include common components but is designed and is expecting customizations. It is kind of a half-and-half system.
ReplyDeleteI've heard this suggested for content management systems and feel other application like ERP systems could benefit from this approach as well. Have you had much experience in using a framework instead of a full COTS?