It is very easy to think that a well designed mobile app is all you need to create a digital telco. While it is certainly important, it is far from reality. I often get asked to demonstrate the MATRIXX platform, and this generally takes the form of showing a consumer onboarding experience coupled with a number of use cases such as group sharing, asset exchange, gifting, application passes etc. This customer experience is loved by all. Who doesn’t want one-click purchasing and provisioning? This beautiful digital experience is based on a seamless interaction between a front-end app and a set of complex back-office processes that run in an automated manner with minimum human intervention.
I’ve seen several companies come (and go…), and they all have that look to capture the entire digital flow in the app layer without any direct network integration. Of course, this kind of overlay app is very appealing. Indeed, many operators are seduced by the promise of an instant digital makeover that costs virtually nothing, doesn’t impact current systems and can be live in a few weeks. Sounds impressive – where do I sign?
The issue though with this approach is that because the existing OSS/BSS systems are not touched or replaced, all the clever digital innovation gets pushed into the mobile app layer. It’s like painting racing stripes on an old car, but at the end of the day, it’s still an old car!
For example, to provide an application specific pass, rather than use a network traffic detection function (TDF) or the Deep Packet Inspection (DPI) capabilities built into many GGSNs, overlay companies typically take one of two approaches. Either they create a VPN that tunnels all the operator traffic through a cloud detection and control layer, or they rely on logic within the handset to control and monetize the applications used. Scratching under the surface of these approaches quickly uncovers numerous operational challenges:
I’m sure Amazon will love the approach of tunneling all traffic through their cloud servers, but it doesn’t create an efficient solution for an operator to have such a bottleneck. Remember this is not just the control plane processing, but all user traffic passing through this single point.
- Security Concerns
Operator security departments get very worried about channeling all traffic through an external environment out of their control. For approaches that rely on handset specific logic, this concern is magnified by the worry that the charging and control is now closer to a potential hacker.
- Handset Availability
A lot of these solutions are reliant on particular handsets which are usually Android only. Apple is a lot stricter about allowing applications to control access within IOS because it really goes against their business model.
Another problem area is that typically the overlay approach integrates into an existing Online Charging System (OCS), and relies on the current call and data session control components of the operator’s present-day architecture. This just increases the overall complexity with a split wallet and ultimately drags the OCS into the workflow for any new marketing proposition, thereby increasing the time to market. It becomes even more problematic when trying to implement complex sharing across family, friends, communities, etc. Can the existing OCS cope with the new digital propositions in terms of increased network signaling (quota management) and shared resource updates without additional hardware or a software update?
- Don’t Forget About Voice
The digital overlay approach often focuses purely on the data channel ignoring the need to process traditional circuit-switched voice and messaging. These are still hugely valuable assets for the operator that ultimately need to converge into any new digital offering. Not just left to die.
Amazon is often cited as a digital innovator and their growth has certainly been impressive. What makes them digital? It is the fact that entire end-to-end workflows are re-engineered. For example, their one-click purchase virtually eliminates human intervention except for the delivery driver, and soon even this human contact will probably be replaced as drone technology improves!
The clear point here is that you cannot engineer a digital experience as a veneer on top of existing systems/processes. Ultimately, the user experience will suffer as cracks appear when you increase scale or try to introduce new use cases.
At MATRIXX, we often talk about the importance of the digital path, i.e., what is the route from the source network data through to the end user, and is this path optimized for millions of interactions? Going back to the demo, the message I always try and get across is to think of the problem as an iceberg – the app is purely the visible bit above water. Below the surface, there needs to be a digital architecture capable of driving the clean, simple client experience that everyone expects. This architecture needs to include robust network grade integration that converges circuit and packet switched elements into a single user model that provides profiles, wallets and product offerings which can then be exposed to the user via a clean digital channel.