Preventing Obsolete Software: How EA's Technology Portfolio Management Keeps Your Enterprise Safe

mcastoe · 6 hours ago

Introduction

Shadow IT. Unsupported technology. Out-of-compliance installations. These aren't just IT governance headaches—they're genuine risks that creep into every enterprise. They arrive quietly, hide in the infrastructure, and one day you realize that critical business application is running on software that hit end-of-support three years ago.

This doesn't have to be your story.

ServiceNow's Technology Reference Model (TRM), part of Enterprise Architecture, gives you the ability to define, govern, and manage the technology standards for the technologies that you use to run your business—and more importantly, to prevent obsolete software from ever taking root in your enterprise. Combined with Technology Lifecycle Management (TLM), TRM is a key component of Technology Portfolio Management (TPM)—ServiceNow's comprehensive function for governing your technology estate. Together, TRM and TLM become the mechanism that keeps you ahead of technical debt rather than constantly fighting it.

NOTE: Technology Lifecycle Management (TLM) was previously named Technology Portfolio Management (TPM); it was renamed as of the Brazil / late-Australia releases. TPM is now the overall function group in ServiceNow Enterprise Architecture that includes TRM, TLM, and Technical Debt. You will still see “TPM” in table names, scheduled job names, and the plugin (sn_apm_tpm), which were not renamed. TLM labels appear only with EA Workspace 9.2.1+ and sn_apm_tpm 1.11.0+.

Let's talk about how.

The Three-Pronged Approach to Eliminating Obsolete Software

Modern enterprises face a hard truth: technology standards don't enforce themselves. You need a structured, repeatable approach. ServiceNow uses three interlocking disciplines—Technology Standards (TRM), Technology Lifecycle Management (TLM), and Technical Debt Management—described below.

These three disciplines work together within Technology Portfolio Management (TPM), the overarching function that gives you complete governance of your technology landscape.

1. Technology Standards (Defined in TRM)

Technology Reference Model (TRM) is where you establish the technologies allowed in your enterprise. But it's more than a catalog—it's the top-level guidance for a governance engine that will bring you visibility and help you build the processes to prevent obsolete, unapproved technologies. In TRM, you define:

Which software and hardware products are approved for use
When those products are approved for use in Production
When existing installations must upgrade to a newer version or, if being Divested, when they must begin the migration
When a product reaches end-of-life and can no longer be deployed

This is the foundation. Without clear technology standards, teams lack guidance and make ad-hoc decisions, and shadow IT spreads.

A tip for shadow IT: when a product is requested and rejected, create a TRM Product set to Unapproved with a single, non-versioned Unapproved lifecycle that never ends. The decision is on record, repeat requests are discouraged, and any discovered installation becomes technical debt.

2. Know What You Have and Where It Is in Use (Technology Lifecycle Management)

ITOM Discovery and asset management gather the facts. ITOM Discovery scans your infrastructure and finds what's actually running. Asset management normalizes that data—translating vendor product names into a common taxonomy. When you combine that intelligence with the service instance maps in Enterprise Architecture, you get visibility into which business applications depend on which technologies.

Now you have a runtime SBOM (Software Bill of Materials) and HBOM (Hardware Bill of Materials). You're not guessing what software version is running somewhere—you're discovering it.

Anatomy of a TLM Record

The TLM records represent the existence of a particular technology installed on an infrastructure Configuration Item (CI) (or the model of the CI if it’s a Hardware TLM record) used by a particular Service Instance (Application Service). By CSDM-prescribed association, Service Instances are the particular “deployments” or instances of a Business Application and therefore the “discovered” tech rolls up to the Business Application.

Each TLM record is actually two records, the “discovery” part and the technology lifecycle information: TLM Discovered Technology [sn_apm_tpm_discovered_technology] and TLM Technology Lifecycle [sn_apm_tpm_technology_lifecycle].

TLM Discovered Technology provides the “where” and “for whom” alignment. The CI (Server, Container etc.) is the “where”. The Service Instance/Application Service and Business Application are the aligned entities—the “who.”

TLM Technology Lifecycle is all about the technology:

the product (software or hardware)
version information including the full build version found
reference back to the normalized software record (Software Discovery Model)
the General Availability, End of Support, End of Extended Support, and End of Life publisher/manufacturer support dates
the TRM Product and governing TRM Product Lifecycle

What TLM needs to find your technology. For each Business Application, the job follows this path, and every link must be in place:

Application Services related to the Business Application by a Consumes::Consumed by relationship
Application Services that are “mapped,” meaning the Service Configuration Item Association [svc_ci_assoc] table is populated. Tag-based, dynamic CI group, calculated, or manual mapping all work; see Creating Minimum Viable Application Services to support TPM
Servers with Software Installation records (and, for hardware, a Hardware Model on the server)
Software Discovery Models that are normalized with a product type of Licensable or Unknown. To filter out noise such as C++ redistributables, set an encoded query in the sn_apm_tpm.softwareDiscoveryModelProductFilterForTPM system property

