It used to be that when someone talked Service Assurance it was all network performance and SLAs. Very soon – if not already – this cannot be the case. Service assurance ties directly to customer satisfaction and brand perception; if services and networks don’t appear to perform flawlessly, operators take hits. Sometimes that hit is poor word of mouth. At an enterprise level, that hit can be abandonment, because in a virtualized cloud society, there are too many big name competitors that make on-boarding easy.
Right now, the industry is like a three legged man straddling three lines – legacy circuit networks; last gen packet networks that used to be called next-gen; and the new next-gen – highly virtualized network and data center environments that constitute “the cloud.” The cloud world focuses on access to applications and high performance, transactional processes that appear to experience little to no latency. Expectations are rising too; customers don’t only want things to work on-demand – they expect real-time.
When a user pushes a button, whatever is expected to happen occurs instantaneously. Whether that’s opening a productivity application that lives in the cloud or making an in-app purchase, users now expect immediate satisfaction. A little delay some of the time is tolerated. A lot of delay any time is never tolerated. A little delay all of the time is considered weak. In this environment, service assurance must live up to its name; assure that the service lives up to extreme expectations.
As a result, Service Assurance can’t be measured after the fact. It’s not post-facto reporting that kicks back to SLA terms. It’s becoming a real-time function that is an inherent part of any service. It should measure how specific components of each service have performed – or failed to - in order to drive underlying improvements that result in better performance going forward. More importantly, however, it needs to take on a more active role – one that crosses over into the service fulfillment domain - in assuring actual quality of experience within the flow of a customer’s interaction with services.
As a result, for many operators this may require a re-think of service assurance architecture. An architecture that stands alone and evolved purely out of the NOC world may not cut it. Service Assurance needs to have a view of network and service resources and a close connection to service fulfillment. It will be inherent to MANO capabilities in the NFV world. It also likely needs to be policy driven so that thresholds tripped in any of these areas – lack of resources, bottlenecks in fulfillment, or degradations or failures in the underlying network – are adapted to as close to real-time as possible.
In the NFV world, capabilities like elasticity and automated recovery characterize the smart, policy-driven, responsive requirements that service assurance must take on. Ultimately, it adds up to the need not only for end-to-end service assurance, but for end-to-end OSS that supports the entire on-demand service lifecycle in unified, responsive and adaptive ways.
Photo by Richard Leeming with Creative Commons license
We have created a low-volume (not-spammy) newsletter so that you can easily keep up with what's going on in the industry.