Driven by the teams, the tools of the Atlassian suite have found their place in the organizations, whether they are SMEs or large accounts. Their ease of use and rapidity of configuration have ensured their adoption by the users. In addition to that, the attractive cost, both in license and in implementation effort, allows the teams to integrate the purchase of the solutions in their project budget.
It is in this context that these solutions have naturally developed and expanded in companies.
However, this phenomenon has a major consequence. In some companies, the IT department is unaware of the existence of these tools or their actual use.
And like all tools, those proposed by Atlassian have their limits. We can regret the absence of certain functionalities. For example, how many project managers did not want to use Jira as a statistical reporting tool? Or Confluence as a DMS?
The Atlassian ecosystem is born
These new needs were sometimes wrongly considered as gaps in the tool. A vast ecosystem of editors has gradually developed to provide solutions via light, flexible and easy to implement (or not...) extensions.
The teams were able to enrich their Jira or Confluence, without looking for integration solutions with existing solutions in their IS.
But this comes at a price:
- These extensions have a significant cost, sometimes exceeding that of the Atlassian tool.
- the accumulation of multiple extensions leads to a heavier administration and performance of Jira or Confluence.
Doesn't this go against the elements that had seduced and convinced the teams to make Atlassian solutions their preferred tools?
Practices are changing
The Atlassian tools, previously introduced in the shadow by the teams, are now brought to light. They are becoming visible for the whole organization, thanks to their recognition by firms such as Gartner or Forrester... But especially because of the prices that are progressively undergoing significant increases! Because obviously, they no longer allow projects to take on the budget.
As a result, the question of their place in the IS becomes much more insistent. And the answers provided by the extensions become obsolete.
Let's take an example to illustrate. A majority of SmartView customers are Office 365 users. They have been developing and maintaining skills on these solutions for years. They finance support and development services to meet their needs.
So, rather than enriching Jira and Confluence with complementary add-ons, wouldn't it be a good idea to first look for a solution in the existing tools?
A concrete case: reporting needs
Jira has excellent functionalities for monitoring operational indicators. This makes it possible to see which developers are working on which projects, whether there are pending requests, what the progress is, etc.
However, Jira is not a Business Intelligence (BI) tool. It does not natively allow the production of pivot tables or the calculation of sums or averages over configurable time periods.
However, in order to analyze its performance and to set up precise indicators, these functionalities become necessary.
In this sense, in an organization using the Office 365 suite for example, PowerBI (data vizualization tool) appears to us as the preferred solution. The implementation of an interface between PowerBI and Jira is a more profitable investment than adding a specific reporting extension.
Integration solutions with IS tools
Typically, plug-ins complement the Atlassian features. But we often see the limits.
Integrating the Atlassian suite with a microservices approach using MS Flow simplifies the integration.
It is rare in an organization to see a total separation of Jira from the rest of the activities. One can identify the need for integration with a customer relationship management (CRM) or IT service management (ITSM) tool. Yes, not everyone uses Jira Service Desk - yet. 
!
Rarer but possible: organizations want to exchange data between different Jira instances managed by separate subsidiaries.
In all these cases, there are extensions that allow these applications to communicate. But often, these extensions are developed by different editors and remain specific. This requires an additional investment in the development of team skills.
These solutions also slow down the organization in the implementation of a clear, simplified and controlled vision of the connections between the IS applications.
For example, Office 365 offers MS Flow. This solution makes it possible to interconnect applications as soon as they are accessible, notably through a REST API. All this without having to resort to a new supplier. And sometimes without even having to acquire additional licenses or develop specific skills.
Our positioning
Many adages[1], proverbs, or principles[2] tend to think that we should reserve tools for the purpose for which they are made.
In parallel, DevOps encourages the development of integrated components. These components focus on what they are good at (micro-services architecture).
Thus, I prefer this approach rather than the systematic enrichment of Atlassian tools by extensions. The benefits are twofold:
- risk reduction through reduced dependence on publishers
- optimization of financial investments and development of internal skills.
Perfection is reached, not when there is nothing more to add, but when there is nothing more to take away.
Saint Exupéry
[1] "Small is Beautiful
[2] KISS principle: https: //fr.wikipedia.org/wiki/Principe_KISS
Source 1st image: Team by Vecteezy (https://fr.vecteezy.com/vecteur-libre/team)