Gathering the TLM records is an automated job, illustrated in the following graphic.

3. Technical Debt Management—The Action Engine

Here's where prevention becomes real. When your discovered technologies are misaligned to your TRM standards—either because they're obsolete, haven't upgraded to approved versions, or they're non-standard shadow IT—the scheduled technical debt job flags that as technical debt. A technical debt record is created, ownership is assigned, and it becomes a driver for action: demand creation, project planning, change orders, or sprint work.

This is critical. Without this last step, your standards are just wishful thinking. Technical debt management turns standards into action.

Technical debt management in EA Workspace is evolving. As of this writing (EA Workspace 10.0.0+ and sn_apm_tpm 1.12.0+), technical debt is:

Persistent – Technical Debt records are no longer deleted and re-created every time the job runs. They persist as actionable focal points and move between the states below.
Consolidated (optional) – based upon user preference, one record can be created per Business Application (or Application Service) and Software, instead of one per server. Every occurrence—each server represented by a TLM Discovered Technology record—appears in a related list on the Technical Debt record.

On each run, the job evaluates every record and moves it between three states:

State	Meaning	Moves to
Active	Needs attention; the default when debt is first detected.	Resolved once compliant; Archived if the technology is removed or its reason is turned off.
Resolved	The technology is still in use but now compliant.	Nothing; Resolved is terminal. If the condition recurs, a new Active record is created.
Archived	The technology no longer exists (e.g., server association removed) or its reason was turned off.	Active if the technology reappears or the reason is re-enabled. Purged by the Delete Archived Tech Debts job.

Configure Technical Debt

The new technical debt capabilities are configurable from the EA Workspace Setup page (Technical debt > Settings; requires the sn_apm.apm_admin role). You can keep the original per-server technical debt, but it is much more efficient to use per Application/Software technical debt.

The graphic below shows the technical debt settings page. First, choose the original behavior (“One technical debt record per server,” the default) or “One technical debt record for all identified servers.” You must delete all existing technical debt records before switching.

You also control when technical debt is created. At least one condition must remain selected:

When the software is not defined in the TRM – the product isn’t in the TRM at all. This is how you identify shadow IT, where somebody is using unreviewed and unapproved software.
When the software is not approved for production – the product is in the TRM, but its TRM Product level phase is not approved for production.
When the software version is not defined in the TRM Product Lifecycle – no lifecycle covers the discovered version (or edition).
When the software version is not approved for production – the lifecycle phase in effect today isn’t marked Production Approved (e.g., Upgrade, Divest, or Unapproved).

Clearing a condition stops new records for that reason, and existing active records for it move to Archived on the next run. This lets you phase in governance: start by enforcing only the version conditions for products already in the TRM, then add the product-level conditions as your practice matures.

Best Practices for Defining TRM Product Lifecycles

The real power of TRM—and the mechanism that prevents obsolete software—lives in how you define product lifecycles. This is where theory meets practice.

Understanding Software Versions

First, a quick note on versioning. When ITOM Discovery runs across your infrastructure, it finds software versions in the familiar dotted-number notation (similar to semantic versioning, with an added build number). For example: 10.6.23.113

Major version: 10 (the first number)
Minor version: 6 (after the first dot)
Patch level: 23 (after the second dot)
Build number: 113 (after the third dot)

In most cases, you want to manage TRM at the major or major-minor level. A version string like "10.6.*" means you're governing all patches of version 10.6. There are edge cases—blocking a specific build that contains a known vulnerability—but the standard practice is to manage at the major or major-minor level. This keeps your governance practical and scalable. One caution: a wildcard lifecycle can’t create technical debt for a product that also has a full-version lifecycle defined, so don’t mix the two for the same product.

The Three-Phase Lifecycle Model

The best practice TRM product lifecycle defines three phases for each major or major-minor version. Here's how it works:

The governing rule: deployments are only allowed when the version is in Production Approved phases. Every TRM phase is either marked Approved for Production or it isn’t. By governance, teams are not allowed to deploy new instances of a version while it is in any phase not marked Production Approved—Upgrade, Divest, Unapproved, Evaluation, or any custom phase you define. Existing installations may run while being remediated, but they are flagged as technical debt. Enforce the rule by checking the TRM phase in your request, procurement, catalog, and change processes.

Phase 1: Approved (GA to Two Years Before End of Support)

The Approved phase begins on the day that the software (or hardware) product support lifecycles show General Availability. This is your safe zone and the only phase in this model marked Production Approved, so teams can deploy this version freely. New business applications can be built on it.

