# Application Portfolio Rationalization: [Portfolio or business unit]

> Application portfolio assessment and rationalization plan using the
> TIME model (Tolerate, Invest, Migrate, Eliminate), a commonly used
> portfolio classification attributed to Gartner: inventory, weighted
> business value and technical health scoring, cost and risk data, a
> disposition per application, a quadrant chart, a decision roadmap, a
> decommissioning checklist and benefits tracking. Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Work in this order: 2 (inventory) -> 3 (agree the scoring rubric and
  weights BEFORE scoring) -> 4 and 5 (cost and risk) -> 6 and 7 (plot and
  decide) -> 8 to 10 (plan, retire, measure benefits).
- The TIME quadrant is a starting point for a conversation, not an
  automatic verdict. Every disposition is confirmed by the business owner
  and the architecture board.
- The worked examples describe a fictional insurer and use one consistent
  set of numbers; recompute every score if you change a weight.
-->

## Document control

<!-- Guidance: Identify the assessment and the inventory snapshot it is based on, so that later reviews can compare like with like. -->

| Field | Value |
|---|---|
| Document ID | [APR-ORG-001] |
| Portfolio in scope | [Business unit, domain or whole enterprise] |
| Inventory snapshot date | YYYY-MM-DD |
| Applications assessed | [Number] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@enterprise-architect] |
| Business sponsor | [@cio] |
| Approvers / reviewers | [@cfo-delegate, @ciso, @portfolio-office] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Business sponsor | [@name] | [Approved / Approved with comments / Rejected] | YYYY-MM-DD |
| Chief architect | [@name] | [Decision] | YYYY-MM-DD |
| Finance business partner | [@name] | [Decision] | YYYY-MM-DD |
| Security officer | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record changes to weights or thresholds explicitly; a changed weight changes every disposition. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Inventory loaded, rubric agreed |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* First scoring round for 5 applications |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Dispositions approved by the architecture board |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Introduction](#1-introduction)
2. [Application inventory](#2-application-inventory)
3. [Scoring rubric](#3-scoring-rubric)
4. [Cost data](#4-cost-data)
5. [Risk assessment](#5-risk-assessment)
6. [TIME quadrant](#6-time-quadrant)
7. [Disposition per application](#7-disposition-per-application)
8. [Rationalization roadmap](#8-rationalization-roadmap)
9. [Decommissioning checklist](#9-decommissioning-checklist)
10. [Benefits tracking](#10-benefits-tracking)
11. [Governance](#11-governance)
12. [Glossary and references](#12-glossary-and-references)

## 1. Introduction

<!-- Guidance: Name the triggers (cost pressure, merger, end of support, cloud move) and the decisions expected. Rationalization without a decision deadline becomes an inventory exercise. -->

### 1.1 Purpose and triggers

This document assesses the applications of [Portfolio] and recommends a
disposition for each one, so that [Organisation] can [reduce run cost by
a target amount, remove unsupported software, consolidate duplicated
capabilities after the merger, fund the applications that drive the
strategy]. Triggers for this round: [end of vendor support for APP-044,
budget target for FY YYYY, findings FND-01 and FND-02 of the capability
map].

### 1.2 Scope

- **In scope**: [all business applications owned by the retail
  business unit, including SaaS subscriptions].
- **Out of scope**: [infrastructure platforms and end-user tools, which
  have their own lifecycle process].
- **Unit of assessment**: one application as known to its users, which
  may contain several technical components.

### 1.3 The TIME model

The TIME model classifies each application on two axes, business value
and technical health (often called technical fit or technical quality),
into four dispositions:

| Disposition | Business value | Technical health | Typical action |
|---|---|---|---|
| **Tolerate** | Low | High | Keep running with minimal change and spend; review again next cycle |
| **Invest** | High | High | Fund enhancement and scaling; treat as a strategic platform |
| **Migrate** | High | Low | Keep the business function but move it to a better platform, by re-platforming, refactoring or replacement |
| **Eliminate** | Low | Low | Retire, after moving any remaining users and data elsewhere |

The model is widely used in application portfolio management and is
commonly attributed to Gartner. Wording of the four dispositions varies
between sources; this document uses the definitions in the table above.
Migrate decisions are detailed further with the 7 Rs in the Legacy
Modernization Assessment (`architecture/modernization-assessment`).

### 1.4 Related documents

| ID | Document | Relationship |
|---|---|---|
| REF-01 | Business Capability Map (`architecture/business-capability-map`) | Capability IDs and strategic importance |
| REF-02 | Total Cost of Ownership Analysis (`architecture/tco-analysis`) | Detailed cost of replacement options |
| REF-03 | Technical Debt Register (`architecture/tech-debt-register`) | Evidence for technical health scores |
| REF-04 | Technology Radar (`architecture/tech-radar`) | Status of underlying technologies |
| REF-05 | Architecture Roadmap and Transition Architectures (`architecture/architecture-roadmap-transition`) | Places decisions on the enterprise roadmap |

## 2. Application inventory

<!-- Guidance: Collect the fields below for every application before scoring. Missing owners and missing cost data are the two most common blockers; flag them rather than guessing. -->

### 2.1 Inventory fields

| Field | Description | Source |
|---|---|---|
| Application ID | Stable identifier `APP-NNN` | CMDB or APM tool |
| Name and short description | What users call it and what it does | Application owner |
| Business owner | Accountable business leader | Organisation directory |
| Technical owner | Accountable delivery or operations lead | CMDB |
| Capabilities supported | Capability IDs from REF-01 | Capability map |
| Users | Number of active users and user groups | Identity provider logs |
| Deployment model | On-premises, IaaS, PaaS, SaaS | CMDB |
| Technology stack | Language, framework, database, middleware | Technical owner |
| Vendor and contract | Vendor, licence model, renewal date, notice period | Procurement |
| Lifecycle status | Vendor support end date, internal status | Vendor, technology radar |
| Interfaces | Number and type of integrations | Integration catalogue |
| Data classification | Highest data classification held | Data catalogue |
| Annual run cost | See section 4 | Finance |

### 2.2 Inventory

| ID | Name | Capabilities | Business owner | Users | Deployment | Vendor support end | Interfaces |
|---|---|---|---|---|---|---|---|
| APP-012 *(Example)* | CRM | CAP-03.02, CAP-03.03 | [@head-of-service] | 850 | On-premises | YYYY-12-31 | 14 |
| APP-020 *(Example)* | Rating engine | CAP-04.02 | [@chief-actuary] | 60 | PaaS | Supported | 6 |
| APP-044 *(Example)* | Broker portal | CAP-03.02 | [@head-of-distribution] | 120 | On-premises | Ended YYYY-06-30 | 5 |
| APP-061 *(Example)* | Claims system | CAP-06.01, CAP-06.02, CAP-06.03 | [@head-of-claims] | 400 | IaaS | YYYY-06-30 | 22 |
| APP-090 *(Example)* | ERP | CAP-07 | [@cfo] | 300 | SaaS | Supported | 18 |
| [APP-nnn] | [Name] | [CAP IDs] | [@owner] | [Users] | [Model] | [Date or status] | [Count] |

## 3. Scoring rubric

<!-- Guidance: Agree the criteria, the 1 to 5 anchors and the weights with business and IT leaders before any application is scored. Score in small panels, with evidence, and calibrate on two applications together. -->

### 3.1 Business value criteria

| ID | Criterion | Weight | 1 (low) | 3 (medium) | 5 (high) |
|---|---|---|---|---|---|
| BV-1 | Strategic alignment | 0.30 | Supports no strategic objective | Supports a core capability | Enables a differentiating capability |
| BV-2 | Functional fit | 0.25 | Users rely on workarounds | Meets most needs | Fully meets needs, liked by users |
| BV-3 | Business criticality and usage | 0.25 | Occasional use, outage tolerable for days | Daily use, outage tolerable for hours | Outage stops revenue or customer service |
| BV-4 | Regulatory or contractual necessity | 0.20 | No obligation depends on it | Supports reporting obligations | Required to meet a legal obligation |

### 3.2 Technical health criteria

| ID | Criterion | Weight | 1 (poor) | 3 (adequate) | 5 (good) |
|---|---|---|---|---|---|
| TH-1 | Architecture and maintainability | 0.25 | Monolith with no tests, few people understand it | Modular in parts, some tests | Modular, well tested, documented |
| TH-2 | Security posture | 0.25 | Known critical vulnerabilities without fixes | Patched, some gaps in controls | Meets security architecture standards |
| TH-3 | Reliability and performance | 0.20 | Frequent incidents, misses targets | Occasional incidents | Meets service level objectives |
| TH-4 | Vendor and lifecycle status | 0.15 | Unsupported or end of life | Support ends within 2 years | Supported, roadmap aligned |
| TH-5 | Data and integration quality | 0.15 | Point-to-point, poor data quality | Mixed | Standard interfaces, good data quality |

### 3.3 Score calculation

Each axis score is the weighted sum of the criterion scores, where each
criterion score is an integer from 1 to 5 and the weights on each axis
sum to 1:

$$
BV = \sum_{i=1}^{4} w_i \, s_i, \qquad TH = \sum_{j=1}^{5} v_j \, t_j, \qquad \sum_i w_i = \sum_j v_j = 1
$$

Both scores therefore range from 1.0 to 5.0. An axis score of 3.0 or
more counts as **high**. A score within 0.25 of the threshold (from 2.75
to 3.25) is **borderline** and needs a review panel decision recorded in
section 7.

### 3.4 Worked example (APP-012 CRM)

*Example:* criterion scores BV-1 to BV-4 = 4, 4, 5, 3 and TH-1 to TH-5 =
2, 2, 3, 1, 2.

$$
BV = 0.30(4) + 0.25(4) + 0.25(5) + 0.20(3) = 1.20 + 1.00 + 1.25 + 0.60 = 4.05
$$

$$
TH = 0.25(2) + 0.25(2) + 0.20(3) + 0.15(1) + 0.15(2) = 0.50 + 0.50 + 0.60 + 0.15 + 0.30 = 2.05
$$

High business value and low technical health place APP-012 in
**Migrate**.

### 3.5 Scores for all applications

| ID | BV-1 | BV-2 | BV-3 | BV-4 | BV | TH-1 | TH-2 | TH-3 | TH-4 | TH-5 | TH | Quadrant |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| APP-012 *(Example)* | 4 | 4 | 5 | 3 | 4.05 | 2 | 2 | 3 | 1 | 2 | 2.05 | Migrate |
| APP-020 *(Example)* | 5 | 4 | 4 | 4 | 4.30 | 4 | 4 | 4 | 4 | 3 | 3.85 | Invest |
| APP-044 *(Example)* | 2 | 2 | 2 | 1 | 1.80 | 2 | 1 | 2 | 2 | 2 | 1.75 | Eliminate |
| APP-061 *(Example)* | 5 | 3 | 5 | 4 | 4.30 | 3 | 3 | 3 | 2 | 3 | 2.85 | Migrate (borderline TH) |
| APP-090 *(Example)* | 3 | 3 | 3 | 2 | 2.80 | 4 | 4 | 4 | 3 | 4 | 3.85 | Tolerate (borderline BV) |
| [APP-nnn] | [1-5] | [1-5] | [1-5] | [1-5] | [BV] | [1-5] | [1-5] | [1-5] | [1-5] | [1-5] | [TH] | [Quadrant] |

## 4. Cost data

<!-- Guidance: Use fully loaded annual run cost, not licence cost alone. Ask finance for the allocation method and state it; otherwise cost comparisons between applications are meaningless. -->

### 4.1 Cost categories

Include licences or subscriptions, infrastructure and hosting, support
and maintenance contracts, internal staff effort (in full-time
equivalents converted at a standard rate), and an allocated share of
shared platforms. Exclude one-off project costs, which belong in section
8 and in the TCO analysis.

### 4.2 Annual run cost

| ID | Licences | Infrastructure | Support contracts | Internal effort | Total annual run cost | Cost per active user |
|---|---|---|---|---|---|---|
| APP-012 *(Example)* | USD 150,000 | USD 90,000 | USD 60,000 | USD 120,000 | USD 420,000 | USD 494 |
| APP-020 *(Example)* | USD 110,000 | USD 40,000 | USD 30,000 | USD 80,000 | USD 260,000 | USD 4,333 |
| APP-044 *(Example)* | USD 50,000 | USD 40,000 | USD 30,000 | USD 60,000 | USD 180,000 | USD 1,500 |
| APP-061 *(Example)* | USD 400,000 | USD 200,000 | USD 150,000 | USD 200,000 | USD 950,000 | USD 2,375 |
| APP-090 *(Example)* | USD 700,000 | USD 0 | USD 100,000 | USD 300,000 | USD 1,100,000 | USD 3,667 |
| **Total** | | | | | **USD 2,910,000** | |
| [APP-nnn] | [Amount] | [Amount] | [Amount] | [Amount] | [Total] | [Total / users] |

Cost allocation method: [describe how shared platform and staff costs
were allocated, and the standard rate per full-time equivalent].

## 5. Risk assessment

<!-- Guidance: Record the risks of keeping each application as it is. A Tolerate decision is also a decision to accept these risks, so they need an owner. -->

| ID | Application | Risk | Likelihood | Impact | Rating | Treatment linked to disposition |
|---|---|---|---|---|---|---|
| RSK-01 *(Example)* | APP-044 | Vendor support ended; no security patches | High | High | High | Eliminate by YYYY-QN; compensating network isolation until then |
| RSK-02 *(Example)* | APP-012 | Support ends YYYY-12-31 and key-person dependency for customisations | Medium | High | High | Migrate; extend support contract as fallback |
| RSK-03 *(Example)* | APP-061 | Vendor support for current major version ends YYYY-06-30 | Medium | High | High | Upgrade path in migration plan |
| RSK-04 *(Example)* | APP-090 | Customisations block vendor upgrades | Low | Medium | Medium | Tolerate with a no-new-customisation rule |
| [RSK-nn] | [APP ID] | [Risk] | [Low / Medium / High] | [Low / Medium / High] | [Rating] | [Treatment] |

## 6. TIME quadrant

<!-- Guidance: Plot every application from the scores in section 3. Convert a 1 to 5 score to the chart's 0 to 1 scale with (score - 1) / 4, so the 3.0 threshold sits at 0.5. -->

The chart plots technical health on the horizontal axis and business
value on the vertical axis. Coordinates are derived from table 3.5 with
the conversion (score minus 1) divided by 4, rounded to two decimals.

```mermaid
quadrantChart
  title TIME quadrant for the example portfolio
  x-axis Low technical health --> High technical health
  y-axis Low business value --> High business value
  quadrant-1 Invest
  quadrant-2 Migrate
  quadrant-3 Eliminate
  quadrant-4 Tolerate
  APP-012 CRM: [0.26, 0.76]
  APP-020 Rating: [0.71, 0.83]
  APP-044 Broker portal: [0.19, 0.20]
  APP-061 Claims: [0.46, 0.83]
  APP-090 ERP: [0.71, 0.45]
```

Observations: [*Example:* two high-value applications sit in Migrate and
hold 47 percent of run cost (USD 1,370,000 of USD 2,910,000); APP-061 is
close to the Invest boundary and the panel confirmed Migrate because of
RSK-03; APP-090 is close to the Invest boundary and stays Tolerate].

## 7. Disposition per application

<!-- Guidance: Confirm or override the quadrant for each application. Record the reason for every override; capability overlap, contracts and dependencies often justify a different disposition than the scores alone. -->

| ID | Quadrant from scores | Final disposition | Override reason | Target state | Decision date | Decision owner |
|---|---|---|---|---|---|---|
| APP-012 *(Example)* | Migrate | Migrate | | Replace with SaaS CRM; consolidate APP-044 users | YYYY-MM-DD | [@head-of-service] |
| APP-020 *(Example)* | Invest | Invest | | Extend to new usage-based products (INV-02) | YYYY-MM-DD | [@chief-actuary] |
| APP-044 *(Example)* | Eliminate | Eliminate | | Broker users move to the new CRM partner portal | YYYY-MM-DD | [@head-of-distribution] |
| APP-061 *(Example)* | Migrate (borderline) | Migrate | Panel review: RSK-03 outweighs borderline score | Re-platform to supported version on managed cloud | YYYY-MM-DD | [@head-of-claims] |
| APP-090 *(Example)* | Tolerate (borderline) | Tolerate | Panel review: borderline BV confirmed; finance is a commodity capability (CAP-07) | Keep; freeze customisation; review next cycle | YYYY-MM-DD | [@cfo] |
| [APP-nnn] | [Quadrant] | [Tolerate / Invest / Migrate / Eliminate] | [Reason or blank] | [Target] | YYYY-MM-DD | [@owner] |

### 7.1 Capability overlap check

For each capability supported by more than one application, state which
application becomes the system of record and what happens to the others.

| Capability | Applications | Chosen system of record | Others |
|---|---|---|---|
| CAP-03.02 *(Example)* | APP-012, APP-044 | New SaaS CRM (replacing APP-012) | APP-044 eliminated |
| [CAP ID] | [APP IDs] | [APP ID] | [Disposition] |

## 8. Rationalization roadmap

<!-- Guidance: Sequence decisions by dependency, risk and contract dates. Eliminations that depend on a migration must follow it, and notice periods often set the real deadline. -->

```mermaid
gantt
  title Rationalization roadmap (example)
  dateFormat YYYY-MM-DD
  section Eliminate
  APP-044 user move and retirement :e1, 2027-01-01, 120d
  section Migrate
  APP-012 CRM replacement :m1, 2027-01-01, 270d
  APP-061 re-platform :m2, 2027-04-01, 240d
  section Invest
  APP-020 product extensions :i1, 2027-02-01, 180d
  section Tolerate
  APP-090 annual review :t1, 2027-11-01, 30d
```

| ID | Decision | Dependencies | Contract or support date | One-off cost | Start | End | Status |
|---|---|---|---|---|---|---|---|
| RD-01 *(Example)* | Eliminate APP-044 | Partner portal in new CRM (RD-02 phase 1) | Support ended | USD 60,000 | YYYY-MM | YYYY-MM | Planned |
| RD-02 *(Example)* | Migrate APP-012 | Data cleansing of customer masters | Support ends YYYY-12-31 | USD 900,000 | YYYY-MM | YYYY-MM | Approved |
| RD-03 *(Example)* | Migrate APP-061 | Landing zone ready | Support ends YYYY-06-30 | USD 700,000 | YYYY-MM | YYYY-MM | Approved |
| [RD-nn] | [Decision] | [Dependencies] | [Date] | [Cost] | YYYY-MM | YYYY-MM | [Status] |

The dates in the chart are illustrative; replace them with your plan.

## 9. Decommissioning checklist

<!-- Guidance: Use one checklist per eliminated or replaced application. Retirement fails most often on forgotten integrations, retained data obligations and contracts that renew automatically. -->

Application: [APP-nnn name]. Decommissioning owner: [@owner].

### 9.1 Before switch-off

- [ ] Business owner has signed off the retirement date.
- [ ] All users and user groups have a replacement and have been
      informed with at least [N] weeks' notice.
- [ ] Every inbound and outbound interface is listed, its consumers are
      informed, and each one is moved or switched off.
- [ ] Data to be migrated has been migrated and reconciled, with record
      counts and sample checks signed off.
- [ ] Data to be retained has an archive location, a retention period
      based on the records schedule, and a tested way to retrieve it.
- [ ] Legal hold status has been checked with the legal team.
- [ ] Batch jobs, scheduled reports and monitoring alerts are listed.
- [ ] Contract notice has been served before the notice deadline.

### 9.2 Switch-off

- [ ] Read-only period completed (if used) with no blocking issues.
- [ ] Application access removed; accounts and service identities
      disabled; secrets and certificates revoked.
- [ ] DNS entries, firewall rules and load balancer configuration
      removed.
- [ ] Infrastructure, licences and SaaS tenants released.

### 9.3 After switch-off

- [ ] Data destroyed where not retained, with a destruction record.
- [ ] CMDB, capability map (section 8 of REF-01) and integration
      catalogue updated.
- [ ] Final cost saving confirmed with finance and recorded in section
      10.
- [ ] Lessons learned recorded.

## 10. Benefits tracking

<!-- Guidance: Agree each benefit with finance before work starts, with a baseline, a target and a date. Report realised benefits, not planned ones, at each portfolio review. -->

| ID | Benefit | Linked decision | Baseline | Target | Target date | Realised to date | Owner |
|---|---|---|---|---|---|---|---|
| BEN-01 *(Example)* | Run cost removed by retiring APP-044 | RD-01 | USD 180,000 per year | USD 0 | YYYY-MM-DD | [Amount] | [@head-of-distribution] |
| BEN-02 *(Example)* | Net run cost change for CRM after replacement | RD-02 | USD 420,000 per year | USD 300,000 per year | YYYY-MM-DD | [Amount] | [@head-of-service] |
| BEN-03 *(Example)* | Applications unsupported or losing vendor support within the plan period | RD-01, RD-02, RD-03 | 3 | 0 | YYYY-MM-DD | [Number] | [@enterprise-architect] |
| BEN-04 *(Example)* | Customer masters for CAP-03.02 | RD-01, RD-02 | 2 in this portfolio | 1 | YYYY-MM-DD | [Number] | [@head-of-data] |
| [BEN-nn] | [Benefit] | [RD IDs] | [Baseline] | [Target] | YYYY-MM-DD | [Realised] | [@owner] |

*Example:* if BEN-01 and BEN-02 are fully realised, annual run cost
falls by USD 300,000 (USD 180,000 plus USD 120,000), from USD 2,910,000
to USD 2,610,000, against one-off costs of USD 960,000 for RD-01 and
RD-02. Confirm the full business case in the TCO analysis.

## 11. Governance

<!-- Guidance: State how often the portfolio is rescored, who may change weights, and how new applications enter the inventory. -->

| Activity | Frequency | Forum | Owner |
|---|---|---|---|
| Inventory refresh from CMDB and procurement | Quarterly | Portfolio office | [@portfolio-office] |
| Full rescoring | Annually, before budget planning | Architecture board | [@enterprise-architect] |
| Rescoring after a major change or incident | As needed | Architecture board | [Application owner] |
| Weight and threshold changes | Only by board decision, recorded in Revision history | Architecture board | [@chief-architect] |
| Benefits review | Each portfolio review | Portfolio board | [@cfo-delegate] |

New applications enter the inventory at procurement or project start,
with a provisional score, a capability mapping and an intended
disposition. Proposals that duplicate an Invest application need an
architecture board dispensation (`architecture/architecture-governance-charter`).

## 12. Glossary and references

<!-- Guidance: Define the terms in the way this document uses them and link the related templates. -->

### 12.1 Glossary

| Term | Meaning in this document |
|---|---|
| Application portfolio management | Ongoing management of the set of applications as an investment portfolio |
| Rationalization | Reducing and improving the portfolio by keeping, consolidating, replacing or retiring applications |
| Business value | Weighted score of strategic alignment, fit, criticality and necessity (section 3.1) |
| Technical health | Weighted score of maintainability, security, reliability, lifecycle and integration quality (section 3.2) |
| Disposition | The TIME classification confirmed for an application |
| System of record | The single authoritative application for a set of business data |
| Run cost | Fully loaded annual cost of operating an application |

### 12.2 References

- TIME model (Tolerate, Invest, Migrate, Eliminate): a commonly used
  application portfolio classification attributed to Gartner; check the
  source you adopt for its exact definitions.
- Related templates: Business Capability Map
  (`architecture/business-capability-map`), Legacy Modernization
  Assessment (`architecture/modernization-assessment`), Total Cost of
  Ownership Analysis (`architecture/tco-analysis`), Technology Selection
  (`architecture/technology-selection`), Technical Debt Register
  (`architecture/tech-debt-register`), Technology Radar
  (`architecture/tech-radar`).

## Standard and licence note

Structure aligned with the TIME model for application portfolio
rationalization (Tolerate, Invest, Migrate, Eliminate), a widely used
classification commonly attributed to Gartner. The scoring criteria,
weights, thresholds, checklists and all wording in this template are
original and are not taken from any proprietary research; check the
current definitions of any framework or tool you adopt alongside it.
Gartner is a registered trademark of Gartner, Inc.
Template licence: MIT.