converging it and network teams: a cloud˜native …...network automation is an imperative if...

analysysmason.com

CONVERGING IT AND NETWORK TEAMS: A CLOUD-NATIVE AUTOMATION PLATFORM IS THE CATALYST FOR SUCCESSFUL OPERATIONS Caroline Chappell

WHITE PAPER

MAY 2018

Converging IT and network teams: a cloud-native automation platform is the catalyst for successful operations | i

© Analysys Mason Limited 2018 Contents

Contents

1. Executive summary 1

2. Accelerating the pace of network operations 2

Drivers for a new speed of digital operations 2

Operational barriers to network automation 4

Network virtualization as a catalyst for network/IT organizational convergence 5

3. Requirements for a cloud-native platform for automated operations 6

Benefits of a data-centric architecture for cloud native operations 7

A microservices-based architecture supports modularity and extensibility 8

AI and autonomy enable the management of network complexity 9

A real-time platform is needed to deliver the best customer experience 9

A cloud-native operations platform supports network-as-a-service (NaaS) models 10

4. A cloud-native operations platform supports the roadmap to NaaS 10

Step 1: Start the collaboration at physical network element level 11

Step 2: Create VNF lifecycle management automation 11

Step 3: Build customer-facing service models together 12

Step 3: Gain experience of closed-loop automation development and AI 12

Step 4: Create a customer-facing abstraction for NaaS ease of use 12

5. Conclusion 12

6. 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

List of figures

Figure 2.1: Service agility is underpinned by automation and virtualization ................................................... 3

Figure 2.2: IT and network organizations are approaching automation and virtualization from NFV and

SDN angles respectively, driving the case for collaboration and convergence ................................................ 6

Figure 3.1: TM Forum Open Digital Business Enablement System [Source: TM Forum, 2018]..................... 7

Figure 3.2: Siloed OSS/NMS create process and data complexity that is difficult to automate ....................... 8

Figure 4.1: Five steps towards operational automation .................................................................................. 11

Converging IT and network teams: a cloud-native automation platform is the catalyst for successful operations | 1

© Analysys Mason Limited 2018 1: Executive summary

1. Executive summary

Network automation is an imperative if operators are to deliver services with sustainable levels of agility and

profitability. Automation enables the network to adapt to events and demands rapidly and efficiently, and

supports a new speed of digital business. However, operators cannot buy all the automation they need off-the-

shelf: they need to build and/or customize it for their own purposes and environments. This means overcoming

cultural, organizational and technical barriers, bridging the separate and often antagonistic roles IT and network

departments play today in managing the physical network.

Network virtualization and its emphasis on automation has started to break down technical barriers as IT and

network organizations increasingly need to work in each other’s domains. Network organisations are

investigating software-defined networking (SDN) as a means of automating key manual interactions with

network elements, and IT organizations are being asked to support network functions directly with data

center/cloud components and associated automation. It is clearly desirable for the two departments to start

sharing tools, knowledge, best practices, cloud-native software development and operations (DevOps)

approaches as their roles converge. Operators that encourage this cross-domain fertilization accelerate the

cultural change necessary to build an automated and adaptive network.1

This paper assesses the value of a cloud-native platform for operational automation, which can be shared by IT

and networking organizations. A common automation platform, with shared tools and capabilities, is a practical

means of encouraging everyone to ‘speak the same language’ and share knowledge. Common tools help blur the

boundaries between separate teams and accelerate the cultural change necessary to enable digital operations.

The TM Forum has defined the requirements for such a platform, pointing out that it should have five key

attributes. The platform should:

• be data-centric, with a shared data layer populated directly from the network as the authoritative source of

truth

• conform to cloud native principles, with platform functionality embedded in microservices and exposed

through open APIs, supporting rapid enhancement, continuous development and scaling, key benefits of

cloud native computing

• enable artificial intelligence-driven, adaptive management of the network, trained on all the telemetry data

that it collects and analyses

• drive decisions in real-time to optimize network operations and support a network-as-a-service platform

business model whereby network capabilities are exposed through the platform as services for consumption

by customers in flexible ways and by partners as elements to which they add further value.

