Ruthless Simplification

One challenge we faced was that product managers tend to introduce products with too many variables to manage. For example, we had an ATM/Frame service that could be configured across 12 billion combinations. Well, how do you build an ordering system with so many variables? The answer is to simplify the product options, so at AT&T we boiled down those 12 billion combinations to about 200.
Hossein Eslambolchi
, CIO/CTO of AT&T.

OSS projects are renowned for going over time, over budget and under-delivering. There are many reasons for this, but the main one is complexity – read layer upon layer of cross-dependencies. I’d rather be working with 200 variables than 12 billion, that’s for sure!!

Whether you’re starting with a greenfield OSS or operating an existing one, ruthless standardisation and simplification should be at the top (or very near the top) of your priority list.

As Eslambolchi found, if there are 12 billion configuration combinations in a single element type*, how complex must your B/OSS become? I have designed interface integrations to a number of legacy voice switches that have in excess of 10,000 A4 pages of command options, so it’s not just ATM that has this level of complexity.

But if we use Pareto’s 80:20 rule the number of combinations is rapidly reduced. Take ruthless simplification to all products in the product catalogue and it becomes simpler again.

The simplification propagates through the CSP, including:

  • Simpler Order Entry
  • Simpler operator training
  • Simpler fault resolution
  • Simpler processes
  • Simpler network interfaces
  • Simpler customer contracts and service levels
  • Simpler reporting
  • The list goes on, but ultimately it leads to
  • Simpler OSS
  • Simpler BSS

But this means the “Ruthless Simplification” ethos must come from the top of the CSP’s hierarchy and must filter through all business units, not just the B/OSS teams. What happens if you’re not at the top of the CSP’s hierarchy? Your message must be all the more compelling to ensure that it gets pushed up through the layers of management.

You may even need an independent consultant to create the sense of urgency higher up within your organisation.

As an aside, it always fascinates me that during a major transformation there is almost always more thought, attention and energy given to the new tools rather than undertaking extensive simplification/rationalisation of the old tools.

Eslambolchi introduced the Concept of One to AT&T, whereby he reduced 70 ordering systems down to one and in doing so, vastly simplified the AT&T operations. Can your OctopOSS be similarly simplified?

As a second aside, I wonder what the BYOD (Bring Your Own Device) trend will do for OSS. Without having analysed this in much detail, it would seem that the proliferation of devices will increase complexity further in most OSS.

* Note: Whilst ATM was the more powerful protocol than Ethernet, it is interesting that ATM has been almost completely superseded. It seems that this is largely because of the complexity of ATM (ie 12 billion different configuration variations means an inordinate amount of testing, not to mention the training and expertise required from the operators of ATM versus Ethernet). Interestingly, whilst Ethernet is almost ubiquitous now, the next disruptive technology is likely to be even simpler than Ethernet and all the associated protocols that have to be added to overcome shortcomings such as QoS, lossless transmission, etc.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.