Over the past few years, there’s been a movement in the business world to espouse the concept of “citizen development”. Gartner defines a citizen developer in this way:

A citizen developer is an employee who creates application capabilities for consumption by themselves or others, using tools that are not actively forbidden by IT or business units. A citizen developer is a persona, not a title or targeted role. They report to a business unit or function other than IT.

Gartner: Definition of Citizen Developer

ServiceNow has espoused this concept in its marketing materials. You’ll see any number of websites, references, articles and online sessions talking about the need for citizen development and how ServiceNow supports it. From their website:

ServiceNow offers a series of citizen development tools, from low code to no code.

• APP Engine Studio and Templates
• Flow Designer
• Process Automation Designer
• Integration Hub
• Virtual Agent
• Predictive Intelligence
• Performance Analytics

ServiceNow: What is Citizen Developer

For the purposes of this article, I’m going to assume that citizen development is marked by these important aspects:

• The development does not involve writing code, particularly logic constructs
• The development does involve GUI elements that allows drag and drop construction
• The developer does not need to be concerned with version control or other development processes
• The development does not involve environment promotions or other release management aspects

Based on the blurb above, I’m going to assume that citizen development in ServiceNow (the platform), as considered by ServiceNow (the company), can involve any or all of the following:

• Flows using Flow Designer
• Table creation
• Data elements (fields)
• Data dictionary attributes
• Form builds
• UI Policies
• Catalog Items

I’m sure I’m leaving quite a bit out, but I wanted to hit the “big stuff”. To me, this list encompasses the things Fred Luddy envisioned when the platform was first devised and built in 2004 (Tables, Fields, Forms, Policies) and the current marketing push around Flows to control all business logic.

Ultimately, what I think ServiceNow is envisioning is the ability to take a whiteboard or Visio-type flow and turn it into actual configuration in the platform, particularly by folks who aren’t developers by trade. This is certainly the Flow aspect. Additionally, the “Fred stuff” included being able to develop new data entry forms and business logic around them to digitize what was previously done on paper, email or spreadsheets. (Really, when you boil down ServiceNow to its core value, this is it.) Also done by “non-developers”.

Here’s the fundamental flaw in this thinking: This level of development democracy assumes the guardrails are big enough and strong enough to prevent the introduction of flaws into the system. These are simple flaws – inconsistency in form design or label nomenclature, and large flaws – applications that don’t fit platform architecture standards set by either ServiceNow or the platform owner(s). So what are the guardrails? ServiceNow will tell you Application Scoping, which silos application elements by namespace and security. However, if you are a platform owner – responsible for the overall health of the entire system – what good are silos if every silo contains a giant mess? It reminds me of the closet scene from The Marx Brothers “A Night at the Opera”.

I certainly have not seen cost-of-maintenance studies done on this, but I have a hard time imagining that the cost of “cleaning up” and/or maintaining the applications developed by non-developers is less than development that uses an architecture, a methodology, and developers.

Consider this analogy: If you were going to try and develop a cogent political philosophy, would it be wiser and easier to read the missives of a few political experts across a range of theories, or turn to social media and attempt to cull the same from it? I often think of social media as citizen development. It’s the “everyone contributes and we hope something cohesive comes out of it” mentality. If this has worked, I’ve yet to see it happen.

I think of another analogy from my college days: In my Operational Management class, specifically the time focused on lean manufacturing, my professor told a story of visiting various auto manufacturing plants. When he visited the Mercedes-Benz factory, he told of a team of highly paid, highly skilled engineers who sat at the end of the assembly line and reviewed and fixed every defect in the car before it passed inspection. So when a consumer buys a Mercedes-Benz, they know for an expensive price, they are getting a quality car. (We’ll leave the cost of engineering and parts out of the equation for now.) Conversely, when he visited a Toyota factory, he saw that every line worker had an alarm they could ring and stop the assembly line whenever they noticed a potential defect caused by anything in the system – process, parts, etc. The lean manufacturing methodology accepts upfront costs of line stoppages in order to eliminate the possibility of downstream defects and the cost of correction. The moral of the story is each way results in a quality product, but the way to get there is completely different.

To come full circle, I see citizen development as choosing the Mercedes-Benz way – where the acceptance of inherent defects means choosing your developers’ efforts will be on the back-end. I say this because, in my experienced opinion, I’ve not seen where the result of citizen development is clean, designed to platform standards, defect-free, and simply able to be deployed with no concern. Conceptually, there likely are ways that putting up enough guardrails is possible, but I don’t think it’s possible in the ServiceNow platform today. Specifically, here are the things required for development, or related to citizen development in ServiceNow, that are outside of the abilities of non-ServiceNow developer:

• Understanding how an application should be built given a platform architecture strategy.
• Where a new table should live in the database structure.
• Deciding what form views should exist and whether they should be forced.
• Any management of record security.
• Any coding. If you’ve worked with ServiceNow, you know there are plenty of business logic aspects that cannot be implemented without some code.
• Troubleshooting Flow Designer bugs. As of Quebec, Flow Designer is still buggy and simply doesn’t work as expected.
• Working with variables on Catalog Items. Since Catalog Items are a big aspect of the ServiceNow citizen developer push, it implies that a citizen developer knows how to define the correct variable types, when to use variable sets, how to do advanced reference qualifiers, and all the other “developer-y” stuff related to variables.

