I Configure ServiceNow. But I’m Called an Architect.

What I Actually Do

I configure ServiceNow.

I configure incidents. I configure problems. I configure changes. I configure requests. I configure workflows. I configure catalog items. I configure approvals. I configure CMDB. I configure dashboards. I configure automation.

I define forms. I configure fields. I set assignment rules. I create workflows. I build service catalogs. I configure SLAs. I maintain business rules. I connect integrations.

I coordinate with ITSM teams, platform teams, security teams, testing teams, operations teams, and business users.

This is important work. But important work is not the same as architecture.

What My Work Really Is

My work is configuration.

It shapes how ServiceNow is set up. It shapes how service workflows behave. It shapes how incidents, changes, requests, approvals, tasks, and service records move inside the tool.

But configuration is still implementation.

It is not the same as defining what the project must achieve, how service decisions must flow, how system and sub-system logic must behave across rules, functions, data, UI, timing, and interactions, and what components must exist before configuration begins.

So when I configure ServiceNow and call that architecture, I am stretching the word beyond what I am actually doing.

The Civil Construction Equivalent

This is like working on a 50-storey building and configuring service desks, access requests, maintenance schedules, escalation paths, facility tickets, and approval workflows.

All of this matters.

But no one would say the person configuring those operational workflows is the architect of the building.

The architect defines what the building is meant to be, how floors are organized, how people move, how service areas are placed, how utilities flow, how safety works, and how the building functions as one whole.

Configuration comes later. It works inside the architecture. It does not define the architecture.

That is the same distinction here.

The ServiceNow Project Distortion

In many ServiceNow projects, this distinction disappears.

Because ServiceNow touches incidents, problems, changes, requests, assets, CMDB, workflows, approvals, service catalogs, and reporting, the person configuring ServiceNow starts to feel like the architect.

And the organization reinforces that feeling.

1. If I configure ITSM workflows, change approvals, incident routing, catalog items, CMDB relationships, SLA rules, dashboards, and automation, it looks like I am shaping how the enterprise operates.

2. If I understand tables, forms, flows, business rules, assignment groups, integrations, and reporting, it looks like I am defining structure.

3. If I coordinate multiple teams, it looks like I am designing the whole service operating model.

But what I am actually doing is configuring how ServiceNow will execute. That is not the same as defining the project anatomy.

What Is Usually Missing

Before ServiceNow configuration begins, P1–P4 of the same project should already be explicit.

1. P1 is Strategy: the direction and value outcomes the project must achieve.

2. P2 is Process: the sequence of activities required to realize the strategy.

3. P3 is Systems / Logic: the systems and sub-system logic that execute or enforce the business flow — including data logic, rule logic, function logic, access logic, UI logic, timing logic, and interaction logic.

4. P4 is Component Specifications: the parts that make those systems real — data, functions, rules, events, interfaces, UI, network, and other component specifications.

In many ServiceNow projects, this does not happen clearly. So configuration starts filling the gap. The tool becomes the place where the service process is “figured out”.

That is where the distortion begins.

A Change Management Example

Take a ServiceNow project for IT change management.

I configure change request forms. I configure approval workflows. I configure assignment groups. I configure risk scoring fields. I configure CAB approval steps. I configure SLA rules. I configure notifications. I configure dashboards and reports.

The project looks complete. But the real questions are different.

1. What exact outcome must this change management project achieve?

2. How should a change move from request to risk evaluation, impact analysis, approval, scheduling, implementation, validation, closure, and post-change review?

3. How should risk logic interact with business criticality?

4. How should dependency analysis affect approval?

5. How should emergency changes be handled without bypassing control?

6. How should failed changes feed back into future risk scoring?

7. How should operational incidents influence future change decisions?

If these are not explicitly defined first, then ServiceNow configuration becomes an implementation of partial understanding. The workflow may move. The change decision flow may still not work.

What Happens Then

Teams submit change requests. Approvals move through the system. CAB meetings happen. Notifications go out. Dashboards show status.

But the change decision still behaves inconsistently.

Low-risk changes get over-reviewed. High-risk changes slip through with weak impact analysis. Emergency changes bypass logic. Dependencies are discovered late. Failed changes become incidents, but the learning does not improve future change decisions.

Every ServiceNow workflow may work. But the project still behaves inconsistently. Because configuration can only express what has been defined.

If the project anatomy is not explicit, configuration spreads the gap across forms, fields, workflows, approvals, assignment groups, dashboards, and integrations.

Financial Impact

This becomes expensive. Every change requires rediscovery.

1. A change in approval logic affects request forms, risk scoring, CAB workflows, SLA rules, notifications, reporting, integrations, and operational handoffs.

2. Impact analysis depends on experienced people because the underlying logic is not explicit.

3. Testing expands because many workflows and business rules carry local assumptions.

4. Rework increases because downstream effects are discovered late.

5. Manual workarounds continue because the configured workflow does not fully reflect the intended service decision flow.

The enterprise spends more on ServiceNow consultants, admins, platform teams, integration fixes, testing, support, and stabilization.

At the same time, operational cost increases because changes take longer, failed changes create incidents, teams over-escalate, and business-critical decisions wait in queues.

Margins are affected because delays, incidents, manual correction, service disruption, and rework absorb value. The project becomes more expensive without becoming more precise.

Why the Title Becomes Dangerous

The problem is not that I configure ServiceNow. The problem is that the organization believes architecture is covered because I configure ServiceNow.

So the harder work never gets done. No one stops and asks:

1. What exactly is the intended outcome?

2. What is the decision sequence?

3. What is the governing logic?

4. What are the required components before configuration begins?

Instead, the project keeps moving because “the architect” is configuring the tool.

That is how workflow configuration gets mistaken for architecture.

What the Role Really Is

A person configuring ServiceNow is a valuable implementation specialist. He may be highly experienced. He may understand the platform deeply. He may coordinate large programs. He may know incidents, changes, requests, CMDB, workflows, approvals, SLAs, integrations, dashboards, and reporting.

That still does not make the role automatically architectural. It makes the role essential within implementation. But architecture starts before configuration.

Architecture defines intent. Configuration applies settings. Architecture defines the anatomy. Configuration works inside it.

The Real Correction

The correction is not to reduce the value of ServiceNow configuration. The correction is to stop calling it architecture by default.

1. If I am truly the architect of the project, I must help define P1–P4 before configuration begins.

2. I must help define what the project must achieve.

3. I must help define how decisions must flow.

4. I must help define how logic must behave across rules, functions, data, UI, timing, and interactions.

5. I must help define what components must exist before the tool is configured.

Only then does ServiceNow configuration have architectural meaning. Without that, I am configuring the workflow platform. Not defining the architecture.

Diagnostics Note

I configure ServiceNow. That is real work. That is useful work. That is important work.

But if P1–P4 are not explicit, I am not the architect of the project.

I am the ServiceNow configurator. And calling that architecture is how service projects get automated without being properly defined.

One Enterprise. One Anatomy.