The principle of middleware has been around for a long time. I remember Tibco rising to fame in the mid 90's with the concept of an enterprise service bus (ESB), a software concept that mimicked the hardware bus found in computers, and which allowed components such as memory, CPU and disks to talk to each other. The idea is very simple - don't integrate multiple systems with each other (point to point) but integrate into a common layer once and allow data to be routed and transformed to whatever system needs it.
Within telco, this has sparked huge transformation projects where multiple stacks are converted into one with postpaid, prepaid, enterprise, mobile, and fixed all coming together into a single stack with all systems communicating via middleware.
Today, there are a plethora of micro-services that can expose an API; and organisations such as TM Forum, provide standardised specifications for how these services should interact with each other. You would have thought that over two decades, we would now be close to the ideal architecture and yet, why is it that operators are still struggling with big IT projects to better serve their customers?
Scratch under the surface and the concept of integrate once gets immediately forgotten when it comes to customer engagement. Operators build a web app and then decide they should build a mobile app for iOS and Android. Following this, marketing then decide they need a WhatsApp bot to better serve their customers and so the story continues.
Public cloud technology has been instrumental in making each of these Touchpoints easy with tools such as AWS Connect and Google Dialog providing engagement services such as messaging or voice chat. However, in the rush to provide new Touchpoints, the lessons learned from years of architectural refinement are thrown out the window and you can end up with multiple stacks on the front-end serving up the same back-end data using the same underlying journey but just in different formats.
The customer journey is critical here. No matter the Touchpoint, there are a set of customer journeys that are required. If you separate the journey from the channel using middleware principles, the implementation becomes much easier, and marketing can launch that new AR experience in a matter of days.
Say that I want to top up my account. The journey is fundamentally straightforward: understand that I need to top up, decide how much and confirm my intent. This journey might be carried out within one digital channel, or it might be across multiple Touchpoints. For example, I might receive an alert on my AR headset warning of a low balance but use Google Assistant to request a top up using my default payment method.
If only there was a middleware for the frontend where each customer journey was already pre-configured, you could try calling it Topware or Frontware! A system that could take all the public cloud goodness but wrap it all up into a single service that integrates once into any legacy BSS while simultaneously providing a wide range of digital Touchpoints for a customer.
Well, there is and given that topware and frontware are lousy names, we called it AwareX instead!
