When companies decide to deploy Microsoft tools such as Exchange or SharePoint, this decision is pretty much always made from on high and then implemented organization-wide. However, for some reason this is often not the way Atlassian tools implementations take place. What we frequently see in the field is that Atlassian will start out as a “rogue” installation long before it eventually turns into a company-sanctioned tool.
It’s usually the engineers who bring in Atlassian
What typically happens is that IT will deploy a company-sanctioned issue tracker or documentation system, and then someone in engineering will decide that this system is not good enough for their needs. So they’ll pay for a Jira Cloud instance on their personal credit card, or stand up Confluence on their own work station. Then, before you know it, the entire team is now using these rogue Atlassian tools. In fact, this situation happens so often that Atlassian has a name for it: Land and Expand. Once the Atlassian tools get in the door, their usage invariably expands.
Management does not appreciate “rogue” systems
After the rogue installation starts to spread it’s only a matter of time before the CTO or some other executive catches wind of the fact that a lot of the company’s intellectual property is now sitting on these non-sanctioned tools. So the executive will wander over to the Engineering floor and ask, “Where is the Jira system?” Someone will point and say, “The system is over there, under John’s desk.” Furious, the executive will literally pull the computer out from under John’s desk, march it over to the IT Director and say, “Guess what? You now ‘own’ the company’ Atlassian system!” And suddenly the IT Director is stuck transforming the company’s Atlassian tools suite from “rogue” to “sanctioned,” and then taking responsibility for managing it.
Getting rogue Atlassian systems up to organization standards
When this entire scenario takes place, there are a number of problems that need to be fixed right away. The rogue system most likely was not built on an IT-sanctioned operating system, and is probably not patched, secured, hooked up to the company’s centralized accounts system, running SSL or being backed up. In addition, the database may not have been set up correctly, there may be performance issues, and the system would not have been built to be able to offer any sort of availability guarantees.
In short, from the standpoint of transitioning to a company-sanctioned system, the rogue system is probably a complete mess!
If you’re in this situation, here are some of the steps you need to take:
- Shore up the system to ensure it will be reliable. Start by migrating it onto a proper server with adequate memory, CPU and storage. Then do a performance analysis on the environment to make sure adequate resources are allocated. Fine tune various operating parameters to ensure that both the database and the Java configurations are set to Atlassian best practices and to match your usage requirements.As part of this effort you will also need to determine if you have any other rogue Atlassian systems to contend with. If you do, you may need to merge multiple instances of JIRA, Confluence and BitBucket (or other source control systems) into one IT-owned system.
- Address business continuance issues. Add your Atlassian system to your daily backups, so that in the event of a failure you’ll be able to recover your data. It’s also a good idea to review your service level agreements and determine if you need to move your Atlassian instance to the DataCenter clustered environment for high availability.
- Get proper licensing in place. You’ll need to take over licensing from whoever brought in the rogue system in the first place. Assuming they actually purchased a license, they probably used their own email address to set it up. This, of course, could become a problem if they ever leave the company! You’ll want to switch this over to a permanent IT email address instead. This also applies to any add-ons that may be in use.You’ll also need to ensure you have adequate licensing for your actual use. Perhaps only one team was using the Atlassian tool when it was a rogue system, but now you want to standardize the entire company on it. In this case you’ll need a larger license to open it up to other people.
- Integrate Atlassian into the big picture. Depending on how your teams will be using your Atlassian tool suite, you may need to set up integrations with other applications, such as your account management system, SalesForce.com, SharePoint, and more.
- Consider implementing centralized reporting. Now that you have a company-sanctioned Atlassian system you may also want to have centralized reporting. Unfortunately, doing so is likely to require a lot of cleanup work. Before you can run centralized reports across multiple teams you’ll need to get these teams all using a similar set of fields, workflow statuses and more.
- Train an administrator. Once your company-sanctioned Atlassian system is in place, users will start making requests. They’ll need changes to their workflows, new Spaces and Projects added, custom fields, add-ons and a host of other things. Someone will need to manage this. If you leave it up to Engineering, you’re giving them the power to destroy the system, which probably isn’t going to help you meet your service level agreement! Which means you need to provide administrator training to one of your team members.
At Coyote Creek we see these exact problems crop up so often that fundamentally about half of our Atlassian engagements involve solving these problems. If you’re faced with this situation, give us a call. We can:
- Stabilize your Atlassian tools and get them from rogue status to a fully company-sanctioned system that IT can manage.
- Facilitate the move from the rogue engineer’s computer to a centralized location.
- Provide licensing with co-termination, so that all of your licenses are due on the same date every year.
- Provide a customized support agreement that meets your needs, from full management of your Atlassian tools to simply serving as an escalation point if issues arise that your in-house staff cannot address.
Plus, we can send you one bill for everything, so that you won’t have to use your credit card to pay for your licenses (which is the case if you buy directly from Atlassian).