Once the cloud-native platform is in place as the foundation for IT/network organizational collaboration,

operators should use it to address simpler automation challenges first and progress to more-complex automation

activities as joint IT/network teams build experience and trust together. We recommend five operational

automation steps that operators can take, which can be carried out sequentially, in parallel or overlap with one

another as the organization’s confidence in automation grows. For example, the network organization can ask

1 For more information about Analysys Mason’s definition of the adaptive network, see From autonomous to adaptive: the next

evolution in networking. Available at www.analysysmason.com/autonomous-to-adaptive-networks-white-paper.

file:///C:/Users/caroline.chappell/AppData/Local/Microsoft/Windows/INetCache/Content.Outlook/1L49JL6S/www.analysysmason.com/autonomous-to-adaptive-networks-white-paper


© Analysys Mason Limited 2018 2: Accelerating the pace of network operations

for IT help in learning new tools for building resource adapters, APIs and configuration scripts as a starting

point, while IT can solicit network engineering support to understand the behaviour of, and requirements for,

virtualized network functions (VNFs) as they build lifecycle management automation.

We expect to see growing numbers of operators converge their IT and network organizations around a cloud-

native automation platform over the coming years as a critical means of implementing network virtualisation

and use cases, including 5G use cases. Early adopters of such a collaboration environment are likely to enjoy a

significant market advantage as their new speed of digital operations drives additional revenue and customer

acquisition.

2. Accelerating the pace of network operations

Drivers for a new speed of digital operations

Digitalization is accelerating the pace of innovation in every industry and setting new expectations for the speed

of doing business. Every company is seeking to become ‘agile’ in multiple dimensions in a digital era. Each

wants to bring new products and features to market in days and weeks, instead of months or years, and to

provision new services in minutes or hours, not weeks or months. Operators see improved agility as a key

business goal that underpins a new digital relationship with their customers. They wish to delight customers by

introducing new services ahead of the competition and by meeting customers’ needs on-demand. And service

agility can unleash upsell opportunities and drive new revenue, to the benefit of operators themselves.

In a telecoms environment, service agility is predicated on the ‘softwareization’ of the network and the

concomitant ability to automate its operations (see Figure 2.1). The virtualization of network functions (NFV)

and the introduction of programmable network control (SDN) allows the network to be manipulated flexibly and

programmatically at speeds far surpassing manual interactions with physical boxes. Installing or upgrading a

piece of network software even in a remote location, requires the execution of a few lines of code and the

automation is replicable across hundreds and thousands of installations with minimal overheads and delays.

Once the right automation is in place, operators can introduce new virtualized network functions (VNFs)

quickly and easily to support new services, accelerating time to market and reducing market entry costs.



Figure 2.1: Service agility is underpinned by automation and virtualization

Automation changes the speed with which network data can be harvested from, and used to drive decisions back

into, the network, enabling the network to adapt rapidly to changing conditions. An adaptive network that can

self-configure, self-monitor, self-heal and self-optimise is key to agility and lean operations. Automated systems

can collect and analyse vast amounts of networking data in near real-time, faster and more cost-effectively than

highly trained human operatives. Operations staff are still needed to create the policies that drive automated

decisions, audit the outcomes of those decisions and deal with exceptions. However, as networks become larger

and more complex due to traffic growth and new 5G and virtualization technologies, operators will need to

harness the speed that automation brings to deliver services at acceptable agility levels and price points.

Creating operational automation for an adaptive network is an extensive and complex exercise. Since network

virtualization will be applied gradually, the automation must integrate with traditional processes used in the

physical network and carefully subsume them over time. Automation-builders with coding skills will need to

work alongside operations staff with networking expertize. NFV introduces a new execution environment for

virtualized functions – the NFV infrastructure (NFVI) – which contains commodity, data center and cloud

components: commercial off-the-shelf (COTS) servers and white box switches, virtualization mechanisms and a

virtualized infrastructure manager (VIM). Although these data center and cloud components become an integral

part of the end-to-end, virtualized network topology, networking personnel have little experience of them. The

IT department is the constituency best placed to build the automation for the NFVI, but it may not appreciate the

