Architecture-Led Delivery: Why It's Different from a Typical SI

The Certified Master Architect credential is the highest technical certification ServiceNow issues. There are fewer than seven hundred of them in the world.

Most ServiceNow implementation partners will have one or two CMAs. They are involved in pre-sales, they attend the kick-off, they sign off on the high-level design. Then delivery is handed to a team of certified consultants: qualified people, but without the same depth of platform knowledge. The CMA moves on to the next opportunity.

This is the model that produces the outcomes described in every ServiceNow remediation engagement we have ever done. It is not a staffing criticism; it is an economic reality of how large SIs work. Senior people are expensive. Keeping them on projects for the full delivery duration compresses margin.

GlydePath works differently because we have to. We are small enough that the CMA on your engagement is also the person doing the work.

What architecture-led actually means

The architect designs it. This sounds obvious. In practice, it is not. Many engagements have a high-level architecture document produced at the start and then a series of configuration decisions made during delivery that are not architectural decisions in the strict sense but that have architectural consequences. An architect who is not in the delivery knows what was designed. An architect who is in the delivery knows what is actually being built.

The architect sees the whole platform. Configuration decisions that are locally reasonable can be globally problematic. A customisation that solves today's problem creates an upgrade barrier. An integration approach that works for one system does not scale when applied to twenty. These interactions only show up if someone is holding the complete picture, not the sub-deliverable they are responsible for this sprint.

The architect makes the hard calls. Technical debt accumulates when the hard calls are deferred. "We'll fix that later." "That is out of scope." "The client wanted it that way." In architecture-led delivery, the architect is present when these moments happen and can make the trade-off explicit rather than invisible. Sometimes the answer is still "we'll fix it later," but it is a documented decision, not an undocumented compromise.

What it means for documentation

Architecture documentation produced retrospectively, at the end of a project and by someone who was not in the delivery, is reconstruction, not documentation. It gets the what mostly right. It misses the why almost entirely.

Architecture decision records written during delivery capture the context that matters. Why was this approach chosen over the alternatives? What were the constraints? What would need to change if the constraint changes? This is the information that makes platforms maintainable over time.

Every GlydePath engagement produces documentation that meets the test above. It is not a deliverable we add to the statement of work; it is how we work.

The AI angle

We use AI in our own delivery work: design review, documentation drafting, code generation, quality checking. The result is that a small team can move at the pace of a larger one without sacrificing architectural quality.

This is not about replacing architects with AI. It is about letting an architect's time go further: less time on the mechanical parts of delivery, more time on the decisions that require genuine expertise. AI does not know what architectural trade-offs are appropriate for your platform. A CMA does.

What this means for you

If you are evaluating ServiceNow implementation partners, the question to ask is not "do you have a CMA?" Most do. The question is "who is the architect on this engagement, and what does their involvement look like after the kick-off?"

The answer will tell you what you need to know.

If you want to understand what architecture-led delivery looks like for your specific situation, start with a conversation.