The OSS Whale Curve

The diagram below shows what is known as The Whale Curve. It shows a graph of the relative profitability of each product in your product mix.
The Whale Curve
From the book, “Waging War on Complexity Costs,” by Steven A Wilson and Andrei Perumal, which I’m currently reading.

You might be wondering how a profitability graph could ever peak at over 100%. After all, a company can only ever have a profitability of 100% of whatever its profits are, regardless of whether they’re large or small. But what this graph shows is that 20-30% of the products (or customers or assets, etc) are generating up to 300% of an organisation’s profits, whilst the remainder are actually destroying roughly 200% of profits.

The title of the book appealed to me greatly because two of OSS biggest pitfalls are complexity and cost. Not only that. They’re also usually closely related, as described in “The Triple Constraint of OSS.”

Many of the complexity factors hitting an OSS are beyond our control. We’re downstream of many of the complexity decisions made within our customers’ organisations. When you look at the CAPEX allocation graph below, which end of the scale do you think implies more complexity?
Global CAPEX
I’d suggest the right-hand side bears more complexity. It shows an estimate of global CAPEX allocated by telcos over a 30 year period. The right-side represents CAPEX being allocated to networks of all shapes, sizes and topologies with an even broader array of services and service configurations running on them. The left-hand side probably represents a predominantly voice-network spend at a time when most revenue tended to be generated by voice calls and ISDN services.

I don’t have a graph that represents profitability of the Telco industry over the corresponding 30 year period, but you can roughly guess that profitability is trending inversely to CAPEX allocations.

The whale curve hints at some provocative statements for our industry:

  1. Many products in a telco’s product mix are going to be delivering disproportionately more costs than revenues
  2. Many of the costs have arisen from the increasing bloat of complexity from more network types, more product lines, more configuration options, more pricing bundles, etc
  3. That complexity funnels into their OSS, which drives up complexity costs
  4. Most OSS are run as cost centres, generating negligible direct revenues, placing them on the endangered side of the whale curve
  5. If we want budgets to continue to be allocated to OSS projects, we collectively have to find a multitude of ways of dragging our OSS over to the left-hand side of the whale curve

Just one last thought – network virtualisation is touted as being the upcoming saviour of the telco industry, the great cost reducer. But do you also feel that complexity costs are only going to go up when virtualised networks are installed alongside existing/legacy network platforms? Perhaps once legacy kit is progressively removed then complexity costs “might” finally start to come down… although the march of CAPEX allocations tends to indicate that the Telco industry hasn’t been great at subtraction projects in the last 30 years – not on their networks, products or OSS.

Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email

5 thoughts on “The OSS Whale Curve

  1. I wonder if data rather than voice is the breaking point for telco, when the Internet of things and data replace voice the complexity may move into the application rather than the OSS?

  2. Hi Scott

    Yep, commoditised data is the first break point and virtualisation (ie putting networks in software) will definitely add complexity like you say

  3. I am not sure that I totally agree with this. Complexity can also be a source of value. The problem with telecom is that the complexity is not valued (while e.g. in pharma it might be valued). In the pre-liberalisation PSTN world, the low ROC of telecom was not a problem as it was inline with cost of capital (a low risk, steady monopoly business). With liberalisation and innovation (mainly mobile), telecom got trapped in a situation where ROC and cost of capital diverged. I do not believe that OSS can help with improving the “R” of the ROC equation. But I believe that it can improve the “C” side i.e. help operators to spend their capex more wisely. But for this to happen, the CFO has to get involved in the OSS selection.

  4. Great comments Roland.
    I agree with you on all counts… with one minor exception. I believe that we can improve the R in ROC and should be looking at ways to do so if we wish to remain relevant. We can’t push into the left side of the whale curve without it. For example, taking a look at items in managed service contracts CSPs offer to enterprise and seeing how OSS can deliver those services in an automated or semi-automated way. Or take the claim that salesforce delivers over 50% of its revenues via APIs. As an industry, we’ve barely touched on what value our OSS can offer via APIs and access to data (noting the need to avoid privacy conflicts, etc of course).
    I do love your statement about complexity being of value. It’s not something I’d previously thought about but it is also discussed in the book referenced within the whale curve post. I also agree wholeheartedly that we’ve barely touched how OSS / BSS can help operators direct CAPEX allocations better.
    Thanks Roland. Great insights!!

  5. Scott said:
    “I wonder if data rather than voice is the breaking point for telco, when the Internet of things and data replace voice the complexity may move into the application rather than the OSS?”

    Hmmm … I fear that this hope may not deliver as much benefit as envisioned wrt OSS. Some form of OSS will still be required to perform traditional OSS functions in “support” of these new services across networks. I have difficulty visualising how OTT applications will manage traditional OSS functions (e.g., FCAPS – Fault, Configuration, Accounting, Performance and Security management etc.) into networks owned, provided and operated by separate enterprises.

    Okay, maybe Configuration could become an application function if operators expose highly-standardised, flexible low-level transport services … and Security, if applications assume that networks provide none and manage this independently as a result. However, I would not want to be an application provider responsible for managing fault remediation and performance of my applications into a complex operator’s network which supports maybe millions of other subscribers.

    Some of these concerns already apply directly to cloud services. However, the deployment models which are developing to support applications in cloud environments are radically different to traditional corporate computing infrastructures. To achieve similar capabilities for IoT and data services, telecom operators will also be required to transform their OSS environments radically … hence coming full circle on this discussion and adding even more OSS complexity.

Leave a Reply

Your email address will not be published. Required fields are marked *