What Every Operator Should Know Before Adding an Orchestration Layer To Their Network

A TM Forum certified Business Developer tells all

There are many elements that operators need to take into consideration while evaluating, choosing, and deploying an orchestration layer to their network:

How can operators prepare their existing infrastructure for an orchestration layer?
What can they do to streamline the deployment process?
What should they look for in automation and orchestration providers?
Why should operators choose an orchestration tool designed for our industry vs. other tools?

Although the benefits of orchestration are numerous, operators need to exercise great care in choosing an agile and flexible solution with the capacity to adapt to the network, systems and existing internal processes seamlessly.

Watch how we install a complex service over GPON in minutes using our service activation and orchestration solution, Symphonica Service Activator

Many questions arise during the process of adding an orchestration layer to a complex network – from battling swivel chair provisioning and legacy processes to making sure that the solution supports guiding principles such as zero-touch provisioning to support digital transformation.

To share an insider’s perspective on important elements operators should keep in mind in the process of choosing an orchestration solution, we went straight to the source: Christopher Gonzalez, Intraway’s Solution Architect, who has over five years of hands-on experience partnering with T1 and T2 operators to integrate Intraway’s orchestration solution, Symphonica. Here’s what he had to say:

What should operators do to prepare their network for an orchestration solution?

CG: Having full visibility of all their processes, especially in areas where there’s a lot of dependency on manual work. An orchestration project will automate many processes. This requires information to be available on databases and maintenance systems, many times transferred over from Excel spreadsheets. Some legacy systems don’t have the capacity to manage what’s required and middleware will need to be developed.

Another important aspect is to make sure that their systems’ APIs are available and documented. Orchestration solutions use APIs for different elements in the network and/or systems that are involved in the process, but frequently, operators’ apps are used with GUIs. Switching over to APIs represents additional time on the operator’s part to learn how to use them, document them and check that they are working. Enabling APIs can also be a considerable additional expense.

What can operators do to facilitate the process of adding an orchestration layer to their network?

CG: Diagramming the As-Is and To-Be processes is KEY. For example, we are going to need to know how the systems work and what other systems they manage, what areas are involved with each one. Knowing exactly how the network operates in detail is crucial for us to be able to make improvements that will optimize network efficiency and communication within systems.

An operator can reduce the orchestration project timeline by two to three months if they already have their current processes outlined and a clear view of what they want their processes to look like in the future. This can be done internally or externally, but I recommend to take the time to do this internally to save on costs.

Another thing that facilitates the orchestration project is providing the company’s org chart and assigning team leads in each department to facilitate communication with the vendor team.

What questions should operators keep in mind while considering different orchestration solutions?

CG: Does the solution align with industry standards and/or frameworks? – The reality is that most workflow tools or BPM will have the capacity to orchestrate, but the project will turn out to be much more complex, costly, and time-consuming in the end. These industry-generic solutions are not oriented toward our industry’s standards and frameworks, such as TM Forum. An orchestration solution designed for our industry will likely be TM Forum oriented, designed for the systems operators use and following industry best practices.

What does the change request process look like? – Change requests can quickly add up, turning into a significant investment that was not accounted for. Having organized processes and a full line of view of how each system interacts with each other will help, but change requests are pretty much inevitable most of the time. Operators should discuss this openly with providers to avoid surprises down the line. Which goes hand in hand with…

How flexible and agile is the OSS/BSS provider? – Each network is a world of its own. A complex, unique world full of quirks and considerations. There are legacy systems, peculiar processes, patched up particularities that only John in Operations knows how to manage, am I right?

A lot of these things are uncovered during the process, not taken into account from the very beginning, which can stress a solution that doesn’t have the agility and flexibility to adapt to a network’s “eccentricities”. An agile provider is much better equipped to manage sudden changes with ease.

Are my current operating processes standardized? – Orchestration is an opportunity to increase efficiency and simplify processes. An orchestration solution’s success will largely depend on the ability to standardize processes so they can be fully automated using the solution.

What are the indirect costs? – Asides from acquiring the orchestration solution, there are several indirect costs that operators should keep in mind when considering adding an orchestration layer to their network. The main indirect costs to consider are the ones associated with adapting the existing systems so they can be integrated with the orchestration solution like we mentioned previously. Another possible indirect cost could be having to license databases, which is very costly.

Is there anything that surprises operators throughout the process of adding an orchestration layer?

CG: Adding an orchestration layer to an operator’s network can be a complex and daunting endeavor, but operators don’t need an end-to-end automation project to benefit from significant efficiencies. Even without end-to-end automation, partial automation by simple integrations can shave off hours of daily work.

An orchestration project is an opportunity to seek efficiency and improve processes. It is very common that during the process operators identify areas of opportunity that weren’t on their radar before. Sometimes it ends up being a bigger project than anticipated, but the results are well worth it!

You may also like

Moving the OSS Infrastructure Stack to the Cloud

Moving the OSS Infrastructure Stack to the Cloud – Challenges and Myths

no-code

Going No-Code to Launch Services Fast

Network Slicing in 5G

Network Slicing in 5G

Menu