The same is true of hydraulic modeling software. Where once modelers wrote bespoke programs around a random number generating function, fully functioned suites of software are now available at one-hundredth or less of the cost of writing in-house. So why do some users still pursue the Build option, rather than buying?
Theoretically, given infinite resources, an in-house development team could write the ideal system, specifically tailored to the user requirement, and it is this conclusion that usually underlies the decision to build. When a package is evaluated, the result can be measured as a percentage fit to the user requirement – say 80 or 90%. Users make the assumption – which often turns out to be false – that an in-house solution will give a 100% fit. Add that to an IT department who are looking for a meaty new application as a more interesting project that application maintenance work, and a new in-house development is born.
But in the real world, there are a host of issues that get in the way of the dream of “getting an hydraulic modeling software system with a 100% fit to our needs”. In our experience, people who follow this route learn to their cost that there is often more to package software than meets the evaluation eye, including the following:
Quality of the core program – water modeling is based around a complex core function. The simulation engine at the center of good hydraulic modeling packages is the sophisticated product of years of development by full time software development and hydraulic engineers. The experience needed to build such a core goes far beyond knowledge of the hydraulic equations; the difficult part is ensuring the stability of the simulation engine under all conditions. No in-house project could or should recruit a development team with such specialist software knowledge and experience.
Usability of the system – many in-house systems may appear fine in terms of core function – but their usability lags way behind commercial packages, because in-house budgets rarely run to including the important functions that simplify the user interface. Add to that the usual absence of user documentation, and you end up with a system that a few can use well but many feel unable to use at all.
Interfaces to other systems – if all your systems are developed in-house you control all the program interfaces. But if you want to interface to any package systems – GIS, modeling software or databases for example – you have to keep up with their occasional interface changes. At the least this is onerous and best left to package sellers who can spread the cost across their installed base. If your software is two years old, your original developers gone, and the program documentation sparse, you may be in serious trouble!
Designed for growth – most in-house developments have the premise, explicit or otherwise, that the system will not be extensively enhanced over time. Packages are designed with the opposite view – the design must be robust to extensive development and enhancement. So packages get better over time, at low cost, but in-house packages are too often frozen in time, too difficult to update to new ideas and new regulatory requirements.
Quality and robustness of the software - in-house software teams rarely possess staff who combine specialist knowledge of hydraulic modeling with quality approved software development methodologies. Good package software is written, maintained, and upgraded by experienced hydraulic software specialists, and this shows in its robustness and its ability to cover a wider range of conditions than a typical in-house development.
Packages represent the best practice across the industry, taking up the best ideas and counteracting any knowledge gaps or “not invented here” bias. The user base of a package is a solid community of modeling skill and experience that all members can use to their benefit, and a good vendor will organize user events to give the opportunity for the swapping of ideas across the user community.
WYSIWYG – when you look at the “buy or build” decision, you are comparing a demonstrable package with an unwritten and untried program specification. It’s not surprising that the unwritten spec often looks better than the package that maybe fits 85% of the requirement. But with a properly evaluated package, what you see is what you get. In-house developments are often driven to drop functionality as the compromises of cost and timescale have to be met.
The percentage fit will change - an 85% package fit now can change in two ways. First, new function will be introduced in the future if the vendor is committed to new releases, and a look back over time will reveal that the best packages now are far advanced beyond their function of five years ago. Second, experience shows that few users know all the function of their package. So an assessed 85% fit can be an underestimate.
Packaged software is immediately available - it may only achieve 90% of what you want, but it can do that immediately. 90% now is better than 95% sometime.
Buying a package delivers more than just the software – the best package suppliers also provide dedicated support services, professionally developed documentation and help, and a proven set of training courses given by highly experienced modellers.
The final argument is one of cost – how can an in-house development ever deliver the value for money of a software package with development costs spread over a thousand copies? And as you estimate these costs, be sure to include the high hidden cost of making the best hydraulic engineers available to spec an in-house system. Re-assigning employees to the task of software development is a true cost on the business bottom line.
All the above arguments specifically address hydraulic modeling software, an application that has similar application in many thousands of utilities and consulting companies around the world. There are some applications where in-house development makes sense, including applications that only a few companies will tackle in similar ways, but hydraulic modeling is not one of them.
As you contemplate the prospect of trying to develop in-house the perfect hydraulic modeling solution, ask yourself whether the inevitable cost and pain justifies the risk. It simply makes good sense to go down the package route