Integration, Federation, & Data Transformation Capabilities

Itential’s API-first, integration approach to network automation and orchestration is redefining how we manage complex, distributed networks. The Itential Platform is the only solution that can integrate with any network (physical, virtual, and cloud) and any IT system, and transform the data into a common language (JSON) delivering a unified, real-time federated view of the resources and data. Our patented approach simplifies network orchestration in that users do not need to learn multiple technology types and can reduce time and effort in deploying, managing, and maintaining network infrastructure.

This white paper explores the foundations of the Itential Platform’s unique, patented integration model for network orchestration across multiple networks and systems. Itential provides out-of-the-box, no-cost integrations to all network and IT systems so network teams can easily build end-to-end orchestrations across every component of network infrastructure. This eliminates the ‘integration tax’ that limits organizations’ flexibility when making new technology decisions.

Components of Itential’s Integration Model:

Dynamic Integrations for API & CLI Assets

Eliminate the Cost & Time Investment to Connect to New Networks & Network Systems

There is a wide variety of tools available today for activities related to every sector of IT infrastructure. As a result, different groups will make individual choices as to which technologies best suit their needs — even within the same organization. The flexibility of this decentralized approach enables technology to be adopted on a case-by-case basis, resulting in tools that more closely match a given use case. However, the resulting large and diverse ecosystem of hardware, software, and applications can negatively impact collaboration between IT teams, affecting end-to-end process time for many activities and hurting the business.

IT organizations do not operate efficiently when teams are siloed. Therefore, an effective network orchestration solution must provide the ability to integrate with every system and technology so that network change processes that involve external systems can be automated end-to-end. This approach eliminates the delay and frustration often associated with either IT teams or network teams making requests of the other.

Itential leverages the APIs that modern systems provide to enable a vendor-agnostic and technology-agnostic approach to integration. For CLI-based assets, the Itential Automation Gateway application allows for easy onboarding without code, turning those assets into APIs for use in the same orchestration workflows. In this way, the Itential Platform serves as a universal intermediate, connecting southbound to all network devices and cloud resources, east/west to all network and IT systems that are used to execute a change process, and northbound to different types of consumers.

Simplifying Connectivity with Integrations & Itential’s No-Code Adapter Builder

The Itential Platform utilizes two mechanisms to communicate with network systems – integrations and adapters. Integrations are designed for real-time API interactions with systems and controllers, while adapters support use cases where more robust, complex interactions may be required with the network.

Adapters are the implementation that supports interactions with controllers, orchestrators, and REST interfaces that trigger specific actions.

To create adapters, teams can use Itential’s free Adapter Builder for most systems, users are able to upload an API document of type Swagger, OpenAPI, or Postman Collection. The tool then reverse-engineers an adapter. For those systems whose APIs do not fit a standardized format, Itential users can also leverage a step-by-step form-based approach to define and build an adapter from scratch.
Explore Itential’s Adapter Builder

Pre-Built Integrations Library

While auto-generation is the primary method Itential users employ to build integrations, Itential also publishes a growing library of 200+ open source Pre-Built Integrations for easy use. Some vendor systems do not provide a publicly available API specification, so Itential engineers work to publish these free resources for users to integrate with those systems. In addition, integrations for several of the most widespread network systems are included for speed and convenience.
Explore Itential’s Pre-Built Integration Library

Itential Automation Gateway for CLI Integration

Itential Automation Gateway is an application within Itential that allows for easy onboarding of all CLI-based networking assets, including those with CLI, SSH, NETCONF, and GNMI protocols. It enables users to turn these assets into APIs and add them to the federated master list of automation assets for use in workflows which are primarily comprised of API-based tasks.

With these methods, integrations can be implemented much more quickly than via any custom development effort. This enables network teams to adapt to new technologies faster, accelerating end-to-end process time for network changes.
Learn more about the Itential Automation Gateway

Data Federation

Maintain an Accurate Real-Time View of all Controllers, Clouds, & Network Systems

Itential’s patented approach to network data federation enables users and applications to implement business logic in one place for all devices, resources, or systems they require, even across distributed network infrastructure.

Federation of network device data within Itential is managed by the broker layer and the adapters layer. The role of the adapters is to connect to southbound systems, using the native API unique to each system. Each adapter registers with the broker layer by providing details to the brokers about the types of entities managed by the southbound system. For example, some controllers may contain information about core network routers while others contain information on data center switches. The adapters and brokers recognize that both of the southbound systems provide information about devices and combine the information from each system into a master table of devices.

Once the brokers have created their master lists, the business logic layer can perform device-related operations across any of the southbound systems. The brokers maintain the mapping of each device to its corresponding southbound system, ensuring that changes are executed correctly. End users can filter the device on a wide range of parameters. They can view all devices and systems globally, or filter by device type, site, capabilities, and other relevant specifications.

When a new system is added to the network, the following process enables Itential to incorporate it with the federation layer. Itential:

• Receives a request for new API interface.
• Instantiates a broker instance and fetches entity models.
• Registers the adapter for the new system.
• Ingests APIs from the adapter.
• Instantiates an entity instance based on ingested APIs.
• Maps registered adapters to instantiated entities for API routing.
• Generates a federated API based on the APIs ingested, which can now be called for use in orchestration workflows.

Correlation & Management of Distributed Network Devices

Federation provides a comprehensive directory of similar device types across multiple disparate network domains. It acts as a mapping of the network, centralizing and displaying devices from all across an organization’s disparate infrastructure and providing type and location information.

Using this master list, an operator could create applications or workflows to perform actions such as a policy audit or global configuration change without logging in to individual EMSs, controllers, or other southbound systems. Another benefit of correlation is in scenarios where a single entity may be represented across multiple systems. For example, a network router may have a representation in a network controller, an IPAM system, a performance management system, and a topology system. In this situation, Itential can recognize that each of the systems is referring to the same router and will provide a single, correlated view of all of these representations.

Global, Real-Time Mapping of Southbound Systems & Connected Devices

Because the federation system dynamically ingests information from the southbound systems, the Itential Platform can present a single, global, real-time directory of all network infrastructure. One example of this is federation of data center controllers. Once connected, the federation system creates a real-time, master list of all southbound controllers and the devices connected to them, in either a single-vendor or a multi-vendor controller environment. The enables end users to utilize a single platform for visibility and management of the configuration lifecycle of those controllers without the need to login to each data center controller individually.

Dynamic Response to Southbound Changes

Each time the federation system requests information from a southbound system, it dynamically learns about changes from those systems, such as deployment of a new device or decommissioning of an old one.

Common Platform for Execution of Business Logic

Since the federation system has visibility and understanding of all of the connected controllers and entity types, it becomes the ideal place for development and execution of business logic. In this approach, the business logic is independent of the specifics of the southbound controllers, enabling users to develop reusable applications and workflow components that can execute changes across multiple connected systems. For example, in the case of compliance, there is business logic that defines rules and exceptions which practitioners must map to and run across different types of objects, whether they are accessed via API or CLI. Federation makes this process more efficient.

With this approach, systems do not need to have the capability to directly communicate with all connected networks, controllers, and devices, enabling greater flexibility. For a complete, technical breakdown of Itential’s unique approach to network data federation, refer to US Patent 11,665,241 B1.

Data Transformation

Eliminate the Cost & Time Investment to Translate Data between API Calls in Automated Workflows

When orchestrating workflows that involve interactions with multiple systems and network types, it’s often necessary to manipulate the data from one system to make it usable by other technologies or within specific use cases. The ability to quickly and easily transform data has become more important as teams expand from single task automation to end-to-end process orchestration, as data may go through multiple transformations as part of an overall process. For example, the request data may begin as a ticket, which then is parsed and augmented with details from sources such as network inventory systems, before finally the payload goes through a last transformation to ensure it is formatted correctly for the relevant network elements.

JSON as a Universal Translator

When Itential was in its earliest design stages, the decision was made to avoid implementing fixed, domain-specific data models and instead provide capabilities for data of any format to be ingested and manipulated to build orchestrations. A prescribed data model would limit a user’s choices or lead to extra cost when adopting new network and IT technologies.

For increased flexibility, Itential leverages JSON as its universal format for data representation. JSON, a human-readable format, has gained market adoption for its efficiency and flexibility. This JSON-based approach enables the platform to act as the intermediary for disparate systems, making it possible to efficiently navigate between data formats from disparate systems and technologies to orchestrate the steps of an end-to-end workflow.
Blog: Top Reasons Why Itential Leverages JSON as our Data Format

JSON Schema Transformations