subtle demands of the network on this environment without help.

The barriers to operational automation are cultural and organizational, not technical. They require a new

contract between the IT department, which understands software and supporting virtualization and COTS

hardware technologies, and the network organization, which understands the behaviour and constraints of the



network. 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 automation

To automate their network operations effectively, operators need to bridge the separate and often antagonistic

roles IT and network departments play today in managing the physical network. The network organization is

connectivity-driven. It concerns itself with defining the architecture of the network in various domains and

deploying new boxes - network elements - to fulfil that architecture. It does not typically consider the broader

service delivery and assurance context– the ‘service wrap’ needed before services built on top of the new

network elements can be sold to customers. The network organization manages and assures the network

elements themselves, but once the boxes have been deployed, it ‘throws over the wall’ to IT the challenge of

designing 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-facing

services but many of the individual steps in these processes, such as the configuration/activation of individual

network elements or the identification of a service-impacting network fault, need to be manually implemented

by the network organization. This leads to back-and-forth manual handovers between IT and network

departments, which add cost, complexity and error. There are many reasons for the often-fraught relationship

between IT and network organizations, such as the following.

• IT/network departments have different priorities and objectives. Network departments do not always

consult IT departments as extensively as they could on how easily new network elements will integrate with

existing operational systems (OSS), what interfaces they will provide or what their management needs will

be. As a result, when new network elements arrive and are deployed, IT departments are often blamed for

the long period of time that it takes to operationalize them. Network departments fear losing out on new

service revenue: IT departments are aggrieved that their network colleagues have increased the complexity

of their integration environment by failing to seek their advice on the new equipment’s operational

requirements. Network organizations’ tendency to bring in new network elements to run new services while

maintaining multiple previous generations of equipment supporting existing services, encourages the

proliferation of management silos. This means more integration complexity, further slowing down the pace

of change and adding cost.

• ‘Not invented here’ attitudes to automation abound. IT may implement automation to help with process

consistency and rigour, but it cannot enforce its use. Network engineers are used to manually changing

network element configurations to ‘get the job done’ and are notorious for not informing the IT keepers of

key data systems – such as the inventory system – that they have done so. It is all too easy for the network

and its OSSs to lose synchronicity, resulting in ‘dirty’ data and configuration errors that can cause order

fallouts or even bring down the network. Both outcomes can be costly in terms of lost business and

reputational damage.

• IT and network departments use disparate management tools and approaches. Feedback between IT

and network departments has historically been slow because they are separate organizations dealing with a

common activity – the management of the network – using different tools and systems. The network

organization deals with element and network management systems (E/NMS) within the network operations

center (NOC); and the IT department deals with network and service operational support systems (OSS) of

record. If E/NMS are integrated at the software level with the IT department’s OSS, a certain amount of

automation can be supported; otherwise, the two departments interface with each other manually.



To overcome these organizational barriers, operators are beginning to look at Agile/DevOps ways of working

that bring together different organizational functions and help them collaborate. Agile/DevOps methodologies

replace the waterfall model where each team creates an output and ‘throws it over the wall’ to the next function

in the process. The waterfall model is anti-agility in that its phases are sequential and therefore time-consuming

to execute; and it can result in expensive rework if upstream requirements become misaligned with downstream

outputs over time. An Agile/DevOps model supports the incremental, collaborative and holistic development of

outputs. It eliminates the communication and responsibilities gaps between those specifying and creating the

outputs (‘developers’) and those deploying and operating them (‘operations’). DevOps has a specific meaning in

the software world but its lessons on collaborative working can equally apply to network/IT organizations that

need to create the automated, virtualized network together.

Network virtualization as a catalyst for network/IT organizational convergence

Network virtualization is becoming the catalyst for operator adoption of agile/DevOps methodologies across

network/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 the

specific behaviours and requirements of network functions. VNFs can behave very differently from IT

applications, especially when they are chained together as network services, and make many more demands on

the 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 near

real-time control over the network (see Figure 2.2). SDN involves the automation of key manual interactions

with network elements, for example, for activation, configuration and monitoring/data collection purposes.

