Skip to main content

How to establish app governance

Overview

Thousands of Marketplace apps augment our Atlassian products and satisfy niche use cases. Apps are usually easy to deploy and start at low price points when your instance’s user tiers are relatively low. As organizations grow, more teams lead to more app requests, and prices start to multiply as the instance’s user count increases. In addition to increased cost, apps can also impact your instance’s performance, block instance upgrades due to version compatibility issues, and introduce license renewal headaches. Many enterprise customers find themselves suffering from a condition known as “app bloat.” It is challenging to wrap your arms around your existing and continually growing app landscape.
If any of these problems sound familiar, then Advisory Services is here to help! We have recommendations to help you manage your current app catalog and introduce governance that will help you combat the symptoms of app bloat. We’ve outlined a governance strategy that will lead to the following key outcomes:
  • You will have a team of individuals consistently reviewing app requests on a regular cadence.
  • You can confidently invest in an app, knowing it meets your organization's requirements and satisfies the use cases of your teams.
  • You can confidently install the app in your production environment since it has been thoroughly validated in a development environment.
  • You have a consistent evaluation process that can be documented, shared, and leveraged when working with disgruntled team members whose app request was rejected.
To achieve these outcomes, there are several steps we recommend that are described in detail:
  1. Establish an app request process
  2. Establish an app request triage process
  3. Establish an app evaluation process
  4. Establish An app technical validation process 

Step 1: Establish an app request process

It is extremely difficult to manage and prioritize requests that come through word of mouth, your internal chat applications, emails, and Jira issues. Streamlining your app request process is the first step toward app governance. How you configure this consistent request process is up to you, but Jira, Jira Service Desk, or a Confluence template can be leveraged to fit this use case. If you already have a portal to intake application configuration change requests, you’re already on your way! Simply augment your existing process to include a new request type for app requests.
You should take full advantage of your app request pipeline to gather the information that will be helpful for your future evaluation. Solicit the following information in the request template:
  • App name
  • Link to the app details (usually Atlassian Marketplace)
  • Projected number of app users
  • Use cases the app will satisfy
  • What is being done today to satisfy desired use cases
  • Overall business impact

Remember, having an app request process doesn’t solve your problems if your user community doesn’t use it! It is important to consistently push your users through this request process, otherwise, requests will continue to flow in from other means of communication. This will ultimately lead to continued frustration for your team and your users since their requests likely aren’t getting prioritized.

Step 2: Establish an app request triage process

With your streamlined app request process established, your next step is triaging and prioritizing the incoming requests. Identify several key stakeholders who can review app requests and then set up a recurring meeting.
Your triage team should include:
  • Engineers with knowledge of the existing app landscape in your Atlassian instances
  • Engineers who will perform the app evaluations
  • Members of your leadership team with decision-making authority. This might include lead Jira administrators, a team lead, and a manager or director with decision-making authority

The goal is to create a triage team with the autonomy to make a final go or no-go decisions on app requests.

Your triage meeting activities should include:
  1. Respond and close app requests if the app:
    • has already been installed
    • fully duplicates functionality offered by another app
    • has been previously declined
    • it is an obvious non-starter (for example, cloud-only apps if you’re running on-premise, app functionality, conflicts with security policies, etc.)
  2. Review new app request details about projected users, use cases, and overall business impact:
    • if more information is required, solicit feedback and revisit the request once the requester provides more details
    • if the overall business impact does not justify the effort to evaluate, validate, and pay for the app, decline the request
    • if the app warrants further review, accept the app request into the evaluation stage and prioritize it against other app requests that are currently pending an evaluation
  3. Review requests that were previously accepted into the evaluation process:
    • if the evaluation is still pending, ensure it is prioritized properly
    • if the evaluation is in progress, provide any requested feedback to the app evaluator
    • if the evaluation and technical validation is complete, review the results and make the final “Yes” or “No” decision

Step 3: Establish an app evaluation process

