B/OSS Software: Should You Buy or Build?

By David West
January 18, 2011

Full disclosure – my company, Equinox Information Systems, sells and customizes commercial-off-the-shelf software, so don’t be surprised that I’m going to make a case for buying most of the time. But, there are situations where building really does make the most sense. My goal in this blog and my next one is to outline the advantages and the challenges of both scenarios.

The Case for Building Your Own
Typically the decision to build a solution in-house makes the most sense at the low end and high end of the project spectrum. If a project has a limited set of well-defined and static requirements, AND development resources are readily available, it’s hard to argue against building it yourself. You can utilize sunk-cost resources and likely get a quicker turn-around. Once the project is done, the development staff can move on to the next project, as maintenance and enhancement work is not likely to be needed.

Likewise at the high end, large scale projects sometimes reach a point where building makes the most sense, such as Tier 1 carriers processing billions of CDRs a day. Any vendor supported solution at that volume would likely include a large up-front charge, and hundreds of thousands of dollars in annual maintenance costs. For that money the carrier can justify a dedicated IT staff of 3 or 4 people to do ongoing development and maintenance of the application.

So, at the low end, where ongoing development resources are not required, or at the high end where dedicated IT resources are cost justified, building may make sense. But I hasten to add a couple of cautions. In either case, the key is having dedicated IT resources for the duration of the engagement. And, to build in-house, you need enough internal subject matter expertise and insight into what’s going on in the industry. Only with that knowledge can you can direct the development staff, saying, “We need to add X, Y, and Z capabilities to the application to keep up with what the industry is doing.”

In-House Projects: the Illusion of Control
The most common argument in favor of building in-house is control. The rationale is that building in-house lets you not only control the cost, but also features and functions, timing, and integration with other systems. And, there is also the potential for strategic differentiation. If there’s something very unique to your company, it can be built into your solution and other carriers will not benefit from it, as opposed to using a vendor who adds features to a commercial release.

In theory, by building yourself, you’ll have total control over these things, making you master of your destiny. But, as Albert Einstein famously said, “In theory, theory and practice are the same. In practice, they are not.”

As I said above, the key is having dedicated IT resources for the duration of the engagement. In my experience, I’ve never run across a carrier with a group of developers sitting in a back room, twiddling their thumbs. When you start digging into how feasible it really is to build yourself, you find that, yes, there are developers on staff, but they are busy working on many other projects.

Getting your hands on those precious IT resources is quite a challenge. Somebody has to first champion the project and convince management to allocate those IT resources in the first place. Then, they need to insist that once the project kicks off, developers aren’t going to be pulled off to do some new strategic project – they are going to keep working on it till it’s done. And remember, unless the project is small and the requirements finite, you are going need those resources not just for the initial development, but also for on-going enhancement and support.

So what happens in the real world? Often, if you’re lucky, IT will build it for you. But once it’s built, the chances of getting a follow-up project prioritized high enough to get timely modifications done are very, very low.

Even if you do succeed in getting resources allocated for follow up work, you might end up having to re-invent the wheel. In the initial development stage, a couple of programmers write the code, and that’s great because these guys really understand the project. But because the IT staff is fairly fluid, when it comes time for changes, those key staff members are gone or are not available, which means there’s no IT folks around or available that really understand the project.

If you are seriously considering building in-house first ask yourself one-simple question: “How responsive was IT when I last had an urgent need?” When I ask customers that question, I usually hear something like, “They were so slammed at the time that it took forever.” If your answer is along those lines, then you have to wonder about how much control building a solution really gives you.

Can Your In-House Application Stay State-of-the-Art?
One of the key selling points for our Protector Fraud Management Solution is that the product doesn’t stand still. As the industry and threats evolve, Protector evolves. We not only build into it the capabilities we know it needs, but in addition, we incorporate almost every feature our customers for the last 20 years have told us they needed.

Fraudsters can beat you in a lot of different ways and their techniques continue to evolve. So if you’ve built a static in-house system that addresses yesterday's fraud problem, but you’ve not made the enhancements to address tomorrow's fraud problem, you’re highly vulnerable to attack.

This is why, to stay on top of fraud trends, like most vendors, we constantly talk to our large community of users, adding features and functions based on their feedback.

When one customer tells us about a new kind of fraud they are seeing, we update our Protector product right away to protect them. Later if another client of ours experiences a similar attack, they’re protected.

The revenue assurance software field is just as dynamic as fraud. Five years ago, the hot issue was phantom traffic. Two years ago traffic pumping was what everybody talked about. Today, as margins get tighter, carriers using wholesale providers want to validate their invoices. As each new trend surfaced, we grew our product accordingly.

In fact, when we first designed our TeleLink application years ago, it was primarily just a reporting tool, but our customers are using it in entirely different ways now. Companies that invested in that product early on are getting the benefit of a product that’s matured into something more valuable than it was before.

And remember, vendors like Equinox don’t operate in a vacuum. We live in a dynamic commercial market that forces us to stay on our toes and offer better features and keep our costs competitive. In the open market, products get better, and benefits get cheaper – you don’t get that same “pressure-to-improve” with an internally developed solution.

Conclusion
At the outset, I highlighted two areas where I think building your own solution makes a lot of sense – a very large-scale application and a small self-contained one.

But beyond those isolated cases, we discovered that the theoretical benefits of building in house – controlling features, functions, timing, and costs – may not play out in practice. We also discovered that keeping an application up-to-date in a fast moving marketplace is difficult if not impossible with an internally built solution.

One final thought. A few years ago I did some research and found some interesting statistics about in-house development projects. It turns out that:

• 75% are delivered behind schedule
• 50% end up over budgeted by more than 50%
• 30% of them fail to deliver the initially promised functionality.

So, to Einstein’s point, in practice, theory and practice are never the same. The assumption that an in-house project will be done on schedule, on budget, and with required functionality is a bad assumption to make. More often than not, buying off the shelf is a better route to a successful project.

* * *

In my next blog article I’ll discuss the follow-up to a buy decision – how telecom carriers and software vendors can work together in partnership to overcome the challenges of implementing an outsourced solution.

David West is executive vice president of Equinox Information Systems, responsible for developing and implementing the company’s long-term strategic plan, including product design and marketing. West works directly with the company’s hundreds of customer sites across the United States, Europe, and Asia.