Best Practice

Build to Scale

There are 2 questions that I get asked most in CMS implementations:

  1. What happens when we upgrade?
  2. Can this CMS solution grow as we do?

Great questions!

The one I follow up with is, “How much time do you have to build?”

The answer is usually that it needs to be done by last Monday. As with any large-scale implementation, time must be taken on the front-end to ensure positive answers to both the questions above.

Let me take a stab at the 2 questions:

1. What happens when we upgrade?

The answer to this really depends on how much customization you plan on having (versus out-of-box). Vague answer right? In reality, if you used the OOB template that comes packaged with ServiceNow, you would still need to do quite a bit of testing if you’re moving up a major version (i.e. from Calgary to Fuji for instance). But that is true for any major CMS provider – it’s usually fairly disruptive to move up a whole new software version.

The one bit of code in ServiceNow that has been really consistent along the way is the CMS application. There have been minimal updates to the core CMS application and nothing really coming in future releases that I know of. What usually changes is the underlying functionality of how ServiceNow treats certain things. For instance, from Calgary to Dublin we saw a major shift in being able to build templates without tables. This had nothing to do with CMS, but everything to do with ServiceNow.

For the most part, custom CMS development is always a layer “above” ServiceNow so when new updates happen, it rarely hits “us” that hard.

2. Can this CMS solution grow as we do?

I like where your head’s at with this one. I’m a huge proponent of build once, use many. If you know going into the project that you are going to on-board a lot of other departments, that changes the entire development focus.

One way to spin up new groups is through the addition of a new site. You can create a new site, use the same layout and theme as the original and make something custom to that group. I’m not a huge fan of this approach as it means more on the maintenance side.

Another way is to create a new application that controls your organizations. This creates a standard approach to how the sites are laid out, controlled etc. Want to add a new group? Just create a new table entry. (Note: this could even be done via workflow!) This approach is much more scalable, however creates less room for flexibility/customization. How this, then, can be defeated is by using roles or other user date to change the layout/experience.

As you can probably tell, I’m more a fan of the latter approach. It does take more time to architect on the front-end, but to me it is a much better enterprise-wide service management approach.

The last thing I will comment on is the need for skilled ownership. The CMS is not something you can just lay on one of your other admin. Someone with a strong coding and web development background should be at the helm if you really want to harness the power of the CMS. If they are able to comfortably work within the platform and have HTML, CSS and JS know-how, you’re golden.

It’s been exciting to see more organizations take risks with their CMS, adding responsive sites, custom search experiences, role-based content delivery and more in the works.

Leave a Reply