Integrating IncidentMonitor with JIRA

In todays Software-As-A-Service (SaaS) and Service Oriented Architectures (SOA) paradigms many organizations end up with several enterprise capable tools with the need to integrate these disparate products to improve their service delivery. Even with the advanced architecture of many products this integration still usually boils down to coding to APIs (RESTful, scripting, etc.).

Over the years we have integrated IncidentMonitor with varying types of enterprise products from competing Service Desk tools, HR Processing, Network Management and Telephony products to name but just a few. With our breadth of integration we have developed a no code , semantic based approach to tool set integration which we refer to as Partner Data Exchange.  This no code approach allows you to "paint up" your message that is going to be sent to the other side. In todays environments with JSON and XML they are simply string replacements of contextual data at runtime with a queue to ensure the sequenced delivery of messages. 

What does this mean? It's an easy way to integrate tools within your environment. We recently had a client who wanted to integrate their IncidentMonitor Change Management process with their hosted JIRA environment. Based on the Change workflow, messages were to be automatically sent to the software development team who are using JIRA. Using IncidentMonitor's Partner Data Exchange messages were configured to be sent when certain workflow events were triggered. The queue always guarantees delivery to the end point. 

It really is that easy!!!!! So what did this customer achieve? They were able to automatically send over all pertinent information including attachments and assign the ticket to the correct team based on fields defined in the IncidentMonitor Change form. No manual intervention is required and the hand-off process is streamlined. This reduces overall fix and deployment time thereby increasing business uptime. When the software fix/enhancement is ready for deployment JIRA sends a message back to IncidentMonitor so the Change process can continue. JIRA has a fixed format that can be sent out so we needed to translate that "hardcoded" message from JIRA into something we could consume - I guess they need to catch up ;-) to our semantic based approach to simplify integration to any tool sets. 

All in all, this is the way integration of tool sets should work and we really can start utilizing best-of-breed instead of being locked in to a single vendor.