ServiceNow as a Philosophy

I've been working with ServiceNow for more years than I'd like to admit.

I've configured it, integrated it, debugged it at 2am, and argued with it in ways that I'm not proud of. I've migrated CMDB data that was so wrong it was almost artistic. I've written discovery probes for systems that technically shouldn't exist but definitely do.

And somewhere in all of that, I started to think of ITSM not as a tooling category but as a philosophy. A way of thinking about how work should move through an organization.

What ITSM actually says

At its core, ITIL — the framework underlying most ITSM implementations — is making a simple claim: work that flows through explicit processes, with clear handoffs and documented states, produces better outcomes than work that flows through informal channels and individual relationships.

This is not a claim about technology. The technology is incidental. You could implement ITIL on index cards if you were sufficiently patient.

The claim is about organizational design. About the difference between an organization that runs on documented processes that anyone can learn and an organization that runs on the knowledge and relationships of a few key people who happen to have been there long enough.

The first kind of organization scales. The second kind doesn't — or scales very slowly, at very high cost.

The resistance to process

Every organization I've worked with has people who resist ITSM frameworks on principle. They call it bureaucracy. Red tape. They talk about the ticket queue as though it's an obstacle rather than a queue.

Usually these people are good at their jobs. Often they're very good. And their resistance is legitimate: formal processes do introduce friction. A change request that requires approvals and a test plan takes longer than calling the sysadmin you know and asking him to push the change.

Until it doesn't.

The informal channel is faster right up until the moment you need to know who changed what, when, and why — and the sysadmin you know has left the company, or is on vacation, or simply doesn't remember. The informal channel is faster until the change that was pushed at 11pm on a Friday causes an outage on Saturday morning and no one can reconstruct what happened.

The process isn't the obstacle. The process is the organizational memory.

Discovery as epistemology

My favorite part of ServiceNow — and the part I've spent the most time on — is discovery.

ServiceNow discovery is an automated probe that goes out across your network and returns with answers to the question: what is actually running, and how is it connected?

This sounds like a technical task. It is also a philosophical one.

What do you actually know about your infrastructure? Not what's in the documentation, not what was deployed eighteen months ago, not what someone told you in a handover meeting. What is actually running right now?

Most organizations, when they first run an honest discovery scan, are surprised by the answer. There are systems nobody knew about. There are connections that shouldn't exist. There are servers running software versions that were supposed to be decommissioned two years ago.

The CMDB — the Configuration Management Database — is the attempt to maintain an accurate answer to this question over time. Keeping it accurate is a constant discipline. Reality drifts from the records. Discovery is the mechanism by which you can pull the records back toward reality.

I improved our discovery completion rate from 50% to 85% over a period of months. The remaining 15% are the most interesting systems — the ones that are hardest to probe, the most likely to be undocumented, the most likely to contain organizational skeletons.

The health of your discovery is a proxy for the health of your operational knowledge.

Workflows as language

Here's the thing I've come to believe about ITSM: well-designed workflows are a form of communication.

A change request with a clear template that captures the what, the why, the rollback plan, and the test procedure isn't just documentation. It's a way of forcing the person making the change to think through those questions explicitly. The form is a cognitive scaffold.

A well-designed incident process isn't just a queue. It's a shared language for talking about disruptions — one that allows people who weren't present to understand what happened, what was tried, what worked.

This is why copying a ServiceNow implementation from another organization rarely works. The workflows encode organizational decisions about what matters, who needs to be involved, what information is required. Those decisions are specific to the organization. The tool is generic; the implementation should be specific.

What I've taken from it

After years of this work, I carry a few beliefs that started in ServiceNow but have spread to how I think about everything:

Make the implicit explicit. If work is flowing through informal channels, formalize them. You lose some speed. You gain resilience, auditability, and the ability to improve.

Measure what matters. Discovery completion rate. Change success rate. Mean time to restore. These numbers are imperfect proxies, but they're better than impressions. The things you measure, you improve.

The map needs to match the territory. Documentation that doesn't reflect reality isn't neutral — it's actively harmful, because it creates false confidence. Better to know that your CMDB is wrong than to act on it as if it's right.

Handoffs are where things break. Most incidents are caused not by individual failures but by failures at handoffs — between teams, between shifts, between systems. Design your processes to make handoffs explicit and documented.

None of this is unique to ServiceNow. All of it applies to how organizations work in general.

That's why I think of it as a philosophy now, not a tool.

The tool is just where I learned it.