“End to end” thinking is a mantra in our industry. We have always felt need to understand the entire experience delivered by service, ideally as a customer sees it.
This much is true.
Too often however, and driven by (many) decades-old technology and practices, we mistakenly believe this means building monolithic network/service models, fulfillment processes, and assurance processes. This practice must end if we want true agility. Rather, it is imperative that we move to a very different conceptual model – one of loosely coupled, autonomous (and likely autonomic) domains.
Why? Consider three scenarios:
- Scenario #1: An SP is involved in a digital collaboration with a network of health providers, medical devices (“things”), and a medical technology company operating cloud based services. Each of these firms will manage it’s own “domain” and therefore they must be loosely coupled. In fact, service provider engineers may have little knowledge that they even exist.
- Scenario #2: Virtual technologies such as NFV, SDN and modern RANs must be self-managing (autonomic). Therefore, they too must be loosely coupled to any telco-wide E2E view and service model. Within each domain NFVs may be moving and scaling, SDN flows re-arranged, and RAN parameters dynamically optimized by SON. It is neither possible nor desirable to micro-manage them as part of individual services.
- Scenario #3: A new technology or administrative domain is added, or the management method for, say, NFV is dramatically upgraded. We want to have minimal impact on E2E processes and minimize the integration nightmare. So, once again, loose coupling to the rescue!
The common thread to all of these is that each domain maintains its own detailed view, domain specific algorithms and methods, and [highly dynamic] state, and abstracts and exposes a set of “service” characteristics to E2E processes, whether fulfillment, assurance, capacity expansion or other management tasks. Engineers accustomed to having detailed drill-down available need to get comfortable with a more abstracted view. On the flip side, there will be parallel teams (in other departments or other firms entirely) managing those domains in more detail.
Within those domains, processes will become incrementally and inevitably more automated. The volume of configuration changes and the complexity of data demand automation, and as well, automation can yield lower costs and proactive maintenance – a better customer experience. There’s a joke in the airline industry: tomorrow’s jet cockpit crew will consist of a pilot and a dog. The pilot’s job is to supervise the autopilot. The dog’s job is to bite the pilot if he touches anything J
Form our surveys of the industry this may be accepted by some in principal, but in execution we are far from adopting a true, multi-domain approach. The Appledore Research Group framework architectures and best practices are predicated on this need – the following is taken from an upcoming major report:
Several suppliers are advocating just such approaches. CENX has re-vectored its entire business to emphasize a federated domain approach to active service assurance. NOKIA is applying these concepts in part to rationalize and modularize its huge and growing portfolio of OSS capabilities – from SDN to SON to MANO to … Netcracker’s inventory vision is one of multiple, loosely coupled, autonomic domains abstracted to an E2E view. So far, our service provider deployment data does not indicate widespread adoption and deployment of this approach, but we expect – and hope – that “next step” is coming.
For more information on this topic we refer you to our published research on closed-loop automation, automated service assurance, dynamic inventory, and our upcoming research on best practices in orchestration, modeling and onboarding, all available (with subscription, or individually) here.
Enjoy!
Grant