Building this automation requires knowledge of scripting and data modeling languages, application

programming interfaces (APIs) and other code-related skills. Network engineers, who have spent their careers

manually manipulating command line interfaces to network boxes, realise they need to acquire similar

programming expertise to their IT colleagues.

As IT and network organizations increasingly need to work in each other’s domain, they can benefit from a

closer relationship with one another. Many operators are bringing their IT and network operations teams

together 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 work

together. Operators need a hands-on method of encouraging collaboration and shared experience if they are to

break down remaining barriers within their new combined organizations. A common automation platform, with

shared tools and capabilities, is a practical means of encouraging everyone to ‘speak the same language’ and

share knowledge, the essence of collaboration. Common tools help blur the boundaries between separate teams

and accelerate the cultural change necessary to enable digital operation


© Analysys Mason Limited 2018 3: Requirements for a cloud-native platform for automated operations

Figure 2.2: IT and network organizations are approaching automation and virtualization from NFV and SDN angles

respectively, driving the case for collaboration and convergence

3. Requirements for a cloud-native platform for automated

operations

The TM Forum has defined an end-to-end architecture for future business and network operations. TM Forum

has specified the requirements for implementing this architecture as a cloud-native platform that can be used by

both IT and network organizations and joint IT/network teams working on network operations. The network

operations platform is a subset of the holistic TM Forum Open Digital Business Enablement System shown in

Figure 3.1.



Figure 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 converged

IT/network teams should have five key attributes:

• data-centric, not process-centric

• microservices-based, using open APIs

• AI-capable and autonomous

• real-time

• able to support platform business models, the basis for a digital service provider business.

Benefits of a data-centric architecture for cloud native operations

Operational data is highly siloed, both between IT and networking organizations and within them, Today, as

Figure 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’ this

data and make it accessible to the stakeholders who need it; increasingly, in a digital environment, this includes

the operator’s customers.



Figure 3.2: Siloed OSS/NMS create process and data complexity that is difficult to automate

In a data-centric network operations architecture, all the data from an inherently distributed system – the

network – is collected in one place, leveraging recent advances in database technology. The data is then

available in real-time to any stakeholder/task that needs it, with both IT and network operations sharing the

same source of truth. A data-centric architecture enables the logical centralisation of network control and

management – 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, for

example, to view the SLAs of customer-facing services, end-to-end network topology, the configuration status

of 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 models

and tools, enabling knowledge-building and sharing across the organizations. For example, customer-facing

services and network elements can be modelled using industry standards, such as TOSCA and YANG; both IT

and network operations staff can work with common templating and scripting tools and languages, such as

Vagrant, Python and Ansible to create automation components such as resource adapters, service templates and

configuration scripts. This is both a productive and cost-efficient way of achieving network automation.

A microservices-based architecture supports modularity and extensibility

The TM Forum is working with members and other standards bodies, such as MEF and ETSI, to define the

granular set of subcomponents within its architecture – it calls these subcomponents ‘framelets’ – and the open



APIs between them. TM Forum envisages that framelets will be realised as microservices that will eventually

run in containers for maximum speed and flexibility of deployment. The framelet concept supports the modular

implementation and extension of the architecture with new functionality as it emerges. A microservices-based

approach also enables the cloud-native platform to support multiple operational capabilities that are today

realised as separate and non-data sharing systems. For example, the path computation engine (PCE), policy

subsystem and alarms can all be implemented as microservices that run on the same platform and benefit from

its data-centric architecture.

This approach allows for the rapid integration of new operational capabilities, including the incorporation of

microservices from open-source platforms such as ONAP. All the microservices in a cloud-native platform are

integrated once and can be called as trusted services by multiple platform-based tools/systems, as described in

our report on the digital network and operations platform (DNOP).2 Each operator will choose its set of

microservices according to its business requirements, enabling operators to differentiate themselves from

competitors. Operators can then gain competitive advantage from the microservices-based composition of their

platforms and the automation capabilities the platforms support.

A microservices-based architecture is essential to achieving the development velocity, high reliability, rapid

feedback and reduced operational costs that are the hallmarks of cloud-native operations.

