The Cost of Development
Posted from LIMSexpert.com
The Cost of Development
Originally Published Mon Jul 28 11:45:10 2008
Some systems are purpose built. It is the nature of the software systems to deliver functionality that meets business needs in an efficient manner. Unfortunately developing functionality that solely meets the current business needs isn’t enough for a viable enterprise-level system. This may seem confusing to you, so let us delve further into the subject.
Enterprise-level systems require several important characteristics, mainly performance, scalability, extensibility, and availability. Third party tool sets like the Microsoft.NET framework can supply you with some of these features, but they unfortunately do not solve all problems. A framework in and of itself is really nothing more than a very large and comprehensive tool chest with potential solutions inside. A laboratory informatics system contains more than potentiality, it contains actual system functionality and real business logic that should be extensible to meet not just today’s but tomorrow’s needs.
For instance, if a laboratory information management system is maintaining some aspect of your business, like raw materials evaluation, and you’re looking to grow your business with new product lines and, therefore, new sets/kinds of raw materials, will your LIMS be able to extend its functionality to accommodate that growth? If your answer is yes, and you had the foresight to realize that early on, you will be three steps ahead of the company or individual that has elected to try to build a system themselves.
Of course there are organizations that have retained high quality IT talent. These organizations may have teams of developers on call to provide both support and development services for a LIMS. In such a case it may be possible to build a comprehensive and scalable system which is extensible into the future. However, studies have shown that building a system is typically more expensive than buying a commercial system over its lifetime. There are a variety of factors involved in this. One contributing factor may include the cost of training unfamiliar professionals/consultants on a completely custom system. A second problem may include the the cost of hidden logical errors that go unnoticed for weeks and years because so few people peruse the source code. Finally, another hidden cost driver includes missed opportunity costs — if a system isn’t regularly updated it cannot be taking advantage of the latest advances in operating systems, security, and/or processor architectures. For instance, your algorithms for performing statistical analysis of data may be twice as efficient on a 64 bit architecture but you’ll never notice it because your custom-built system will remain in the 32 bit universe until its retirement.
This leaves one with the purpose for this article, the cost of development. Is it better to save money on a system that you will inevitably have to spend more money on in the future to enhance and support, or is it sensible to spend a reasonable sum on a system that is extensible, customizable, and road proven? The answer is obvious to some. Others are still looking to learn the hard way.
There are benefits to building your own system, but they need to be justified. First, one should give commercial vendors an honest shake. This means you should see what systems are out there. Prepare to run a legitimate evaluation cycle to see if those systems do more than just match your price point, see if they can match 80% or more of your existing and planned functionality needs. If you cannot find any such system, the next step is to evaluate the costs of building on top of an existing system rather than building one from scratch. Costs of developers, documentation professionals, and software validation personnel must be included in such an initiative. You will also likely require the assistance of qualified software project managers as well. A completely custom system should be your last resort. Corporate management should be leery of any proposal that is not accompanied by metrics that show how the other alternatives are unacceptable. In other words, if the only thing that shows up on your desk is a proposal to build a custom system sans evidence that buying/customizing a system is wrong, the right thing to do is reject that proposal.
The old build versus buy decision can be unduly influenced by software developers and IT professionals in your organization. Don’t let this occur. The hidden costs and negative effects to your bottom line will be too great.
