WIXLIB

Converging IT and network teams: a cloud-native automation platform is the catalyst for successful operations 4network. Both sides need to work closely together if operators are to exploit the potential of network‘softwareization’ and become truly agile.Operational barriers to network automationTo automate their network operations effectively, operators need to bridge the separate and often antagonisticroles IT and network departments play today in managing the physical network. The network organization isconnectivity-driven. It concerns itself with defining the architecture of the network in various domains anddeploying new boxes - network elements - to fulfil that architecture. It does not typically consider the broaderservice delivery and assurance context– the ‘service wrap’ needed before services built on top of the newnetwork elements can be sold to customers. The network organization manages and assures the networkelements themselves, but once the boxes have been deployed, it ‘throws over the wall’ to IT the challenge ofdesigning and managing the customer services that run on them and their end-to-end SLAs.The IT organization builds process (workflow) support for the fulfilment and assurance of customer-facingservices but many of the individual steps in these processes, such as the configuration/activation of individualnetwork elements or the identification of a service-impacting network fault, need to be manually implementedby the network organization. This leads to back-and-forth manual handovers between IT and networkdepartments, which add cost, complexity and error. There are many reasons for the often-fraught relationshipbetween IT and network organizations, such as the following. IT/network departments have different priorities and objectives. Network departments do not alwaysconsult IT departments as extensively as they could on how easily new network elements will integrate withexisting operational systems (OSS), what interfaces they will provide or what their management needs willbe. As a result, when new network elements arrive and are deployed, IT departments are often blamed forthe long period of time that it takes to operationalize them. Network departments fear losing out on newservice revenue: IT departments are aggrieved that their network colleagues have increased the complexityof their integration environment by failing to seek their advice on the new equipment’s operationalrequirements. Network organizations’ tendency to bring in new network elements to run new services whilemaintaining multiple previous generations of equipment supporting existing services, encourages theproliferation of management silos. This means more integration complexity, further slowing down the paceof change and adding cost. ‘Not invented here’ attitudes to automation abound. IT may implement automation to help with processconsistency and rigour, but it cannot enforce its use. Network engineers are used to manually changingnetwork element configurations to ‘get the job done’ and are notorious for not informing the IT keepers ofkey data systems – such as the inventory system – that they have done so. It is all too easy for the networkand its OSSs to lose synchronicity, resulting in ‘dirty’ data and configuration errors that can cause orderfallouts or even bring down the network. Both outcomes can be costly in terms of lost business andreputational damage. IT and network departments use disparate management tools and approaches. Feedback between ITand network departments has historically been slow because they are separate organizations dealing with acommon activity – the management of the network – using different tools and systems. The networkorganization deals with element and network management systems (E/NMS) within the network operationscenter (NOC); and the IT department deals with network and service operational support systems (OSS) ofrecord. If E/NMS are integrated at the software level with the IT department’s OSS, a certain amount ofautomation can be supported; otherwise, the two departments interface with each other manually. Analysys Mason Limited 20182: Accelerating the pace of network operations

Converging IT and network teams: a cloud-native automation platform is the catalyst for successful operations 5To overcome these organizational barriers, operators are beginning to look at Agile/DevOps ways of workingthat bring together different organizational functions and help them collaborate. Agile/DevOps methodologiesreplace the waterfall model where each team creates an output and ‘throws it over the wall’ to the next functionin the process. The waterfall model is anti-agility in that its phases are sequential and therefore time-consumingto execute; and it can result in expensive rework if upstream requirements become misaligned with downstreamoutputs over time. An Agile/DevOps model supports the incremental, collaborative and holistic development ofoutputs. It eliminates the communication and responsibilities gaps between those specifying and creating theoutputs (‘developers’) and those deploying and operating them (‘operations’). DevOps has a specific meaning inthe software world but its lessons on collaborative working can equally apply to network/IT organizations thatneed to create the automated, virtualized network together.Network virtualization as a catalyst for network/IT organizational convergenceNetwork virtualization is becoming the catalyst for operator adoption of agile/DevOps methodologies acrossnetwork/IT organizations.IT organizations are being asked to support NFV with data center/cloud components and associated automation(see Figure 2.2). They know how to run IT applications in such environments, but they are not familiar with thespecific behaviours and requirements of network functions. VNFs can behave very differently from ITapplications, especially when they are chained together as network services, and make many more demands onthe cloud to ensure they can execute with the right levels of performance and availability.Network organizations are investigating software defined networking (SDN) as a means of expanding nearreal-time control over the network (see Figure 2.2). SDN involves the automation of key manual interactionswith network elements, for example, for activation, configuration and monitoring/data collection purposes.Building this automation requires knowledge of scripting and data modeling languages, applicationprogramming interfaces (APIs) and other code-related skills. Network engineers, who have spent their careersmanually manipulating command line interfaces to network boxes, realise they need to acquire similarprogramming expertise to their IT colleagues.As IT and network organizations increasingly need to work in each other’s domain, they can benefit from acloser relationship with one another. Many operators are bringing their IT and network operations teamstogether in a single organization, through executive mandate. Changing the organizational structure, however,may not be sufficient to force people from different backgrounds out of their comfort zones to sit, talk and worktogether. Operators need a hands-on method of encouraging collaboration and shared experience if they are tobreak down remaining barriers within their new combined organizations. A common automation platform, withshared tools and capabilities, is a practical means of encouraging everyone to ‘speak the same language’ andshare knowledge, the essence of collaboration. Common tools help blur the boundaries between separate teamsand accelerate the cultural change necessary to enable digital operation Analysys Mason Limited 20182: Accelerating the pace of network operations

