Introduction

I guess it’s time to write something about AI. The topic seems unavoidable these days. Everywhere you turn there’s another article either breathlessly extolling the virtues of AI, or warning of the dangers, or predicting a future where AI either has given us lives of leisure or made us its slaves. What I don’t see is a lot of analyses of the short-term practical uses of AI, and where it may or may not make sense for business use. In this vein, I will give you my thoughts on how AI fits into a ServiceNow strategy for the next 1-5 years, and highlight what I think are both the realistic benefits and the unrealistic hype.

A Brief History (and Where We Are Now)

There has been some version of AI in the ServiceNow platform for years now. The early iterations were machine learning (ML) models that attempted to fill in “ticket” details based on what was learned from previous tickets. For example, an Incident comes in from an end-user with a short description of “Can’t access SAP expense module”. The ML uses its database of learning similar Incidents with keywords of access”, “SAP”, and “expense module” to auto-assign and prioritize the Incident automatically, bypassing initial human triage, saving time and human intervention.

The second phase of AI incorporated Large Language Models (LLM) into specific toolsets (currently branded Now Assist). These tools can take data from the system and build natural language outputs for a variety of uses. The most common example is using LLM to summarize a triage type “ticket” (Incident, Case, etc) into a resolution notes field, saving a human from having to read through the entire history and start writing a summary from scratch. They can also be used to write emails and code blocks.

The next phase is Agentic AI; there’s quite a bit of “press” about this today. Agentic AI is meant to mimic a human’s process / decision flow – analyzing a problem and taking steps to remediate the problem automatically using intelligence it has built up over time analyzing similar problems. It is meant to work largely if not wholly autonomously.

The AI journey to-date can be summarized thusly:

1. Informational: The AI provides information – and hopefully answers – to human interactions based on learning from previous similar interactions and “grading” of the information provided by the AI.
2. Problem Solving: The AI runs workflow automations based on input from the human to automatically provide solutions to the user’s needs. The AI bases its decision making on “grading” the success of previously suggested solutions.
3. Automatic detection and remediation: The AI learns when issues are occurring and runs workflow automations based on learned knowledge of the issue to automatically resolve the issue.

Much of the AI available in ServiceNow today is still ML-based. You’ll notice this as you read about and set up the AI tools: there are minimum number-of-record thresholds that must be met in order for the “machine” to learn enough to be able to provide viable suggestions and solutions. Viable in the sense that the AI can determine it is statistically likely that the suggestion is accurate.

Recently, ServiceNow has added large language model capabilities to leverage “ChatGPT-like” functionality. This allows for auto-creation of chat and “ticket” summaries, notification text, and other customer communications. This is the next phase of AI in ServiceNow, currently branded as Now Assist.

As we venture into mid-2025 (and the annual Knowledge conference), it is likely we will be hearing quite a bit about ServiceNow’s plans for Agentic AI, as the promise aligns so well with the Service Management paradigm ServiceNow has excelled in.

Considerations for AI in Service Delivery

The marketing around these new AI solutions certainly make them sound like the answers to all your problems. While there is promise for automating facets of work that are tedious and human-intensive, I believe that using AI specifically for Service Delivery needs to be carefully considered. Let’s look at a tiered approach to using AI for a Service Delivery situation, then delve into the concerns and challenges.

Consider an example of the layered approaches to Service Request using AI:

• A chatbot that attempts to answer user questions based on knowledge gleaned from analyzing the available data in the system. This is the most basic level and functions much like ChatGPT does using the broader internet. Simple to turn on and implement, but many users don’t want this as a solution, any more than they want an automated phone tree when they call a company’s customer support number.
• Automatic ordering of a Catalog Item based on questions and prompts to the user. This expands on the solution above, but adds the intelligence to understand when a Catalog Item will provide the required solution, and uses prompts to gather the required information to begin the Service Request process without the user having to navigate to the Catalog and order it themselves.
• Automatic fulfillment of the process started in part 2. This would include the AI initiating an RPA or orchestration to complete the Service Request without human intervention.

The layers go from initial “call” deflection with targeted knowledge, to full end-to-end delivery with AI making all the determinations for the correct process steps along the way.

Concerns/Challenges

What are the concerns for letting AI take over the end-to-end delivery? Typically they are allowing AI to make all the decisions along the way. Regarding the full process, you can ask yourself:

