In the last couple of posts, I've talked about a scenario and some concepts to lay out the framework to discuss the integrations between tools used for different management disciplines.
I should note that I don't intend to talk about the integration between specific management tools (though I may use specific tools as examples), rather, I'll attempt to analyze integration requirements between tools used in different management disciplines. Although tools from different vendors each may have their differences, we should be able to talk about the functional areas in more generic terms, hence I hope that the discussion will be useful for a broader audience.
In this post, I'll start going through the process flow described in our scenario and focus on the integration between the event management and the trouble ticketing systems which is probably the most common integration implemented in the field.
Almost all event management systems provide some sort of "integration" with the ticketing systems, yet not all integrations are created equal, and certainly not all trouble ticketing integrations have the same functionality. So what functionality should we expect from this integration?
- Opening a ticket from the event management console.
We want the operator to be able to take an action to “open a ticket” from the console. The operator should not need to know anything particular about the ticketing system. The data from the event would be passed to the ticketing systems in the back end and a ticket would be opened.
This is an interactive process that requires the operator to take explicit action to open the ticket.
This functionality may be used in Step 2 of the scenario.
- Populating the TicketID field in the event management console.
We want some way to identify the ticket that is opened for the event, hence we want to populate a field of the event with the ticket number/id from the ticketing system. Users can then use this number to get additional information about the state of the ticket (who is working on it, when it's expected to be resolved, etc.)
- Closing a ticket from the event management console
In some cases, we may also be able to give the operator the ability to close a ticket. The process would be similar to opening a ticket; operator would take explicit action to close a ticket associated with the event. It should be stated that this functionality is not popular with all customers. Complex verification and granular controls may be necessary to determine who can close tickets, when, etc.
- In context launch of the ticketing tool user interface
In some cases, it is not feasible/desirable to open a ticket only based on information available in the event fields. Operator may need to supply additional information to open the ticket (who to assign the ticket to, priority, etc.). In this scenario, the operator may need to be presented a user interface to provide the additional information. This user interface can be the primary user interface of the ticketing system, or a custom user interface specifically developed for the integration.
- Opening a ticket automatically for specific events
Some organizations want (at least strive towards) opening tickets automatically from the event management system, rather than an operator to do it interactively as discussed above. This approach requires a mature, sophisticated event management system to ensure that tickets are opened only for the real problems, etc, and typically used when an IT organization uses the ticketing system as the primary work tool for the IT processes.
- Synchronization of the event and ticket logs
Most event management systems provide an audit log for the events, where a user can see the history of an event, when it was created, acknowledged, etc. The audit log may also be used by different users to inform each on their actions.
Ticketing systems also have a similar mechanism, a diary or a log, where all activities related to the ticket would be logged. The diary of the ticket would provide information about the status of the ticket, who is working on it, when it is expected to be closed, etc. This information can be useful for anyone who is looking at the event, hence we may want to synchronize the event management and ticketing system logs, to give the users of the event management system immediate information about the ticket.
- Accessing events related to an IT resource from the ticketing system
When investigating the problem, a user may need to be able to find all events related to an specific IT resource (a service, device, server, application, etc.) This may be accomplished by sending all events to the ticketing system (not a common option), or having a query tool in the ticketing system to query the event management tool, etc.
- Accessing tickets related to an IT resource from the event management system
Similar to the one above, it may be useful to query the ticketing system to find out all tickets about a service, device, etc. from the event management system.
Not all of these capabilities are necessary, useful in every organization. In our scenario, steps 2,3,5,6 require some level of integration between these system. To be able to do everything in the scenario, we need to be able to open a ticket, populate the ticket id field. Access to event from ticketing system and tickets from the event system is also necessary, however, it may be possible (but not desirable or recommended) to use two tools side by side as well.
Hopefully the information above can serve as a framework to analyze/evaluate/design an integration solution between event management and trouble ticketing systems.
In the next post, I plan to analyze the integration between the event and change management tools.