As I said many years ago at a Knowledge conference when the concept of citizen developer was introduced, “Ask a citizen developer when they should or should not extend the Task table.” I’d love to be proven wrong on this, but I’m still waiting.

Happy developing!

The generally accepted ITIL definition of a Service Request is “request from a user or a user’s authorized representative that initiates a service action which has been agreed as a normal part of service delivery”. (This differentiates from Incident, in that it doesn’t involve a restoration of Service.) The key part of this is “agreed as a normal part of service delivery”. Companies often struggle with what a “normal part of service delivery” means. ServiceNow further complicates this with how they built the Service Request application. If you’ve worked with the Service Catalog, Catalog Items, and the Service Request records they create, then you are probably aware of some of these challenges.

I drew this picture on whiteboards for customers for a few years and then gave it to ServiceNow training in 2013 and said “This needs to be in your curriculum. People need to understand this picture.”

The initial challenges are two-fold:

1. The Service Catalog and Catalog Items were designed to give an “Amazon” like experience. Customers select items, add them to a cart, and order them. In order to do this properly, the items need to be well-defined. You don’t go to Amazon and say, “I need socks”, press “Order” and Amazon says, “we’ll figure out the rest on the backend”. No, the expectation is you are selecting a well-defined product – size, style, color, etc. Amazon knows what they offer, which leads us to part 2 – they also know how to deliver it.
2. The Service Request is a 3-tiered record structure, with an Item-specific workflow running against the middle tier (Requested Item). The workflow generates and assigns Tasks (the third tier) based on a known delivery flow. In other words, because Amazon has defined what they are offering, they also know exactly how to deliver it.

In this way, the Service Request structure does not lend itself well to open-ended requests or ad-hoc delivery flows (aka “We’ll figure it out as we go”). The idea is that IT (or any part of the business) is delivering a known entity – they are able to define what that entity is, what it needs to ask the requester about the entity request, and what process and people need to be involved to fulfill the request for the entity successfully.

When part or all of this can’t be met, the reality is that the Service Request application (starting with a Catalog Item) may not be the correct place to build the requirement. In general, I ask the following questions of the requirement to determine if it can and should fit into a Service Request:

1. Does the use case have special security requirements? (Securing individual records gets complicated with the 3-tier record structure, and doesn’t scale well. Not to mention the notification and audit concerns.)
2. Does the use case have a known approval and delivery process? (Open-ended and ad-hoc approvals and tasks make for complicated workflows.)
3. Does the use case need the user to interact with the data after submitting the request, beyond comments? Do users need the ability to save something as a “draft” before submitting?
4. Does the use case have special schema requirements for a single entity? (e.g. Dept X needs to have 5 “special” fields on RITM to satisfy some specific need)
5. Does the use case need special notifications?
6. Does the use case require editing of variable answers after the submission of the request?
7. Does the use case have reporting requirements against what would be a variable? (ServiceNow still doesn’t do variable reporting well. Even though it is supported, it wasn’t designed with this in mind.)
8. Does the use case need an integration after the request has been submitted? (I’m shuddering at the thought of having to integrate variable data with another system.)

In general, I treat variables almost as “read-only” and un-reportable, in that a user should be able to populate them, submit them, the fulfiller looks at them to fulfill the request, and never needs to do anything else with them. Adding logic to variables is kludgy, and you don’t get a real audit history when they get edited. So when someone comes up with some complex use case that needs all this weird logic and interaction with variables, it starts to look like a Picasso painting. (As usual, this is as much art as science.)

So what to do? There isn’t a hard and fast answer to this. In some cases, when a customer is new to the platform, I have less of an issue creating a single “generic” request item that fills the need for requesters of “I don’t see what I need, can I just tell you what I need?” What this usually requires is two-fold:

1. An open-ended description that allows the requester to describe what they need. The assumption is that this almost always requires a follow-up by a service desk agent and some back-and-forth before being able to assign out work and fulfill the request.
2. A fulfillment workflow that allows for ad-hoc approvals and/or fulfillment tasks.

Keep in mind this type of request usually cannot be aligned with any delivery metrics, or if it is, will potentially skew these metrics.

In other cases, I’ve built an entirely new application to support these kinds of requests, using the Out of Box “Ticket” (ticket) table. This was for large organizations who have a well-defined catalog of items, but also fulfill a lot of requests that don’t align with a pre-built item. These are organizations whose use cases answer “yes” to many of the questions above. Once built, the records themselves can be assigned, worked and reported on like any other task-based record in ServiceNow, and queues can be managed with the ideas of “My Work” and “My Groups Work”.

So why not use Incident? An argument can be made for this, particularly if the volume is small. This is the reason for Category “Question” and Priority 5. However, keep in mind that the definition of Incident is something is broken and the goal is to restore service as quickly as possible. Often the use cases we are describing have nothing to do with restoration of service.

Regardless of the approach, the best practice is to continue to mine the requests entered for these use cases to determine if they can be converted to a well-defined Catalog Item and Fulfillment Workflow.