AI and autonomy enable the management of network complexity

Managing the network as a single, distributed system will remain difficult even if operators simplify

management and control through a cloud-native operations platform. Relentless traffic growth requires

continued scaling of the network, 5G is introducing new technologies to densify and increase capacity at the

edge and IoT is leading to an explosion of devices that require network connectivity. Decision-making across

the network, for example, to create a new network slice or optimise the end-to-end network for a specific

service, 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 be

governed by artificial intelligence. In other words, it will enable AI-driven, adaptive management of the

network. This AI capability will be knowledge-driven, based on learnings from all the network telemetry data

collected and analysed in the platform. The vast, end-to-end data set on which the platform will be built is tailor-

made for the implementation of AI. AI systems will also learn from the success or otherwise of automation

applied within the platform and will use this knowledge optimally to adapt it. As operators increasingly trust the

knowledge-driven automation that will be refined through the application of AI, the TM Forum expects that

network operations will become highly autonomous.

A real-time platform is needed to deliver the best customer experience

Customers have increasingly high expectations of the experience they receive from operators. They expect

service delivery and reporting on-demand and are intolerant of service failure. To provide an excellent digital

experience, operators need an operations platform that has a real-time view of the state of the network, based on

real-time data from the infrastructure itself, and an ability to respond and change that state in real-time. Real-

time operations can only be supported if IT and network operations staff work closely together to build the

appropriate 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.

2 For 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.

file:///C:/Users/caroline.chappell/AppData/Local/Microsoft/Windows/INetCache/Content.Outlook/1L49JL6S/www.analysysmason.com/defining-dnop-5g-rma16


© Analysys Mason Limited 2018 4: A cloud-native operations platform supports the roadmap to NaaS

IT and network operations staff will need to adapt to the new velocity of network management and control such

a real-time platform brings. They will also need to develop the right governance around real-time change

management, both as applied by the platform to the network and within the platform itself as its microservices

are updated using continuous integration.

A cloud-native operations platform supports network-as-a-service (NaaS) models

Today, IT and operations staff typically use their separate tools and manual processes to build connectivity

services on behalf of customers. Leading operators are already using automation to enable customers to create

connectivity services themselves, on demand. In the future, a common operations platform based on the above

attributes will enable operators to provide their network ‘as a service’. That is, the network and its operations

will become a set of platform services, with customers selecting and integrating, in drag and drop fashion, the

service components they need to meet their connectivity needs. IT and network operations staff will collaborate

to 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 of

granularity. IT/network teams will also create the necessary closed-loop automation for provisioning and

assuring the resulting connectivity service. An operator’s ecosystem of partners may be granted access to

platform services at a deeper level than customers to enable them to build innovative value-added, customer-

facing services that leverage the operator’s network capabilities. Operators can expect to drive new value from

the business models their platforms will support.

For example, the NaaS business model will be key to monetizing network slices, which customers and partners

will be able to populate with services selected from an operator’s NaaS catalog to meet specific latency

requirements or provide differentiated service characteristics. In our network slicing report, we describe a future

phase of slicing in which applications will navigate through operator networks themselves, self-selecting the

resources they need and creating ephemeral slices ‘on the fly’, in a networking version of IT serverless

architecture.3 This will require applications to be able to negotiate with the platform services they consume, a

further development of the platform business model.

4. A cloud-native operations platform supports the

roadmap to NaaS

The journey to a knowledge-driven, adaptive network will take time and will require many incremental steps.

IT/network organizations will need to collaborate to achieve this goal and a cloud-native platform provides a

common meeting point where they can learn quickly from each other. IT and networking teams can use the

cloud-native operations platform to address simpler automation challenges first and progress to more complex

automation activities as they build experience and trust together. The five steps described below can be carried

out in parallel or overlap with one another as confidence in automation grows.

Windstream is an example of an operator that uses a cloud-native operations platform to bring its IT and

network operations teams together. By picking a solution with a strong DevOps framework and one based on

3 For more information, see Analysys Mason’s Network slicing: the future of connectivity in a 5G and fibre era. Available at

