Over 10 years we help companies reach their financial and branding goals. Engitech is a values-driven technology agency dedicated.

Contact Us

Boston, MA, USA


+1 -781-960-5010

NetOps Transformation
netops 2.0 transformation

Is Reducing Collaboration the Key to NetOps 2.0?

I know it sounds counter intuitive, but let me explain what this means to the NetOps 2.0 Transformation Engineer.

In today’s NetOps 1.0 teams, when it comes time to collaborate on a network issue, how do you do this today?

In my experience working with many Fortune 500 companies, the answer is “create/escalate a ticket”.

The problem is that the data in the ticket is most often a subset or summary of the actual work that was completed and a lot of information is lost through summarization.

The first thing a network operations Engineer does when receiving the ticket is perform a discovery.

  • What devices are part of the problem area?
  • How is the environmental health?
  • What logs are available?
  • Is there any congestion?
  • What changes have happened between the last time the network worked as expected and now?

Not surprisingly, this is exactly what the first NetOps Engineer did when they claimed ownership of the incident in the ITSM. It’s also the same thing that every Engineer who works on the incident will do.

Your inefficiency alarm bells should be ringing loudly!

In my observation, the difference between a NetOps 1.0 and NetOps 2.0 organization is two fold.

  1. NetOps 2.0 organizations have a method of encapsulating all the work that was done previously so it isn’t repeated, wasting critical time that is counting towards their MTTR.
  2. Strong NetOps 2.0 organizations have a method of reducing the collaboration requirements altogether.

The topic of this blog entry is more around #2 so let’s dive in deeper.

When looking at performing a NetOps 2.0 Transformation, one eye needs to be on how information is shared when collaboration is needed (let’s face it, this will never go away), and another eye needs to be on self-service in an effort to reduce collaboration and escalations.

Self-service is accomplished by taking the knowledge required to perform many tasks, and making it shareable and executable. This way, regardless of who is trying to accomplish the task, they have a higher level of competency.

If the knowledge required to collect and analyze information is shared and executable, and first level Engineers and even the Service Desk can be more self-service.

This doesn’t only apply to internal NetOps collaboration. There are many cases when teams that rely on the network team to perform their tasks need to wait to get their work done.

The CI/CD and Application teams, for example, when deploying a new application, will require the NetOps team to verify network readiness. When this is happening at a rate that’s growing exponentially, we see a huge delay, and lost revenue for organizations looking to maintain competitive advantage.

How is this performed today?

You guessed it. Typically a ticket is opened with the NetOps team which sits in a queue waiting for action.

The priority of this ticket is always lower than an network outage or degradation right?

What I’ve seen in advanced NetOps 2. 0 organizations is the leveraging of automation to assist these teams to be self service.

In other words, they enable the CI/CD and application teams to define the network intent (they know it better than anyone), and network automation immediately tells them if the network will support their application or not. 

The NetOps 2.0 team will be notified of the failed intent, bypassing the low-priority queue, because this is now viewed as an outage or degradation. 

There’s a few other side benefits as well:

  • There is a reduction in incoming tickets, reducing the load on the NetOps team. This keeps them focused on break/fix type activities instead of verification activities.
  • The running list of Intents become part of Network Regression Testing. In short, this means that as the network changes, the Intents for the network are a always being verified and validated.
    • Some products can even test network changes against these intents prior to deployment, to avoid the unplanned outages we experience in NetOps far too often
  • The “blame game” is reduced, because any application team can now run a very detailed network verification against the intents, with proof of network reachability and performance, without any NetOps interruptions.

So, while it might be counter intuitive to reduce collaboration, it actually makes a lot of sense to eliminate the need for it in as many cases as possible by enabling self-service.

The DIRE NetOps Methodology will inherently improve collaboration by reducing the duplication of effort (as much as 80% of the work), but this is only half that battle.

Reducing collaboration and escalation is paramount to a successful NetOps 2.0 Transformation.

DIRE NetOps can Help.

If you find yourself struggling with your NetOps 2.0 Transformation, you are not alone. Let DIRE NetOps, our parent company and professional services company, help you find the right tools to fill the gap, and transform your NetOps organization into a world class, well oiled machine.

Leave a Reply

%d bloggers like this: