Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Don’t Confuse Business Process Management with Network Automation

DZone's Guide to

Don’t Confuse Business Process Management with Network Automation

Fore every task, there is an appropriate tool, and choosing the wrong one results in frustration and failed projects.

· DevOps Zone ·
Free Resource

Learn how integrating security into DevOps to deliver "DevSecOps" requires changing mindsets, processes and technology.

It is not uncommon for enterprises to confuse the role of a Business Process Management (BPM) system with that of a network automation solution. Because there are a lot of similarities between the two, we often see organizations attempt to leverage BPM systems to automate network activities in an effort to leverage their existing investments in these tools. Additionally, the allure of open source BPM options is often mistakenly seen as low-cost alternatives to network automation solutions. While the differences between the two are vast at their core, they are often overlooked or discounted in the planning process due to their common traits and similarities at the surface. Inevitably, their differences always present themselves as major problems during implementation when operators discover they can’t force a network focused automation process into a system not designed with that in mind; it’s just not the right tool for the job and as a result, falls short in automating critical network operations.

When looking at the capabilities of a BPM system as compared to a network automation solution, they both share similar features such as:

  • A workflow capability that allows you to define a series of tasks that must be completed in order to accomplish an activity.
  • A rules capability that allows you to define specific requirements with regard to who should perform a task or which pieces of data are required to complete a task.
  • Built-in intelligence for the specific kinds of activities they are asked to perform to enable reusability and to avoid having to build automation from scratch each time.
  • The ability to integrate to third-party systems and tools to allow for kicking off automation processes, a query of data from external systems for use in the automation, and to execute processes that exist in those external systems.

At the surface, it’s obvious why people make the assumption that a BPM system can be leveraged for network automation. However, as you begin attempting to follow this path it quickly becomes even more obvious that BPM systems fall short in many ways with regard to network automation.

In discussing why BPM systems fall short, it is important to mention the intent involved in the design of each type of system. BPM systems are designed with the sole intent of automating business focused processes such as those seen in Sales, Human Resources, and Finance. They focus much more on who is to perform a task, and they integrate with the intent of pulling or pushing relatively static data around pricing, billing, or benefits information such as health insurance. Additionally, they are heavily focused on human interaction, content management, and even social media integration.

Network automation systems are designed with the sole intent of automating very complex tasks in the network with very little human interaction. As opposed to only considering who is performing a task, a network automation solution has to consider whether that user has permissions to access the network elements involved in the automation. It would not be a good idea to assign a task to a person and just assume that because that person could be assigned a task that they were allowed to make a change in the network.

When diving deeper into specific use cases involved in network automation, the shortcomings start to become even more obvious. Activities such as device OS upgrades, configuration, and activation of network services, new device configuration, port activations, policy management, access control management, configuration management, and enforcement of configuration standards require the use of networking specific standards and technologies. Among these are modeling languages such as YANG, Ansible YAML, and TOSCA, which BPM systems were not built to understand or consume. Attempting to build network automation with a BPM system that has no understanding of these modeling languages would inhibit the ability to integrate with network facing systems such as managers, orchestrators, and controllers which are critical to network automation success.

Furthermore, the differences in integration and built-in intelligence between the two types of systems present a challenge. BPM systems have built-in functions for collaboration, document management, social media integration, and other business focused activities. Also, BPM systems frequently come with out-of-the box integrations to popular sales, HR, and other business applications to quickly get you up and running. Network automation systems have built-in intelligence on how to do pre- and post-network checks, software upgrades, port turn-ups, and other very technical network specific activities. Network automation solutions come with out-of-the-box integrations to network controllers, orchestrators, ITSM tools, and other network focused tools needed to build and execute network automation workflows. Each type of tool provides you with a head start in the domain it is designed for.

The Right Tool for the Job

Despite these challenges, some people still try to leverage BPM tools to automate network activities. The result is, at best, an inefficient and highly manual “automation” and, at worst, a complete failure to meet any of the goals set for the effort, thus resulting in a total waste of the time and money invested. The same problem would be seen in any attempt to use a network automation solution for a sales process. Both sets of tools have their place, but you must choose the right tool for the right job.

The right tool for network automation will have a very specific set of capabilities. These include:

  • Built-in network intelligence that is available out of the box with no custom development required.
  • Low-code, drag-and-drop approach to defining and executing automation that enable anyone, not just developers, to utilize by abstracting the complexity inherent with the network.
  • The ability to import in and leverage existing processes and investments in models, templates, scripts, and spreadsheets.
  • Industry standard compliance for YANG, TOSCA, Ansible YAML, and other templating languages used in the network and cloud domains.
  • Secure from the start, controlling who can and cannot have an impact on the operation of the network.

It is important to consider these capabilities when choosing network automation tools in order to avoid projects with unachievable goals and expectations. Attempting to automate your network with a BPM system that meets none of these will result in countless issues and will ultimately prove unscalable. Those who have tried to do so have canceled the projects and started over with the correct tools before ever making any significant progress. It is possible to avoid this tremendous waste of time, money and resources by understanding the differences between the two and selecting the right tools for the right job.

Learn how enterprises are using tools to automate security in their DevOps toolchain with these DevSecOps Reference Architectures.

Topics:
network automation ,business process management ,yaml ,tosca ,orchestrator ,configuration ,bpm ,workflow automation ,devops

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}