Itential users leverage the JSON Schema Transformation (JST) Designer application within Itential to build data transformation tasks without writing code. The tool provides a drag-and-drop visual interface that abstracts the transformation logic so network engineers can use the feature with no special skills. The tool transforms data from one JSON schema to another, ingesting the output of one API call and returning the correct format for the next API call’s required input. Then, the JST itself becomes a drag-and-drop automation task in an orchestrated workflow, similar to the steps that represent the API calls themselves.

For example, one network engineer builds a JST to take in an output from an inventory system and transform it into a series of CLI commands to determine network state. This data transformation will allow an automation for CLI-based devices to trigger without manual intervention after the workflow step that returned the device list from the inventory system. In addition, this JST will be reusable as a modular asset going forward, reducing future work to build workflows.
Explore the Itential JST Designer

Modularity & Reusability

In Itential, JSTs are available assets in the library of an organization’s instance of the platform, just like integrations, adapters, and individual automation tasks.

In the future, any JST an engineer builds can be reused for any automated workflows of other use cases that require the same type of data transformation. Furthermore, Itential provides an open source library of Pre-Built Data Transformations, which cover many common operations and can be used or edited across any number of orchestrated workflows.

By using the platform, Itential users are constantly contributing to a growing library of modular assets. Each successive automation use case that a team or teams build and deploy has a stacking benefit, accelerating orchestration efforts over time.

With its patented data transformation capabilities, Itential enables network teams to build workflows that orchestrate full processes end-to-end, across any number of different east/west systems, without compromising data integrity. Enterprise networks include numerous external systems, a state that is unlikely to change in the near future. Itential’s JSON-based approach ensures that orchestration efforts are not hindered by these complex networking ecosystems.
Explore Itential’s Pre-Built Data Transformations

Flexible Northbound Exposure Model

Expose Network Orchestration Functionality to Every Northbound System, Pipeline, & End User

Integration is as much about exposure and consumption as it is about creating the conditions to build effective orchestrations. For network orchestration to drive business value, orchestrations that the network team builds must be actively consumed by end users. Itential is designed to deliver northbound exposure capabilities to as large and diverse a set of end users as possible, enabling any type of system, pipeline, or user to make network requests of Itential’s API and see the instant cloud-like network service delivery that modern users are trained to expect. In this model, network orchestration services are equally easy to request for all teams, no matter their native system.

This approach to enabling orchestration consumption solves two potential issues. First, it means Itential users are not forced to consume orchestration in a specific way, so orchestration can be seamlessly incorporated with current tools and processes. Second, it eliminates the delay for IT teams such as application developers to see their network service requests fulfilled, which accelerates business processes overall.

A Single, Aggregated Network API

Itential can be imagined as the centerpoint between two funnels opening outward, or the middle section of an hourglass. It acts as a single intermediary through which any kind of user can request any kind of network service.

The platform essentially aggregates the functionality of all southbound systems to present a unified network API, which can be consumed by northbound systems for self-serve network orchestration requests. In addition, microservices associated with specific southbound systems can be called via the Itential northbound API, adding a new degree of flexibility to network and IT operations.

This simplifies interactions with ITSM, DevOps pipelines, and other systems by enabling them to create a single connection to Itential’s federation system and gain visibility into southbound systems. The data federation system creates a kind of map of the network, and then any type of northbound user can access it in accordance with their use case and their permissions.

When an API call is made to Itential’s aggregated API from some end user or application, the following process enables Itential to determine how to route the call. Itential:

• Receives the API call at a universal business logic layer.
• Generates a language-agnostic message corresponding to the API call and transmits that message to a broker (federation) system.
• Determines the optimized adapter(s) to use, prioritizing making only one API call.
• Routes the API call to the correct adapter.

For a complete, technical breakdown of Itential’s method for API call routing via a broker layer, refer to US Patent 11,665,241 B1.

Accommodate Every Northbound System, Pipeline, & User

Building orchestrations for network change processes only drives value when those orchestrations are consumed. Modern IT organizations leverage complex technology ecosystems to manage work, and many teams that are the most relevant end users for network orchestration efforts are entrenched in certain environments, such as ServiceNow for IT admin teams or pipelines for application developers.

Itential’s northbound API approach enables any kind of system that can make an API call to request published network automations or specific pieces of Itential functionality. When a network automation is exposed in this way, the network team becomes a more efficient component of the overall IT organization.