フィードを購読する

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.


執筆者紹介

Jesse Langhoff is the Director of Sales at Keyva, an ISV and Apex services partner of Red Hat dedicated to helping its clients achieve business and technical success through emerging technologies. Langhoff has spent over 15 years in automation and cloud technologies most recently with Red Hat and prior to that as the head of sales for a cloud consulting organization.

Read full bio
UI_Icon-Red_Hat-Close-A-Black-RGB

チャンネル別に見る

automation icon

自動化

テクノロジー、チームおよび環境に関する IT 自動化の最新情報

AI icon

AI (人工知能)

お客様が AI ワークロードをどこでも自由に実行することを可能にするプラットフォームについてのアップデート

open hybrid cloud icon

オープン・ハイブリッドクラウド

ハイブリッドクラウドで柔軟に未来を築く方法をご確認ください。

security icon

セキュリティ

環境やテクノロジー全体に及ぶリスクを軽減する方法に関する最新情報

edge icon

エッジコンピューティング

エッジでの運用を単純化するプラットフォームのアップデート

Infrastructure icon

インフラストラクチャ

世界有数のエンタープライズ向け Linux プラットフォームの最新情報

application development icon

アプリケーション

アプリケーションの最も困難な課題に対する Red Hat ソリューションの詳細

Original series icon

オリジナル番組

エンタープライズ向けテクノロジーのメーカーやリーダーによるストーリー