Moving from Implementer to ServiceNow Architect: The Power of the "Reframe"

[Bill Martin]

Hey ServiceNow Community,

How many times have you received a requirement that looks like this?

"Can you please add a field to track which app an incident belongs to?"

If you have an implementer mindset, your immediate instinct is to map out the field, configure it, add it to the form layout, and close the ticket. It feels highly productive, the stakeholder gets exactly what they asked for, and the ticket closes fast.

But as many of us know, this is exactly how technical debt creeps into an instance. Within a few months, that field is full of typos, half of them are left blank, and reporting on it reliably becomes impossible.

The secret lies in a single mental shift: Implementers build what they are told, while architects decide what should be built.

The First Move: The Reframe

When an architect gets a request, they don't see a solution; they see a symptom. They take the request (which is almost always disguised as a solution) and turn it back into a problem statement by asking three simple questions:

1. Who is this for?

2. What exactly can they not do today?

3. Why does it matter to them?

 

Putting It Into Practice

Let’s take that initial request for a custom field and pass it through the three questions:

• Who is this for? The service owner.

• What can they not do today? They cannot see which incidents are impacting a specific banking service.

• Why does it matter? Because they cannot prioritize resources, cannot report impact accurately, and cannot meet the regulatory mean-time-to-resolve (MTTR) expectations inside their KPIs.

Now, let's rewrite the original request as an architectural problem statement:

"Service owners cannot see which incidents impact a specific banking service, so they cannot prioritize, report impact, or meet regulatory meantime to resolve expectations."

Notice what just happened? The word "field" completely disappeared. By reframing the request around the business outcome rather than the technical symptom, a custom free-text field is immediately exposed as the wrong answer. Instead, this problem statement naturally points you toward a best-practice platform solution: relating incidents to the service in your CMDB using the Common Service Data Model (CSDM) blueprint.

Your Homework for This Week

Before you touch the platform or open Studio on your next requirement, challenge yourself to write out a single sentence:

[Who] cannot do [what] because [why]?

Just bringing that single sentence to your next stand-up or stakeholder meeting will immediately elevate the conversation and make you sound more senior. It quietly kills bad technical habits before they ever make it into an update set.

How do you handle requirement gathering in your current roles? Do you use a similar framework to push back on "order-taker" requests? Let's discuss in the comments!

Check out the full video breakdown here: Stop Building What You're Told: Think Like a ServiceNow Architect

[SoureshD6782072]

Great perspective. I especially like the point that most requirements arrive as a predefined solution, not as the actual problem statement.

In my experience, the biggest shift from implementer to architect is learning to pause before configuring and ask, “What business outcome are we really trying to enable?” That one question often changes the solution completely.

For the incident/app example, adding another field may solve the immediate ask, but it can easily create reporting inconsistency, ownership confusion, and long-term CMDB bypass. Reframing it around service impact naturally pushes the design toward CSDM, service relationships, impact reporting, and better operational visibility.

I usually try to validate requirements using a similar structure:
Who is impacted, what decision or action can they not perform today, what data do they need to make that decision, and is the platform already designed to manage that relationship?
That last part is important in ServiceNow because many “new field” requests are actually signs that we are not fully using existing capabilities like CMDB, service mapping, assignment rules, catalog variables, related lists, or reporting models.

The challenge is balancing speed with governance. Sometimes the quick field is tempting, but the architect’s responsibility is to prevent today’s shortcut from becoming tomorrow’s cleanup project.
Great reminder that good architecture often starts before anyone opens the form designer.