The ServiceNow Architecture Metric Nobody Tracks: predicting a replatform 3 years out

Bill Martin · 15 hours ago

Most ServiceNow platforms do not fail loudly. They fail quietly, over about three years, as a slow accumulation of custom scripts, brittle integrations, and undocumented design decisions. By the time leadership realises something is wrong, the conversation has already shifted from "how do we fix this" to "do we replatform."

There is no public metric to detect this drift early. We measure incidents resolved, change success rate, CSAT, deployment frequency. We do not measure whether the platform itself is structurally sound.

Before the metric, the context. The framework this comes from, in twelve minutes:

I want to propose one.

The Architectural Debt Ratio

Architectural Debt Ratio = lines of custom code in scope / number of out-of-the-box capabilities actively used

That is it. Count every line of script in your update sets and scoped applications. Count every OOTB capability your platform is genuinely using, not licensed, actually using. Divide.

The ratio is not interesting in absolute terms. It is interesting as a trend line over quarters.

A healthy platform sees this number flat or declining. Custom code grows, but so does adoption of platform capability. The ratio holds steady or improves as the team learns to lean on configuration instead of code.

A platform heading toward replatform sees this number climb every quarter. The team is solving every new requirement with a script because nobody has the time, the architectural pattern, or the authority to push back and use what the platform already does.

What this looks like in the field

I once walked into a banking client running ITSM at scale across roughly four thousand fulfillers. On paper the platform was healthy. Stable, no major incidents, change success rate above ninety percent.

Underneath, the team had written over three hundred Business Rules and Script Includes to bend the OOTB incident, change, and request flows into something that resembled their legacy ticketing tool.

Every upgrade took six months. Every regulatory change required a developer. The replatform conversation started in year three. The audit conversation started in year four. By the time I was brought in, the cost of unwinding the custom logic was higher than the cost of a fresh implementation. None of this was visible until someone counted the scripts.

How to measure it on your instance this week

You do not need a fancy dashboard. You need one query and one count.

Custom script volume. Run a Background Script that totals the script field length across sys_script, sys_script_include, sys_script_client, sys_ui_action, sys_ui_policy, and any custom Business Rules in scope. That gives you a defensible proxy for custom code lines.

OOTB capabilities in use. Walk the Application Navigator and list every module your team has touched in the last ninety days. Be honest. Licensed but unused does not count.

Divide. Record the number. Add it to your platform owner's dashboard. Re-measure next quarter.

The number itself is not the story. The slope is.

Five questions to ask once you have the number

Is the ratio higher today than it was six months ago?
Of the top ten longest scripts on the platform, how many would survive a "could this be OOTB" challenge?
When was the last time a build was rejected at design review for being too custom?
Does your Architecture Review Board have the authority to send a design back, or only to comment on it?
If you replatform in three years, what is the actual cost — licensing, integrator fees, business disruption — and who is sitting in the seat that owns preventing it?

If question four made you uncomfortable, that is the real finding.

Where this comes from

The Architectural Debt Ratio is one of five metrics inside the Build It The Right Way framework — an architecture-led, compliance-first operating model for the Now Platform. The full framework, including the eight pillars, four governance control gates, and the role-by-role accountability model, is published here:

build-it-the-right-way.gitbook.io

The Configurable-over-Custom pillar and the Success Metrics section are the direct deep-dives on what this post introduces.

This is the first of a recurring column on ServiceNow architecture. Next post: the four design gates every ServiceNow build should pass before it touches production.

What is your platform's ratio? Drop a number in the replies, even a rough one. I will respond to every comment this week.

— Bill Martin
ServiceNow MVP 2026 · Certified Technical Architect · 7× CIS

#servicenow-architecture #technical-debt #platform-governance #csdm #architecture-review-board #architect