In this blog post, I’d like to share lessons learned from the getint.io team, gathered during plenty of years in Atlassian-related integrations – including Jira, Azure DevOps, ServiceNow, Asana, GitHub, GitLab, Monday, Zendesk, and Wrike.All those apps are used by different teams – Azure DevOps, GitHub, GitLab, and Jira are used mostly by software engineers. ServiceNow, and Zendesk by support teams, while Asana, Wrike, Monday by marketing, sales, product teams.
What does that mean for tech people supposed to do the integration on the company side (usually Atlassian Administrators)? Different teams mean different requirements but also different levels of technical awareness of the challenge. Usually, the more technical the person, the easier it is to prepare a complete task description of all that is needed for integration.
The more business-oriented a person, the more general requirements are – meaning that more and more things will pop up along the way. When it’s about minor adjustments, it’s OK. But when the change is critical, and it’s a little too late to stop internal development (since the costs are already high) – then… All you can do is say, “Huston, we have a problem.”
One day I noticed that for us – everything related to the integration topic seems so obvious – but for companies that come to us, it’s really not.
Sure, there are plenty of how-to guides, but they are not human-oriented. Many times, they are just the blog posts to put in as many keywords as possible. I’ll try to make this one a bit different.
Let me do a quick intro to our team. Getint.io is a platform to integrate software to make the collaboration between teams and companies easier, more secure, and more smooth.
As getint.io Founders, we met several years ago working for one of the first Atlassian Vendors, developing an application to integrate Jira and Microsoft TFS (now Azure DevOps). One of us was managing the dev team, and the other (me) was starting a Partner Program, was speaking at plenty of Atlassian User Groups meetings, recording podcasts and webinars with Atlassian Ecosystem influencers, and talking to hundreds of people at Atlassian Summits – all that to learn what tech people want.
We always wanted to develop applications that solve real problems that become business-critical for companies that use them. I’m sure integrations are precisely that, and getint.io is the answer. We wanted to develop software that has the newest tech stack, is fast, reliable, and fairly priced.
Let’s get started. It’s time to write more about the topic:
The 5 business-related things to consider when choosing the software to execute the job.
1. Why do you need the app?
It’s not just about saving some time.
Most companies we meet during our daily work think that the reason to get an integration app is just to save some time. Instead of manually copying and pasting issues/tasks by humans, now we will get the tool (app) that will do the job, which would be way faster, and more smooth. And it sure is, but it’s not the most significant improvement. What our customers say, the biggest benefit is to avoid the mistakes, which people usually do while copying and pasting issues, alongside with better morale of those team members.
So spend some time investigating the possible benefits for your company – those benefits and possible savings will be a valuable benchmark for discussing the price to decide what is expensive and reasonable.
2. Should I build the tool in-house or buy the license for existing software?
Sure, native, built-in integrations are looking attractive. You have developers on your payroll, so why not use them? The question to answer is, is building the integration software, learning how to do it, making all the mistakes one can make is the best possible value your developers can bring?
Even if the answer is positive, one thing is to develop the solution. The other is to maintain, customize and keep track of all the changes with the apps we integrate with (f.e. when Jira changes API or when Jira server API is different from Jira Cloud). There is also evolving scope – in most cases, and people don’t know what they need at the very start, which causes frustrations.
Here comes the other option – simply buying what is already there. Yeah… right… you Google it, or you go to the Atlassian Marketplace directly. You see plenty of options. You go with the one that has the most installations and reviews – meaning you end up with one of the oldest and most expensive tools there is. Not the best one.
To choose wisely, answer the 22 questions below:
- Do you need one-way or two-way integrations? It may be good to have both when the requirements change in time.
- Do you need to filter out some issues/tasks/incidents? For example, you may need to integrate just a given project first but then also limit the integrations to a given label.
- Is there a chance to add custom JQL to the integration setting?
- What about custom fields?
- Do you need to integrate attachments and comments?
- What about integrating users?
- Is there a migration option?
- How is more complex data like status transition performed? That is very important when connected projects (like Scrum and Kanban projects) have different workflows.
- Is there an option to add post-creation updates?
- Is there an option to quickly scale to other connections, f.e. you have a new contractor you want to connect with – what are the rules? Usually, it costs.
- How about data security?
- What are the deployment options? The bigger the customer, the more they are interested in on-premise deployment, while plenty of Vendors offer SaaS-only solutions.
- What about the volume of issues? If you have a Jira DC, you may want to make sure the app can handle the load, f.e. thanks to the parallel threads.
- What about syncing intervals? Is the tool supporting real-time synchronization? Some tools charge more for shorter intervals.
- How can I know that everything is synced as it should be? Is there some dashboard/reporting module?
- What happens when suddenly, an app (f.e.) Jira, to which data should be sent out is OFFLINE?
- Is there any mechanism that will notify me when something is wrong with my integration?
- When, e.g., someone in a destination app (like Jira) changes mandatory fields, and all my synchronisations fail, how can I make sure they are resynced gracefully?
- What about custom development options, when needed?
- Is the app owned by a Partner, a vendor with plenty of other applications, or are they specialised in one topic?
- What is the SLA? Is there a Premium SLA option?
- What about the docs? Are there video tutorials?
Also, schedule a call/test the quality of the Vendors’ responses – make sure you work with the ones that really care. Too many companies out there are just doing business, having plenty of different, expensive applications, plus the consulting services, and they lack focus. They look to save money by outsourcing the support, extending the SLA – and that may harm you when you will need some help. Go to reviews, check the enthusiasm of reviewers – the bigger, the better.
3. Think long-term, not short-term. Requirements change in time when the organization grows. Think about the past, the present, and the future.
Integrations are not just about here and now. Often customers need to migrate existing data (past) first. Then, they need to integrate existing issues/tasks/tickets (the present). Then when the business grows, it’s good to be able to scale up the integrations – f.e. adding a new contractor that uses a different app or just adding a new tool within your organization – let’s say you needed Jira Azure DevOps integration, and one year later you have a contractor with Asana, or the new business requirement comes. Now you need to integrate Jira with ServiceNow within your company. Make sure your tool of choice will be helpful here.
4. Expensive vs. reasonable. How to perceive the pricing of the tools?
Regarding price perception – most minor cloud customers are looking for free solutions first, losing plenty of hours. When the correct perception of the price should be based on the proper benchmark, from a business perspective, time should be saved, which equals money. So let’s calculate the average price of the hour of work of an IT representative, multiply it, and then we can see the actual cost. Then, let’s see how much time teams are losing in manual work and discussions around tasks to integrate/copy. Then it’s easy to see that the price for each of the apps in the Atlassian Marketplace is reasonable. We can use one of the calculators available on the web. We will use one developed by unito – which states that if you have 100 people in the team, your actual cost of wasted time is… 11.322,00 USD monthly. So is the tool that costs 200 USD monthly expensive? Not really, especially when some other one costs 400$.
5. Deliver value fast – what’s the Time to POC (proof of concept)?
I’ve been choosing software many, many times. If I’m about to choose between the tools, where one takes very long to see some value, because of a complicated config that requires me to know everything right here and then, vs. a tool that can be launched within minutes – I’m choosing the second tool every single time.
When testing out solutions, when you need to prove the value to the business side in any organization, it’s best to look out for a tool that lets you test your case and prove that it can be solved quickly – ideally in minutes realistically in an hour. So simplicity, at first, is fundamental. From that point, you need a tool that can help you cover the specifics of the particular case, which you usually discover while testing.
I hope this relatively short blog post, which was intended to be more like a set of insider notes, was helpful. If you’d like to take just one tip, let it be the one about carefully answering all the questions that will guide you in the direction of what will work best for you. If you’d like to try our solutions, getint.io apps are available via Atlassian Marketplace here. If you’d like to talk directly with me – reach out at firstname.lastname@example.org.