IT Operations Management (ITOM)
cancel

Chatbots in the Enterprise: Part 3- Starting and maturing your ChatOps journey

Chatbots in the Enterprise: Part 3- Starting and maturing your ChatOps journey

Oded_Zilinsky

chatOps robot.png

 

In the previous parts of this blog series, I looked at the Chatbot revolution in the consumer space and the team collaboration space (ChatOps), and then discussed how chatbots are used within enterprises, and what Enterprise ChatOps currently looks like. In this third part, we’ll take a look at how Enterprise IT and Application Development can start their ChatOps journey and help it mature.

This post is most relevant for people who are operating IT, developing applications, or doing DevOps.

What problem are we trying to solve?

By now, you should have a good understanding into what ChatOps is about and how it can be applied in the enterprise. You understand that you can connect your systems to your group chat collaboration tool, and interact with your systems from it via bots. You understand that your systems can deliver meaningful alerts to persistent and adhoc channels in the collaboration tool. And you realize that this communication has provided transformative value to ChatOps practitioners. Now you want to try this practice on your own.

To get started, select the right organizational problem that you want to solve.

While integrating systems and Chatbots with a collaboration tool can deliver value in many ways, it is worth beginning by looking at inefficient collaborations that are currently happening in your organization. Throughout the years, software vendors have delivered remarkable systems and tools to help different developers, administrators, managers, agents and subject matter experts with doing their job. But some of the job that needs to be done can only be done through collaborations.

While integrating systems and Chatbots with a collaboration tool can deliver value in many ways, it is worth beginning by looking at inefficient collaborations that are currently happening in your organization.

So far, collaborations have been unaided by technology, and you can now improve. It is important to see which kind of tasks can only be achieved through collaborations in your organization. Then you need to consider whether moving those collaborations to a digital medium (group chat collaboration tool) and connecting them to the systems – could help.

If you are working in the IT Operations organization – consider applying ChatOps to your practice of handling Major/Critical Incidents (sometimes called “Incident War-Room”).  You might be a candidate if handling major incidents in your organization looks like this:

  • 20+ people conversing over a phone bridge
  • Each trying to understand what was done before they joined the discussion
  • Each trying to convey the situation as they see it
  • There is no good way capturing of the actions and solutions that were implemented for future retrospection in this model.

If you answered “yes” to any of these bullet points, then it looks like this is a perfect process to tackle and improve. I recommend looking at starting ChatOps with your Service Desk or Event Management systems first because of their potential for success.

If you are working on an Application Development—consider applying ChatOps first to your practice of handling failed builds. You might be a candidate for this implementation if in your organization:

  • A typical handling of failed builds involve a build manager chasing developers in order to figure out why the latest build is failing over an automated test
  • QA engineers are arguing with developers on the correctness of the failing test
  • Developers bouncing responsibility from one to the other, and a
  • “red” build pipeline for dozens of minutes

If this sounds familiar, it looks like handling failed builds is a perfect process to start with. I encourage you to look at starting ChatOps with your Build Pipeline Management, or your Application Lifecycle Management systems first.

If you are doing DevOps – consider applying ChatOps first to your practice in the area around providing visibility of your production environment to the developers. If in your organization developers need to coordinate with Ops in order to gain visibility to production, or Ops needs to chase the developers to find the right one that might’ve caused a production issue – it appears like this is a great place to start with. I recommend you examine starting ChatOps with your application monitoring systems first.

Try it out on your own

ChatOps is a rather new practice, especially within enterprises. As such, there are not many practical resources available on it currently.  You may find few colleagues that have wealth of experience in it, and there is not necessarily any experience within your own organization. Therefore it is difficult to assess the value and practicality of ChatOps without putting your hands on it and experimenting for yourself. (Imagine a block of clay as an analogy as we walk through this process.)

Giving ChatOps an initial try is usually rather simple and fast. (You will probably want to do this sooner than later in your decision-making process.) In our internal use within Hewlett Packard Enterprise, we’ve learned that this was the best route both for our own IT as well as for our Software Development organization.

You might not yet have a group-chat collaboration tool available at this moment. There are cloud-based solutions available for you such as Slack, FlowDock and Microsoft Teams (coming up), as well as on-prem and open-source solutions such as MatterMost, Rocket.Chat and HipChat, and others. When making the decision on a group-chat collaboration tool, it is important to consider:

  • Whether you can adopt a cloud solution in your company
  • Whether the cloud-hosting geography makes sense to you
  • Whether the solution is secure and compliant enough for your needs
  • Whether your organization is already a customer of one of these vendors

Based on the answers to these questions you could make your choice of the collaboration tool to try out.

After having a collaboration tool up and running, it is time to connect your first system, based on the collaboration challenge that you know you want to address.

At this point you can either go for the usually faster and simpler approach of directly connecting the system of your choice (such as a monitoring system) to your collaboration tool, if such integration is available.  Or, you can go with the longer-term flexible and mature approach right from the start, and introduce a chatbot.

Introduce a chatbot? Sounds like an added complexity… is it really important?

Let’s discuss.

To bot or not to bot?

For the purpose of giving ChatOps an initial try you could either take a bot or leave it aside for now and start with a direct integration. Starting with a direct integration is usually fast and rewarding – you can very quickly having your build management tool (such as Jenkins for orchestration, or HPE’s ALM Octane for pipeline management) report the latest status of your build into a dedicated channel.  You can also have your monitoring tool (such as HPE’s SiteScope) report on memory leakages or captured log file issues.

But let’s understand what the benefits of having a chatbot are in the long-run.

  • Decoupling your tools – If you directly integrate the systems that you use with your collaboration tool, you’d be coupling the two and potentially with time you’d be “baking” your processes into your collaboration tool. If one day you’d want to change your collaboration tool (such as if your organization is no longer requiring an on-premise solution and you now prefer the cloud) then you’d have significantly more work to do here. The level of work depends on the amount of integrations you created with your collaboration tool.

By using a vendor-neutral chatbot you can be sure that it is possible to change your collaboration tool without too much work. Most of your processes would be projected into their relative systems or into their bots.

Our own HPE-IT, we used the bot approach.  As we faced changes due to the latest spin-merge activities, the team discovered that it would be very easy for them to switch from our current collaboration tool to a new one.

  • Flexibility and power - In many cases a direct integration between your systems and your collaboration tool is limited in terms of where you can take it. Yes, it can report build failures to your collaboration channel, but can it also provide further information about the failed test, its QA owner, and the latest code committers? Yes, it can report on a new major Incident into an existing collaboration channel, but can it also create a dedicate collaboration channel adhoc for this incident, pull in the right people, and surface the information in the important fields that you’ve customized and added into your Service Desk?

By using an extendible chatbot you can always adopt the technology to your organizational context and needs, and make sure you bring the important data from your systems, and perform the right update and query commands back into the systems. You would be able to go beyond the capabilities that are provided out of the box by the software vendors.

As an example, one of our customers took our Service Desk bot (HPE’s Service Manager) which out of the box allows flexible interfacing with Incidents. They enhanced it so that they could also update the helpdesk agents with important status updates regarding the handled major Incident – directly from the collaboration tool where the IT experts are collaborating to find the solution.

  • Maintain control of the language – In many cases a direct integration between your systems and your collaboration tool is limited in terms of the conversational commands that you can perform toward your system from the collaboration tool—including a limited ability to tune the command language.

Communication and language systems and taxonomies may be good enough when integrating with just one system.

However, as you mature your ChatOps implementation and integrating additional systems that were potentially developed by different software vendors – you might find that the conversational interface is significantly different across those systems. Each integration introduces its own command language structure.

However, as you mature your ChatOps implementation and integrating additional systems that were potentially developed by different software vendors – you might find that the conversational interface is significantly different across those systems. Each integration introduces its own command language structure. For example, the Service Desk may expect a “get Incidents for server hr-gtwy-13” while your System Monitoring tool may expect a “retrieve hr-gtwy-13 CPU status”. This plethora of languages increases the mental load on your users, increases the learning curve and inhibits adoption.

By using customizable chatbots many times you can also customize their supported command language, and make sure all your bots can understand and cope with similar language.

It is also worth checking if your software vendor ensures a consistent conversational experience across their provided bots and/or direct integrations. This capability will allow you to easily use multiple bots while benefitting from a consistent language experience.

 

Now that you understand the role that chatbots play and the value that they bring, you can choose if you want to POC with or without the bots. Just keep in mind that you’ll probably want to come back and implement a bot as you mature your ChatOps implementation.

Start small

You’ve POCed your new ChatOps solution and now you have better understanding of what this process really means and how to best use it within your own organization. You’ve discussed ChatOps with your Security & Compliance organization, as well as with various different stakeholders, and made plans in order to start introducing it into production.

