The Benefits of Commercial Off-the-Shelf Software Over Homegrown Solutions
Many organizations still rely on homegrown software to run key aspects of their business. While custom-built applications served a purpose in the past, the case for purchasing commercial off-the-shelf (COTS) solutions grows stronger every year. This article explores five reasons why COTS software delivers more value and reduces risk compared to maintaining internally developed systems.
1. COTS solutions are “productized” for ease of use
They go through extensive testing and quality assurance checks that are not feasible with homegrown tools. Vendors also prioritize comprehensive documentation and training to support users. With homegrown systems, tasks often require customization versus configuration through the UI. COTS products also cater to a wide range of use cases, ensuring capabilities are there when needed.
2. The “write once, sell many times” Factor
The “write once, sell many times” model underlying COTS allows vendors to spread costs over a large customer base. This provides more resources for continuous enhancement and high-quality support staff. Homegrown systems have just one client – you! Without the leverage of a large user base, it’s difficult to justify ongoing investment at the same level as commercial solutions.
3. The Money Factor
While COTS may carry higher upfront licensing expenses, maintaining customized code over time grows increasingly expensive. With commercial software, regular upgrades and new features are built into maintenance fees. Ease of use also minimizes training and onboarding costs for additional applications. Homegrown systems typically rely on the original development team for ongoing support as needs evolve.
4. The Community
COTS solutions benefit from an extensive community of partners, clients, and developers collaborating to maximize value. This awareness shapes both product development and assistance resources. Tap into experienced service partners, easily find qualified personnel, and learn from networked user groups. Homegrown systems operate in isolation without this support network.
5. The Human Factor
Small, undocumented codebases written for an immediate need carry tremendous downside risk. What happens when key developers leave the company? How can you ensure a succession plan for long-term maintenance? COTS vendors architect solutions for longevity and provide continuity for customers. Even if acquired, the large user base incentives continued enhancement.
Rather than reinventing the wheel, integrate best-of-breed COTS solutions to focus on core business capabilities. Reserve homegrown tools for small one-off needs that are unlikely to require ongoing enhancement. For mission-critical systems, the support community, continuous innovation, and risk reduction inherent in commercial software make it the superior choice.
Work with COTS providers as true partners to ensure alignment with your strategic direction. Take advantage of available training resources to maximize user productivity and stay on current versions to benefit from the latest features. The economies of scale and purpose-built design of off-the-shelf solutions make them hard to beat for delivering lasting value.
I am a programmer and I’ve developed a lot of homegrown software over the years while working for a publishing houses and print outsource vendors. I even have patents. Software I wrote 27 years ago is still in production today. Even back then my philosophy was “Don’t write it if you can buy it”. The difference was back then there was no software that did many of the things that we needed to do. So, I had to write it. For the last 23 years, I’ve worked in product management for leading software organizations. I have a very detailed knowledge about how software companies work and how they make the software. Today, I’m going to try to explain to you why you should not be doing major software development, but also give some tips on how to maximize the impact of your internal development projects.
There is a place for homegrown software. You just need to be smart about how you run those projects. Let’s get into it. First, let’s start by defining homegrown versus commercial off the shelf software. Homegrown software is code that is built, supported and maintained by internal I.T. teams. Commercial off the shelf software or COTS is created by organizations that specialize in developing, selling, supporting and maintaining software. Many times for large worldwide customers. COTS companies themselves, their staffing, processes, structures are all optimized for software development, sales and support. It’s what we do.
Reason number one why I think COTS is a better approach than homegrown. Commercial off the shelf software is productized. So, what do I mean by that? Well, it has an installer, an upgrade process, and goes through extensive regression testing. Homegrown software is typically installed by the team who wrote it. They don’t spend weeks running extensive regression testing on different hardware and software versions prior to release. Not only would they not know how to do this, probably. they would not get the budget for it. Homegrown software is typically QA’ed by the development team. COTS is never QA’ed by developers. It’s like proofreading your own writing. Not a good thing. Part of productization is making products easy to use and easy to support and fully documenting them. This is necessary when you have thousands of customers. Homegrown software is seldom well documented, and ease of use is really sacrificed for functionality. Maybe things you do all of the time might be easy to do in homegrown software, but infrequent use cases such as configuration of complicated tasks is usually awkward, and manual. Support from I.T. can be hit or miss. Support for COTS companies, especially at Solimar, is not a distraction. It’s a differentiator. Software products are built to be flexible so that they can support a wide variety of customer use cases. Well, not every feature of a given piece of software is useful to you today, it’s nice to know they’re there when you’re working on future projects. Think about Microsoft Word. Most people use maybe 5% of what it does, but when you buy it, you buy it because you know the other 95% is there when you need it.
Reason number two. Commercial off the shelf software uses the publishing model. When Microsoft first started selling software, they looked at different sales models. The closest they could find to what they were doing was book publishing. And, so that’s the model that they followed. Like books software as written once and sold many times. There are many benefits to this approach, but the main one is that costs can be distributed across a large user base. Write once, sell many times provides the leverage needed to make a better product. User base for homegrown is one customer. Understandably, homegrown products never see the level of investment COTS products receive. This impacts all aspects of the product, not just the code.
Reason number three. Total cost of ownership. Let’s face it, if you’re buying licenses, outright COTS is expensive. You can buy subscriptions which eliminate the initial license fee, but they increase ongoing costs. Whether COTS or homegrown, there’s a substantial investment for the implementation. However, there are huge benefits for COTS here. You need to install the software, learn how it works, implement workflows with it. Because of COTS productization, these things are all typically faster and cheaper. Because COTS tends to be easier to use, once you get the hang of it, ongoing effort is minimized. New work can be easily added, and most of what you need to do can be done through simple configuration. Most of these tasks that you need to do on a regular basis are made simple through a UI. With homegrown, the story is different. You might think, if we write it ourselves, it is free. Well, kind of. What you save on initial license fees, you pay for an initial and ongoing development costs. With homegrown, many times the development time is longer because requirements must be gathered, the software must be written and tested, and all of that with a small team. Once in place, many tasks may need to be accomplished through the developer customizing things rather than by users through the UI because homegrown is less productized. Adding customers and workflows is harder, takes longer and requires more resources. With COTS, you pay for support, but not only do you get high-quality support, you get upgrades that keep your software current and deliver a steady stream of product enhancements.
Reason number four. The power of community. Whether looking for a services partner or hiring new employees, it’s a lot easier to find people who know COTS than your homegrown software. It’s also easier to train people on COTS because not only is there high-quality documentation, many times there are free training materials. Solimar has hundreds of hours of video training available to get new users up to speed and to help experienced users with new features. You can also partner with companies using the same COTS products for failover and redundancy. Solimar has a large group of knowledgeable customers who network and share tips and tricks with each other. Not only do customers learn from each other, we learn from you with every discussion and support call, we learn about how to improve our products and better serve you and all of our other customers. Another less obvious advantage is that COTS is generalized to industry norms. COTS tends to drive you to and reinforce industry best practices where homegrown may be wrapped around your own strange ways of doing things. So, homegrown takes you away from industry standards, whereas COTS can drive you towards them.
Reason number five. High risk of homegrown software. When you develop software for a living, you can afford to do quite a bit to reduce risk. You can hire redundant resources, have large development teams for QA, support, documentation and education. You can hire professional software engineers and take the time to plan the architecture of your software so that it is extensible and robust. Homegrown software is frequently built in a very ad hoc way. It is as if you start out with a small house and you just tack on another room and then another and maybe another floor. Homegrown software can easily become kind of an unstable Frankenstein monster. In software, this approach leads to functional limitations, leads to instability, and usually a lot of bugs. Software companies not only plan out their architecture more carefully from the start, they frequently take time to refactor code, which really means to go back and rewrite core pieces to ensure a solid foundation for future development. Most homegrown software is tactical. Good luck asking for six months or a year of engineering and testing time with no new features.
Let’s talk about the life cycle of homegrown versus COTS. Homegrown software is usually tactical and serves an immediate need. The lifespan of most homegrown software is pretty short, as it is many times considered a throwaway, waiting for the right COTS to be found. It’s not uncommon to have the new management discover that you have a huge software development going on and wonder rightly, Why are we doing this? We’re not a software company. COTS software truly has a life of its own. Once products are put out in the wild, they’re really hard to sunset. Solimar has products that are older than 25 years companies are incented to maintain products because we earn support fees and to enhance them to remain competitive. COTS products have to compete or they die. COTS companies almost always provide a path forward for customers, even for very old products. It just makes good business sense.
Let’s wrap up with some final thoughts. There is a third category of software that’s between homegrown and COTS. These are solutions that started life as homegrown but are now being sold as COTS. Typically, these solutions are either built by or for a large organization by an internal or maybe an external professional services group. That group decides to resell the solution to another customer in order to recover the costs and maybe get some leverage. Most of the time they’ll try to pass it off as a product. But, if you look under the covers, you can pretty easily see that it lacks many of the hallmarks of COTS. Specifically, the productization characteristics like documentation and training. These products are commonly sold with lots of services to fill in the productization gaps. Indeed, they’re designed to support their services business. Stay clear of these solutions. They require a lot of services initially and ongoing. They have high initial costs of COTS and the homegrown high ongoing costs because of the lack of productization. They’re really the worst of both worlds. These homegrown COTS products are pretty easy to spot. Find out about the history of the product and the company. Are they a software product company or a professional services company? What is their product services cost breakdown? Do they require services for implement patients for ongoing work? Solimar is a software product company? Most of our customers quickly learn our products and become completely self-sufficient.
Okay, so how do we do homegrown, right? Your strength is knowing your business, not writing software. Your analysts should be focused on revenue generation and cost saving opportunities, not writing software that you can buy. It’s your job to be the best integrator of commercial off the shelf software. Put those best of breed pieces together, leveraging your knowledge and your core competencies to create unique, differentiated solutions that deliver competitive advantage. Homegrown is great for small utilities that don’t need a lot of ongoing work. Focus on being the glue, filling the gaps from those larger pieces where absolutely necessary, and build your platform using the biggest components that you can that do all of the heavy lifting. Don’t write any of the low level code yourself.
Many of you may have homegrown systems out there and you’re thinking, Yeah, so what? Well, how do I sunset these? How do I move on? Just to be clear, I’m not talking about little tiny utilities. I’m talking about larger kind of key business systems. What you want to do is start by documenting your business requirements. And, this is what the system needs to do, not how it needs to do it. What are the key features? What are the key capabilities or characteristics of this for a commercial off the shelf replacement? Identify and build out key use cases. Clean them of personal information so that you can share them with vendors. Work with vendors to ensure that they can handle these use cases. It’s important that you know how they handle the use cases. Don’t be fooled by slick demos. They shouldn’t be using workarounds or a lot of custom code to accomplish common tasks for your workflow. Think beyond price. You’re about to get involved in a long term relationship. Make sure you’re picking the right partner. Finally, I have some thoughts on how to get the most of your commercial off the shelf software. Stay on the latest versions of the software. If you’re not on the latest version, you may not be taking full advantage of all the new features.
Take advantage of all the free learning resources from your COTS companies. Solimar has a huge learning library with videos and documentation that can help your people be more productive and learn new product features. Take advantage of the community. If there are user group organizations, join, participate. Connect with other customers in similar situations and learn from each other. Many of our customers regularly call each other in addition to calling our support. Stay close to your key COTS vendors. Know their strategy. Make sure they know yours. Alignment is key. Great products don’t require a lot of services. When picking COTS vendors, talk to them about services delivery to make sure that their philosophy is in alignment with yours. Solimar caters to companies that have a preference for self-service. We create easy to use products, enabling customers to do it for themselves.