• Has a human determined the process can be automated?
• Has a human built the workflow that the AI can initiate?
• Can the Request be fulfilled without human approval or other fulfillment work done by a human?

If you say that a human does not need to make these determinations, there are potential organizational challenges that arise. They center around what KPIs a company uses, and how they rank the importance of these KPIs. In a Service Management environment, consider:

• Customer satisfaction risk. Regardless of the AI solution, is a company willing to risk customer satisfaction, and potentially customer retention, by turning customer service over to a non-human entity? In the scenarios above, what if the AI makes an incorrect determination and there is no human error-proofing along the way? What if AI misinterprets a password reset request as a system reset request and reinitializes a server VM?

Most of us in the business world live in risk-averse environments. Leadership and management are more likely to preserve the status quo than take large risks against customer satisfaction and retention.

There’s a further challenge I don’t hear about much: AI works best with large volumes of data to analyze. The bigger the better. In an ideal world, ServiceNow’s AI would be analyzing data across all customer instances, not just one customer. But companies are not likely to sign up to share their data. Additionally, there is some data even within a single customer environment that will not be made available to AI: Think sensitive HR data. It certainly is a different scenario than say a Google AI agent scanning the entire internet for useful data.

Reality Check

What I see for most ServiceNow customers is a “tiptoe into the AI water” approach, rather than wholesale adoption. The approach often incorporates these aspects:

• Turning on an AI tool in a subproduction environment and observing the results
• Using LLM to auto-create text passages for notes and emails that get reviewed and edited by a human
• Letting AI make a suggestion for a resolution but having a human execute the action, or at least approve of the action prior to AI executing them
• Building orchestration flows that AI (the system) will execute, but a human designs, or co-designs with AI

Smart companies use their best employees to spearhead these initiatives, running in lab-like environments before turning on in production, and becoming champions of the initiative throughout the organization to drive adoption.

Conclusion

There’s great promise in the features and functionality of AI. Being able to use machine learning and large language modeling to remediate issues and fulfill requests automatically, freeing up precious human resource time and capital, is appealing to corporate executives in all industries. As with most new technologies, the theory and the marketing pitch run far ahead of the reality and challenges of implementation and management of the technology. Given the scope of AI for automating work, much consideration must be given as to when, where and how to implement. Smart organizations have knowledge of themselves and their processes, and plan for an intelligent, phased approach to AI implementation, aligned with their KPI objectives. These same organizations measure against these KPIs and continually tune along the way. The alternative risks both customer satisfaction and retention; eliminate these risks as you go on your AI journey!

In part one, we discussed what an architect is within the ServiceNow and the larger IT ecosystems. Now, we’ll delve into design documentation – a key part of an architect’s deliverables, and some of the behaviors of folks who may have the title architect but whose actions belie the title.

Documenting designs and implementations

A good architect understands the value of documentation, and both creates and enforces documentation. My rules of thumb for documentation are:

• Any custom development that includes creating new tables needs design documentation. This does not include Import Set tables, but does include tables meant for custom lookup functionality, extensions to existing functionality, and new task-based applications.
• Any development that spans multiple Agile stories likely requires design and implementation documentation. What I mean by this is if the solution being implemented is complex enough to require multiple stories, there should be a centralized design for the solution that can be referenced by Story developers and post-implementation maintainers.
• Any development whose essential nature cannot be found in existing ServiceNow documentation likely requires documenting. This is typically custom development.
• Any development that would not be obvious to an experienced ServiceNow admin or developer who walks in “off the street” likely requires documenting. In other words, if an experienced ServiceNow person wouldn’t be able to understand the design of the solution simply by looking at what’s in the platform, then the architect “owes” them design documentation so they can see the thinking behind the design. (I can’t say how many times I’ve come into a situation like this and my only tact is to start reverse engineering code. I find this unacceptable.)

My standard “as-built” documentation for these scenarios includes:

• The picture of what was designed (aka “Visio”)
• The narrative of what was designed, and why
• The elements of what was implemented, and where
• The narrative of how the solution is to be maintained

For the sake of illustration, a Salesforce integrated application design document make look something like this:

Design Diagram

Design Narration:

