Many companies start using Atlassian tools within a small team. Then they soon see the number of end users grow exponentially: 50, 250, 2,000, 5,000…
So how hard is scaling an Atlassian instance as it grows within your organisation? What challenges will arise on your journey, and more importantly, how do you ensure you’re well prepared to meet them?
Nathan Chantrenne, Head of Client Services France at Valiantys and senior consultant with over 30 large deployment projects under his belt, answers these questions.
Q. What are the key challenges admins face in scaling an Atlassian instance?
A. For application managers, three major challenges to address as the tools scale within organisations are professionalising environments, sizing servers and day-to-day administration. Let’s take a closer look at these in detail.
When you’re running a small instance with very small teams, you don’t bother with checking and validation processes or with running several environments – when a change needs to be made, you simply do it on your production environment.
The more users you have the more critical the instance becomes, and the harder it becomes to perform changes on the fly. Every time the application is made unavailable in production because there’s a mistake in an evolution that’s just been deployed, hundreds, or even thousands, of users are impacted.
When you no longer can afford service interruptions, you need to deploy several environments and set up governance rules for each of them.
Typically, you’ll have:
- A production environment, configured so that all modifications have to be approved by a committee
- A pre-production environment, a replica of the production environment that’s copied either automatically or manually every X days.
- A test environment, a replica of the production environment where numerous evolutions can be tested at the same time.
- And finally in some cases a development environment, used if you want to go further with, for example, add-on development.
When you start to have hundreds, or even thousands, of users, you need to size your servers so they allow you to both support the current number of users and anticipate future growth. The application’s performance and stability are key to a good adoption.
I recommend working doing some capacity planning forecasting for the upcoming years. This involves planning the evolution of how your tools are likely to be used two years from now taking into account two scenarios – an optimistic one, and a pessimist one. This helps avoid the need to change the system architecture too often, which can become a nightmare – especially if your hosting is externalised. It doesn’t prevent to revising the sizing in mid-course to adapt it if necessary.
This aspect of scaling an Atlassian instance is simple maths. The more users and projects you have, the more requests and specific need you will need to deal with. I strongly recommend using JIRA to automate this process as much as possible.
For each day-to-day admin task, you need to ask yourself “does doing this task manually add any value? If not, can I automate it?” You must then create a simple and intuitive service catalogue for all the automated requests.
For requests outside the catalogue (which by definition require manual action), you need to set up a group of support agents and administrators who will take them into consideration with relevant SLAs depending on how critical the application is. The way administrators maintain and evolve the application has to be led by previously established governance.
Q. In your experience, what are the different stages in terms of governance? How do teams recognise them, and what actions should they put in place at each stage?
A. We often say “the sooner the better” when it comes to setting up governance rules. However, when you only have 50 users it makes no sense –it will take a huge amount of time for just a small benefit.
I would say that once you hit 150-250 users, you should start thinking about governance. It’s often at this stage that you’re confronted with numerous different teams, different use cases and disparate needs in terms of workflows, custom fields and more. You need to be capable of handling this – sometimes it will mean redirecting requests to alternative or existing solutions, and configuring all of this with reusable items every time.
There are a number of best practices, some of them common-sense, that you can learn with JIRA administration training.
Above 1,000 users, we see the same challenges, with the additional challenge of managing a team and ensuring consistency in administration of the tool.
Q. What is the role of the platform administrator? How can they support organisational transformation?
A. For the admin of an instance that grows from 50 users to several thousands in a few months, the challenge can be daunting and overwhelming as requests flood in.
The biggest challenge when scaling an Atlassian application is stepping back and conducting a global analysis of the situation. We would typically do this during the healthcheck we run with our clients. We build a complete view of the instance covering all technical and functional aspects, looking at future user categories and the impact these would have.
Taking the time to run a complete audit of your platform is essential in order to size servers, build environments and establish a team capable of managing this volume.
Q. When you talk about governance, you need to talk about rationalisation. However Atlassian tools are renowned for their flexibility and power. How do teams ensure that setting up governance doesn’t have a negative impact on tool adoption?
A. The admin team constantly needs to juggle two goals: offering a simple, well-performing and intuitive service and being able to maintain secured administration of the tool. When you start setting up rigid rules, it automatically impacts adoption.
But managing to balance these governance rules so teams can work in a sane environment that answers their needs while ensuring the continuity of the instance is no mean feat.
I’ll give you a classic example. I’ve worked with several customers that were adding custom fields in their JIRA without any restriction. However, one day they have found themselves with over 800 fields, which of course wasn’t manageable and even caused performance issues. They then decided not to add any new custom fields at all.
In a way, this was a good decision. But let’s imagine a new team joining the instance that needs a custom field – this team will be very frustrated, especially as their colleagues from the office next door have 50 custom fields they still use.
The best practice when defining a governance rule is to apply it to all projects, both existing and new.
This involves a lot of cleaning and normalisation work, but in the end you will benefit from fair, consistent administration across your tools.
Ready to scale? We hope you find this advice useful – get in touch with any questions you may have!