OSS Line

Comptel Acquires Xtract

More evidence that OSS/BSS vendors and their customers are starting to really appreciate data analytics.

Comptel has announced its acquisition of Xtract (here), supplier of analytics products for telco (and retail/banking too).

The price paid by Comptel is modest to say the least: 3.1 million Euros paid, for Xtract's last year revenues of 2.4 million Euros. So not even a 1.5x multiplier. Either Xtract are motivated sellers, or it suggests that much of the analytics success is services-driven, rather than being off-the-shelf product sales; services companies usually achieve lower exit multipliers than product companies.

The deal is good news. Innovative OSS/BSS vendors are recognising that they can offer smarter solutions with analytics.

Most OSS/BSS products that grew out of the telco boom of the 90s/00s are process-oriented. They sit on a wealth of valuable data, using it to execute jobs, rules and tasks to do something useful (provision a DSL line, calculate a bill, etc). But all that data is ripe for analytics, either to perform additional tasks (like Xtract's customer churn prediction and service upsell suggestions) or to do existing tasks an order of magnitude better (like Aria Networks re-optimising the network for greater service resilience).

This is where the big OSS/BSS vendors are going to be differentiating their product range. Analytics is a natural bolt-on to existing OSS/BSS data sources, making it an attractive up-sell opportunity for vendors and a low-risk project for customers.  We can expect to see more acquisitions and product development in this space over then next couple of years.

 

Cisco Buys Bits of Comptel

It says here that Comptel is selling parts of its OSS portfolio to Cisco.

This is not the clear-cut Big-Vendor-Buys-OSS-Company that we are familiar with. No, in this case Cisco is acquiring a specific part of Comptel's OSS product portfolio: The Axioss suite picked up as part of Comptel's own acquisition of UK-based Axiom back in 2008.

Furthermore, some of the Axioss staff will move as part of the deal, but Comptel will remain in the OSS market with its other products and, perhaps most interestingly, will continue to offer support to their existing Axioss customers.

So, from Cisco's perspective it's a technology purchase, giving them the freedom to employ it however they wish, without the ball-and-chain of existing support contracts.

Cisco has a history of investing in OSS to augment the core iOS network management system. This investment has been both in-house development and acquisition. To my knowledge this is a first step-up to 'proper' fulfilment OSS, as opposed to stand-alone engineering tools.

Expect more of this in the next twenty four months: Anyone at recent events like TMW Dublin will have noticed how the traditional OSS vendors booths are getting smaller while hardware vendors like Huawei are Going Big.

Hardware vendors <3 OSS right now. This, along with the Ericordia deal, is the start of a second wave of OSS deals.

Update: The purchase price is 21.3 million Euros. Not bad in the current economy. Comptel acquired Axiom for 'up to' 21.6 million Euros, based on another slightly unusual deal that tied the price to their business performance for the year.

Comptel Real-Time OSS Benchmark with IBM

Comptel this week issued a PR about their recent benchmark results with IBM. It's a bit different from the Cramer OSS benchmark I wrote about a few weeks back when looking at a new BSS benchmark, also on IBM kit. For starters, Comptel's transactions are more billing and mediation than service design and provisioning. Secondly, the transaction volumes are huge! Billions of transactions per hour rather than thousands/millions one would expect in 'traditional' service provisioning.

The reason for this difference is Comptel's focus on serving large numbers of customer-initiated real-time transactions. This usage pattern, they claim, reflects the trend in 'lifestyle' services. I assume what they mean is that if you're offering, say, quad-play, there's going to be a lot of stuff to do in terms of billing and activation to get it all up and running. Then you also hope to sell lots of little add-ons or on-demand services which results in lots of little configuration and charging changes. Same situation if you allow users to regrade their services on-demand. And at any one time all those services/add-ons/subscriptions will require more billing and mediation, whether on not the service configuration is actually changing.

Comptel and IBM have achieved these figures using an in-memory database. Most popular, modern, system architectures with layers of web, Java and database components just can't deliver real-time transactions. I use the term real-time loosely to mean a transaction with latency acceptable to an inpatient end-customer. 'Acceptable' will vary depending on the transaction, but let's assume less than 10 seconds to do something like issuing an order for an on-demand service and that service becoming available to the customer.  Sure, a classic J2EE stack can turn-around a transaction, like a dynamic web page, in less than 10 seconds, but it's just one system. Service provisioning from order to activation requires several systems to complete their jobs (order management, billing, service management, activation, as a minimum set of distinct systems). This means any one system has to deliver their results consistently, while under load, in less than 2 seconds. Latency like this will only be achieved by minimizing calls between 'layers' inside the system, and minimizing or eliminating disk I/O by using in-memory databases or some very clever caching.

With the trend in lifestyle services I expect their to be a complimentary trend in OSS. Near-real-time inventory and design/assign transactions will still be needed, offering data resilience and transaction management for long-running processes. In parallel there will be real-time OSS processes that offer low-latency transactions. Today we are seeing OSS vendors promoting separate architectures for 'service management' solutions that can offer fast-track processes. However, there's no reason why these should be physically distinct applications that require integrating and synchronizing with OSS inventory. In the future, new OSS architectures will deliver more than one path from order to activation in a single system, depending on the transaction's latency requirements.