Multi-vendor, multi SLA: Join us at the coal face

Oh, how I remember the good old days, working as a support engineer in telecoms during the late nineties, early two thousands. The demand for mobile phones seemed endless as did the money available to build and support the networks. We would usually interact with one vendor and anything we asked for we would get; training documentation, engineers, customized solutions outside the defined SLAs. Vendors were so busy dealing with the explosion in sales that any support issues were an afterthought. Support engineers had the flexibility to develop and investigate without budgetary or time restrictions. The situation was probably a CFO’s nightmare, but it did produce results. The whole industry was moving at break neck speed, but the operators were able to keep up and deploy new infrastructure and services on an almost monthly basis.

Then came the intervention by governments, politicians and in their endless wisdom realized the value of radio spectrum and started to initiate 3G license auctions. Any operator of the time realized that without the relevant license you were no longer an operator. The result was a highly inflated valuation and a very large cost to the operator that they had to then focus on recuperating. The main target for reduction was operations costs, which is still true today. This took the form of restrictions and reductions within operations but also pressurizing vendors for discounts and reduced costing. Now that the vendor’s bottom line was being impacted, they in turn responded with reductions and reorganizations in the areas that supply support services to operators, tightening up of SLAs and enforcing strict compliance.

Suddenly my life as a support engineer had changed, the honeymoon period was over, except I didn’t know I was on a honeymoon. Lead time to resolve CSRs became longer, there was now discussions as to who is responsible for the problem, support engineers on both the operator side and vendor side had to justify all activities. It became a case of vendors and operators sweating their assets, which in this case was the support engineers.

However, network quality had to be maintained so the engineers had to overcome and deal with the new reality. This was a challenge but one aspect that was still an advantage to the operator was that in most situations they were still dealing with one main vendor, one vendor one SLA. -vendor multi SLA environments bring another layer of complexity to the task of keeping a network alive and breathing. It has become more common in recent years for an operator to involve more than one vendor however there are still a large number recognizing the benefits both commercially and technically of betting on one vendor. However, once again, due to the intervention of governments that is about to change.

This time around the intervention is not due to the latest spectrum auctions for 5G, which still has impact, but the industry has adapted, no this time the intervention hits at the very core of the decision making of what technology and what vendors the operator can and should use within their network. The drivers behind such developments whether it be related to economic, geopolitical or security reasons are for another days discussion What can be stated is that it has and will have major impacts on the operator’s costs and decision making now and in the future. With the introduction of 5G, which brings with it among other things smart cities, autonomous vehicles and industrial automation, societies reliance on network-based technology is about to go nuclear. Governments have woken up to the fact of how critical operators’ infrastructures are to both the security and GDP, so this new development is not going to fade away.

What can operators do to overcome such challenges? In short, they will have to diversify both in technologies and vendors. The joy of a single vendor environment is going to become a thing of the past and the battle worn support engineer’s life is about to get that little bit more complicated.

In relation to a multi-vendor environment, this brings a lot of overhead to the lead time to apply changes and resolve issues. In certain scenarios the operator’s first and second line engineering groups may have to deal with several vendors for one issue, opening multiple tickets, all working off different SLAs. In such an environment it can take longer to find the correct owner of a fault than fixing the fault itself. With this ping-pong of issues between vendors, we are looking at an impact on the operator’s ability to maintain and deliver services.

As well as this, it is also recognized that the operator needs to diversify with regard to the technology used. For this reason, these global developments can be seen as giving a boost to such initiatives as OpenRAN which allows for the opening up of the radio-based technology. In effect it allows for new technologies and companies to become involved in the area of the network that normally falls within the domain control of a small number of vendors, which in the long term gives the operators more choice. Whereas this can be seen as a positive development for the industry it does also mean that the already overloaded operators engineering groups will have to expand their core knowledge skills even further.

For me I jumped ship a while back, although I haven’t moved a million miles away. The company I joined, Aspire Technology, is heavily involved in telecoms from development to managed services to optimization. One of the approaches we have taken is to identify the continuing challenges facing the operations layer within the operator’s environment from this we tasked ourselves with creating a structure that effectively deal with issues in an efficient and cost-conscious manner. This takes the form of a tiger team approach which consists of telecom domain experts, data scientists and developers, all backed up by a suite of service enabling tools. We position ourselves not to sit back and wait for issues to be raised but to join the operators engineering teams right on the coal face. But when we arrive, we don’t bring another pick axe we bring a JCB The concept is to work side by side with first/second line and pro-actively detect and resolve issues by maximizing the use of existing infrastructure and automating tasks, our motto is never to fix the same problem twice. In taking this approach we greatly simplify the complexity of working in a multi-vendor, multi SLA environment. We have put this in place for certain operators and the impact has been significant, a large reduction in CSR escalated to vendors, a large reduction in the overall network management traffic and a significant improvement in network quality and availability.

From the operator’s perspective this approach can be seen as a fast and effective way to introduce automation into their environment at an acceptable cost level, since the process builds upon the existing skills and infrastructure within operations. Also, where necessary, our task teams have access to specialized back office support units such as for accessing Aspire OpenRAN lab to performance benchmark new devices and solutions.

Even excluding the issues facing operators in the operations layer as mentioned here, the environment facing today’s operators to maintain profitability while delivering state of the art services is challenging. We strongly believe within Aspire that our approach goes a long way to help the operator, at least within operations, to improve network quality while reducing OpEx. As for me, well I’m just happy to give the support engineers a bit of breathing space.