The telco move to the cloud is set to transform our industry, and the momentum is building. Acquisitions teams are sniffing around the software providers, one example being the purchase by Amdocs of Irish software company Openet, a digital BSS company that provides charging, policy and data management solutions. “The Openet solutions complement our portfolio and this acquisition is part of our mission to accelerate this industry’s move to the cloud,” stated the Amdocs CEO.
I wrote about the crappy valuations software companies in telco get in an article for Light Reading. I got a lot of “Amen, sister!” from other vendors, echoing the frustration they have experienced in this industry. I guess I touched on a nerve when I said something that everyone thinks, but no one talks about – at least not publicly. So let’s talk about it some more.
I’m talking about what a slippery slope customizations are to a software company, and by extension, to its customers. At most software companies, customization revenue is buried somewhere in the professional services revenue line. The margin is typically low when compared to software margins – it hovers around 20-30%; at well-run software companies it may get up to 50% or higher. It’s difficult to replace, since it is usually one-time revenue and not recurring, so once you deliver it, the company has to find that revenue again, typically with another customer. Since you’re always looking for replacement revenue, coupled with the fact that customers usually don’t have a super deep understanding of your product (and your people in the field don’t either), when a customer asks if the product can handle some business logic, the easy answer is to say yes – via a customization. It solves your revenue treadmill problem and you solve a problem for your customer.
It seems like it would be easy enough to do this, so what’s the big deal? I’ve run 16+ software companies and I’ve seen A LOT of different ways to handle customizations. The best way is a low code / no code approach via configurations. I scream HALLELUJAH when I get a company that handles it this way. I’ll tell you right now, very few companies do.
Another way is via an Application Programming Interface (API), which requires coding but is abstracted away from the product code base. A lot of companies handle it this way. It’s not ideal but it’s not the worst way. You can deliver customizations and not impact the product, but it makes upgrades pretty difficult because not only are you upgrading the product, but you have to maintain the customizations along the way and update them too.
The absolute worst way ever, ever, ever known to man is to embed customizations in the base product. Who ever even thought this was a good idea? When you spot this approach you should run far away, because you don’t have a product, you have N code bases, where N equals the number of customers. It’s totally brutal. I’ve seen two or three companies like this (and a lot in telco), where they let their customers customize their installation so much that it was more expensive to upgrade them than it was for them to just swap to another product and start over. That’s a really, really bad place to be, for both company and customer.
If this was the most profitable way to bring software to the telcos, then there would be many more private equity and venture capital companies showing interest in telco software companies. However, the intensive nature of the development work required for exactly one customer at a time limits the valuation multiples of these businesses. Most service businesses are valued at two to three times revenue, not 10 times revenue, like you see at typical SaaS software companies.
So why do software companies continue to accept customizations to their products? Because the CSPs DEMAND IT. Telcos believe that in order to provide a differentiated service to their subscribers, they must be able to customize their software. Most customizations have been done in the name of providing an omni-channel, consistent, and excellent customer experience. But in fact, it’s done the opposite: the systems are old, clunky, slow to improve and difficult to upgrade. Most software upgrade cycles are 3-5 years apart, not every month or every quarter like in other industries.
So here’s my controversial take: telcos should aim for less customization (changes that require coding) and more configuration (changes that do not require coding). Working from a widely used product base means that the time to market becomes more cost effective and faster. It has fewer bugs, it’s faster to upgrade, and it has lower cost of operations and maintenance because more people are using it and testing it in lots of different ways. By minimizing the potential failure points you mitigate operational risk. But in order to achieve this state, it means telcos would have to give up all their beloved customizations.
But they can’t. At least, not yet. That’s because the software products offered on the market presently are not good enough: they need to be 10x better than they are today. Most of the current offerings do not have a strong enough user interface to implement the business changes required as a configuration. Therefore, the software vendors need to step up and develop it, to allow for configuration. But that’s going to be hard to do, too. Professional services revenue is pretty lucrative and all the vendors are addicted to it. Just ask Amdocs if it’s ready to give up its consulting revenue. My guess is the answer will be a simple “no way, Jose.” Even if it did, it’s going to take A LOT of money to pivot all this software to this state. It is possible, but it’s going to take some time and a bunch of investment.
Which brings me to what I’m trying to do in telco – convince everyone to move their software to the public cloud. It’s scalable, reliable, redundant; you get off the treadmill of buying and managing infrastructure; and you completely eliminate capacity and disaster recovery planning. The software that’s available only in the public cloud is extensible, reusable, and better than what you have today, built by the world’s most advanced technologists.
But beware, vendors: don’t move your customers to the public cloud AND try to keep everyone’s customizations, otherwise you’re going to end up not with multi-tenant software-as-a-service with all the wonderful economies of scale – you’ll end up with HOSTED CUSTOMIZED CUSTOMERS. If this is your plan, you might as well stay on bare metal. It’s going to be way easier and way cheaper.
So that’s my pitch: get rid of your customizations, move to multi-tenant SaaS software, put your business logic into configurations and be able to turn on new functionality and services at the speed of light. But if you insist that you need to hold onto your customizations (and customization revenue), be prepared to be left in the dark ages, seeing the sun only every 3-5 years and being left in your competitor’s dust.