Programmability – reflects collection and analytics from all data from the referenced visibility and control automation. This data reflects that which is real-time and trended, across single streams or that which is correlated across multiple sources. The application of algorithms can be basic if/then/else or those which are more advanced against real-time, trended, and correlated datasets (leveraging Machine Learning and Artificial Intelligence). The extension of this programmability is also inclusive of inventory-centric use cases around what is physically in place (resource layer), and that which is logically in place (services layer). 

Overall, this is where CDX first shows up and drives the ability to ‘custom define’ what data to analyze, when to take an action. It also defines the ‘determined outcome’ of the actioning. Simple examples might reflect a notification of when network capacity hits a threshold alert, highlighting the need for a growth job. Other analytics-driven examples reflect control-loop actioning where a defined performance threshold or trendline is crossed, automated test and triage occurs, root-cause is determined, and automated remediation occurs, if possible. An example that is beyond that of if/then/else against specified datasets is that which is calendared, or scheduled, where specific times or days and times have a specified policy that is enacted (for example, different notification or decisioning for test or triage automation, outside of NOC business hours).

Service Infrastructure – reflects the ‘plumbing’ of how the respective network automations, advanced analytics, and customer defined actioning can be extended to consuming applications. This becomes examples of what is referred to as ‘make it look all the same’ as the Application Programming Interface (APIs) for the referenced automations look the same across disparate network elements, generations of technologies, varying OS releases, and broader. As an example, the API for ‘Get Inventory’ looks the same for next-generation network elements from one supplier as it does for legacy network elements from another supplier. This componentization of network automations is also extended to RESTful Web Services and Cloud Native architectures leveraging containerization, microservices, and dynamic orchestration, to extend these customer defined use cases and integrations to the broader ecosystem.

Personalization – As the last pillar, personalization becomes the consumption of the referenced Network Automation, standard and customized Data and Analytics, as delivered through RESTful Web Services. This becomes the enabler of Network-as-a-Service (NaaS), where an individual automation, series of automations, customized algorithm applied, and broader can be consumed by a network operator or their end customers. This NaaS framework can be leveraged for uniform integrations to legacy BSS/OSS, multi-domain orchestration within an SDN reference model, a customized UI/UX portal for operations, or extended directly to an end customer. We like to look at this as a bucket of building blocks, with each one representing an individualized automation, algorithm, in standard form or customized form, that can be leveraged as one brick, or a custom creation of bricks, as the enabler of a truly differentiated experience.

CDX in summary

In summary, a Customer Defined Experience reduces all the complexities of network and service automation, and advanced data and analytics and allows for programmability across the entire experience. The end output is a simplification that can be personalized for the ultimate experience.