Listen to me as I say these words: Start small.

Enabling ChatOps means that you are enabling a new interface, but it doesn’t mean you have to ever completely stop the old way of interfacing with your systems.

You can start by inviting just the first team to practice ChatOps, while allowing all the rest of the organization to continue interfacing with their systems as they’ve always done. Enabling ChatOps means that you are enabling a new interface, but it doesn’t mean you have to ever completely stop the old way of interfacing with your systems. (You can always fail back to collaborating over a phone call.)

By starting with a rather isolated team – you can make sure you control the adoption of ChatOps and tune it as you expand—to ensure success. By controlling the set of challenges that you start with – you can lower risk and reduce friction to the adoption. For example, if you are in a healthcare organization and want to make sure that no patient data leaks to the collaboration tool or to the outside world – you can start by handling only system-level Incidents.

In HPE-IT, we’ve started ChatOps with just one DevOps team that owns a less critical service, which allowed us to “run” and learn ChatOps very well before expanding its adoption to additional teams.

At HPE Software we’ve started ChatOps within one of our ALM Octane development teams. We allowed developers to choose between continuing their work via traditional collaboration (including emails or shouts across the hall), and our collaboration tool – so that users could gradually on-board the new practice as they see fit.

One of our customers gradually exposed ChatOps to his Incident-handling process, starting with just one relevant team. He quickly saw more and more teams coming to him asking to onboard on the new ChatOps practice because they were impressed with the results.

 

Reading is easier than writing

When choosing the first challenge that you want to address, and the first systems that you want to integrate with, keep in mind this trivial yet important maturity rule: it is easier to read than to write.

  • It is easiest to start by having your systems surface information to the collaboration tool. No one needs to learn any command. This offers the lowest level of security concerns.
  • It is quite easy is to consume information from your systems in your collaboration tool by performing bot commands. Most companies are less strict in regards to controlling data visibility, and the collaboration tool also usually allows a level of control here.
  • Updating logical information (such as Incident tickets, or Defects) is usually not too challenging. Not too many things can go completely wrong here, and production isn’t put at risk. You’d usually expect that the user can perform a chat command on a system (such as updating a ticket) only if that user is authorized to do so in the actual system.
  • Changing production is hard. Things can go wrong if you allow direct access to changing your production environment from your collaboration tool. You’d want to be very mature in your ChatOps process, and have good security solution in place before reaching this level.

 

Further evolving your ChatOps

With time you will probably want to evolve your ChatOps practices. You will want to ask a few questions. Would you keep a collaboration channel per IT Service and handle all its Incidents, Defects and customer Enhancement Requests in it? Would you have an adhoc channel created to handle each major Incident? Would the Operation Center have its own always-on channel? How do you keep the execs notified on the overall status?

Adopting and evolving ChatOps may lead you to rethinking your processes and even your organizational structure. You may see that collaboration has dramatically improved across teams that were siloed up to this point. You may also find that such teams now better share the same context on which they are working, and are no longer bouncing issues and tasks from one to the other. Instead work together and even congratulate each other when progress is made. You might have been planning your way around adopting DevOps and are thinking of re-organizing so that your Dev and Ops teams are united per IT Service. But with ChatOps you might find that such a re-org is no longer needed because they’re already collaborating excellently.

You may see that collaboration has dramatically improved across teams that were siloed up to this point

A successful integration means your bots are evolving and growing with content. At some point, you should rethink your strategy around using your bots as a means to orchestrate more complex processes across your systems. There are Automation and Orchestration tools that are the right place to that, and you will  want to keep your bot mostly as your conversational interface.

At some point you may want your bots to be smart. I’ll discuss that in a fourth  part of this blog series.

Summing it all up

Choose a good challenge to address in your organization. A collaboration challenge.

Try ChatOps out earlier than later.

Start implementation in a small scale.

Use a bot for a future-proof solution.

Start by consuming information within the collaboration tool rather than changing anything.

Gradually evolve your ChatOps practices and with time rethink your processes.

Gain experience as you prepare for smart bots.

 

Catch up on the previous blogs in this series if you missed them here:

  • infrastructure management
About the Author

Oded_Zilinsky

Oded leads the ChatBot and ChatOps Strategy for the HPE Software IT Operations Management business.. His background is in the DevOps and IT Service Management domains.