In our integratiON interviews, we talked about Jira ServiceNow integrations with Marcin Osowski from Engage ESM, Platinum ServiceNow Partner. Marcin has 12 years of experience, and 6 years of experience with ServiceNow alone. Marcin works with plenty of Fortune 500 companies and has a very big experience in integrations and migrations.
Jacek: Why have you chosen ServiceNow to work with, to specialize in this tool?
Marcin: About 6 years ago, I was working with the BMC remedy, another great ITSM tool, and I started to look for ideas on how to better support my customers. And… I found out more about ServiceNow, which was rapidly growing. I started to explore it, and I was fascinated by its modern approach. ServiceNow is much more than just a ticketing tool. It’s a whole platform, with plenty of apps with their own app studio, they have a big and rich ecosystem of Consultants, Partners, and Vendors. So I decided to switch, and I became an expert in ServiceNow.
What makes ServiceNow interesting, is that it’s a typical enterprise-level tool, it’s hard to find small companies using it. Ofter, their clients are big, well-known companies.
Yes, because in the past, the ITSM tools were used just by the big companies that could afford them. Later on, smaller organizations started to look for solutions too, and more and more ServiceNow alternatives started to emerge – Jira Service Desk for example.
OK, so why do people integrate ServiceNow with another tool such as Azure DevOps, or Jira?
It’s mostly because companies need to automate some processes and make the work more efficient. ServiceNow provides a good, secure way to access the data. It’s easy to get access to those data, modules, or items stored in the portal. The UI is very user-friendly. Establishing a connection with ServiceNow is easy. Why do people integrate ServiceNow? Because they need to work with contractors or other departments within the organization.
Based on your experience, how would you choose the tool for integrating ServiceNow with Jira or Azure DevOps? What requirements the tool has to meet so you could recommend it to your customers?
Marcin: Let’s start with the basics – we need to make sure, that the tool will be providing the value stated in the business requirements. You need to define a goal for integrating two or more systems. Start with designing the integration – this work will make it easier to test, and later implement the final solution. Involve the right people, with tech backgrounds. While evaluating different solutions, it’s worth checking:
– the way the tools connect to the platforms (Jira/Azure DevOps/ServiceNow) – do you need to install them, or just connect to them?
– Check the security concerns – how it will work with the firewalls?
– How the data will be authenticated – only basic authentication, OAuth, or token authentication?
– How the error handling is solved? How frequently the data will be synced (real-time/scheduled/bathes)?
– What is the format of the data integration?
It’s a good opportunity to evaluate your existing processes while preparing for the integration.
What about the native integration? When does it make sense to use native options for integration, and when it makes more sense to get some existing solution from the market?
Out-of-the-box integration tools are faster to start working with, they have support, and they are proven. But… some of them are limited, and may not meet your requirements. So you need to check what happens then – how the Vendor will approach this? Will it offer you a custom development, to add the features you’re missing? If not, what then?
On the other hand, you can do the custom integration yourself – but you need to understand the effort it takes to build, and maintain it. Even though building ServiceNow integration is relatively easy for a skilled developer, it is costly due to the high rates those specialists have.
But, in some simple integration cases, it may be reasonable to use native solutions.
This is where getint could be a silver bullet – it’s an out-of-the-box solution, with custom development opportunities, all very reasonably priced.
How much time it could take to migrate from one tool to another?
Marcin: It depends on the scope, and complexity of the migration. It won’t happen overnight for sure. You need to design it, test it, and make sure you have all the resources you need. You need to prepare the environment to test it out properly. My experience shows, that if you’re switching from one tool to another, start using a new solution first. Understand the new data structure. If possible, archive older data instead of migrating it all. Proper data migration is a challenge.
How to prepare the integration/migration when it comes to stakeholder management? How to manage expectations?
The key is to involve the stakeholders at the very beginning of the project. Show them how the process looks, and how much it costs. Involve SMEs, security people, and admins. All roles could be important here and can influence the scope. Present different options with advantages and disadvantages to driving questions, to spot the possible weak points. Understand, that bad design integration can cause data loss – most companies can’t afford it. Communicate, that integrations are complex and errors are possible – they can happen on many different levels – applications themselves, network level. Bad implemented integration may be useless in the end – so you can lose a lot of time, and money – and you can cause a lot of stress for the business people depending on making it right. So choose your Partner carefully. Don’t do things too fast, because you may miss the point of what it is all about.