While I’m not one for buzzwords (and the telecom industry is awash with them), agile implementation is more than a trendy tech phrase. It’s something we need to take seriously.
It is especially true for operators that want to be successful in transforming themselves into digital service providers. Success means embracing agile at the core of the business – from how new technologies are selected, all the way down to the people who are tasked with implementing them.
Timing is everything in business. According to Salesforce research, 76% of IT leaders say that speed of application or project delivery is a critically or very important KPI, and 67% of IT leaders say that improving the speed of development cycles is a critical or high priority. Unfortunately, most telco operators are hamstrung by deeply customized (or home-grown) solutions that are expensive, time-consuming, and risky to change.
Innovation & The Frustration of Telco Operators
I’ve spoken with many operators around the world and the feedback I hear astounds me. For example, one operator told me that due to the complexity of their home-grown digital platform, it takes two weeks just to change the price of an SMS, and another explained simply adding support for a new Diameter AVP usually takes several months. Not too long ago, a different operator provided a use case for our team at MATRIXX Software to analyze. They had been trying to implement with their existing incumbent vendor for over nine months with no success. So much for telco innovation.
When you dig into the details, you find that many telco operators have a tangled web of outdated systems and cumbersome processes. It’s no wonder they have all of this pain when it comes to trying to innovate and deliver new products.
Configuration and Agile Best Practices
It is very common for operators to send me and my presales colleagues a set of use cases that they are currently implementing, or plan to do so in the future. They typically ask us to come in and explain if we can support them and if so, present some slides as to how we might go about the digital transformation implementation. However, in my experience, at least 95% of all the use cases I receive can be implemented purely through configuration.
This is one of the most enjoyable parts of my job (maybe I’m just weird). Rather than explain how we would implement, it’s quicker, easier and more exciting to implement them by including writing test cases in our highly flexible test framework, so that I can demonstrate and prove that they work as expected.
Recently, I was provided a set of about 15 use cases ranging in complexity and covering both consumer and shared enterprise that a digital telco operator explained couldn’t be implemented within their existing platforms. I spent around seven days implementing and testing them. A week or two later, I demonstrated the configuration and execution of the use cases in a workshop with the operator.
Delivering Telco Innovation: From Configuration to Implementation
To do this, I spin up a virtualized development environment on my laptop, which is in effect a complete installation of MATRIXX, but with a few unneeded components turned off. I then start configuring and testing each use case until they are implemented correctly, taking anywhere between an hour to a couple of days depending on the scope and complexity of the use case.
I must admit, I take the ability to spin up development environments when I need them and the capacity to easily move config between environments (dev, test, pre-production, etc.) for granted at MATRIXX. However, I do recall during a POC an operator telling me that one of our competitors had needed to carry in a physical server just to demonstrate the implementation of some use cases.
I Am Only Agile for Agile Project Development
Luckily for me and my back, I don’t need to carry any servers around. Still, the downside of not just going the slideware approach (and showing the real implementation in the configuration GUI and running test scripts that create subscribers, enterprise groups, buy offers, inject traffic, etc.) means that at the end of it you don’t have any slides to give the operator when they ask.
That is why when the workshop was over, I spent a day documenting the configuration and test outputs. I wanted the operator to have a detailed reference of everything they had witnessed (even though I don’t find the documentation part anywhere as much fun as the implementation).
The configuration flexibility in MATRIXX allows me as a presales engineer to quickly implement, and these capabilities can truly transform the way operators innovate and launch new services in the digital age.