Once an app request has passed the initial triage process, the next step is performing an evaluation. We highly recommend creating a template in Confluence so that you can quickly kick off new evaluations that follow a consistent process. This section will cover different factors to consider in your evaluation and provide a sample template.
Here are things to consider in your app evaluation process:
Category
Considerations
Additional comments and rationale
Environment compatibility
Is the app compatible with your platform and version?
As a first step, always make sure the app is compatible with your current environment. You can save yourself plenty of time if you find the app is incompatible.
Environment compatibility
How frequently is the app updated, and does it quickly support the most recent Atlassian product releases?
Compare the app’s release dates and version compatibility to major platform releases. You want to avoid apps that could potentially block your future upgrades.
Environment compatibility
Is the app Data Center Certified?
Even if you’re running on a Cloud or Server platform, an app deserves bonus points if it meets performance requirements to achieve Data Center certification standards.
Vendor & app reputation
How many active installs are there?
The app Marketplace displays this information; be cautious of apps that have a small footprint.
Vendor & app reputation
Are there any negative reviews that raise red flags?
Customer reviews can be highly subjective, but it’s an early warning sign if many app users are unsatisfied.
Vendor & app reputation
Has the app vendor achieved Top Vendor status?
This is not a deal breaker, but you can proceed with additional confidence if you see the Top Vendor tag.
Vendor & app reputation
Is the app from “Atlassian Labs?"
Proceed with caution on Atlassian Lab apps; these are typically unsupported, provided “as-is,” and may not be maintained throughout future releases of the platform they were developed for.
Vendor & app reputation
Is there an active user community?
Spend a few minutes searching the internet for content about the app. See if the app comes up in the Atlassian Community, Stack Overflow, or other community outlets.
App support
Is the app supported, and if so, to what degree?
  • What hours are support available?
  • What hours are they available?
  • Is phone support available?
  • How do we file requests for support?
  • Is there an SLA for support for this app? How soon can I expect to get support once I make a request?
  • App support is very important, and you can gauge how mature the app is based on the degree to which it is supported. Email support is okay, but a formal request intake process is ideal.
    App support
    Is the app well documented for administrators and end users alike?
    Well-written documentation is a great sign of app maturity; no documentation, on the other hand, is a red flag.
    Administration impact
    What is the administrative burden? How complex is the app?
    Browse the app’s documentation to determine how much initial and ongoing effort is required to install, configure, maintain, and upgrade the app for months and years to come. Be on the lookout for apps that require their own database schema, require a separate indexing process, or introduce integrations to external systems. Generally, the higher the app complexity, the higher the administration burden.
    Administration impact
    Are there any minimum software or hardware requirements?
    Browse app documentation to make sure your environment meets any specified requirements.
    Administration impact
    Can the app be managed via the Universal Plugin Manager?
    The UPM offers many app management conveniences and is a nice-to-have.
    Cost
    How much does the app cost?
    This may or may not be a factor depending on your budgetary constraints.
    User/business impact
    Are there any alternative means to satisfy the app requester’s use case?
    Review the app request and understand the “Why”; determine if the required use cases can be solved through alternative means.
    User/business impact
    What are the user and business impacts?
    Gauge the demand for this app throughout your user community and how widespread usage will be if the app is installed.
    User/business impact
    Are there other apps offering similar functionality?
    Spend a few minutes searching for similar apps. If the answer is “yes,” consider kicking off another app evaluation to compare results and find the best fit.

    As an enterprise customer, you and your operations teams are hosting mission-critical content for a significant number of users. In general, we encourage that you use supported, reputable, Data Center compatible apps. If an app fails to meet these expectations, you are potentially signing up for increased risk and administrative burden if issues arise. Ultimately, your evaluation criteria and the importance they hold are up to your team.

    With that said, we’ve produced a sample template and example to get you started.

    Sample template

    Here are several key points:
    • Leverage the Rating criteria and Importance columns to outline your organization's specific requirements. Note any show-stoppers – this can help save your evaluator’s time and halt evaluations in their tracks.
    • When the evaluation is complete
      • Review any high “Importance” considerations that have an OKAY or BAD rating – these will be critical factors in your final decision to purchase an app.
      • For apps that remain on the fence, consider the question: "Does the user/business impact justify the app’s cost, administrative burden, and other red flags raised throughout the evaluation?”
    • This template can be adjusted to make it as simple or as complex as you’d like. Consider removing rows that are unimportant to your team. Or take it to the next level with a more sophisticated weight and score-based rating system.
    Category
    Evaluation consideration
    Rating criteria
    Importance 1 (Low) - 4 (High)
    Rating GOOD / OKAY /BAD
    Comments
    Environment compatibility
    Is the app compatible with your platform and version?
    Environment compatibility
    How frequently is the app updated, and does it quickly support the most recent Atlassian product releases?
     
     
     
    Environment compatibility
    Is the app Data Center Certified?
     
     
     
    Vendor & app reputation
    How many customers/active installs are there?
    Vendor & app reputation
    Are there any negative reviews that raise red flags?
     
     
     
    Vendor & app reputation
    Has the app vendor achieved Top Vendor status?
     
     
     
    Vendor & app reputation
    Is the app from “Atlassian Labs”?
     
     
     
    Vendor & app reputation
    Is there an active user community?
     
     
     
    App support
    Is the app supported, and if so, to what degree?
  • What hours are support available?
  • What hours are they available?
  • Is phone support available?
  • How do we file requests for support?
  • Is there an SLA for support for this app? How soon can I expect to get support once I make a request?
  • App support
     Is the app well documented for administrators and end users alike?
     
     
     
    Cost
    How much does the app cost?
    Administration impact
    What is the administrative burden/how complex is the app?
    Administration impact
     Are there any minimum software or hardware requirements?
     
     
     
    Administration impact
     Can the app be managed via the Universal Plugin Manager?
     
     
     
    User/business impact
    Are there any alternative means to satisfy the app requester’s use case?
    User/business impact
     What are the user and business impacts?
     
     
     
    User/business impact
     Are there other apps offering similar functionality?
     
     
     

    Example evaluation

    Several rows are filled with example text to give you an idea of how to use this particular table. You’ll see we met a “show-stopper” that was mentioned in the Rating Criteria column and saved a lot of time!
    Category
    Evaluation consideration
    Rating criteria
    Importance 1 (Low) - 4 (High)
    Rating GOOD / OKAY / BAD
    Comments
    Environment compatibility
    Is the app compatible with your platform and version?
  • Rate “Good” if compatible
  • Rate “Bad” if not compatible
  • 3
    GOOD
    The app is compatible with the most recent product version
    Environment compatibility
    How frequently is the app updated, and does it quickly support the most recent Atlassian product releases?
     
     
     
    Environment compatibility
    Is the app Data Center Certified?
  •  Rate “Good” if certified
  • Rate “Okay” if not certified, but vendor claims compatibility in their documentation
  • Rate “Bad” if not certified
  •  4
     OKAY
    App has never been Data Center compatible, but the vendor claims it works in the DC environment
    Vendor & app reputation
    How many customers/active installs are there?
    Vendor & app reputation
    Are there any negative reviews that raise red flags?
    Subjective/low importance, leave comments for any significant bad reviews
    1
     OKAY
    The customer said the app crashed several times
    Vendor & app reputation
    Has the app vendor achieved Top Vendor status?
     
     
     
    Vendor & app reputation
    Is the app from “Atlassian Labs”?
     
     
     
    Vendor & app reputation
    Is there an active user community?
     
     
     
    App support
    Is the app supported, and if so, to what degree?
  • What hours are support available?
  • What hours are they available?
  • Is phone support available?
  • How do we file requests for support?
  • Is there an SLA for support for this app? How soon can I expect to get support once I make a request?
  • Rate “Good” if there is an issue tracking/SLAs
  • Rate “Okay” for anywhere in between
  • Rate “Bad” if there is no support – this is a show-stopper!
  • 4
    BAD
    No support offered; no longer necessary to continue evaluation
    App support
    Is the app well documented for administrators and end users alike?
     
     
     
    Cost
    How much does the app cost?
    Administration impact
    What is the administrative burden/how complex is the app?
    Administration impact
    Are there any minimum software or hardware requirements?
     
     
     
    Administration impact
     Can the app be managed via the Universal Plugin Manager?
     
     
     
    User/business impact
    Are there any alternative means to satisfy the app requester’s use case?
    User/business impact
     What are the user and business impacts?
     
     
     
    User/business impact
     Are there other apps offering similar functionality?
     
     
     

    Step 4: Establish an app technical validation process

    In addition to the app evaluation process outlined above, we recommend you pair this with a thorough technical validation process. This serves several purposes:
    • It will inform Administration impact and User/business impact evaluation considerations above.
    • It allows you and your users to explore the app in a development environment.
    • It leaves you with a test plan artifact that can be leveraged for future upgrades or migrations if you decide to purchase and install the app in production.

    As a best practice and to help save time, ensure that the technical validation process is kicked off AFTER the initial app evaluation has confirmed there are no applicable show-stoppers.

    The technical validation process should involve four distinct tasks, detailed below:
    1. Create a test plan template
    2. Execute the test plan in a development environment
    3. Facilitate a user acceptance test
    4. Document results

    Create a test plan template

    Test plans are a handy tool in your kit because they can be peer-reviewed, referenced when troubleshooting future issues, and reused when performing upgrades or migrations.
    A test plan template is best served by a table that captures the following data:
    • Test cases that describe the goal of the test
    • Prerequisites that the test case assumes are in place
    • Test steps that outline the steps to perform the test case
    • Expected results that define test success criteria
    • Actual results that note results from your test
    Each app has specific features to evaluate, but here are some general testing recommendations to include in your template:
    • How is app configurations/data affected if it is
      • Unlicensed
      • Disabled
      • Uninstalled
      • Reinstalled
      • Rolled back to a previous version
    • Is there a significant impact to re-index times after the app is installed?
    • Does your instance stop and start without issue after the app is installed?
    • Does the app support all internationalization and accessibility requirements for your instance?

    Sample test plan template

    Here are several key points:
    • Make your test plan as robust as possible to account for all potential concerns.
    • Once you’ve run through a few test plans and added new test cases, update your template to include additional generic test cases.
    • You may not always know the expected results the first time you perform a test with a given app; that’s okay! In such cases, simply update the expected results as you perform the test case.
    Test case
    Prerequisites
    Test steps
    Expected results
    Actual results
    Install app
  • App is available via the universal app manager
  • Tail application logs
  • Navigate to the UPM
  • Search for the app
  • Click “Install”
  • Apply for an evaluation license
  • App is available via UPM
  • App is successfully installed
  • You can see UI elements introduced by the app
  • Logs don't indicate any installation warnings or errors
  •  
    What is affected when the app is
  • Unlicensed
  • Disabled
  • Uninstalled
  • Reinstalled
  • Rolled back to the previous version
  • App is installed and licensed
  • App-related configurations and data have been set
  • Remove the app license and check the behavior
  • Disable the app and check the behavior
  • Uninstall the app and check the behavior
  • Reinstall and re-license the app and check the behavior
  • TBD for discovery purposes
  • App configurations and data remain after all steps
  •  
    Check impacts to Jira re-index time
  • Baseline background re-index time established
  • Perform Jira background re-index
  • Re-index time matches baseline time
  •  
    Restart application
  • App is installed and licensed
  • Tail application logs
  • Stop development instance
  • Start development instance
  • Application starts cleanly with no app-related warnings or errors
  •  

    Execute the test plan in a development environment

    With your test plan in hand, kick off your technical validation in a development environment!
    • As an admin, you’re responsible for validating all aspects of the app, from initial installation and configuration to user features and use cases.
    • Leverage the app vendor’s documentation as you explore all of the app’s capabilities.
    • Your initial test plan is not set in stone! As you run through administrative configurations and features of the app, update your test plan to account for applicable test cases, especially if the test should be performed for future upgrades and migrations.

    Facilitate a user acceptance test

    Invite your app administration team, the app requester(s), and other eager power users into your development environment and encourage them to assist in the technical validation. You will achieve the best results by holding a kick-off meeting, establishing a timeline, outlining test goals, and soliciting feedback after the evaluation period ends. You’re ultimately looking for your team’s perspective on the following questions:
    • Did app features satisfy desired use cases?
    • Are there any use cases or requirements that are still missing?
    • Were there any examples of poor performance or broken functionality?
    • Was the app intuitive, and were its features easy to navigate?

    Document results

    Wrap up your technical validation by documenting all results and linking them back to the original app request. Remember, your technical validation results should help inform the Administration impact and User/business impact evaluation considerations, so ensure your evaluators are circling back and providing applicable ratings and comments.
    That’s a LOT of information, can someone please draw me a picture?
    Certainly! This flowchart outlines the key roles in this process and the interactions they have from the app request creation to the final approved/denied decision.
    How To Establish App Governance 1

    How to manage your existing app catalog like a pro

    App governance is an excellent start towards improving the app intake process, but managing your current app catalog can still introduce various challenges. Review the recommendations below to help address the complexities of a large app catalog.

    Document your app catalog

    We recommend customers maintain a list of installed apps for each Atlassian platform and the product you support, which captures information like:
    • App Name
    • Vendor
    • Purpose/use cases
    • Risk to the business if functionality is lost
    • Points of contact (App Champions – more on this below!)
    • Known issues/performance history
    • Installation date/renewal date
    • Links to
      • Marketplace listing
      • Original app request, evaluation, and test plan
    This will help you keep track of the apps you own and any relevant information about those apps in one location. It will take effort to maintain, but you’ll thank yourself time and time again when you have this information in one convenient location.

    Perform app audits

    Apps can introduce significant performance burdens and complexity to your Atlassian products. It’s important to routinely re-evaluate installed apps and prune the ones that are no longer necessary.
    • For any apps acquired before establishing app governance, consider performing the evaluation exercise outlined above to determine if they meet your desired acceptance criteria and establish App Champions. If the app is unsatisfactory but still actively used, work with your user community to find an alternative solution and uninstall the app.
    • For any app acquired after establishing app governance, you should have a record of the original app evaluation results. As a first step, work with your user community to make sure it’s still actively used. If so, quickly review previous evaluation results, compare important past evaluation criteria to results observed in the present, and consider any evaluation criteria adjustments that you’ve made since your last audit. If there are any new concerns or red flags, work with your user community to find an alternative solution and uninstall the app.

    Recruit app champions

    When an app is ultimately approved and installed, you’re committed to supporting the app throughout its lifetime on your instance. Luckily, the users who requested the app are generally invested in its success, and you should leverage this as much as possible! Level-set with these requestors, establish a degree of commitment, and identify several people who are willing to act as “App Champions.” Document a running list of apps and their current App Champions – this will come in handy in several different scenarios:
    • When performing an upgrade or migrating to another instance, solicit help from your App Champions to focus test the app in a development environment. This will help elevate your test coverage and distribute your testing burden.
    • When performing an app audit, re-engage the App Champions to determine if their app is still necessary and what use cases it continues to serve.

    Co-term license renewals

    Handling license renewals can drain even the most resilient Atlassian administration team. “Co-terming” aligns the renewal date of your licenses to a single date. This can be done for Server licenses, Data Center licenses, and Atlassian Services like Advisory Services and Premier Support. This allows you to save time throughout the year by consolidating your renewal efforts into a single and consistent time period.

    Renew licenses through solution partners

    If you’re actively engaged with an Atlassian Solution Partner, consider offloading your license renewals to a partner. They can assist with renewal reminders, quote generation, and co-terming. In some cases, they may even be able to extend discounts, but this is at the sole discretion of the partner you’re working with. Most Atlassian Solution Partners provide this service for free; talk to your existing solution partner to learn more, or talk to your Advisory Services team member to provide Solution Partner recommendations if you’ve never worked with a partner before.

    Was this content helpful?

    Connect, share, or get additional help

    Atlassian Community