Creating an enterprise service request bridge between ServiceNow ITOM and Red Hat Ansible Tower

At Keyva, we see clients in all phases of their automation journey. Some organizations are just starting out and automating domain lifecycle tasks, such as provisioning firewall rules or automating server builds, while others may be well down the path of creating self-service IT capabilities. In most cases, regardless of where a team is on its journey, they eventually want to arrive at the point where they can provide self-service IT capabilities to the teams and users that want to consume them. 

At a basic level, self-service IT requests require two primary pieces of functionality: a request portal and automated request fulfillment. Let’s briefly look at both components. 

Request Portal (Service Catalog):

In a simple form, this is any sort of user interface that will generate a request for an IT capability or service. In an enterprise IT setting this often takes the form of an enterprise service request catalog. The benefits of an enterprise service request catalog are many, but generally include: role-based access control, multitenancy, approvers, approval flow, governance, auditability, configurable request interface and process flow. Service catalog owners usually want to be able to provide access to a wide array of service catalog items that follow a known best practice for request and fulfillment which can be audited. 

Automated Request Fulfillment (Automation Platform): 

This is the other side of the self-service IT request process. Automated Fulfillment takes in the request from the request portal and runs automation against one or more tools or systems using information passed to it in order to fulfill the request. Generally automation platform owners want to know that the request being made is valid, that the information being passed to the automation platform is correct and was approved via best practices. Additionally, they want to ensure the automation requested leverages key best practices. As the request is fulfilled and the automated tasks are executed, important service and diagnostic information is passed back to the service request interface along with details regarding the newly provisioned service. 

Looking at it another way, on one side of the river we have the request for service. On the other side of the river, we have fulfillment capabilities. How we reliably cross the river back and forth becomes important. We want something that can scale, something that we can support, and something that can provide end-to-end visibility to our service request & fulfillment. 

Should We Build And Support Our Own Bridge Between Request & Fulfillment?

In the absence of a better choice this might be one of your only options. Generally speaking, this is not a desirable solution. Whatever you build, you will need to maintain.  

If you are not an ISV (independent software vendor) of the solutions you are linking together, you likely cannot get the integration certified by either vendor. You are likely adding to your operational overhead, spending time focusing on supporting what you deliver, rather than creating new capabilities. 

Lastly, remember the two river banks: a service request is generally handled by a different team than automated fulfillment. What may be acceptable for one side may be unworkable for the other. 

Certified Integrations Are Made For This Work 

At Keyva, we spend a lot of time automating self-service requests for our clients and we see the “lack of a bridge” issue arise frequently. We believe if a certified integration exists that you should seriously consider it before rolling your own version. We believe this strongly enough that we became an ISV of multiple vendors to better support our clients in building the bridges they need to successfully deliver self-service capabilities. One bridge we often see a need for is between ServiceNow service request catalogs and Red Hat Ansible Tower. So we created one!

What Do Certified Integrations Look Like?

In our example, the Keyva integration between ServiceNow and Red Hat Ansible Tower is bidirectional: there is a ServiceNow component and a Red Hat Ansible Tower component. The ServiceNow portion is called a northbound integration (originating from ServiceNow and integrating with Red Hat Ansible Tower). 

This integration has the NOW certification designation from ServiceNow. That means it is certified by ServiceNow to work with the last three major versions of ServiceNow. The Red Hat Ansible Tower portion (a southbound integration from Ansible Tower back to ServiceNow) is a Keyva-developed Ansible module which we support. 

So what is the operational overhead of a supported module? As you would expect, it is low. The ServiceNow (northbound side) is a ServiceNow scoped app — that means it does not require any additional ServiceNow licensing (Orchestrator or Integration Hub) and it installs with a click from the ServiceNow app store. 

As a scoped app it simply adds another tab for Ansible configuration within the ServiceNow interface (you can view the integration and request a trial here.) The Ansible Tower module (southbound) integration works exactly like you’d expect a module to work — simply install it and you’re ready to start using it. 

The southbound component is extremely important as Ansible, will be orchestrating downstream provisioning, configuration, and other tasks. This southbound component allows it to bring status and important configuration information back to ServiceNow and closes the loop on self-service catalog requests.

Seeing Is Believing

Building a proper bridge between request and fulfillment can greatly accelerate your ability as an IT organization to provide a multitude of self-service capabilities, but don’t take my word for it, please see it in action for yourself. 

Keyva offers free trials of the ServiceNow and Ansible Tower integrations and is happy to talk you through your self-service use cases. Learn more about the ServiceNow and Red Hat Ansible Integration.