www.analysysmason.com/network-slicing-connectivity-rma16-rma18.

file:///C:/Users/caroline.chappell/AppData/Local/Microsoft/Windows/INetCache/Content.Outlook/1L49JL6S/www.analysysmason.com/network-slicing-connectivity-rma16-rma18http://www.analysysmason.com/Research/Content/Reports/network-slicing-connectivity-RMA16-RMA18/#23%20February%202018


© Analysys Mason Limited 2018 4: A cloud-native operations platform supports the roadmap to NaaS

data model-driven configuration and a microservices architecture, Windstream wanted to spur internal,

converged IT/network groups to innovate on new services rather than depend on vendors.4

Figure 4.1: Five steps towards operational automation

Step 1: Start the collaboration at physical network element level

Operators can start by creating teams with combined IT and networking skills to build open API, /resource

adapters, device models and configuration scripts for network elements using supporting WAN SDN tools

within the common operational platform. This will empower network operations and engineering staff to create

their own exposure of network resources and to gain experience of the open APIs used by SDN controllers,

where these are implemented. In doing so, they will familiarise themselves with key IT tools that facilitate

integration and network abstraction. At the same time, working in a converged environment will educate IT

software engineers on the nuances of networking and the data and capabilities available in network elements

which can enrich their systems’ management of the network.

Step 2: Create VNF lifecycle management automation

Operators implementing virtualized network functions (VNFs) will need both IT and network operations input

to build the automation for VNF lifecycle management. The IT department has the expertise to install and

maintain software deployed in cloud environments, so it is best-placed to build the initial automation that will be

needed to support VNF onboarding, instantiation, Day Zero configuration and upgrades on an NFV

infrastructure. However, network engineers best understand the behaviour of individual network functions, the

Day One configurations needed to support customer services and the implications of more complex VNF

lifecycle management tasks such as scaling and healing. Both IT and networking knowledge is needed to build

complex, closed-loop VNF management automation, including continuous integration and deployment.

Automating communications across the VNFM-virtual infrastructure manager (VIM) and VNFM-NFV

orchestration (NFVO) interfaces will require both specialist network understanding of VNF and network

behaviour and IT expertise around data center infrastructure operations and software lifecycle management.

4 For more information, see Analysys Mason’s Windstream: Intelligent multi-layer, multi-domain network automation with SDN.

Available at www.analysysmason.com/windstream-ciena-sdn-rma16.


© Analysys Mason Limited 2018 5: Conclusion

Step 3: Build customer-facing service models together

The next logical step beyond automating device configuration is the development of end-to-end and cross-

domain customer-facing service models. Such service models will need to be implemented using both physical

network elements and VNFs at this stage of the market. Once service models are in place, and with the right

common operations platform support, operators can then automate a larger chunk of the service provisioning

process, building the workflows that span IT and network operations environments. Converging IT and network

teams will enable both to develop the cross-domain skills needed to bring virtualized network functions into the

service provisioning process, using the common operations platform to establish standardised, automated

processes for VNF onboarding, instantiation, setting up SDN connectivity, infrastructure management, VM

management and cloud resources management.

Step 3: Gain experience of closed-loop automation development and AI

Once IT and network functions are comfortable working with one another and the common operations platform

has bedded in, operators will be ready to tackle more advanced automation activities, such as the development

of analytics-driven closed-loop automation. Closed-loop automation extends beyond provisioning to include

service assurance and network performance and fault management. The common operations platform gives

operators a rich opportunity to apply AI and analytics to the wealth of combined data it contains. However,

understanding the implications of this data and building the right algorithms to drive desired network outcomes

takes the skills and knowledge of mixed IT/network teams. Operators that can build sophisticated closed-loop

automation will gain a competitive advantage in terms of cost of operations, speed of service delivery and

quality of customer experience.

Step 4: Create a customer-facing abstraction for NaaS ease of use

In order to abstract the network as a service in a way that is easy for customers to consume, joint IT/networking

teams need to build a high-level, intent-based interface that abstracts further their operational interface to the

network. Such an interface should make it as easy as possible for customers to discover and drive network

