Maturity Model Overview
Itential’s experience delivering innovative network automation and orchestration solutions to network teams has made clear the need to present a well-defined model for how teams and organizations evolve their automation journey.
The model is designed for you to:
- Understand what an automation journey looks like.
- Identify where you, your team, and your organization are on the journey.
- Determine your desired future state and automation goals.
- Identify what challenges you will have to face to get there.
- Achieve the benefits automation can deliver, faster.
The fundamentals of the network automation maturity model are the concepts of scope, benefits, and complexity. When many people think about automation, their minds turn to scripts or code or automation of discrete tasks typically performed by an individual or small team. The more value an organization wants to see from automation, the wider the scope must become. Network automation can extend past the task level to the process and organizational levels, but to get there requires a concerted effort and an understanding of the journey.
Evaluating Your Automation Maturity
As detailed above, each evolution or advancement in network automation comes with a renewed perspective. To automate individual tasks, it’s enough for a single engineer to pick up Python or Ansible in their free time. But to expand and automate entire business processes end-to-end requires a team-wide strategy — with the eventual goal of delivering self-serve networking across an organization.
In essence, the stages of the model are delineated by levels of scale. Task automation drives value for the engineer by reducing effort per task. Process orchestration drives value for the end users by reducing time to complete and deliver infrastructure requests. And delivering self-serve network automations drives value for the organization, extending its value and decoupling network change volume from headcount and labor.
Successful automation evolution is about maturing the network change process to the point that network changes are consumable by everyone in an organization, which requires a shift from ad hoc, reactive network operations to proactive efforts where teams build assets and automate more processes and activities.
It’s about a shift in mentality as much as technology. To get the most out of network automation, network engineers must think in NetDevOps terms, breaking out of the networking silo to conceptualize how networking fits into IT and gaining a greater understanding of application dependencies. By taking this view, network engineers will be able to draw a line from where they are today to a self-serve networking target state, as well as understand why they should want to achieve that goal to begin with.
It’s important to keep in mind that an organization or even a network team will not fall cleanly on one spot along the model. Different teams, and individual engineers and practitioners, will be at different levels of automation adoption. With every stage, though, comes a widening scope. To go from no automation at Stage 1 to task automation at Stage 2, an engineer only needs to pursue automation independently, leveraging open source tools to get started. But from Stage 2 to Stage 3 requires involvement from other stakeholders and team members, and from Stage 3 to Stage 4 requires a cross-team effort at the organizational level. Understanding how to apply the model to your own organization will help you determine which teams or individuals should contribute toward building an effective, unified automation strategy that scales.
Stage 1: Limited to No Automation
Defining Limited to No Automation
At the first stage, automation is not part of your overall organizational or team-wide strategy. Here, network management is done manually or almost entirely manually, and any automation is performed at the individual level, if at all.
Common Characteristics
- Network engineers are either unfamiliar with automation or unwilling to adopt it.
- Automation is mainly discussed as an aspirational goal or something difficult to adopt.
- There are a small handful of engineers leveraging scripts solely to perform their work more efficiently, without any sharing of skills or assets.
- Automation is not part of the IT leadership’s strategic plan.
Drawbacks
- Networking is often a bottleneck for IT service delivery.
- Network changes are often both slow and time-consuming, placing strain on network engineers and on other IT teams.
- Routine, repetitive processes like port turn-ups, router upgrades, device onboarding, and firewall provisioning take up a significant portion of the networking team’s time.
- Knowledge of network operations is siloed to very specific people.
- A lack of standardized, consistent network configurations impedes repeatability.
- As networks scale, growing in size and expanding to new types of domains, network teams will struggle to keep up without significantly increasing headcount if they continue to hesitate around automation.
Challenges: What’s Keeping You Here?
- Engineers and/or IT leaders believe automation is too difficult to adopt.
- Cultural hesitance toward reskilling or adopting new technologies.
- The network team believes that using controllers from equipment providers that allow for ClickOps instead of manual CLI commands is enough automation to keep up with complexity.
- Material and/or financial reasons to be cautious about investing in skills.
- Misconceptions around the cost and/or value of automation.
Network teams want to move away from hours spent on routine, repetitive networking tasks to lighten engineer workloads. Additionally, network engineers are looking to future-proof their skillsets and establish their value in an automation-centric networking future.
How to Evolve
Engineers looking to increase their capacity will almost always look to automation. In the early days of networking, practitioners built Perl and Expect scripts, and now we see Python, Ansible, and Terraform rising in prominence. Automating with scripts can seem intimidating — however, the idea that network engineers should become developers is misguided. Simple scripts can be easy to learn, but there is also another option.
One area where networking teams can see immediate value is by simply looking to what’s already out there. Low-code automation platforms tailored for network engineers exist on the market, which can be good alternatives to a heavy reskilling investment. Additionally, many of these platforms can help your organization achieve greater levels of automation maturity in the future.
For those at Stage 1, the most important thing is to just get started — an understanding of the full automation picture will become clearer once you have some experience.
As an Engineer
- Find the right tool for the job, exploring open source options like Python and Ansible.
- Start small, with simple show commands, and build confidence and skill toward scripting specific types of network changes.
- Tackle that backlog of repetitive CLI tasks.
As an IT Leader
- Invest in skills – provide resources for your engineers to learn open source automation tooling.
- Build organizational and cultural support for automation.
- Implement script-based task automation as the first phase of a larger transformation and automation effort.
By evolving toward task automation, organizations, teams, and engineers alike can see significant increases to the speed and scalability of routine network change processes, freeing up engineers’ time for more complex network management.
Stage 2: Task Automation
Defining Task Automation
At the second stage, network engineers leverage automation for routine, repeatable tasks. Whether at the individual level or the team level, this stage is characterized by a familiarity with open source tooling such as Ansible or Python scripts, enabling engineers to create automations for tasks like port turn-ups, router upgrades, firewall provisioning, and other processes that are simple in terms of logic but take up a lot of time to perform manually. Automation of discrete, individual networking tasks has been achieved, but manual work is still required for surrounding processes like pre-checks, post-checks, data collection, and updating tickets.
Common Characteristics
- Network engineers write automations for routine, repetitive tasks using open source tooling like Python or Ansible.
- Automation has a manual trigger, i.e., a network engineer must choose to run a script.
- Work is managed via tickets, ordering systems, messaging system, or some alternative – while network changes are automated, these systems still require manual inputs.
- Common tooling for this stage includes: Rundeck, Netbrain, Solarwinds, Ansible, HashiCorp, HPNA, Cisco DNAC, other point solutions.
Benefits
- By adopting task automation as part of their day to day, network engineers can greatly reduce manual effort for everyday network changes.
- Automation brings consistency, which can reduce or eliminate human error for routine network operations.
- Network engineering teams can scale up network management capacity without adding headcount by saving time on repetitive tasks.
Drawbacks
- Network changes aren’t completed much faster than they were without automation when considered end-to-end – while the engineer’s work itself is faster, surrounding systems and processes like order management, ticketing, and data gathering add manual steps and cause delay.
- Multi-domain networking poses additional challenges for script-based task automation, as different tools are suited for specific domains, often leading to swivel-chairing between systems.
- With a variety of network systems comes a variety of data formats, and network engineers can be left manually transforming data from each format to the next when they need to run a sequence of automations.
- While open source tools are free and accessible, the effort and time required to become confident enough to make network changes at scale can be significant.
- Script-based task automations tend to be limited to specific use cases instead of being reusable. An automation that an engineer writes one week to onboard a hundred devices from one vendor cannot be reused for another vendor the next week, typically leading to a copy/paste approach without reusability.
Network teams who have successfully automated many of their routine tasks will begin to hit against the limitations of a scripts-based approach. Scripting and task-based automation are efforts to increase engineer productivity – but that alone is not the only road to efficiency gains. Some percentage of a change process will be prohibitively difficult or expensive to automate via scripting alone, such as data gathering, notifications, and ticket updates, and that is usually a larger percentage than teams initially believe. Teams who have reached a level of efficiency with their engineers will find that, without evolving to a process-oriented approach, their automation efforts only take them so far.
Challenges: What’s Keeping You Here?
- If leadership is not aligned on the value of automation, moving from scripts, which require only engineer-level buy-in, to adopting a solution for end-to-end automation and orchestration can present organizational challenges.
- Network engineers may be unwilling or hesitant to adopt a network automation platform.
- Network engineers and teams who have invested in learning script-based automation may worry their time was wasted.
- Teams which currently use emails and spreadsheets to manage systems will need to move towards API-level exposure to make activities consumable by an orchestration process.
- Expanding and multiplying base of scripts and other assets that can be difficult to manage.
- It’s important to understand that looking to third-party network automation solutions to help manage this asset base and progress to Stage 3 is often the best way to address this challenge anyway.
- The misconception that “I need to get my data organized” or a single source of truth is required for automation.
Is a Single Source of Truth Required for Automation?
- Authoritative information that is electronically obtainable is critical, but with network infrastructure distributed across domains and systems, attempting to consolidate a single source of truth is a losing proposition.
- In fact, the attempt to build a single source of truth can cause issues – for example, a given cloud provider is essentially the source of truth for your networking activities in that cloud environment, and you are able to access that information when needed. But an attempt to duplicate that information somewhere else will almost inevitably lead to making automation decisions from outdated/cached data.
- Instead, an orchestration solution should meet the realities of the industry. Your infrastructure is distributed, and your sources of truth must be as well – thus, successful orchestration must involve federation of all your sources of truth.
How to Evolve
On a team of network engineers pursuing scripting, each engineer has achieved greater capacity for themselves, but it doesn’t often scale effectively. If, for example, you asked a network engineer in a Stage 2 team whether they would share their scripts with the person next to them, they might say yes – that person, after all, will know when not to run the script, which devices will break it, the fact that the device passwords are embedded, and so on.
However, if you ask the same engineer whether they’d share their scripts with someone they don’t know who works on another team, the response will be more reluctant. Thus, there is a natural cap on the value that scripts-only, task-based automation will provide. To operationalize automation and scale from engineer-level scripting to team-level processes, you can look to orchestration.
To successfully evolve to Stage 3, where automated processes can be orchestrated end-to-end, there needs to be alignment amongst the networking team and a robust strategy for adopting the right solution. Placing your automation goals within the context of something like this automation maturity model can help with acquiring necessary budgets and approvals to adopt a network automation solution. Then, the right platform that works with all your systems and enables you to scale up your team’s capabilities is crucial.
One area where networking teams can see immediate value is by simply looking to what’s already out there. Low-code automation platforms tailored for network engineers exist on the market, which can be good alternatives to a heavy reskilling investment. Additionally, many of these platforms can help your organization achieve greater levels of automation maturity in the future.
For those at Stage 1, the most important thing is to just get started — an understanding of the full automation picture will become clearer once you have some experience.
As an Engineer
- Familiarize yourself with APIs, a crucial component of multi-domain and multi-platform orchestration.
- Ask leadership about automation initiatives – provide your input. Key things to look out for:
- Can a potential solution ingest your current automation assets (scripts, Playbooks, etc.) so you won’t be starting from scratch?
- Can a potential solution enable users with no coding expertise to build automations, without limiting those who can code?
- Investigate ways end-to-end network automation can address repetitive, time-consuming activities to enable you to focus on those that require more advanced network engineering skills.
As an IT Leader
- Develop a goals-driven strategy for automation adoption to present to other decision makers.
- Identify which network automation solution is right for your organization.
- Invest in team and practitioner buy-in, both technically and culturally.
- Invest in education and pursue leading industry analysis around best practices for adopting automation – avoid being misled by ideas like single source of truth or single-vendor technology stacks.
An evolution from task automation to process orchestration will deliver tremendous business value from automation. At Stage 2, automation is great for the network engineer, but is only a marginal benefit for the team. But at Stage 3, IT services and applications that require connectivity can be deployed faster due to orchestrated network automations that fold in business processes, testing and validation, and any other required processes that come along with a network change.
Stage 3: Process Orchestration
Defining Process Orchestration
At the third stage, your automation approach has scaled up from an engineer-level effort to something that exists at the team level at a minimum. Automations for specific, individual tasks can be orchestrated to run in sequences to accomplish different network changes. Additionally, the automated process includes pieces like responding to or closing an IT ticket, performing configuration validation, and communicating with sources of truth.
A script is an engineer-level automation asset. To extend automation to the entirety of a network change process from end-to-end, teams and leaders have invested in operationalizing task automation efforts to produce organization-level assets.
Common Characteristics
- Automations are integrated with ITSM systems or your equivalent work management system.
- Pre-checks, post-checks, and other testing and validation steps are included in your automations.
- The network team leverages an automation platform that integrates east/west with their other IT systems for easy one-window orchestration.
- Teams with DevOps experience look to coordinate script execution through pipelines.
- Some network engineers may write scripts, while others rely fully on a low-code or no-code platform, but both types contribute to orchestrating end-to-end network automation.
Benefits
- Automation saves time for network changes, which speeds up IT service delivery overall for any service that requires a networking component.
- The network team’s capacity is enhanced again when compared to Stage 2 – the team will be able to handle network management at far greater scale than previously.
- Automation integrates east and west across different network and IT systems, so that everything from monitoring and telemetry data to inventory and source of truth information can be leveraged while building automations.
- The business value of automation accelerates at this stage as it evolves from saving time for an engineer to saving time and driving value across the organization.
Drawbacks
- Network services may not be part of the same DevOps, CI/CD ecosystem that other IT assets participate in, meaning network changes cannot be triggered by events or as part of a CI/CD pipeline.
- End users outside of networking would need to learn how to use the tools leveraged by the network team to run automations themselves.
- Requires a high level of engagement and involvement from all relevant stakeholders.
- Other teams must be willing to participate in the orchestration process, meaning they will either need to delegate authority for their steps in the process, or they will need to commit to an SLA for approval/execution of the steps they are responsible for.
- Requires a reasonably mature end-to-end process with clear handoffs and accountabilities. If a team does not have a mature process, it is impossible to orchestrate effectively.
Network teams who have achieved process orchestration have successfully built automations for entire network change processes end-to-end, across their disparate systems, technologies, and network domains. They have progressed beyond engineer-level optimization to team-level optimization, successfully automating a far greater percentage of each business process.
However, forward-looking teams are seeking ways to expose their automations for easier consumption by other end users in the IT organization. Just as teams who reached a cap in terms of engineer-level optimization looked to process orchestration, organizations that have reached this second efficiency cap will look to self-serve networking delivery to increase automation consumption, scaling its impact across the organization.
Challenges: What’s Keeping You Here?
- Satisfaction and/or a lack of training — organizations, leaders, and engineers alike may feel they have achieved their automation goals.
- An orchestration tool that lacks the ability to expose its functionality for self-service.
- End users/consumers whose work management systems lack the technical sophistication to request a network service via API.
- A lack of understanding at any level of the organization around the value moving from process orchestration to self-serve networking can deliver.
How to Evolve
The most important thing a network automation platform can offer to help your organization reach Stage 4 is northbound integration via API exposure. Teams who have not already should invest in a platform that enables northbound exposure of network automations as services that can be accessed in other systems such as pipelines or ITSM systems. If the platform has already been adopted, then teams should invest in expertise with their chosen platform such that they understand how to expose automations for external consumption while including guardrails to keep the network safe.
As an Engineer
- Familiarize yourself with APIs.
- Familiarize yourself with data formats such as JSON and schemas such as JSON Schema.
- Gain an understanding of the DevOps approach and CI/CD strategies.
- Gain a process-level understanding of pipelines, microservices, and version control – no need to learn how to code.
As an IT Leader
- Work with relevant business stakeholders to define your self-serve networking requirements and begin to define your desired services catalog.
- Ensure you’ve invested in an automation platform that enables self-serve networking delivery with capabilities like northbound API exposure and pipeline integration.
- Learn about treating network infrastructure as code, which is simpler than it sounds – focus on enabling reusability, leveraging available resources, and bringing NetOps closer to the rest of IT.
By evolving from engineer-level task automation to team-wide process orchestration, organizations see faster service delivery and increased network team capacity. Without a comprehensive understanding of network automation and the possibilities that can be achieved with it, an organization might just stop here. But those on the forefront are pursuing self-serve networking to achieve even greater value. They are working to bring networking to IT and application teams in a way that is consumable, supported, and scalable.
Stage 4: Self-Serve Networking
Defining Self-Serve Networking
At this stage, network functionality is exposed for self-serve consumption to end users and systems in the IT organization, facilitating cloud-like delivery of network services by enabling other teams to make network requests with no back-and-forth and minimal wait times. Ideally, automations can be triggered by events, called via CI/CD pipelines, and exposed in end user IT systems like ServiceNow enabling network assets to fully participate in the DevOps ecosystem with all its benefits. The more widely and more easily consumed discrete network operations are, the more opportunities there are for customers and the internal business to benefit from each automation asset.
Delivering self-serve networking is the best way to maximize automation consumption, which therefore drives automation value. Automations should be exposed to the systems and platforms in use among the IT organization today, ensuring maximum value and minimum investment in challenges that have already been solved.
Common Characteristics
- Cloud-like IT service delivery.
- Individual network change processes are exposed as microservices for consumption by other users, to be triggered by events, and for consumption via CI/CD pipelines.
- The impetus for automation is a business process instead of a network engineering need alone – automations are built with a larger strategy in mind and as a result deliver increased value.
- Larger organizations will be working toward a platform engineering strategy.
Benefits
- The network automation platform exposes its API northbound so that network changes can be consumed as services, including changes in systems that the platform integrates with southbound e.g., SD-WAN controllers, data centers, and cloud assets.
- Automations are seamlessly integrated with the systems your organization uses to manage work today, e.g., ServiceNow or other ITSM systems.
- Automations can be exposed to external end users with no risk due to configuration validation and customizable guardrails.
- Testing and validation capacity is greatly increased – many tests can become part of standard unit testing for all automations, and pipelines can be leveraged for regression testing.
What’s Next?
Self-serve networking is not so much an end state as a constant iteration and improvement. The systems your organization uses to manage work may change, which will change where or how your network team looks to expose these network services to users. Additionally, as a team continues to pursue self-serve networking, their base of automation assets only continues to grow, which then requires strategic management for success. With the right mindset and strategy, and by ensuring the automation tooling you use is built to be adaptable for a modern technology stack, you can set your organization up for success going forward.
A highly mature network automation team that delivers self-serve networking across an organization’s IT infrastructure will be better equipped to adopt new security technologies, expand into new network domains, and adapt to new connectivity requirements, since methods and practices will be highly standardized.
At this stage of automation maturity, you have successfully achieved cloud-like delivery of network services – so run with it. Now, networking and the rest of IT can collaborate faster and more easily to deliver more innovation at scale. Applications can be developed and tested faster, new locations are easier to connect to your infrastructure, and your organization has greater business flexibility, all enabled by your network automation evolution.
Teams that have achieved self-serve networking can deliver network services to end users with a cloud-like experience and minimal wait times, maximizing automation consumption and increasing the value of every automation asset. Work output is decoupled from head count, and almost all physical work performed by the network team now goes toward the creation of reusable assets that drive additional value. The incremental cost to perform a change is minimal, enabling a much greater level of scale than had previously been possible.
Key Takeaways
Identify Your Current State, Determine Your Automation Goals, & Build Your Evolution Strategy
- Perform an assessment of your people, team(s), and organization.
- Skills – Network technologies, Cloud, DevOps, software development, etc.
- Capacity – head count, team structure, skillsets, and organization.
- Current automation maturity – will often vary between individuals and between teams.
- Identify a target state leveraging the Maturity Model that helps unify and progress your automation strategy.
- Understand the business and technical requirements and the scope of control for leaders in different parts of the process.
- Evaluate costs and benefits of progressing to the next stage of the model.
- Work with relevant stakeholders and determine a 3-5 year plan for the organization that allows you to evolve your automation capabilities practically and predictably.
This guide is designed to help you place yourself, your team, and your organization in a wider context so you can understand where you are and where you want to be – whether you’re a network engineer or a CIO, understanding the different stages of automation maturity is crucial to enabling significant evolution with a tangible payoff.
How Itential Helps You Evolve
Core to Itential is the belief that automation solutions should meet users where they are in their journey, helping to expand the scale and impact of their network automation efforts by providing the right tools to evolve. The Itential Automation Platform is built to provide automation value and support automation evolution no matter where along the Maturity Model a user, team, or organization starts. This is achieved primarily via Itential’s API-first integration approach and its low-code, modular automation building features.
Evolving from Task Automation to Process Orchestration
At the earliest levels of automation maturity, Itential provides a unified platform and a no-code option for building automation workflows. Teams with disparate automation efforts, where single engineers write scripts ad hoc, can come together to build automations for all their routine tasks and share automation assets in one place without learning special skills.
Evolving from Process Orchestration to Self-Serve Networking
Maturing teams can leverage Itential’s robust integration and orchestration capabilities to build end-to-end automations, orchestrating entire processes instead of automating single tasks.
And for forward-looking organizations looking to solidify and evolve their automation strategies, Itential’s ability to expose its own API to northbound systems allows for self-service delivery of network automations to whichever platform or system your end users require. This cloud-like service delivery drives up automation consumption and accelerates processes across the entire organization.
As an Engineer
- The low-code workflow builder canvas means engineers can get started right
away without learning special skills, accelerating adoption and making
automation more efficient from day one. - Codeless onboarding of all CLI-based automation assets, such as Python scripts and Ansible Playbooks, allows engineers to not only continue to use automations they’ve built, but turn them into modular, reusable, secure and
scalable assets. - A focus on modularity means any individual piece of an automation workflow
can be shared, reused, and extended. Collaboration becomes a practical
possibility, as individual automation assets like scripts can be decoupled from
the single engineer who built them. - Codeless integrations enable network automations to traverse any system and
any network domain without cost or delay. That means extending automation
activities past a specific network change, enabling entire processes to be
automated for zero-touch delivery and freeing up engineers’ time and effort.
As an IT Leader
- The low-code workflow builder is easy to learn, which makes getting team buy-in and encouraging automation adoption faster and smoother.
- The API-based integration model allows network teams to more reliably
collaborate with other IT teams, building automations that are seamless pieces of overall infrastructure as opposed to staying within the networking silo. - End-to-end automation enables faster service delivery, which accelerates
innovation across the organization and changes networking from a bottleneck
to a value driver. - Itential’s standards-based API-first approach is vital to its future-proof approach. Rather than limiting users to certain kinds of network technology decisions, Itential allows for any future system, technology, or domain to be adopted, since integration is possible regardless.
- The platform avoids prescribing a data model by leveraging JSON for data
transformation, taking a data federation approach that allows for distributed
network infrastructure with multiple sources of truth.
