The Philosophy of ServiceNow Development

 

The Philosophy of ServiceNow Development

Let’s talk about The Philosophy of ServiceNow Development.

Why does development in ServiceNow look so unintuitive; so complex; so ugh…??!

Maybe I’m a complete idiot, but let me ask you this:

Specifically concerning the server side of things, where does the inspiration for using script includes, business rules, system properties, etc. come from to build business logic and custom applications??

What’s the philosophy behind these tools??!

Isn’t it possible to make development in ServiceNow easier and more intuitive for developers??

Flow designer should solve this problem, right?

If so, why are we still using those old tools?? Is it too much to ask for an easier way of building stuff in ServiceNow??

Can somebody help me clarify this??!!

Can somebody confirm that I am a complete idiot who doesn’t understand anything about developing things in ServiceNow??

Cool & Refreshing Perspectives

In fact, I posted this article on my various social media accounts and surprisingly I got some interesting answers and perspectives worth sharing!

This one is my favorite:

To answer this question you'll have to take a look at ServiceNow across its entire history and not just the more recent advancements that have been made. Each of the tools you mentioned serves a specific distinct function that might not be served in a complimentary system. Not to mention that some of the tools you have access to now were not available earlier (e.g. before flow designer there were workflows, before workflows were a core thing there were business rules)

For example, let's take script includes. Assuming you have reusable logic that you would like to call from different points in the system, how would you go about this (a use case could be a report that requires you to build the query dynamically, maybe you want to see all incidents created by all dependents of a specific line manager) 

Let's take a look at Business rules. What if you wanted to conditionally make a field on a form mandatory depending on something that might be on another record.

Let's take a look at System Properties. What if you wanted a specific piece of data (such as the instance name) to be shared across multiple emails, and you needed to update the instance name cause you made a type (would you manually go through each email doing a ctrl +f and replace?)

You'll realize that with ServiceNow being a PaaS there ends up being multiple ways to perform the same action. With enough practice and trial, you get to the point of choosing a specific module not because it's easy, but for the specific need it serves. 

Now, SN knows that the above is only really understood by people who have been using the system for a while. So what'd they do, they added low code (flow designer/catalog builder/process automation designer) for users that do not necessarily need to go into fine-grained development, you see how this compares with the earlier tools? Meeting a specific need that cannot be achieved in a complimentary module?. A mistake a lot of people make is assuming low code is definitely the way to go because SN said so, I argue no. Low code meets a specific functionality, if you don't have enough technical expertise and need to meet a need, then definitely low code. 

Now one disadvantage of low code is that a lot of technical control is abstracted.  The reason some of us still make use of the 'old' technologies is because they would not be covered in low code. Not to mention that as low code abstracts a lot of functionality, you end up having to do more to achieve the same thing whereas it could have easily been handled in the 'old' technologies.

Another illuminating perspective is this one: 

 I think the core philosophy of ServiceNow is trying to enable non-developers. Whether or not they have been successful at that is questionable. They want you to default to using a low-code solution when possible.

One of their problems is they have introduced so many low-code tools over time that there are many ways of doing the same thing in ServiceNow. Each low code tool they introduced has strengths and weaknesses. That's how you get at least 3 low code workflow engines in the platform, process engine, classic workflow editor, and flow designer. I believe there was one before the process engine as well. You have 3 UI frameworks, UI16, ServicePortal, Next Experience. There are multiple ways to send out emails. You can implement logic similar logic in business rules and flow designer flows. And on and on.

Each time they introduce a new low code tool it increases the amount of configuration knowledge you need of the platform to understand how to optimally implement an application.

So the problem with ServiceNow, if you see this as a problem, is depending on what you're supporting you have to know those specific set of tools that were used to create the application. I don't believe there is a "right way" to implement custom apps on ServiceNow. It really depends on the skillset of your developers. If you have pro coders then you are probably not going to lean on a lot of the low-code tools. I'd say you probably shouldn't. The low code tools almost universally have limitations and you will be forced to have some combination of low code and pro code in your implementation. That will increase the surface area of ServiceNow knowledge you'll need to maintain your app. If you don't have pro coders then it's simple. You can only do as much as the low-code tools allow you.

But beware, ServiceNow will always say any scripting is technical debt. I believe this is misleading. I've often found the low code stuff comes with the tradeoff of being less flexible and harder to maintain than scripting, so use your judgment and don't blindly follow what ServiceNow is selling. I almost kind of think they want you to get really familiar with the low code stuff so you end up really needing a staff of ServiceNow experts to maintain whatever you've built on the platform versus general software developers that would understand scripting better.

You can read other insightful perspectives on Reddit