Email a colleague    

September 2010

Telecom Software: Should I Buy or Should I Build?

Telecom Software: Should I Buy or Should I Build?

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 turnaround.  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 three or four 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 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. “If I build my own system, I can not only control the cost, but also features and functions, timing, and integration with other systems.  And I can also do strategic differentiation.  If there’s something very unique to my value chain, I can build that into my solution and other carriers will not benefit from it, which might happen if I use a vendor who adds it to their 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 to need those resources not just for the initial development, but also for ongoing 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 reinvent 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 are 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:

  • Seventy-five percent are delivered behind schedule.
  • Fifty percent end up over-budgeted by more than 50 percent.
  • Thirty percent 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.

This article first appeared in Billing and OSS World.

Copyright 2010 Black Swan Telecom Journal

 

About the Expert

David West

David West

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.

Equinox Information Systems is one of the leading fraud and RA software vendors in the U.S.   Contact David via

Related Stories

  • High Touch Networking meets High Tech Partnering:  How to Leverage a Software User Conference by Dan Baker — Because a user conference is highly targeted at customers and prospects, it’s one of the most cost effective and personal ways for a software vendor to spread positive industry buzz and pave the way for sales.
  • Telecom Software: Should I Buy or Should I Build? by David West — Build custom systems in-house vs. buying commercial software is a critical issue for service providers.  This article make a strong case for why commercial software is best in most situations.  Discussion points include: cost tradeoffs, the illusion of in-house control, and staying current in a dynamic market like fraud assurance.

Related Articles

  • The Bluejay Speaks: How to Rise above the Chatter, Grow Followers, and Deliver Rich, Powerful Content on the Web interview with Michael Bluejay — Telecom professionals need to constantly hone their web communication and marketing skills.  Here we interview a high Google ranking website author who shows how to communicate with power on any subject via the web.
  • Please Mishandle my Telecom Job and Professional Career interview with Eric Priezkalns — Philosopher Nassim Taleb has released a new book on the subject of anti-fragility, a self-invented word describing how people, businessees, and other organic things can benefit from a certain amount of stress, disorder, and shocks.  The article examines Taleb’s theory from the context of the telecom business, and business assurance careers especially.  Professionalism is defined as a bold dedication to scientific inquiry and a data analytics mindset.
  • Stay Focused, Coordinate and Keep it Simple: Applying Steve Jobs‘ Leadership Tenets to Telecoms and Business Assurance interview with Ed Shanahan — Much has already been said about the brilliance of the late Steve Jobs.  In this article, RA consultant Ed Shanahan analyzes the leadership tenets of Jobs, then uses that as a springboard for a deeper diagnosis of telecom’s organizational flaws.  It’s a rallying cry for executives and business assurance pros to get things moving in a simpler, better coordinated, and more focused direction.
  • 19th Century Telecom Pioneer, Thomas Edison: How He Succeeded as Told by Himself interview with Thomas Edison & Orison Swett Marden — Here is a remarkable first-person interview with electrical and telecom industry giant, Thomas Edison, the Steve Jobs of the late 19th century.  Edison’s remarks, as orginally published in a 1901 book, reaffirm the principles that deliver success in any century or in any human pursuit: drive, dedication, focus, and an ability to turn good luck into victory.
  • High Touch Networking meets High Tech Partnering:  How to Leverage a Software User Conference by Dan Baker — Because a user conference is highly targeted at customers and prospects, it’s one of the most cost effective and personal ways for a software vendor to spread positive industry buzz and pave the way for sales.
  • Is Your Company Penny-Smart and Dollar-Foolish in Auditor Productivity? by Peter Yelle — Operators who fail to automate their invoice reconciliation process could be seriously undermining the morale and efficiency of their most valuable auditors.  This article explains the many subtle ways that manual auditing process can cost operators money.  Also presented is an analysis of the typical returns achieved by CSPs with mature cost assurance programs.
  • What If a Large Telecom Operated as a Thousand Business Units? interview with Eric Priezkalns — The Haier Group, a $20 billion consumer appliance manufacturer is a one-company Capitalism Revolution.  It’s organized into thousands of business units with bottom-up as opposed to top-down decision making.  What would happen if Haier’s management style was used to transform a large carrier?  That questoin is the starting point for an intriguing “outside the box” analysis by one of RA’s biggest thinkers.
  • What Are the Proper Boundaries of Revenue Assurance Software and Organizations? interview with Guera Romo — Is the mission of a revenue assurance department to be simply a watchdog over billing and operations functions?  This article challenges readers to examine the fundamental assumptions that underlie RA organizations.  Issues discussed include personal accountability, training, the scope of RA oversight, and the role of assurance software.
  • Japan’s Community Assurance: The ‘Ganbatte’ Spirit by Dan Baker — This story, posted a month after Japan’s devastating March 2011 tsunani, takes stock of the community assurance spirit that pervades Japanese culture and allows the nation to both overcome disasters and deliver high quality products.
  • Can Revenue Assurance Pioneers Survive the Age of Analytics? interview with Eric Priezkalns — Here is a pundit’s analysis of the revenue assurance profession.  Tracing the history of RA from pioneer consultants to modern-day “big data” pros, the article discusses different analysis styles, career strategies, and provides ideas on how RA can further leverage technology to add even greater value to telecom organizations.
  • When Revenue Assurance and IT Clash, Look in the Mirror interview with Rob Mattison — Succeeding in RA requires coordination with outside departments — billing, customer care, marketing, engineering, and especially IT.  This article shows how conflict often arises between RA and IT over what it truly means to “run systems”,  However, IT can be an even bigger roadblock when RA is confused about its proper mission.
  • Telecom Software: Should I Buy or Should I Build? by David West — Build custom systems in-house vs. buying commercial software is a critical issue for service providers.  This article make a strong case for why commercial software is best in most situations.  Discussion points include: cost tradeoffs, the illusion of in-house control, and staying current in a dynamic market like fraud assurance.