Converging IT and network teams: a cloud-native automation platform is the catalyst for successful operations 6Figure 2.2: IT and network organizations are approaching automation and virtualization from NFV and SDN anglesrespectively, driving the case for collaboration and convergence3. Requirements for a cloud-native platform for automatedoperationsThe TM Forum has defined an end-to-end architecture for future business and network operations. TM Forumhas specified the requirements for implementing this architecture as a cloud-native platform that can be used byboth IT and network organizations and joint IT/network teams working on network operations. The networkoperations platform is a subset of the holistic TM Forum Open Digital Business Enablement System shown inFigure 3.1. Analysys Mason Limited 20183: Requirements for a cloud-native platform for automated operations

Converging IT and network teams: a cloud-native automation platform is the catalyst for successful operations 7Figure 3.1: TM Forum Open Digital Business Enablement System [Source: TM Forum, 2018]In line with the TM Forum’s best-practice thinking, the cloud-native operations platform that serves convergedIT/network teams should have five key attributes: data-centric, not process-centricmicroservices-based, using open APIsAI-capable and autonomousreal-timeable to support platform business models, the basis for a digital service provider business.Benefits of a data-centric architecture for cloud native operationsOperational data is highly siloed, both between IT and networking organizations and within them, Today, asFigure 3.2 shows, different OSS/NMS are associated with different layers of the network and network domains(for example, fixed/mobile/enterprise services). Operators need to create complex processes to ‘join up’ thisdata and make it accessible to the stakeholders who need it; increasingly, in a digital environment, this includesthe operator’s customers. Analysys Mason Limited 20183: Requirements for a cloud-native platform for automated operations

Converging IT and network teams: a cloud-native automation platform is the catalyst for successful operations 8Figure 3.2: Siloed OSS/NMS create process and data complexity that is difficult to automateIn a data-centric network operations architecture, all the data from an inherently distributed system – thenetwork – is collected in one place, leveraging recent advances in database technology. The data is thenavailable in real-time to any stakeholder/task that needs it, with both IT and network operations sharing thesame source of truth. A data-centric architecture enables the logical centralisation of network control andmanagement – the goal of SDN. This is a further incentive to bring IT and network operational teams together.Centralization enables teams to work with a common platform while still interacting with network data, forexample, to view the SLAs of customer-facing services, end-to-end network topology, the configuration statusof physical and virtual network assets, from the perspective of their own functional responsibility.A data-driven, cloud-native operations platform encourages IT and network teams to use the same data modelsand tools, enabling knowledge-building and sharing across the organizations. For example, customer-facingservices and network elements can be modelled using industry standards, such as TOSCA and YANG; both ITand network operations staff can work with common templating and scripting tools and languages, such asVagrant, Python and Ansible to create automation components such as resource adapters, service templates andconfiguration scripts. This is both a productive and cost-efficient way of achieving network automation.A microservices-based architecture supports modularity and extensibilityThe TM Forum is working with members and other standards bodies, such as MEF and ETSI, to define thegranular set of subcomponents within its architecture – it calls these subcomponents ‘framelets’ – and the open Analysys Mason Limited 20183: Requirements for a cloud-native platform for automated operations

