Chat iconGet in touch

Traditional BSS and implementation pain

By August 27, 2014 No Comments

Working for a cellular operator in a previous life where, as a manager responsible for pricing,  I experienced firsthand the development cycles typical of some of the large and traditional BSS vendors. These cycles were often fraught with delays, confusion and interruptions. These were not just stones in your shoes, they were stones worthy of consideration by the builders of the Great Pyramid at Giza.  If I can mix my metaphors, Sisyphus would think twice about this rock.

The cycle dictated by the supplier to meet their business needs spanned at least nine months, all going well.  All too often, the ability of the operator to compete was limited by the processes and procedures of the supplier.

First of all, there was a period of consultation, of business definition and of estimation.  A tedious but necessary period to set out requirements clearly, without ambiguity and to determine the effort required to develop the functionality.  But three months?

Sometimes three months would have been a dream come true.  If Oracle issued a new release or a network vendor installed a new network element, that could take development effort sufficient to knock your commercial functionality to touch, three months became six.

The second trimester was the “black hole” period, that time when a team of developers was feverishly beavering away writing code and testing the results and building up the great edifice of a solution. 

As an aside, I set out to meet the dedicated team once, that band of brave souls proudly writing code.  They seemed a decent enough bunch but it was fairly obvious that this dedicated team had not met before.  They were getting on famously, wonderfully, getting to know each other, but work mates, a team they were not.

To get back to the spec’ed and developed solution, at the end of month six, it was delivered to the operator!  Only to be tested again by my IT department and a whole team doing functional and regression and conformance and security and just about every kind of testing, known and unknown. 

Of course, the team really was a team; a team that could be pulled off the project at a moments notice if a production issue arose.  And the test environment seemed to have an issue with stability and conformity and, well testing.  It was not a priority compared to live, customer-facing systems so it suffered from a bit of neglect and attention.

And finally the great day would arrive and we could move the lump of functionality into production and generate some revenue from it, add to the bottom line, and pay for all that time and effort.

Now imagine just how much better a world it would be, how much more agile a business would be, how better able to compete with OTTs and the myriad of new business models if virtualized Policy and Charging solutions were available.  Take off that shoe and shake out that stone.

Brian Noble, Research Manager, Openet. Brian has previously worked for a number of mobile operators.