The solution uses a custom request application to align with the Salesforce model, and uses Web Service Import Sets to stage the Salesforce data. Within ServiceNow, the same request can be initiated through a Record Producer in the Service Catalog… continue to describe the diagram and how the pieces fit together.

Implemented Elements:

Maintenance Notes:

In order to extend the data schema on both systems, add fields to the ServiceNow request and import set tables, and use the transform map functionality to populate the field(s). Extend the custom mapping table to Salesforce so the outbound REST message will pick up the new field from ServiceNow… continue to describe the maintenance and extension of functionality

The goal is not documentation for documentation’s sake. The documentation should be clear and straightforward – think of the person who is seeing the solution for the first time. If it were you, what would you want to see to understand what was built?

You should be able to give the document to an experienced ServiceNow admin or developer and they understand the solution and can maintain it without having to comb through the system and/or reverse engineer it to learn it. And if I’m being perfectly honest, there are plenty of times I have to do this with new ServiceNow created applications or solutions.

Architect Failings, aka When It’s a Misnomer

It’s also helpful to list things that aren’t architecture, or at least don’t fall under the heading of “what makes a (good) architect”. I posit that when someone who has the title of “Architect” does these things, they are not truly an architect.

• Treating all requirements development as a one-off. In other words, as requirements come in, the named architect only considers the requirement within the scope of itself, and solutions inside of that box. Doing so results in many unrelated one-off solutions within the platform, without a cohesive platform strategy to tie them together. This leads to maintenance challenges, as each change requires modifying a particular element. For example, I was working with a customer who had several hundred catalog items, each with their own workflow. We made a platform change at the Task level that required the modification of the same few lines of code across hundreds of workflows. A good architect somewhere in that development journey should (would) have stopped these one-off developments and designed a solution where the code existed in one place and was called where needed by the workflows. (I would argue a good architect would also consolidate the workflows, but I hope you see my general point.)
• Implementing all requirements with code. I also refer to this as “write code until it works”. I’ve written about developing solutions that leverage the elements of the platform and maximize configuration over code. An architect understands how this is done, and avoids the common trap of overcoding. Just as important, he or she assures that the development team doesn’t do this either by providing design guidance as I’ve described previously.
• Pushing products over solutions. There is a balance that must be struck between defaulting to a ServiceNow product as a solution, and developing a custom solution that may more perfectly align directly with business requirements. An architect understands each, and the tradeoffs, can articulate the advantages and disadvantages of each, and guides customers to the correct implementation for their business needs. In my view, those who do not make this distinction, but default to a ServiceNow product based on a few keywords heard in requirements sessions, are better termed as Sales or Solution Architects and not Technical Architects.
• Limiting solution scope to ServiceNow. When reviewing business needs, if an architect does not consider all possible solutions in the enterprise, but limits their scope to only ServiceNow, they are not performing the duties of a true architect.

Conclusion

A good ServiceNow architect always starts with understanding the business’s short and long term needs, and recommending a solution that aligns with both, regardless of the technology. He or she understands enough about the ServiceNow platform to recommend the correct application or platform technology to meet the need when ServiceNow is the correct solution. And the good architect provides design oversight so that all parties involved in the solution are working toward the correct goal in the correct ways. In short, the best ServiceNow architects have knowledge of, and can work in, all spheres of the ServiceNow and Enterprise IT scopes:

Lastly, when the architect doesn’t have the required experience in a particular area, they know enough to seek expertise in that area (rather than “faking it until they make it”). If knowledge is power, knowing what you don’t know is wisdom.

“Architecture is not an inspirational business, it’s a rational procedure to do sensible and hopefully beautiful things; that’s all.” – Harry Seidler

If you’re here and reading this, you probably have a concept of what a ServiceNow architect is. (In this context, “architect” means a ServiceNow technical architect.) And you’ve likely worked with folks who have the title “architect”, whether on implementation projects or as part of a larger IT ecosystem. But what does this mean, and what should it mean? I’ll spend the rest of this article discussing this topic. Having the title Certified Master Architect doesn’t mean I have all the answers, but I’ll posit that having my experience and acumen means I can define it as well as anyone.

In part one, we’re going to discuss what an architect is within the ServiceNow and the larger IT ecosystems. In part two, we’ll delve into design documentation – a key part of an architect’s deliverables, and some of the behaviors of folks who may have the title architect but whose actions belie the title.

