* – A play on the famous James Carville quote about the economy, not implying that ServiceNow folks are stupid
It’s been a few years since I wrote Part 1 of this article, going through the history and evolution of the ServiceNow platform, and the morphing of the company strategy from platform to product. Part 2 delved further into the marketing of ServiceNow products and discussed how a good architect should think about implementing customer requirements by looking past the marketing and understanding the decision at a platform level.
In this article we’ll get deeper into the fundamental structures of ServiceNow and talk about how discussions and decisions can change quite a bit when architects both understand it and factor it into all of their thought processes.
Introduction
“I don’t think I’ve ever seen you this happy after an interview.” It was early fall of 2010, and I had just finished my in-person interview at the ServiceNow HQ in Solana Beach. My wife was surprised to see me grinning, which is ironic since I learned later that the Director of Professional Services didn’t want to hire me because I was “just a project manager”. Why I was grinning was at a point during the interview the curtain opened and I realized what Fred and company were doing with the platform, and how they were doing it.
Ultimately what got me the job was a few technical consultants going to bat for me because I developed and maintained my own fantasy football web site: The front-end, the database, the dynamic server pages. As a hobby. Almost 16 years later I’m still doing it, but have made my career helping businesses have success with ServiceNow.
So what was it that had me grinning and allowed me to find the greatest success in my career? It was the recognition from an initial conversation that the ServiceNow platform was designed and built much like my fantasy football website: front-end web pages, code that sits on a server and delivers the front-end dynamically, and data in the back-end database that populates the front-end.
But there was something more: The ServiceNow database didn’t just contain the data that showed on the front-end, but also the code and configuration that determined how the data displayed, and how the applications functioned. In Part 1 I talked about how the platform itself is pre-defined elements that allow an admin to piece together forms, reports, flows and UI logic. Many of these elements are contained in the database. When an admin configures something, it’s stored as a record in the database.
“It’s all a giant database”
A few years ago I was working with a client who was quite familiar with systems administration and IT operations but was new to ServiceNow. We would spend quality time discussing business requirements and implementation options, but also maintaining the system and the data. One day while we were looking at some data and configuration that was giving us trouble, and I was showing him list views of each, he said, “Oh, now I get ServiceNow. It’s all a giant database.” And he is correct. As mentioned previously, the ServiceNow database contains everything an admin or developer sees when they access the system:
- Application Data: The service records end-users submit and fulfillers work, e.g. Incident, Change, Service Request, Case, etc.
- Core Data: The organizational data used by service records – users, groups, departments, locations – and CMDB CI data
- Import Data: (Often) Transient data from other systems stored in Import sets
- Configuration: Choice lists, UI Policies, UI Actions, Workflows/Flows, Transform Maps and other configuration elements that might be created and updated through the UI but are stored as database records.
- Code: Client scripts, Business Rules, Script Includes, Transform Map Scripts, etc.
If you’ve worked in ServiceNow, you probably recognize that these things often combine and interweave in the UI presentation layer. For example, a Business Rule has configuration and script elements on the same screen. So it’s not a hard-and-fast rule that configuration and code are separate records in the database. More often than not, the script (code) is a field on a configuration record. I primarily separate it here because many view these as disparate things (equating “code” with “customization”, a separate discussion).
Why does this matter? For one, if you know everything is a record, if you need to make changes, or find things that are causing issues or concerns, you can use queries to find things. In other words, you can both understand and navigate “under” the UI level, you can get to the root of the matter. As my ServiceNow developer friend used to say “it’s all records, if you can figure out which records, and how to change them, you can change the system quickly and easily.” Of course with great power comes great responsibility: changing something at its root level – at the database record level – without any UI controls in place to make sure you don’t do something incorrectly, can lead to quite poor consequences. As with any change, test with small test quantities in sub-production environments and only scale once you are confident in the results.
It’s all a giant Lego® Set
As discussed in the first two parts of these articles, in addition to ServiceNow being a giant database, it’s also a set of components that are reusable across the platform, whether out of box or custom built. These components are like pieces of Lego. They can be used for whatever purpose needed as you construct business solutions.
When Fred and team devised Glide back in the early 2000s, they built it as a platform first, with a series of components “lying atop” a database that could be used for creating form-based applications with lifecycle workflows driving business outcomes. Specifically, every table in the database inherently had record form view, a list of records view, and available UI actions, policies, labels, related lists, workflows, etc. Consider these to be the Lego blocks. When they tried to sell it as a platform, business leaders couldn’t wrap their heads around what they were buying. So much like Lego, they started to build pre-packaged “sets” like Incident, Change and Service Request. (Of course they were already built rather than coming in a box with instructions.) Much like you wouldn’t buy a giant box of Legos with no designs, business leaders didn’t want to buy a platform without some products already built in. But, what the early adopters with vision realized is they were also buying all the components with which they could build their own designs. Like Lego, once you see a few sets put together, you can get your own ideas and use all the pieces to build your own set. And so the ecosystem quickly started building their own applications in ServiceNow using the components provided, and solving a myriad of business problems.
This is why it drives me crazy every time I hear someone blindly say, “Stay out of the box”! It’s as if they’re saying, “We can’t design anything new with the Legos we’ve been given, we can only have the sets Lego has provided.” What’s the fun in that? If you consider this same scenario from the ServiceNow side, once the company went public and was now being driven by financial results, their leadership realized the quickest way to new revenue streams was to build new products and sell them. Like new Lego sets provided by Lego! Ergo we see the shift of ServiceNow from a platform company to a product company.
Conclusion
So why does this matter? Understanding that at the root level most of what you see and work on at the UI level is just a series of extensible and reusable components on top of (and inside of) a giant database allows you to use the platform as it was intended, and to create solutions that solve your business problems perfectly, rather than “sort of”. Using the components to perfectly match your business needs rather than plugging in a ServiceNow provided “Lego set” that “sort of” matches your business need means a better result and a better user experience. And knowing it’s all stored in a giant database means you can more easily find things and make changes at the “root level”. And finally it helps you understand new ServiceNow products and solutions more quickly, as you see the layers on top of the root levels ServiceNow has designed, but understand it at the root level as well.
Go forth and develop wisely…
