The other day, a customer asked me why his system’s custom features remain custom when they are probably features that others in his own industry would like to have. He wanted to know why the software vendor never incorporated these features into the product so that he wouldn’t need to keep his features as custom ones, where his company would continue to have to maintain them instead of the software vendor maintaining them.
My response was long and rambling (I went so far down the path on this that, in hindsight, have to feel quite sorry for him having to listen to it all). I went into a clinical analysis of the situation. I pointed-out that his industry’s features weren’t quite so cut-and-dried. I gave lengthy examples of those industries and applications that do tend to have custom-built LIMS. For one example, we do see that Clinical labs tend to have some specific features and this is probably why there are now a number of clinical systems specifically available. Another example would be a drug metabolism lab. There are quite specific features to this and their studies are not like other types of studies in the features, durations and needs. Thus, we’ve seen the Watson LIMS implemented in many of these labs, as this product is specifically meant for that.
My point is that, even though you think your features are fairly generic, they’re less generic than you think they are.
I will also tell you that it is difficult to take features developed for one company and genericize them. It’s much easier to start from scratch and, then, the one developed by a customer for their installation will never look like the one the vendor creates for an entire industry. It would usually not be simple to upgrade from the custom code to the standard version from the vendor. Unless you do joint development with your software vendor, you will not end up with something that goes to the industry and doing a joint development is something you have to agree to BEFORE you start designing or developing anything. If you don’t get that commitment from the start, it almost certainly won’t happen.
The Real Reason
That evening, I realized there is a much better reason why your code won’t be incorporated into a system. Most people who have a lot of code they’ve written are now no longer the up-and-coming market. If you’ve had time to write a lot of code, in these days of short time spans, you’ve probably become an older system than you realize.
Software vendors write solutions for the hot and upcoming markets that they want to get into. Development is expensive and they need to think they’ll get payback on it. They get payback by getting a foot into new market segments and selling an entirely new industry full of licenses and services. In fact, the person who asked the question of me is in an extremely old market — one that will probably not get much attention from new software products unless something changes in that market.
What Markets are Old?
Pharma is old, energy is old, chemical is old, food and beverage is old, Biotech and Biopharma is kind of old, and, since we said Genomics was hot just recently, then it’s already probably old. The same goes for Clinical. So, while we were talking about how hot Clinical and Genomics were, and all those software vendors were jumping to get their footholds in those industries, that was probably a year or two ago, already. These days, that probably means those markets are no longer hot.
My point is this — customers sometimes think their market is a hotter proposition than the vendors do. They’re then confused why software vendors don’t jump to take their advice, or even do simple things such as come to demo the software. If you as a customer somehow really have clout, and you’ll see it by how high everyone jumps when you call them (or when they don’t), use it to get what you need, including trying to get the best resources, joint application deals, or anything else that comes to mind. But if you find that you have no clout, don’t sit around waiting for people to knock on your door. Start whatever work you need done and do your best with it. That includes trying to minimize the amount of custom code you write for your system, but in going ahead and writing it. Minimize it so that you can maintain it for the life of the system because, as you know, the more of it you have, the more people you’ll need to maintain it, long-term.