IBM i DevOps TechTalk
Interface Ticketing Systems with Your DevOps Process #19

R.B. – Welcome to IBM i DevOps TechTalk, where we discuss key topics and questions with ARCAD experts. I’m Ray Bernardi and I’ll be your host today. In today’s Techtalk, I’ll be joined by Alan Ashley. He’s a senior solutions architect here at ARCAD software. Alan and I are going to discuss ticketing systems like JIRA or ServiceNow, and how ARCAD can interface with them, and how it can improve your organization’s overall performance.
Alan, you and I do a lot of demonstrations, and we talked to a lot of prospects, and we both know that ticketing systems are really critical components for people to implement within their organizations. Now a lot of the people that we run into are using Jira or ServiceNow. What’s the importance of having that linked to an actual task within change management, like our maintenance reports within ARCAD?

A.A. – Right. As you’re saying, ARCAD does have a built in maintenance reporting or task tracking system. But when you start to link those, you actually get some real time updates, as we’ll talk about in some of our demos that we’ve seen. But you’re talking about accuracy as a task is updated within ARCAD. It’s being updated within your ticketing system.
It saves time because now you’re not having to go specially update tickets. It’s being updated as you’re doing it. And one of the other nice things here is reporting is such a big factor when it comes to auditors and things like that, because they’re always asking for reports, the reporting systems that you have within JIRA or ServiceNow are now even more accurate because it is taking the information being supplied by ARCAD and applying it to those tickets as it goes across the different stages within JIRA or ServiceNow.
And lastly, when you start talking about auditors, the other thing that comes up is compliance. You have to be able to show why something’s being worked on, who worked on it. How is it done? How does that link back to the actual item within the IBM i that was worked on with this linkage? That is even you get that granular level of linkage saying, it was this object by this developer, and here are the comments and so forth that are tied to that.
That helps you when you go to your compliance and your audit reviews. It really makes things a lot smoother in the end.

R.B. – And you mentioned that this thing is going to tie in and make your reporting more up-to-date and so on. I can understand that because if it’s automatic, if a developer moves something into QA and the task automatically updates itself to QA, then really what that’s giving you is the ability to, in real time, identify trends, look for inefficiencies in your organization, look for areas of improvement. And a link like this helps with that, doesn’t it?

A.A. – It really does. And that’s one of the nice things is, because ARCAD does have it built in. It is part of ARCAD. And so when you start building that linkage, now you’ve got to a two way tracking and ticket gets created. The associated ticket or task in ARCAD gets created, the developer goes in and sees that it starts working on an object.
That object is now linked to this ticket. Depending on what your workflow is and everybody’s going to be different, that ticket and Jira or ServiceNow can move over to the next stage.

R.B. – So this is a bi-directional communication you’re talking about.

A.A. – Bi-directional comments can flow. Who’s assigned the ticket can flow. Priorities can flow. What is the cause. You put it in a cause and a ticket that can flow down to the MR ticket. So that the developer can be working in the CPS Code and he’s working on the project. He needs to go review it. He can look right at the maintenance report and see what was the cause and some of the information that’s in the actual JIRA ticket that stays alive.
If he’s got comments, he’d say, oh, I’ve made a change to this field, I’m moving it over to QA and he starts that process the ticket, if your workflow shows it’s going into the QA bucket. That’s all handled automatically. The developer really doesn’t have to do anything because of the automation that’s tied into this. You can easily tie it into a Jenkins pipeline, for example, to have it go through the different stages and the developer just fixes the code, writes the code, fixes the bug, whatever the task may be, and it gets updated into the JIRA or ServiceNow ticketing system.
Those are the popular ones that we always run across.
But that’s really the key here, it’s tied in at such a level that there’s really not a lot of information lost going back and forth between the two systems.

R.B. – And you’re saying this can adapt to all kinds of different workflows. They’re not locked into any specific workflow here.

A.A. – Exactly. And one of the things that I was working with a customer on is they only wanted certain types of tickets to be seen on the IBM i. So if it was a Java ticket going to the open system, they didn’t want an MR ticket created for it. So you can filter those out. So only the IBM i relevant tickets go to the IBM i developers on the IBM i.
And that’s all they focus on. They don’t have to see all the other parts and pieces that may be going along with this. That’s being shown in JIRA or ServiceNow. They can focus on what they need to focus on. So you can have those filters. And it is very customizable. Let’s say for example, you have seven stages that you’re going to go across. You can map those seven stages to the seven stages in ARCAD, if you wanted to. Maybe you wanted to skip stages. Don’t map those and have it go a different direction. That’s the customer customizations that are available within ARCAD using our connector tool.

R.B. – Or for the specific progression, so from this step to this step.

A.A. – And so many people that are already using ARCAD have a workflow, and they actually have a ticketing system that has a workflow. It’s just a matter of mapping those two together with a little bit of time and a little bit of effort. Not much. And it’s set up. And what’s nice is it’s a one time thing. Stop the mapping and you’re done.

R.B. – So you’re talking about automation here. You’re telling me automation is in play. You’re telling me the tickets are all updated automatic. You mentioned the Jenkins pipeline and things like that. So in the end, doesn’t this allow management to see tasks progressing better and understand how tasks relate to each other and see if there’s going to be any issues between tasks and things like that?