Support lifecycles guide TRM Product Lifecycles. The Approved phase ends two years before the vendor's announced End of Support date.

Why two years? This is your buffer. It gives teams 24 months of lead time to plan, budget, and execute an upgrade before the product hits end-of-support. Two years is long enough for a typical enterprise upgrade cycle, but close enough to create urgency.

Variations to consider: some organizations add an Evaluation phase around GA, start Approved three to six months after GA to let the version settle, or apply an N-1 rule. Whatever you choose, set TRM usage dates inside the vendor support dates rather than mirroring them.

Phase 2: Upgrade (Two Years Before EOS to End of Support)

On the day after that two-year mark, the phase changes to Upgrade. This is your warning phase.

The Upgrade phase is a signal: "If you're running this version, plan to move. Your window is closing." Upgrade is not marked Production Approved, so by governance teams may not deploy new instances of this version. Existing installations continue to run, but they now appear as technical debt, giving owners a two-year window to plan, fund, and upgrade. The Upgrade phase persists until the vendor's End of Support date arrives.

This creates a clear governance rule: You have a defined window to move. No more ambiguity about when you need to act.
NOTE: Upgrade is not currently an out-of-the-box TRM phase, but it is highly recommended for clarity. There are roadmap plans (Safe Harbor) to add it in the future. Many customers currently use the original out-of-the-box phase, Divest, which is also not Production Approved. If you add Upgrade as a custom phase, make sure it is not marked approved for production.

Phase 3: Unapproved (After End of Support, Onward)

The day after the vendor's End of Support date, the version transitions to Unapproved. This phase has no end date—it goes on forever.

Like Upgrade, Unapproved is not Production Approved, so the version can no longer be deployed. Any installation still running is now past-due technical debt: an existing application running Unapproved software needs to either upgrade or retire.

Putting It Together: The Lifecycle Timeline

For a software product with a General Availability date of January 1, 2022 and an End of Support date of December 31, 2028:

Phase	Start Date	End Date	Rules
Approved	January 1, 2022	December 30, 2026	Deploy freely; new apps can use this version
Upgrade (or Divest)	December 31, 2026	December 31, 2028	No new deployments; existing installations flagged as technical debt; plan to upgrade
Unapproved	January 1, 2029	Forever	Do not deploy; existing use is past-due technical debt

Why This Works

Three things make this approach powerful:

First, it's predictable. Teams know exactly when they need to act. Two years is enough time to plan. Surprises are eliminated.
Second, it's automated. ITOM Discovery finds what’s installed, and each scheduled run of the TLM and technical debt jobs compares it against the TRM and flags misalignments as technical debt. You're not depending on manual audits or compliance hunting.
Third, it's connected to action. Technical debt isn't just a metric—it becomes a work item. It can be attached to projects, sprints, or change requests. It becomes part of your planning.

The Result: Staying Ahead of Risk

When you implement TRM with disciplined product lifecycle definitions, you shift from reactive to proactive. Instead of discovering in a compliance audit that 47 applications are running unsupported software, you've already created technical debt work items up to two years before support ends.

Teams have planned.
Budgets are allocated.
The upgrade is underway.
You're not scrambling.

You're ahead of the game. Shadow IT shrinks.

Technical debt doesn't accumulate. Your enterprise runs on known, supported, managed technologies. That's the power of a well-defined Technology Reference Model + Technology usage discovery of TLM + Unapproved technology technical debt management.

Getting Started

Implementing TRM with these best practices requires:

Buy-in from technology governance and enterprise architecture teams. They own the standards process.
Mature ITAM and software discovery. You need accurate asset data and continuous scanning.
Aligned CMDB and CSDM. Your business applications and their technical dependencies need to be clearly mapped.
A process for handling requests. When teams need to use technology outside the standard, they request it through a formal process.

The effort is real, but the payoff is real too. The alternative—managing technology debt as a crisis rather than a process—costs far more.

What If I Don’t Have SAM/HAM Pro, a Mature CMDB, or Service Mapping?

There is still valuable work to be done. TRM itself does not require CMDB/CSDM or Software/Hardware Asset Management. Asset Management is highly desirable and everything works better with it, but it is not absolutely required. Note, however, that the technical debt job requires at least the SAM Foundation plugin, and TLM needs mapped Application Services.

We have a third-party, non-ServiceNow Asset Management solution but also use ServiceNow’s Discovery and CMDB

Here are steps you can take.

Work with your CMDB team to integrate your asset management tool(s). It is highly likely they are already integrated.
If at all possible, work with your platform team and have ServiceNow support enable the SAM Foundation plugin (com.snc.sams). This gives you the critical Software Asset Management tables: Software Product, Software Product Lifecycles, Software Discovery Model and Software Install.
Build or enhance the existing integration to populate the tables described above.
At this point, TRM, technical debt, and TLM (provided you have some form of service mapping) should function much as they would with the full ServiceNow Asset Management suite.

