Introduction
The network landscape has changed significantly in recent years, with the introduction of technologies like public/private/hybrid cloud networking, SDN, SD-WAN, virtualization/containerization of network functions, and the explosive growth in demand for fully functional, remote worker access. With their dynamic, virtualized API-centric interfaces, these functions and applications have disrupted the former CLI-centric model. and have introduced additional complexity to the operations and management of the network. At the same time, developers and users have become accustomed to “same day” availability of services from public cloud providers like AWS and Azure.
With this shift and the increase in demand, organizations are challenged with developing an effective automation program to ease the burden put on teams to understand, learn, and execute across the modern network landscape. In order to maximize automation efforts, Itential has worked with countless organizations to take a new approach to automation by building an Automation Factory model instead of taking an ad-hoc approach.
This white paper will cover the importance of developing an overall strategy for automation, the drivers for organizations to consider when creating their own Automation Factory and how the Automation Factory model fits into an organization’s overall strategy.
By having a common set of metrics and common criteria for prioritization and selection of use cases, teams will have a clear perspective on how to select and measure the use cases that will drive the greatest benefit for their business. If each team is using the same methods for evaluating what they are going to automate and measuring the results of the automation, it allows the overall organization to understand how and where automation drives the best results.
There are many organizations that are using a “tribal” approach to automation. Small teams have discovered the advantages they can gain through automation and have begun to develop their own unique toolsets and scripts. The problem with this approach is that it will be extremely difficult for automation within the overall organization to hit critical mass. This type of ad-hoc approach becomes more and more difficult to manage as the number of use cases grows and the scale increases. At some point, teams find themselves spending more time maintaining old code than developing new automations, resulting in productivity declines.
Developing an organizational automation strategy avoids this scenario by ensuring that all teams are using common methods. Investments can be better leveraged across multiple teams, which gives organizations the ability to invest in a smaller set of tools that can support the growth and scale required by the business.
A Tool is Not a Strategy
To help set the context, it’s important to address a common misconception – An automation tool is not a strategy. Tools are important, but they are only one element of what’s required to have an effective automation strategy. Tools, on their own, can be used in lots of different ways but just picking a specific scripting language, application, or orchestrator ignores critical factors such as business imperatives and lacks program structure, processes, business alignment, and the mechanisms required to maximize business value.
Picking a Tool is Not Enough
In most environments that use a tool-focused approach, automation activities focus only on the automation of the change to the network elements. For example, an engineer might write a script or playbook to push out configurations, provision a service, or to complete a device maintenance activity such as an upgrade.
This timeline roughly approximates the duration and effort associated with business processes that involve changes to the network. Typically, the process starts with activities related to the planning and scheduling of the change – this may include performing discovery of target devices through a network inventory or an audit of the network, as well as planning for the change and creation of the implementation schedule.
Next, the engineering team will perform the design work associated with the change. This would include things like creating the new configurations, obtaining the appropriate variables (like IP addresses, firewall rules, or policy definitions), and testing the changes.
Once the design and testing work has been completed, and the target elements have been identified, the implementation of the change is scheduled for maintenance window and the change is applied.
Once the change has been applied, the engineers will perform verification to confirm the changes were successful, either by performing post checks or by using an external test system. Finally, when the change has been confirmed to be successful, the engineering team will perform closeout activities, which may include things like closing a ticket, updating databases, or notifying end customers.
The percentages for each phase refer to the relative time and effort associated with each of the stages. So in this example, the design and preparation phase accounts for 40% of the total time and effort to execute the business process.
The bracket is focused on the implementation and activation step, which accounts for only 10% of the total time and effort. This is the only step that most tool-centric automation approaches focus on. Typically, engineers will create and run a script during a maintenance window.
While this approach may be good for the engineer that is running the script during the maintenance window, it does very little for the rest of the business process. This means that the best an organization could hope for is to significantly reduce the effort for only 10% of the end-to-end process.
With Itential’s Automation Factory approach, the automation focus extends beyond the 10% of the implementation step to encompass the end-to-end process. There are several factors that are required to make this possible:
- First, all groups involved in the business process need to be aligned on performing their activities within an automation-centric model. They need to be prepared to move away from emails, manual database interactions, and spreadsheets to move toward automation platforms that enable systems to collect, analyze, transform, and engineer the data during the planning and design phases.
- Second, they need to use platforms that can interact with databases and IT systems to manipulate the data, using accepted engineering rules, for creating and testing the changes to the network.
If both factors are in place, an organization gains the ability to automate 100% of the business process. This is where the real business benefits can be realized, in terms of productivity increases and in the reduction of time intervals for the completion of the work.
What is an Automation Factory?
At Itential, we believe there are four components of an Automation Factory:
01 People
The engineers and developers who define the automations, develop the code, and run the systems, all guided by the automation strategy.
02 Technology
The software, integrations, and connectivity required to execute the automation strategy. This includes components like the ability to interact with multiple technology domains and business systems, as well as capabilities like performance, throughput, and scalability.
03 Processes
The processes for selecting, prioritizing, quantifying, and developing automations that are aligned with the strategic objectives.
04 Metrics
For quantifying and validating the business benefits.
A recent quote from Ross Winser at Gartner further highlights the shortcomings of a tool-centric approach.
Winser predicts that top performers will avoid the pitfalls of ad-hoc automation by establishing dedicated leaders responsible for automation and through the creation of proper automation strategies, not just tool selection.
People: Leveraging the Right Skillsets
Automation activities require a unique mix of skillsets. Technical subject matter expertise is essential for designing and implementing effective and efficient automations, while some level of software development is required to create the software that will perform an automation.
Historically, subject matter experts oriented their skillsets around their technical area of expertise and were not required to be proficient in software development. Conversely, software development experts frequently lack the deep understanding of the specific network technologies, so the only solutions were to either find the rare engineer that possessed both skillsets or to create hybrid teams with a mix of subject matter experts and developers.
To address this gap, Itential’s Automation Factory approach is based on the following considerations:
- Select tools and techniques that enable domain experts to focus their expertise on solving engineering challenges by offloading repetitive, time-intensive tasks to Itential’s Pre-Built Automations or to tools that require minimal or no software development.
- Create frameworks and components that are guided by engineering best practices.
- Enable developers, when needed, to focus on creating those frameworks and components.
Technology: Selecting the Right Tool for the Job
Selection of effective automation technologies is an essential component of an automation strategy to ensure the ability to deliver on the foundational principles. The technologies must, first and foremost, provide the most efficient capabilities for accelerating the realization of business benefits, in terms of productivity, cost, and efficiency.
Tools Approach vs. Platform Approach
The initial decision point for tool selection is whether to build the capability in-house using existing technologies and open source components (tools approach), or to implement a fully functional, pre-integrated automation platform (platform approach) like the Itential Automation Platform.
With a tool-centric approach most of the efforts are focused on automating repetitive tasks to gain efficiencies. Business processes remain largely unchanged, with tools being used to automate standalone tasks within the process. The impact of these efforts can be meaningful for individuals — an engineer can perform 100 assignments in the time it previously took to complete one — but the results are not transformational for an organization, due to two reasons:
- Does Not Impact the Overall Processes: This approach to automation is only focused on specific tasks and does not impact the overall process because this approach neglects handoffs and other activities that occur beyond these execution tasks. Automation that addresses individual tasks but not the idle time from handoffs between teams provides limited value.
- Relies on Human-Centric Paradigm: A task-centric automation approach still uses a “human-centric” paradigm for process execution. Most activities and processes are designed around how much time it would take an average engineer to perform a task – so the work and the Service Level Agreements (SLAs) are based on human limits. For example, if an engineer only has enough time to perform 2 pre-checks in a maintenance window, then 2 pre-checks become the standard. The standard isn’t driven by technical requirements, its driven by a human limitation. The technical requirement may be better satisfied with 10 pre-checks, but there is not enough time for 10 pre-checks. With automation, the automation system can perform a pre-check in seconds as opposed to tens of minutes or even hours. By moving from a “human-centric” paradigm to an automation-centric model, the team can let the system run 10, 15, 20+ pre-checks in seconds, enabling the process to execute more efficiently and safely. The only way to do this is to move away from a model that automates individual tasks, and instead automates the entire process.
How a Platform Approach Utilizes Automation Properly to Fully Transform an Organization
For automation to become truly transformative, automation implementation must have the ability to reflect a “machine-centric” paradigm, which is only possible by taking a platform approach to automation and moving away from a tools-centric model.
By automating an entire process, not just individual tasks, teams gain the flexibility to do much more in much less time with fewer resources — truly making innovation possible. When the marginal cost and time to provision a service or to deploy a new network function becomes trivial, internal customers can focus on creating new services, composed of capabilities that were previously too costly to manage. Engineering and operations teams can focus their attention on strategic activities of greater value that require their domain expertise instead of performing routine, time-intensive, and repetitive activities.
As the rate of change in network technologies increases, the value of a platform-centric model with becomes even greater. Networks are now composed of a more diverse set of technologies than at any other time — with older Command Line Interface (CLI) based systems operating alongside cloud controllers, virtualized/containerized functions, and network controllers. These technologies have the potential to deliver unique, differentiated, high-value services, but only if a business transforms the way they are designing and executing business processes, and only if they utilize the Itential Automation Platform that has the capabilities to deliver true end-to-end, machine-centric automation.
Creating an in-house automation platform requires significant effort, both in terms of building the platform and then in terms of operating, maintaining, and updating the platform. Approaches that depend on a CI/CD toolchain require a high level of ongoing maintenance, and have challenges associated with their ability to scale without requiring additional resources for ongoing care and feeding of the toolset. This creates additional burden on an automation team, as they not only have to focus resources on the development and implementation of the automation use cases, but also need to invest significant time, energy, and resources to first build the environment, and then to perform ongoing maintenance and development of the environment.
The alternative is to select an existing platform like Itential that meets the requirements, while providing additional capabilities that can further extend the functionality and flexibility of the automation system to scale and to support new use cases and emerging technologies.
This alternative provides a much faster path, as it requires no development cycles to establish the platform capabilities, so an automation team can immediately begin to develop and deploy automations – driving a much faster time to value than through any other method.
When comparing the option of building vs. buying a platform, the option is clear:
One of the main advantages of utilizing the Itential Automation PLatform is it’s ability to expose and interact with capabilities that already exist within an organization’s network. Itential provides this level of ease-of-use and functionality by providing the following benefits:
- Pre-Built Integrations with more than 100 systems and the ability to auto-generate integrations for any in-house developed systems.
- Integrated security model with ability to control access at a granular API-call level, eliminating the need for a separate process for managing access and eliminating the risk of running untested scripts or unmanaged access.
- No-code development and execution environment that allows non-developers to create automations based on their technology domain expertise.
- Ability to expose functionality via API or Automation Catalog.
- Robust logging capabilities to enable product owners to collect operational data and report on key metrics to demonstrate realization of business benefits.
Process: How to Manage Network Automation
A network automation process provides the framework to start with an initial, narrowly defined network use case and engage a wider audience of stakeholders to determine the broader impact automation can have for the business and the proper metrics to determine success. Once this is accomplished, this process provides structure and accountability in creating, testing, and deploying automations which are then compared to the defined metrics to understand their real effectiveness to the business.
Planning Automations
The objective of the plan phase is to quantify, select, and prioritize use cases to be automated by engaging the appropriate stakeholders in the organization.
- Selection: The Automation Architect meets with other IT stakeholders to review the use cases that have been created in order to understand the technical and business requirements required for each use case.
- Evaluation: The Automation Architect and IT stakeholders perform a business analysis of the use cases in order to quantify the business benefits (effort reduction, time-to-complete, etc.).
- Prioritization: The Automation Architect and IT stakeholders prioritize the use cases for automation based on business impact, complexity or other factors, identifying which key metrics the use cases will impact. High impact use cases will be added to the development queue.
Design & Build Automations
In the design and build phases of the process, the technical work to build automations for the identified use case is accomplished. This involves starting with identifying the technical requirements by the Automation Architect and engaging the Automation Designers and Automation Developers to work on their focused tasks.
- Design Overall Automation: The Automation Architect collects the necessary requirements, defines automation(s), evaluates functional requirements, and identifies development requirements based on their discovery.
- Develop Automation Components: Automation Developers create custom components (workflow tasks, scripts, system integrations, etc.) based on the design requirements determined by the Automation Architect.
- Build Automations: Automation Designers construct the complete automation for a use case using a library composed of existing components and newly created components built by the Automation Developers.
Test & Deploy Automations
Once the building of the automation is completed, the test and deploy phases are where the automation now run in a lab environment to determine whether it functions as intended. There may be several iterations between testing and development teams before the automation is determined to be ready for production deployment.
- Test: Automation Designers and Automation Testers collaborate to define and execute testing of the use case automation in an appropriate test environment.
- Stage: After successful testing, the staging team moves the automation from the test environment to a staging environment for final review and preparation.
- Deploy: The automation is promoted to production by the staging team and executed by the operations group. End users execute automations and provide feedback to Automation Architect and Automation Development teams.
Analysis & Calibration of Automations
In the analysis and calibration phases of the process, the feedback loop of the automation process is completed. Performance data and metrics collected from running in the live environment is reported back to the stakeholders to determine if they are meeting the proposed requirements and if they are generating the expected business impact.
- Data Collection: Platform Operations extracts operational data from the production environment on per automation level to provide data on execution times, frequency, and quantity.
- Analysis: Planner and Business Owners analyze the operational data and calculate performance and business metrics to share with executives and report on business impact.
- Calibration: Planner and Business Owners compare results with projected impact to identify areas of improvement and to calibrate planning models and development approach based on actual results.
The diagram below shows an example of the CI/CD infrastructure that supports the automation development, test, delivery, and deployment cycle.
Network as Code
In order to advance network automation and truly adopt the process, organizations need to embrace software development practices, and treat the network configuration components as code.
Mindset for Network as Code
- Remove humans from network device CLI.
- Take monolithic treatment of network configuration and break it down into components.
- Determine the lifecycle for each component.
- Store components in git repository as the source of truth.
- Leverage appropriate tools to make modifications to each components (Day 0, Service, Policy, etc.).
- Leverage build processes to generate device configuration from components.
- Leverage tooling to perform validation (linting, static code analysis, unit testing, integration testing, lab validation).
- Leverage network integration tools to push network configuration tools to the network (Controller, Orchestrator, DevOps) to perform min-diff and transactional benefits.
Example Network as Code Process
Metrics: Maximizing Network Automation Value
Being able to measure automation success is key to any network automation project. Before you embark on building an Automation Factory, it’s imperative that teams uncover the key metrics that can help them measure the impact and build their business case for network automation.
Why A Metrics Driven Approach?
It’s critical for network teams to start thinking about how network automation will not just help them to do their jobs more effectively, but how automation will benefit their business.
- Quantify Impact of Your Automation: As the automation industry emerges from infancy, companies must start focusing on maximizing business impact.
- Enable Informed Automation Decisions: High-level goals like “OPEX Reduction” or “Go Faster” are directional, but not particularly useful for decision making.
- Create a Common Language: Automation teams and internal sponsors can gain from using a common set of metrics that more accurately capture the business impact of automation.
- Improve Selection & Performance of Automation: These metrics can be used both as an aid for evaluating/comparing automation solutions, and as a method to measure and report on automation implementations.
These are the four key objectives that Itential has been using with organizations as they executive on their automation initiatives that maximize business value:
Workload Unit Cost
Workload unit cost focuses not only on the total cost of the automation platform, but on the cost of that system in relation to how many activities it has completed or will complete. The more activities your automation completes, the lower the workload unit cost.
Efficiency & Productivity
Efficiency and productivity focuses on the quantity of people involved in, and required to, perform any manual steps that still remains in your automation. It can be based on the number of activities that can be performed by a single engineer or a group.
Time-to-Complete
Workload unit cost focuses not only on the total cost of the automation platform, but on the cost of that system in relation to how many activities it has completed or will complete. The more activities your automation completes, the lower the workload unit cost.
Versatility & Reach
Versatility and reach focuses on activities that can be expressed as a quantity but should also be characterized by the type and complexity of the activities performed: low complexity use case vs. high complexity use case.
It’s important to note that this is a very different approach than a high-level goal such as “OPEX reduction” or “revenue growth.” Instead, these reframe targets around cost, time, and flexibility so that they are oriented around specific automation targets.
How to Use the Metrics for Evaluating Automation Approaches
Consider the following when evaluating and selecting automation technology for your Automation Factory:
Workload Unit Cost
Does the capacity and cost of the option provide the lowest workload unit cost?
Efficiency & Productivity
Does the option require heavy human interaction or can it run unattended and maximize productivity?
Time-to-Complete
Does the option have the ability and connectivity to optimize time-to-complete?
Versatility & Reach
Does the option have the capability to touch as much of the network and business as possible? Can it automate the variety of use cases required by the business?
How an Automation Factory Fits with a Comprehensive Strategy
A comprehensive strategy is critical for network automation to move from pockets of automation to the level of business transformational.
By creating an effective strategy, automation teams can:
- Ensure alignment with business imperatives.
- Maximize utilization of investments.
- Accelerate realization of benefits.
- Drive consistency for metrics.
- Evolve automation to become organization-wide.
By taking this approach to build an Automation Factory, organizations can truly define their own automation strategy through alignment with business objectives to maximize the busines impact of their automation efforts. By leveraging Itential, teams have the platform they need to execute and optimize their network automation efforts across any network, any domain, and any use case, ensuring fully transformational benefits.
How Colt Built an Automation Factory
Colt’s Head of Network and Platform Architecture, Joan Espin Garcia, shared his story how he lead his team to build a successful Automation Factory.
Watch his session from AutoCon 1 to get a real-life implementation story including details on their automation journey, the strategic and technological reasons for shifting to an Automation Factory model and their step-by-step approach to implementing it.
