Does Your OSS/BSS Have a Power-to-Weight Problem?

Telecom architects often jump to the conclusion that more capability means better performance.

Add another feature, another platform, another integration, another automation layer and the system should become more powerful.

But I wonder whether a Formula 1 engineer would immediately see that perspective as a problem rather than a solution? To an F1 engineer, it’s more about reduction. More horsepower is useless if every improvement also adds weight, drag and complexity.

Perhaps OSS/BSS performance should be measured by what we can remove, not what we can add. Let’s explore that concept further.

.

F1 Engineers Obsess Over Milliseconds

F1 engineers spend every design day hunting for milliseconds and grams.

But they can only do that because the car’s design gives them the flexibility to experiment.

It might not immediately seem like it, but in F1 the milliseconds come from flexibility. In OSS, we wish for rapid responsiveness but architectures and change processes restrict us. Even the smallest changes generally take months to implement.

.

Power to Weight Ratio

An F1 designer doesn’t simply ask, “How do I make the engine more powerful?”

Power matters, of course. But so does weight, balance, aerodynamic efficiency, tyre performance and how all those elements interact.

There’s an interesting parallel here for OSS/BSS.

We tend to equate more capability with a better architecture. More automation. More orchestration. More data. More platforms. But every capability adds weight.

I wonder whether a more useful way of thinking about OSS/BSS might therefore be its power-to-weight ratio or Newton’s Second Law of Motion (F = ma)?

How much useful business and operational capability are we delivering relative to the architectural weight required to support it?

.

Measure how fast the OSS can Change, not just how Fast it can run

Imagine two OSS platforms.

1. One responds to an API call in 50 milliseconds but requires three months of analysis, development, integration and regression testing to support a new feature or bundle
2. Another takes 100 milliseconds but can accommodate that same commercial change in days

Which is the faster OSS?

.

Drag is often more Important than Horsepower

When an F1 car needs to go faster, adding more power is not always the answer.

Sometimes it’s better to reduce drag.

OSS/BSS has drag too.

Every additional hand-off creates it.

Every user interface, adapter, transformation, workflow, database and integration creates some form of resistance to change.

Individually, each addition can be entirely rational. It solves a problem. Adds a capability. But the effect is cumulative.

.

Optimise the Whole Car, Not the Individual Components

An F1 championship is not won by assembling the highest-performing individual components available. Everything has to work together as a system.

Optimising one element can compromise another. OSS/BSS is clearly no different.

You can have an outstanding inventory platform, a powerful orchestration engine and an advanced assurance solution and still end up with an OSS that is slow to change.

Individual platforms can meet every performance target while the end-to-end architecture struggles.

That’s because the customer, service or network outcome does not care which component was responsible for the delay.

It experiences the complete system. F1 teams are exceptionally good at systems engineering.

.

Don’t wait until Race Day

There is one more lesson from F1 that matters here.

Teams don’t wait until race day to discover whether an idea works. They model. Simulate. Test. Measure. Change something and test again.

The wind tunnel exists so that learning can happen away from the race.

OSS/BSS needs an equivalent. Would you believe we already have an equivalent, but we don’t use it to chase flexibility and speed like F1 teams do?

Non-production can be more. It can be our wind tunnel. Not simply just allowing us to confirm that the next release doesn’t break the previous one.

It can (and should?) be somewhere we experiment constantly. It can be our digital twin where we can perform “what if?” scenario planning:

1. What happens if we remove this dependency?
2. Can this process be simplified?
3. How does the architecture behave at ten times the volume?
4. What happens when a network component fails?
5. Can we introduce a new product without modifying six surrounding systems?
6. How quickly can the OSS respond when the business, customer or network needs it to do something different?

What do you think? What can we learn from F1?