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.
Sull'autore
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.
Altri risultati simili a questo
Ricerca per canale
Automazione
Novità sull'automazione IT di tecnologie, team e ambienti
Intelligenza artificiale
Aggiornamenti sulle piattaforme che consentono alle aziende di eseguire carichi di lavoro IA ovunque
Hybrid cloud open source
Scopri come affrontare il futuro in modo più agile grazie al cloud ibrido
Sicurezza
Le ultime novità sulle nostre soluzioni per ridurre i rischi nelle tecnologie e negli ambienti
Edge computing
Aggiornamenti sulle piattaforme che semplificano l'operatività edge
Infrastruttura
Le ultime novità sulla piattaforma Linux aziendale leader a livello mondiale
Applicazioni
Approfondimenti sulle nostre soluzioni alle sfide applicative più difficili
Serie originali
Raccontiamo le interessanti storie di leader e creatori di tecnologie pensate per le aziende
Prodotti
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Servizi cloud
- Scopri tutti i prodotti
Strumenti
- Formazione e certificazioni
- Il mio account
- Supporto clienti
- Risorse per sviluppatori
- Trova un partner
- Red Hat Ecosystem Catalog
- Calcola il valore delle soluzioni Red Hat
- Documentazione
Prova, acquista, vendi
Comunica
- Contatta l'ufficio vendite
- Contatta l'assistenza clienti
- Contatta un esperto della formazione
- Social media
Informazioni su Red Hat
Red Hat è leader mondiale nella fornitura di soluzioni open source per le aziende, tra cui Linux, Kubernetes, container e soluzioni cloud. Le nostre soluzioni open source, rese sicure per un uso aziendale, consentono di operare su più piattaforme e ambienti, dal datacenter centrale all'edge della rete.
Seleziona la tua lingua
Red Hat legal and privacy links
- Informazioni su Red Hat
- Opportunità di lavoro
- Eventi
- Sedi
- Contattaci
- Blog di Red Hat
- Diversità, equità e inclusione
- Cool Stuff Store
- Red Hat Summit