Converging IT and network teams: a cloud-native automation platform is the catalyst for successful operations 9APIs between them. TM Forum envisages that framelets will be realised as microservices that will eventuallyrun in containers for maximum speed and flexibility of deployment. The framelet concept supports the modularimplementation and extension of the architecture with new functionality as it emerges. A microservices-basedapproach also enables the cloud-native platform to support multiple operational capabilities that are todayrealised as separate and non-data sharing systems. For example, the path computation engine (PCE), policysubsystem and alarms can all be implemented as microservices that run on the same platform and benefit fromits data-centric architecture.This approach allows for the rapid integration of new operational capabilities, including the incorporation ofmicroservices from open-source platforms such as ONAP. All the microservices in a cloud-native platform areintegrated once and can be called as trusted services by multiple platform-based tools/systems, as described inour report on the digital network and operations platform (DNOP).2 Each operator will choose its set ofmicroservices according to its business requirements, enabling operators to differentiate themselves fromcompetitors. Operators can then gain competitive advantage from the microservices-based composition of theirplatforms and the automation capabilities the platforms support.A microservices-based architecture is essential to achieving the development velocity, high reliability, rapidfeedback and reduced operational costs that are the hallmarks of cloud-native operations.AI and autonomy enable the management of network complexityManaging the network as a single, distributed system will remain difficult even if operators simplifymanagement and control through a cloud-native operations platform. Relentless traffic growth requirescontinued scaling of the network, 5G is introducing new technologies to densify and increase capacity at theedge and IoT is leading to an explosion of devices that require network connectivity. Decision-making acrossthe network, for example, to create a new network slice or optimise the end-to-end network for a specificservice, will need to take place in real-time at a scale that is already impossible for the human brain to compute.The TM Forum envisages that a common operations platform will have an event-driven model that will begoverned by artificial intelligence. In other words, it will enable AI-driven, adaptive management of thenetwork. This AI capability will be knowledge-driven, based on learnings from all the network telemetry datacollected and analysed in the platform. The vast, end-to-end data set on which the platform will be built is tailormade for the implementation of AI. AI systems will also learn from the success or otherwise of automationapplied within the platform and will use this knowledge optimally to adapt it. As operators increasingly trust theknowledge-driven automation that will be refined through the application of AI, the TM Forum expects thatnetwork operations will become highly autonomous.A real-time platform is needed to deliver the best customer experienceCustomers have increasingly high expectations of the experience they receive from operators. They expectservice delivery and reporting on-demand and are intolerant of service failure. To provide an excellent digitalexperience, operators need an operations platform that has a real-time view of the state of the network, based onreal-time data from the infrastructure itself, and an ability to respond and change that state in real-time. Realtime operations can only be supported if IT and network operations staff work closely together to build theappropriate end-to-end service automation, using the network itself as their data set and single source of truth.Clean, consistent real-time data is a further driver for the adoption of a cloud-native operations platform.2For more information, see Analysys Mason’s Defining the digital network and operations platform for 5G and future networks.Available at www.analysysmason.com/defining-dnop-5g-rma16. Analysys Mason Limited 20183: Requirements for a cloud-native platform for automated operations

Converging IT and network teams: a cloud-native automation platform is the catalyst for successful operations 10IT and network operations staff will need to adapt to the new velocity of network management and control sucha real-time platform brings. They will also need to develop the right governance around real-time changemanagement, both as applied by the platform to the network and within the platform itself as its microservicesare updated using continuous integration.A cloud-native operations platform supports network-as-a-service (NaaS) modelsToday, IT and operations staff typically use their separate tools and manual processes to build connectivityservices on behalf of customers. Leading operators are already using automation to enable customers to createconnectivity services themselves, on demand. In the future, a common operations platform based on the aboveattributes will enable operators to provide their network ‘as a service’. That is, the network and its operationswill become a set of platform services, with customers selecting and integrating, in drag and drop fashion, theservice components they need to meet their connectivity needs. IT and network operations staff will collaborateto build the automation needed to underpin this vision, using the platform’s microservices-based architecture,open APIs and DevOps methods to expose services to customers, or indeed partners, at an appropriate level ofgranularity. IT/network teams will also create the necessary closed-loop automation for provisioning andassuring the resulting connectivity service. An operator’s ecosystem of partners may be granted access toplatform services at a deeper level than customers to enable them to build innovative value-added, customerfacing services that leverage the operator’s network capabilities. Operators can expect to drive new value fromthe business models their platforms will support.For example, the NaaS business model will be key to monetizing network slices, which customers and partnerswill be able to populate with services selected from an operator’s NaaS catalog to meet specific latencyrequirements or provide differentiated service characteristics. In our network slicing report, we describe a futurephase of slicing in which applications will navigate through operator networks themselves, self-selecting theresources they need and creating ephemeral slices ‘on the fly’, in a networking version of IT serverlessarchitecture.3 This will require applications to be able to negotiate with the platform services they consume, afurther development of the platform business model.4. A cloud-native operations platform supports theroadmap to NaaSThe journey to a knowled

About Ciena Blue Planet 13 About the author 15 Analysys Mason's consulting and research are uniquely positioned 16 Research from Analysys Mason 17 Consulting from Analysys Mason 18 . (SDN) as a means of automating key manual interactions with network elements, and IT organizations are being asked to support network functions directly with .