You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
On February 10th, we ran a joint webinar with yasoon on Atlassian Integrations. At Blended Perspectives, we’re keen to share our knowledge on all things Atlassian through our webinars and we’re very happy that so many of you choose to join us both live and on-demand.
However, we also recognize that in the busy workday many would-be viewers struggle to find an hour to set aside. You can still catch up with our webinar here, while in this article we’ll recap all of the main points from the webinar.
A lot of our content in this webinar was based on our MARS database of 3rd party Atlassian Marketplace apps.
MARS is one of our unique offerings in the Atlassian ecosystem and we believe it overcomes two fundamental problems with the Atlassian Marketplace:
MARS is essential for two reasons:
Firstly, there is the vast size of the Marketplace: with 1,000+ vendors, 4,000+ apps, and 1.5M+ active installs it can be difficult to see through the noise of the Marketplace and find apps that will add value to your instance.
Secondly, there is a problem with vendors self categorizing on the Marketplace. While this is certainly democratic practically, when you’re searching for an app in a category, for example, reporting, it can be a challenge. With so many entries how do you compare true, dedicated reporting apps? Charts and diagramming for instance has 200+ apps in it, few of which have anything to do with diagramming.
MARS overcomes these problems in two ways:
To overcome the size of the Marketplace we focus our attention on the 544 apps in the 500 Club. This means we are able to have more valuable insights into the Marketplace without seriously sacrificing our breadth since the 500 Club apps make up over 82% of Marketplace instances.
And to overcome vendor self-selection, we have carefully assigned “Meaningful Categories” to all 500 Club apps based on the primary functionality. This means that when you search for a reporting app in MARS, you will only see true reporting apps.
Strange as it may sound, we like to compare the Atlassian Marketplace to a fruit and vegetable market. Most markets are great and there is usually too much produce to know what to do with–but herein lies the problem.
Say you want to bake an apple pie and you go to the market to find the best apple for your pie. All of the apple sellers will tell you “my apple is great in a pie” because it probably is. However, you’re looking to really impress your friends with this pie so you want the best apple for the pie. How do you make an informed decision about what will really make your pie stand out? If you’re looking for which apple to put in your pie then you can use pickyourown.org and if you’re looking to make an informed decision about which Atlassian Marketplace app to buy you can use MARS.
Out of the “Meaningful Categorizations” in MARS Integration is the largest.
In MARS we classify as “Integration” any app that provides a linkage between Atlassian and non-Atlassian products.
These apps make up the biggest segment of the Atlassian Marketplace so obviously then there is a lot of integration taking place in the Marketplace. However what is driving this desire to integrate between Atlassian and other products.
Firstly, it is to overcome the problem of siloing.
As organizations grow they’ll generally tend to acquire more and more tools that serve a specific function within the company. However, whatever task it is that these tools are doing, how they link into the functions of the rest of the organization is usually a bit of an afterthought. This can lead to data sitting in product silos and it can become hard to find the information you want, processes can become slow and labor heavy, and time that could be spent on high-value tasks is wasted doing admin.
The second driving force behind this is the desire for teams to use the best tool for the specific task at hand.
Dev teams, in particular, can be quite particular about their tools and want specific tools to serve certain functions. However, while these tools may be the best of breed product for their function, this approach can lead to a growing and very fragmented tool stack.
These trends can be seen in the growing popularity of integrations when compared to the other largest Marketplace categories.
And this growth is largely being driven by Cloud.
Atlassian’s cloud platform has exploded over the past few years—over the last 3 years well over 90% of Atlassian’s new customers have opted to join on the cloud while more and more customers continue to migrate.
Since Atlassian Cloud and the various cloud-based products that it can integrate to are sitting in the Cloud rather than behind firewalls, this allows for more streamlined integration between the two versus on-prem.
As we can see from the MARS data that there is a lot of integration going on between Atlassian and a number of key platforms. This obviously great news as you’d be hard-pressed to find anyone who is against integrated platforms and doesn’t believe that it can bring pretty significant benefits.
However, this doesn’t mean that there is still a worrying trend of what we like to call “Fortress Architectures”
At Blended Perspectives, we’ve increasingly seen an inherent disconnect between popular methodologies (like ITIL, SAFe, and Integrated GCR) and these “fortress architectures”.
While these methodologies strive for integration and connectedness, we find that they often come up against these fortress architectures that don’t allow for this due to their insistence on control.
This is partly down to this kind of “Gartner approach” to tool selection—with organizations buying whatever the supposed leader in a market segment is–as well as these tools, and those operating them, generally tend to be very interested in controlling their segment and making sure they own that world making integrating between them very difficult.
However, despite these “Fortress Architectures” there is still a lot of integration happening in the Atlassian Marketplace.
Most integration (2/3rds) takes place with “Free” apps. However, this information is a little skewed as what we are considering to be “Free” integrations are generally paid for elsewhere, and often pretty significant amounts.
This does raise the question though on why, if you’re already paying for a product elsewhere, would you pay again to integrate it to Jira/Confluence. As you’ll see by looking at a product like Microsoft 365 for Jira though, which is a paid integration, you can see the incredible amount of depth and additional value from your paid-for integration for what is a relatively low cost.
On the other hand, most free integrations are largely what we would call “windows”— in that they give you insight into what’s happening elsewhere but often don’t give you the same level of interaction, especially 2-way interaction, that something like Microsoft 365 for Jira will do. This deeper integration, which allows for cross-platform tracking and communication, really is where most of the value from integrating products comes from.
Because we assign what we call a ‘secondary category’ to all of our integrations (which are primarily categorized as integration) we can compare these secondary categories to the primary categories of other apps.
This is very interesting because it lets us know what kinds of things users are doing in Atlassian with native apps and what they’re choosing to do elsewhere then integrate into their Atlassian suite.
The number one thing Atlassian users are doing with integrated products is Requirements Management.
This is really a space in which Jira users are integrating in order to make the most of their best-of-breed tools.
Designers generally do their work in these tools and are comfortable using them so by creating a simple connection between designs made in the products themselves and Jira issues, developers should always have access to the most up-to-date designs.
Between these three largest requirements management integrations though the obvious winner here is Figma for Jira which more than doubled its instance count in 2021.
We can’t really comment on the pros and cons of the tools themselves but in terms of how they link into Jira, Figma is generally the best at doing this with pretty notable performance differences as well as live embeds which help users save time finding the most up to date versions.
Code-related integrations is the second most popular integrating done by Atlassian customers.
The growth of code-related integrations over the past few years has been pretty remarkable.
Here we’re essentially comparing all Bitbucket apps and using that as a proxy for code-related Atlassian 3rd party apps and all code-related integrations.
The trend here is pretty obvious I think—the integrations have exploded recently, particularly over the last year or so while native code apps haven’t grown as quickly.
This is likely an example of developers using favored tools (like GitHub and GitLab).
The third most popular way to integrate is Diagramming.
Diagramming is really a tale of draw.io and Lucidchart pushing on while Gliffy is somewhat stagnating.
Lucidchart is an integrated product while draw.io and Gliffy are native to Confluence.
What’s particularly interesting though about diagramming as a category though is what it demonstrates about the evolution of the cloud and cloud-based products and the potential for vendors to design products not just specifically for the Atlassian space and by doing so benefit from being in more markets.
Lucid has made Lucidchart, a web-based app, not specific to Atlassian or the marketplace, but through the connector for the user, the app acts in the same way that draw.io and Gliffy do—the only difference being that you’re paying your subscription directly to lucid rather than through the Marketplace.
This is a trend we’re seeing more and more of and as cloud continues to be more prevalent
The fourth most popular thing for Atlassian users to do while integrating is integrating to collaboration tools.
Within collaboration as a category, we think that by far the most interesting subsection of this has been the digital whiteboards market
Miro, which is the leading whiteboard collaboration tool, saw the installs for both its Jira and Confluence products shoot up in early 2020 which, coincidentally or not, was around the time work patterns started to shift due to Covid-19 lockdowns.
We’ve found that remote and hybrid teams are trying to replicate the best bits of in-person working and for a lot of folks this is being able to work together on a whiteboard.
We’re also big fans of Whiteboards for Jira by Appfire and it grew by over 150% in 2021.
Entering the market so late though and going up against such an established force like Miro is always going to be tough. However, we really like what they’re doing and when a product can be kept in Jira is generally more affordable.
Microsoft 365 for Jira is an integration between Jira and the entire Microsoft 365 suite.
Since restructuring their app in mid-2021 to encompass the entire Microsoft 365 suite rather than just Outlook installs have trended up pretty significantly.
We think that they’ve found a really good niche and by covering all of Microsoft 365 in one app are generating making things really easy and efficient for their customers.
Microsoft 365 for Jira very nicely straddles both worlds: Microsoft and Jira.
As a paid-for integration, Microsoft 365 for Jira is backed up by its ability to link the two worlds of Microsoft and Jira–”Free” integrations that are claiming to link the two worlds will more often than not push you towards one world or the other.
We’ve previously done an in-depth overview of Microsoft 365 for Jira’s features and potential use cases when we awarded the app our “App of the Month” prize in October.
Essentially there are two main use cases for Microsoft 365 for Jira:
Microsoft 365 for Jira can also help accelerate IT support by ensuring linked communication and visibility which help agents resolve tickets efficiently:
Users who tend to work more in Teams can easily create support tickets in an environment they are more comfortable within a similar-looking portal to what they would see in JSM.
When the requests come through to support, they can directly respond through Teams chat and can even share the issue to their ITSM Teams channel to involve other agents if needed.
Furthermore, if you think you’d be able to resolve the issue more quickly face to face agents can schedule Teams meetings from the Jira issue. With just one click Outlook calendar will show when you are both available.
If agents receive a support request in Outlook, they can also easily raise the ticket in Outlook (no more copy and pasting) with many issue fields already prefilled. Past email conversations are displayed on the issue and new emails will be automatically added.
IT Project Management
Microsoft 365 for Jira is great for ensuring there is visibility in IT Project Management and that within teams and between teams, everyone is on the same page. For instance:
Say a project manager receives a feature request from management in Outlook. Straight away the PM can bring the email into the relevant Jira board by selecting the project and creating the issue straight from Outlook
Once this new issue is added to the relevant project and it is seen by a member of the team, they may realize that a non-technical team is required. Straight from the Jira issue they can then send a message to an individual or channel (say marketing or design) who may not even have Jira. Any responses to the message from Teams can be seen on the Jira issue.
Furthermore, say you want to organize a meeting about the feature request – straight from the Jira issue you can use Outlook calendar to create a Teams meeting that works for all parties involved. While in the meeting any Teams comments can be make transferred into sub-issues directly.
Most impressively, all of this info: subtasks, meetings that have taken place, and Teams conversations, can be seen from the initial Jira issue which itself can be seen from the initial email.