Managing Jira -Solo or Team Effort?

[Chris Annal]

I wonder how the user community handles their company installation of Jira and Confluence. I mean, there is the administration of the front-facing side of these tools (and the plugins) to support user management, workflows, post functions, automation, etc....then there's the "server side" (going away soon, I guess) that involves (IMO) a different skillset that includes knowledge of Tomcat, Oracle JRE / JDK, Linux, etc.

Is this a solo task, or do most companies have separate assignments for this type of work?

[Nic Brough -Adaptavist-]

It can be solo, but we always recommend having between 3 and 10 admins.  A lot of admins are often part-time though and the 3 minimum is to cover for holidays, sickness and other unexpected events, it may be that your main admin is part time.  

In my career where I was "the jira admin", I was always part of a wider team looking after systems for the rest of the business, and it was never the whole job.  We always had a backup person in the team, and in the largest place, Atlassian Admin was a full time job for up to 8 people (although I was able to make changes that freed up 5 of them from the role).  A good chunk of the job was however, preparing for upgrades and moves, not just admin of the tools, and those admins had Tomcat/Database/Server too.  The admin side was just one part of it.  And I never worked as a dedicated Jira admin - it was always part of a wider role looking after swathes of related systems.  The closest I got to "pure" Jira Admin included admin for Confluence, some internal software test systems, the build servers, the code and artefact repositories, and and and.

The one thing I would say for "how we handle the installation" is "use Jira to track change in it" - every new project admins are asked for, new fields, workflows - get the requests into a Jira project so that the other admins of the systems can see why something has been done, or even if it's just one of you so you can answer "who the hell made this thing do that?" questions that you will inevitably get if you customise anything!

[Danno]

@Nic Brough -Adaptavist-thanks for your insight. I'm on my own right now and even though our employee count is down it does seem to take up a lot of my time.

I am going to implement your idea of having a Jira project to track the changes. Thanks for that.

[Thomas]

For me, it became a single task. Configuring the server + setting up the Jira SM and Confluence environment. And I did it without any knowledge in the administration of Atlassian products. My company knew that I worked with Jira as a developer, and they let me become an administrator. I gained tremendous experience and am still gaining it today.

I think most companies will split the tasks: the server will be on the network administrator, and the Jira setup will probably be on the DevOps engineer since there are some additional apps (for Jira) that use the Groovy language to automate tasks.

[Charlie Misonne]

This is probably not the right Community Group but:

In my experience it really depends on the instance size and complexity. Some companies chose to have very strict configurations like: a limited amount of workflows to chose from, a couple of screen configurations etc. In this scenario the workload for the admin(s) is low and I see typically 2-3 admins combining this with another role in the company like software developer or system administrator.

For environments with more complex configurations there are often more admins where 1-2 admins manage Jira among other Atlassian or ALM applications as a full time job and the others are a backup or perform changes for the projects the manage.

And about the server side: it also depends :-)

I see a lot of companies managing the system and database themselves with their sysadmin team. But when it comes to upgrades they call a consultant to do it for them (and sometimes learn from it to do it themselves next time)

[Patrick Vanhoof]

For us the front side is for the Confluence admins on the business side, which I think is logical. Close to the business users.

The server side is the responsability of the system administrators of the IT department.

Server side admins of course also have the Confluence admin rights.

[Alex Gay]

Until some months ago I was a solo/ full time Atlassian admin.

Since march I have a new colleague.

To me this was needed for the continuity (during holidays) and it helps to have an other view on a possible solution.  

He is doing the more technical issues (incidents / bugs) and I'm doing the more functional issues + talking to stakeholders to get their needs.

During our sprints we test each other work before we go live.

[Steven Mustari]

This is an interesting topic.

In my case at my company adaptation of JIRA/Confluence was over a period of time, with no real centralized ownership. A migration was done to the Service Management/Service Desk at the time, and in the role of Service Desk supervisor I took over many of the Admin functions within JIRA. As the company and department grew, and inevitable re-evaluation of the environment and more adaptation of a true Dev-ops philosophy took hold, I eventually moved from managing people (I was a manager at this point) to the full-time JIRA Administrator at our company.

I have found that it can be difficult to talk to stakeholders in a way they can truly understand, and coordinating changes/understand the environment as a whole really requires someone with good insight into how your particular deployment functions. Can solo-admin be done? Certainly. I am currently managing 50 unique workflows, 800 customfields,100+ custom scripts, thousands of customers and projects that are generating in total over 100k issues/yr.

Is this ideal? That is up for debate.

I do work on an infrastructure team largely responsible for the server health, and network portions of our deployment (we are on-prem) but all JIRA/Confluence configuration changes, addon management, and general day-to-day admin functions, as well as feature/additional functionality requests are performed by myself.

I think this question is complex as it really comes down to how you interact with the product as a company, the buy in from various stakeholders, and are you on a path to using something like JIRA Align, or are you setting something up to manage a segment of the business? How complex is the environment going to be? Do you have workflows that interact with one another with complex approval processes and issues that trigger other events/issues/workflows, or are you using it as a giant digital sticky notes board?

One of the absolute beautiful traits these Atlassian products carry is they can be as incredibly simple or as incredibly complex as a company wants to make them. It's an open drawing board to create something that works for your particular use case.

[Daniel Ebers]

This is a huge topic and I believe every team and every company handles some aspect a single way or another, probably handling changes during times or needs adaption - so all said below is highly special and based on personal opinions.

The basic question would be where to do the slicing. From my experience one single admin can take care for several installations, as long as they are covered by some kind of automation. It will less likely to work out fine if the administrator must manually log in to a machine, check things, apply patches, take care for audits and so on.
Agreeing with Nic for sure that it works better still if done as a team sport. Illness and vacation is inevitable and while several topic can be planned to be done after the admin's return it is always better to have an appropriate coverage by staff for critical topics.
Those would include many things from having the systems run, backups, upgrades, user management, documentation, trainings, supporting the first/second levels (if present), supporting the application teams.

Having said this it might be the case that installing a dedicated team for hardware (caring for the real server underneath your virtualization platform), databases, directory services (LDAP/Active Directory), backup, network might save you some resources to work with the application admins - in order to deliver the best value to your end users.

When it comes to Application I always refer to Atlassian's blog-post:

• The human side to scaling Jira software: governance, change control, and more
  https://www.atlassian.com/blog/jira-software/human-side-scaling-jira-software-governance-custom-fields-admins

Having such a governance model in place distributes many of in-appliction aspects onto several shoulders - consulting and decision-making is best done here (always in negotiation with the Jira-admins for the applications and, often, also with the admins responsible for the system) and the real work (as soon as dicussed, agreed upon and understood) best to be executed by well-educated Jira-admins.
The first level and, to some extend, second level support topics can then be given to volunteers (yes, there are always any!) which could be Business Engineers, Project Managers but also developers - why not!
Key, from my experience, is that all keep the rules in mind and only do what was agreed upon but not anything else "just like I have the permissions by technical means".

Overall I think this is a highly complex topic which requires many hours of planning and adaption as the size of the company grows but also as values shift and requirements change.

By no means this is the one-site-fits-all solution, as well as all of the said above applies to Server/Data Center - Cloud will be a complete different story.