Dmitry Kabanov

In-house dev: What could possibly go wrong?

SysAdmin

We have been designing billing solutions for telecom applications for 8 years. We’ve made more than 80 successful integrations, but along the way we’ve found that about 50% of companies develop custom tools in order to keep their businesses competitive.

Why do people believe they can tailor any tool to their needs? Usually they tell you: “_We understand how our business works_”.

It can be a great way to cover your short-term goals but ultimately it leads nowhere. We think this approach is a bit risky … and this is why:

Even minor updates cause major pain

Custom billing solutions magnify system’s inertia every time your business wants to introduce new features for clients, or switch for PPP to IPoE. Companies tend to integrate CRM and help desk solutions together with billing systems and it ties everything together.

Once you start down the in-house path, you’re committed to one methodology. You have to keep your in-house dev team together with its DevOps gurus and more. For many businesses, it becomes impossible to keep up with the pace of change in the industry and customization hits back where it hurts the most.

Help is just around the corner

Vendors understand the needs of the market and offer tools that are reliable and reassuringly familiar to most users. We recommend the following course of action for anyone interested in moving from in-house solutions to market-proven products:

  1. Don’t delay! The quicker you migrate, the less danger of bugs popping up here and there.
  2. Using the in-house team to help you move could rebound on you, leading to failures and additional costs.
  3. Migration should be gradual. This might push up the total cost of moving, but it protects against failures and associated reputation damage. It’s an extra cost that often pays for itself.
  4. Don’t skimp on testing. We recommend integrating new tools on your system’s clones first.
  5. Cherry-pick billing products: make sure you clearly understand what future your product(s) will have.

Next up: How we improved fault tolerance and scalability.

Dmitry Kabanov

Comments

    Flux 3,751

    Ropes — Fast Strings

    Most of us work with strings one way or another. There’s no way to avoid them — when writing code, you’re doomed to concatinate strings every day, split them into parts and access certain characters by index. We are used to the fact that strings are fixed-length arrays of characters, which leads to certain limitations when working with them. For instance, we cannot quickly concatenate two strings. To do this, we will at first need to allocate the required amount of memory, and then copy there the data from the concatenated strings.