It’s helpful to start with two lists that will contextualize the discussion: The roles that are common to a medium to large-sized ServiceNow environment, and the spheres of influence the ServiceNow leaders oversee.

Common ServiceNow Roles

• System Administrator – hands on configuration and management of the platform
• Business Analyst – elucidating business requirements
• Developer – custom solution development
• Designer – intra and inter application solution design
• Architect

In many customer environments, folks fill more than one of these roles, and potentially one person wears all the hats in small platform implementations.

ServiceNow Decision Spheres

• Hands-on development
• Application design
• Platform strategy
• Enterprise strategy

These are the areas that require guidance to be provided and decisions to be made. Much like the roles, the people providing the guidance and making the decisions may cross spheres, but the spheres exist.

These spheres fit into a pyramid picture of ServiceNow within the IT ecosystem.

At its most narrow, it helps define development best practices, and at its broadest delineates where and how ServiceNow fits in the overall IT enterprise.

Defining the “Good” Architect

In my experience, and based on feedback from my customers, here’s what makes a good ServiceNow architect, and comparing it to what might be considered architecture but really isn’t:

Considering ServiceNow in the larger customer environment

This is traditionally the purview of the Enterprise Architect in larger organizations. The role takes into account short-term organizational and project needs, and longer-term strategic needs, and evaluates which technology tools are the correct ones to meet both needs. A ServiceNow architect should be able to converse intelligently about these customer needs and convey where ServiceNow can and should fit into meeting those needs. Just as importantly, he or she should also understand and be honest about where ServiceNow may not fit those needs. Between these two, the architect should be able to articulate what ServiceNow can do, the level of effort and cost to implement and maintain in ServiceNow, and help the customer make the correct decisions about using – and not using – ServiceNow.

Understanding the platform separately from products

A good ServiceNow architect understands the platform inherently – I’ve written about this previously. ServiceNow has increasingly moved from being a platform to being a series of products developed on that platform. While there is value in understanding these products, particularly from a business process perspective(*), a good architect can separate the chaff of product marketing from the value of the platform. And more importantly, can align this knowledge with customer requirements.

*For example, understanding how HR processes work, and how these processes are implemented in ServiceNow HR, has value.

Translating customer requirements into the correct platform solutions

Assuming an architect fundamentally understands the ServiceNow platform and understands when ServiceNow should or should not be used in the customer’s overall IT environment, he or she should be able to listen to business requirements and translate into the best way to achieve them in ServiceNow (assuming ServiceNow is the best place to achieve them). What this means is that the architect knows enough about the platform to determine if there is a pre-built solution that best serves the need, or if it is better served by extending platform capabilities to create a customized solution. He or she should also be able to articulate the reasons why to choose one over the other, and both speak to and document the advantages and disadvantages of both, including hard and soft costs.

Knowing and advising on best practices

The ideal architect is knowledgeable enough to not only design the correct solution, but advise on how to implement that solution. This includes advising on technical best practices. For example, when I serve as a technical architect on both projects and ongoing development in an Agile environment, my role and input includes documenting the technical approach on Stories. This is the detail of what and where to develop to satisfy the stated requirements, not necessarily the how. In other words, because there are often 3-4 ways to satisfy a requirement in ServiceNow, the architect should advise on the best way to do it based on their knowledge and experience. This is often beyond the knowledge of a developer or administrator, and beyond what can be found in ServiceNow documentation.

After reading this, you might think “but there’s too much crossover with the roles mentioned at the beginning”. And you may be right. What I’ve found in my ServiceNow journey is that it’s rare that an architect can only fulfill a pure architecture role. Most customer environments aren’t large enough to support this level of “purity” or responsibility delineation. In addition, I’ve found that you cannot provide the correct architecture decisions without some hands-on experience with the platform. Doing so leads to “book” answers without the benefit of real-work experience.

In addition to the more pure architecture I’ve listed, the best architects can also advise on practices for instance management: managing configuration and code updates through the SDLC and provide insight on how to build and maintain to simplify system upgrades (new releases). In short, the architect should be a trusted advisor to IT Management on minimizing cost and maximizing value with ServiceNow.

Coming up in part two, we’ll look at documentation and behaviors that belie the architect title.