A.A. – It is, and this is what’s nice, is you can have some tasks that are maybe working on the front end of something, from a Linux server that’s going to be the front end web page. And now you have a task that’s dealing with the back-end database. Now you’ll see those two tickets together within JIRA. And you can say, oh wait, the we’re missing a component.
So now you’re starting to mitigate any risks. Before the risk even happens, because you can say, oh, we’re updating the front end, we’re updating the backend. What are we missing? And you can start to see those pieces fall together. So in real time, you can start to see gaps that may be there, particularly if you’re using something like a dashboard.
So you can have your JIRA ticketing system flow into a dashboard, like in Grafana or something to that effect. And you can see how all that plays together. And again, you can get real complex when it comes to these dashboards, down to program levels and all that type of information. But that’s a discussion for another day.
But in this task, when they’re linked, you start to see all the projects come together within your ticketing system.

R.B. – See the dependencies between the tasks. So on. So there’s a lot of automation here. What developers have to learn to make all this happen?

A.A. – The short answer is nothing. But there is an answer to it. And what they had to learn how to do is update and make comments. That’s it. Within the ARCAD maintenance system, as you’re going through and you’re making your changes to your code, you just make a little note in the MR ticketing system and save it, and that gets pushed up to the JIRA ticket.
That’s the only thing they have to be told to do, and odds are they’re already going, leaving their development, going over to Jira or ServiceNow and in and out, coming back and doing their work, then going back to JIRA, adding more information and coming back and doing the work. Now they can stay in their workflow and make the notes within the tool right in their IDE that they’re going with, and now they’re more productive.
That’s it. That’s the only thing they have to learn how to do. Now, if they still want to make the ticket updates and JIRA, they can do that. But we’re making it a little bit easier for them.

R.B. – So once this interface is implemented, really they just do what they’re doing now. If they’re already using our ARCAD, they’re probably already using maintenance reports. So there’s nothing to learn there. But this is going to improve collaboration between different teams like development operations and support things like that, because they’re all going to be able to look and see instantly where something is, and there’s not going to be any lag at all.

A.A. – Right. It’s the visibility and the tracking of the tasks. You get that real time visibility into what is happening on your systems as the developer makes those changes, and as it goes through the different stages of your workflow from development into test, into QA, into UAT, into preprod, into production. So customer calls in; says, hey, I got this ticket, where’s it at?
The operator can look at it, say, oh it is in UAT right now. And he can look at the notes that the developer has put in there from the linkage that ARCAD has with that ticketing tool.

R.B. – So this is also going to help reporting for auditors?

A.A. – Exactly. And as we talked about a little bit earlier keeping the reporting up-to-date. So as you make your changes in your development on the IBM i, it’s updating all the behind the scenes information that is tied to this MR that is linked to JIRA. So an auditor comes in and says, hey, I need to see this.
You can just go to your JIRA or whatever your main ticketing tool is. That’s tied in and producers reports. Now those reports are more accurate.

R.B. – Sounds like a lot. What does it take to set up?

A.A. – Really just a few little changes and tweaks to some settings. And like for example here, this is Jira. You go through and you look at your JIRA workflow, you install the application through the tool, through the JIRA tool installs an application, it links over to the JIRA system and ARCAD. Then all you do is you map out your workflow and literally it’s got a gooey interface and you say, I want this mapped to this, this task map to this, this setting map to this setting.
You can map your users and everything. That’s it. And it’s one time, the only time you’d ever need to go in and change anything is if you changed your workflow. You need to update how the ticket may flow. That’s really the only difference. And if you’re using ServiceNow, it’s even easier because they’ve got a serviceNow API that we tie into that builds that linkage.

R.B. – But what if you’re not JIRA or ServiceNow? Can this still help in any way, shape or form?

A.A. – It can definitely help. We do have some CLI aspects. So if you’re using a different external ticketing tool and it has the ability to use CLI or command line interface, we do have that available. So you can start to type this in. Now some of the functions may not be as great as it is for JIRA ServiceNow because those are the big ones that are out there.
But it is still very possible to build that linkage and get that real time update between the two.

R.B. – So Alan, we hit a lot of things. We hit visibility and tracking. We hit risk mitigation. We talked about collaboration. Did we talk about compliances? Does this help in any way with compliance?

A.A. – We did. We talked a little bit about compliance because what it is, is now you’re even giving more information into the auditor reports that may be in your JIRA, your ServiceNow because you’re getting object level information that’s assigned to the MR ticket. That’s tied back to ARCAD. So compliance, auditing, collaboration, saving time, all that is improved just by having this linkage between two ticketing systems.

R.B. – I just want to hit one more thing. You mentioned dashboards a little bit earlier, and being able to have this information show on dashboards and it be real time information. And really that type of analytics can help a company identify areas where they need to improve. Can it not? So this could be a lot more than just change management and a couple of changes.
This is at a very high level, can help organizations improve overall?

A.A. – This goes into kind of touches on a topic that I kind of like talking about. Here is VSM value stream mapping, the management of those. So as you start through your DevOps journeys, there’s different areas that are always kind of like a roadblock. And when you start looking at the value stream mapping part of this, and this is where this dashboards come in, this information being fed into a dashboard, you can see updates to saying, okay, UAT is the holdup.
Why is UAT the holdup or why QA is the holdup? Now you can go back and look at this tickets and see what information is being put into those tickets from the developer as he’s developing it on the IBM i. So here you’re starting to touch on VSM, but you’re also talking about some ROI. And this goes all back to the saving time aspect and improving the workflows.

R.B. – So I guess in the end, it’s a pretty essential piece of automation for any shop that is using a ticketing system to link it with their change management system. ARCAD makes that easy.