behaviours and set up connectivity services that meet their business needs. It is likely that such an abstraction

will be used by other stakeholders as well, such as product managers and partners who want to innovate new

products and services, and business executives who want to set and audit policies that help to run the network

efficiently. Getting this interface right will require combined IT and network skills and deep support from the

common operations platform capabilities.

5. Conclusion

Operators that have already started on their journey towards an automated – and therefore self-adapting –

network recommend that others start as soon as possible: there are no benefits to delay. Leading operators say

that by embarking on an automation strategy, they have been forced to confront issues that they had not

anticipated and to uncover implications that they would not otherwise be aware of. This is a valuable exercise

because every organization is different and needs to adapt automation to its own circumstances: it cannot simply

apply an industry blueprint and expect success.

However, operators can adopt industry best practices, such as IT/network collaboration, to help them automate

quickly and efficiently. Overcoming long-standing cultural barriers to working across organizational boundaries


© Analysys Mason Limited 2018 6: About Ciena Blue Planet

is the hardest part of any transformation. Therefore, operators need an effective strategy to break these barriers

down. Providing IT and network departments with a platform that enables them to share a common set of tools,

data refreshed directly from the network and access to advanced capabilities such as AI and analytics,

encourages collaboration and reduces cost and complexity in the operator environment. When the platform is

built on cloud-native principles, it inherently supports the agile development and cloud-native operational

automation at the heart of DevOps. IT and networking staff can equally benefit from a DevOps approach as they

increase their responsiveness to customer demand and productivity.

Operators already using such a platform are moving quickly towards the goal of a highly automated, highly

adaptive network. We expect to see growing numbers of operators consolidate their operational automation on a

single, cloud-native platform over the coming years as the foundation for their 5G networks. First movers are

likely to enjoy a significant market advantage as their new speed of digital operations drives new revenue and

customer acquisition.

6. About Ciena Blue Planet

The Blue Planet Intelligent Automation Platform is a programmable software suite that uses deep networking

knowledge to drive adaptive optimization of operator services and operations. Blue Planet plays a central role in

Ciena’s Adaptive Network vision that expands on autonomous networking concepts, which allow operators to

maintain control while transforming today’s static network into a dynamic, programmable environment driven

by analytics and automation.

Combining multi-domain orchestration, SDN control and analytics in a common microservices-based

architecture, Blue Planet supports the evolution toward more efficient, modernized network operations to reduce

costs, accelerate service delivery and enable a path to more adaptive networks.

Blue Planet’s open, vendor-agnostic approach supports the integration of third-party technologies and vendors.

The platform’s open, published REST APIs enable integration with operational support systems (OSS) such as

order management and inventory systems, and customer portals, as well as open southbound interfaces to

orchestrate services across underlying multi-vendor physical or virtual resources. The platform is built on open-

source technologies, such as Docker, Cassandra, Kafka and others.

The platform is supported by a DevOps Toolkit and an open community that enables collaboration among

internal product development, IT, and network operations teams to improve operational agility, increase

innovation, and accelerate ‘concept-to-revenue’ times for new services. These resources give network operators

greater control over their infrastructure and reduce their dependence on professional services associated with

integrating network resources and developing new services.

Ciena’s Blue Planet portfolio includes several components:

Software control and automation:

• Blue Planet Multi-domain Service Orchestrator (MDSO) – simplifies the end-to-end management and

automation of network services across multi-vendor physical and virtual networks


© Analysys Mason Limited 2018 6: About Ciena Blue Planet

• Blue Planet NFV Orchestration (NFVO) – automates the delivery and lifecycle management of NFV-based

network services

• Blue Planet Manage, Control and Plan (MCP) – domain controller for automating the complete service

delivery lifecycle across Ciena packet-optical networks.

Analytics and intelligence:

• Blue Planet Analytics (BPA) – an integrated network analytics and machine learning framework for

deriving actionable insights from network performance data

• Network Health Predictor (NHP) – an analytics application for BPA that enables proactive network

assurance in multi-vendor networks by predicting network element (NE) failures before they occur.


© Analysys Mason Limited 2018 About the author

About the author

