All the examples in the book have been recorded as Update Sets, which we discuss in detail in Chapter 10, Packaging with Applications, Update Sets, and Upgrades. The hotels application is also in a public Git repository. You can apply them to short-cut the examples. Even if you you wish to work through all the examples, I recommend applying the first one, so your scope identifier is the same as the book. It'll make copying and pasting code much easier!

You can download the Update Sets at http://www.gardiner-hotels.com. Alternatively, you can fork the Git repository available at https://github.com/gardinerhotels/hotel. More instructions are at the website.

An instance is an independent implementation of ServiceNow. It is isolated and autonomous, meaning your code and data is not shared with other customers. ServiceNow uses a single-tenancy architecture, which means your instance is yours: you can do what you want with it, such as changing logic, updating the UI, and adding fields.

Every customer has several instances-again, each isolated and independent. One instance is usually marked out for developing on, another for testing, and yet another for production. And because each instance is independent, each one can be running a different release of ServiceNow. The production instance differs by having more powerful hardware.

A new instance starts with a few ServiceNow applications, some demo configuration, and example data. This is often called the out-of-the-box state. One of the example data elements is the System Administrator user. You are able to log in and get going, getting full control immediately.

Everyone makes changes to their instance. Unless the people who will be using the system are called Beth Anglin or David Dan (some of the default example users), you'll need to load some users at the very least. Some ServiceNow customers configure a lot, and some do the bare minimum. You can choose how much you wish to do. Because it is single-tenant, you can alter the configuration and data in almost any way you see fit-now, it might not always be smart to do that, but you can!

My favorite analogy, if you haven't guessed it yet, is a building. ServiceNow gives you an office that is yours. It starts off identical, built to the standard plans, but you can redecorate or remodel as you see fit-perhaps even knock down a wall! (Let's hope it's not load bearing.) This is the benefit of single tenancy.

Multitenancy is like an apartment in a block. It is generally more efficient to pack lots of people together in a single building, and you can build it pretty high. However, you don't have the flexibility that being in control gives you. The landlords of the block won't let you knock down a wall!

The vast majority of customers have their instance hosted by ServiceNow. This means that the people who built the house will also look after it, on their land. You get great economies of scale and the benefit of tools and automation design to perform maintenance and give support fast. All the gardeners and janitors are on site, ready to work-they don't need to travel to help out.

The heart of ServiceNow is the platform. This is a series of data, logic, and user interface layers, combined to provide a high-level environment that makes it really easy to build workflow and forms-based business applications. If you like, the platform takes raw materials and develops them into building blocks. You then plug them together to create what you need.

ServiceNow has already done a lot of building work. Prebuilt applications are available to perform service management, such as IT, HR, and facilities. Managing IT infrastructure is made easier with the ServiceWatch suite, while the needs of the business are helped with demand, project, and vendor management.

When you know how the platform works, you can more quickly use and support the applications built upon it. And, of course, you can build your own. Understanding the platform will help you in all respects-which is the focus of this book.

All ServiceNow functionalities are delivered as plugins. When an instance is turned on, one of its first tasks is to load all the plugins that are turned on out of the box. There are quite a few of those: over 200 in the Helsinki version of ServiceNow. And there are several hundred more that you can turn on if you want. A plugin may provide an app, such as HR Service Management, or provide new platform functionality, such as domain separation.

When a plugin is turned on, all the data and configuration that the application needs is loaded into the database, meaning that it is ready for work in just a few moments. Many also contain demo data, giving you examples of how it could work.

Each new version of ServiceNow brings new and improved applications and enhancements to the platform. These are packaged as updates to plugins.

ServiceNow tends to release twice a year, meaning it can be quite a task to keep up with the latest version! This book is written for the Helsinki version of ServiceNow, though most of the information is relevant for newer and older versions.

Aside from improved functionality and bug fixes, ServiceNow often creates improvements to the user interface. An instance provisioned with the Helsinki version of ServiceNow uses UI16 by default. The screenshots in this book show UI16, so if you use a different interface (perhaps for browser compatibility reasons or because of a different version), things may look slightly different, and all of the features may not work the same.

A typical ServiceNow-hosted instance is split over two physical datacenters, forming a high-availability pair. Each location runs independently of the other, creating a semi-clustered environment. In the event of a catastrophic disaster with one location being completely unavailable, the other nodes will just pick up the load, with almost no downtime. In fact, the process of switching between locations is used for maintenance procedures, enabling your instance to be well protected against hardware and other failures.

When you visit your instance, you are directed through several layers:

From an architectural perspective, a ServiceNow instance is made up of several application and database servers or nodes. These generally run on shared hardware, meaning although your instance is logically separate and independent, it is physically hosted alongside another customer. At each location, there are generally at least two application nodes, each running a copy of the ServiceNow platform and working together to share load. Additionally, there may be worker nodes installed to process the noninteractive jobs, such as sending out e-mails or dealing with integrations. Even though you'll never directly log in to these worker nodes, they perform some background processing, allowing the interactive application servers to respond more quickly to user requests. While there are generally lots of application nodes, there is only one active database server, running on a separate physical server. It does have a redundant pair hosted in the remote datacenter.