We have no integrated Asset Management and no, or immature, CMDB/CSDM

You still have a very valuable capability. TRM does not require Asset Management in any way; it just works better with it. Without Asset Management, you can still build your Technology Reference Model standards, align them to Technical Capabilities, and align them to your Business Application portfolio.

Conclusion

Obsolete software doesn't appear overnight. It creeps in through accumulated decisions, deferred upgrades, and lack of visibility. ServiceNow's Technology Reference Model, combined with disciplined product lifecycle definitions, puts you in control. You define the standards. You discover what's running. You create technical debt for misalignments. You act before risk arrives.

That's how you keep your enterprise safe.

Appendix

Technology Portfolio Management jobs

These are the scheduled jobs you need to enable for the automated technology portfolio management functions.

Populate TPM Discovered Technologies and Lifecycles – this is the primary, automated TLM job that populates the TLM Discovered Technologies.
Populate Number field in TPM Discovered Technologies – should be a one-time run for customers who have had TPM running and have upgraded to the September 2026 version of EA Workspace v10.1.3 and Technology Portfolio Management v1.12.1
Populate TRM technical debts in the EA Workspace – this is the technical debt job
Delete Archived Tech Debts – Runs automatically on the first day of each month and removes Archived technical debt records older than the retention period set in the sn_apm_tpm.monthsToDeleteArchivedTechDebt system property (default 12 months). Run it manually to apply a retention change immediately.
Populate Technology Lifecycle Risks – this job calculates the Technology Lifecycle Risk score for each technology, Service Instance, and Business Application based on Publisher End of Support lifecycle dates

Risk Score calculation

For each Business Application

For each App Service

For each Discovered Technology record
If no “Earliest” lifecycle date return maximum risk, 100, for the technology
Else
Calculate a value from 0 (no risk because no EOS/EOES/EOL lifecycle in next 540 days)
to maximum of 100 (imminent risk) for each technology

Sum the individual technology risk scores and “set” the Application Service risk as sum of its technology risk scores

Sum the Application Service risk scores and set the Business Application risk score as sum of its Application Service technology risk scores

When calculating individual technology risk, the number of days from the current date to the earliest risk date (i.e. End of Support (EOS), End of Extended Support (EOES), End of Life (EOL)) is determined.

Depending on what date is earliest, EOS/EOES/EOL, there is a multiplier assigned such that the multiplier is:
EOS = 2
EOES = 3
EOL = 4

If the earliest date is sometime after today then the following calculations are used

Earliest date is less than or equal to 30 days: risk = multiplier * 20
Earliest date is less than or equal to 90 days: risk = multiplier * 10
Earliest date is less than or equal to 180 days: risk = multiplier * 6
Earliest date is less than or equal to 360 days: risk = multiplier * 4
Earliest date is less than or equal to 540 days: risk = multiplier * 2

If the earliest date has already passed (i.e. EOS is past)

The next risk date is EOES and it is not past, then the multiplier is 3 and the above day-range calculations apply
If EOES has passed and EOL is the next date, then the multiplier is 4 and the above day-range calculations apply
If EOL has passed, the maximum risk, 100, is returned

The Business Application, Application Service, and technology risk scores are all recorded in the TPM Technology Risks table [sn_apm_tpm_technology_risk].

From this table, the Indicator, Technology Lifecycle Risk, will calculate the indicator score using the values for each business application. To make it all run smoothly, the TPM Technology Risks must be calculated each month (i.e. run the job). The indicator expects monthly values.

Schedule or Launch the TLM Scheduled Job

The Populate TPM Discovered Technologies and Lifecycles job will analyze all business applications. To configure the TPM scheduled job:

Navigate to System Definition > Scheduled Jobs
Locate the Populate TPM Discovered Technologies and Lifecycles job.
Open the record and set a schedule OR, launch the job manually.

You can track the progress of TLM analysis by examining the TLM Discovered Technology Run Log [sn_apm_tpm_discovered_technology_run_log] table. Each time the analysis is run, an entry is added to this table.

The list view for the table will be shown. Note that if the process is launched from a Business Application, then the Business Application will be shown. If the job is run on schedule, nothing is shown in the Business Application column since it is run against all business applications.

To analyze a single application, open the Business Application in EA Workspace, select the ellipsis (top right), and choose Update TPM Data. Only one analysis can run at a time.

Troubleshooting Missing Lifecycles

If a TLM record shows no lifecycle dates, remember that TLM queries publisher support lifecycles using the Publisher, Product, Version, Edition, and Full Version on the Software Discovery Model. Without an exact match, a heuristic best fit is attempted and logged. The usual cause is a Software Discovery Model that hasn’t been normalized.