Caroline Chappell (Research Director) is the lead analyst for Analysys Mason’s Software-

Controlled Networking research programme. Her research focuses on service provider adoption

of cloud, and the application of cloud technologies to fixed and mobile networks. She is a

leading exponent of SDN and NFV and the potential that these technologies have to enhance

business agility and enable new revenue opportunities for service providers. Caroline

investigates key cloud and network virtualisation challenges and helps telecoms customers to

devise strategies that mitigate the disruptive effects of cloud, supporting a smooth transition to the era of

software-controlled networks.


© Analysys Mason Limited 2018 Analysys Mason’s consulting and research are uniquely positioned

Analysys Mason’s consulting and research are uniquely

positioned

Analysys Mason is a trusted adviser on telecoms, technology and media. We work with our clients, including

communications service providers (CSPs), regulators and end users to:

• design winning strategies that deliver measurable results

• make informed decisions based on market intelligence and analytical rigour

• develop innovative propositions to gain competitive advantage.

We have more than 220 staff in 14 offices and are respected worldwide for exceptional quality of work,

independence and flexibility in responding to client needs. For more than 30 years, we have been helping clients

in more than 100 countries to maximise their opportunities.

Consulting

• We deliver tangible benefits to clients across the telecoms industry:

• communications and digital service providers, vendors, financial and strategic investors, private equity

and infrastructure funds, governments, regulators, broadcasters, and service and content providers.

• Our sector specialists understand the distinct local

challenges facing clients, in addition to the wider

effects of global forces.

• We are future-focused and help clients understand

the challenges and opportunities that new

technology brings.

Research

• Our dedicated team of analysts track and forecast

the different services accessed by consumers and

enterprises.

• We offer detailed insight into the software,

infrastructure and technology delivering those

services.

• Clients benefit from regular and timely intelligence, and direct access to analysts.


© Analysys Mason Limited 2018 Research from Analysys Mason

Research from Analysys Mason

We provide dedicated coverage of developments in the telecoms, media and technology (TMT) sectors,

through a range of research programmes that focus on different services and regions of the world

The division consists of a specialised team of analysts, who provide dedicated coverage of TMT issues and

trends. Our experts understand not only the complexities of the TMT sectors, but the unique challenges of

companies, regulators and other stakeholders operating in such a dynamic industry.

Our subscription research programmes cover the following key areas.

Each subscription programme provides a combination of quantitative deliverables, including access to more

than 3 million consumer and industry data points, as well as research articles and reports on emerging trends

drawn from our library of research and consulting work.

Our custom research service offers in-depth, tailored analysis that addresses specific issues to meet your

exact requirements

Alongside our standardised suite of research programmes, Analysys Mason’s Custom Research team undertakes

specialised, bespoke research projects for clients. The dedicated team offers tailored investigations and answers

complex questions on markets, competitors and services with customised industry intelligence and insights.

For more information about our research services, please visit www.analysysmason.com/research.

http://www.analysysmason.com/research


© Analysys Mason Limited 2018 Consulting from Analysys Mason

Consulting from Analysys Mason

For more than 30 years, our consultants have been bringing the benefits of applied intelligence to enable

clients around the world to make the most of their opportunities

Our clients in the telecoms, media and technology (TMT) sectors operate in dynamic markets where change is

constant. We help shape their understanding of the future so they can thrive in these demanding conditions. To

do that, we have developed rigorous methodologies that deliver real results for clients around the world.

Our focus is exclusively on TMT. We advise clients on regulatory matters, help shape spectrum policy and

develop spectrum strategy, support multi-billion dollar investments, advise on operational performance and

develop new business strategies. Such projects result in a depth of knowledge and a range of expertise that sets

us apart.

We look beyond the obvious to understand a situation from a client’s perspective. Most importantly, we never

forget that the point of consultancy is to provide appropriate and practical solutions. We help clients solve their

most pressing problems, enabling them to go farther, faster and achieve their commercial objectives.

For more information about our consulting services, please visit www.analysysmason.com/consulting.
http://www.analysysmason.com/consulting

converging it and network teams: a cloud˜native …...network automation is an imperative if...

Documents