Kick-starting your ServiceNow Technical Governance journey – Part 1 – Environment Management

[Stephen Farrar]

Hi, I'm Stephen Farrar, a Solution Architect with Expert Services at ServiceNow, based in Brisbane, Australia.

I’ve recently been working with a customer who is brand new to ServiceNow and, as part of their initial implementation, I’ve been working with them to establish their ServiceNow Technical Governance processes.

Throughout this process I’ve found that for a new customer it’s not easy to get started with all the myriad pieces that need to be understood for technical governance, for some areas there are great documents describing what is needed, but no samples to get you started, in other areas we might have a sample but no real guidance about why to do one thing or another.

In this series of blog posts I intend to explore the four technical governance domains: Environment Management, Platform Management, Data Management and Development Management. Working through each domain I’ll highlight the different areas you need to consider for each, point out useful white papers and sample collateral that can be used, and suggest some priorities in each area for getting started.

This post covers the Environment Management domain.

But first, why should you care what I have to say?

• I am a ServiceNow Certified Master Architect
• I’ve been working in ServiceNow Professional Services (Customer Excellence Group/Expert Services) for 9 years.
• I’ve worked across a number of different roles during that time: Technical Consultant, Platform Architect, and currently a Solution Architect.
• I’ve worked across a number of different industries and digital transformation projects during that time, including both Commercial enterprise and Regulated organisations.

And what even is ServiceNow Technical Governance anyway?

ServiceNow Technical Governance is the part of your ServiceNow Governance framework that’s concerned with guiding technical decisions regarding the ServiceNow platform. In doing so the intent is to ensure that the platform remains stable, secure and aligned with the overall vision and strategy for the platform. This should also maximise value realisation by ensuring all solutions are consistent and fit for purpose.

The Technical Governance Board is responsible for overseeing the development of technical governance policies and standards within the four technical governance domains: Environment Management, Platform Management, Data Management and Development Management.

For this series of blog posts I assume that you have the charter defined for your Technical Governance Board and are ready to start developing your policies and standards. I also assume that you have defined your initial ‘Golden Rules’ or guiding principles that will be the high-level guidance for technical decisions that come before the Technical Governance Board.

If you have access to Impact (Advanced or Total) through your ServiceNow subscription, you may also want to consider executing the ‘Technical Governance’ architecture accelerator.

Environment Management

Environment management is concerned with setting the architecture and processes needed to establish the appropriate environment structure to support the organization's development, testing, and release processes.

It includes the following areas:

• Instance structure – what instances do we have and what are they used for.
• Instance management – how will we manage our instances to support their use.
• Cloning practices – how do we ensure that our instances are in sync with ongoing activities such that when development work is pushed through we can have a high confidence of success when it reaches production
• Application Management – what applications do we have, who uses them and how should we support them. This usually begins with looking at any custom apps you may have but is similarly important for the many apps that are now being made available through the ServiceNow store.

Instance Structure

• Typically this is decided as part of your initial ServiceNow purchase, but additional instances can always be added.
• Will be heavily influenced by the way you perform development, testing, and release activities.
• Consider where the following activities will occur:
  • Initial development
  • Testing of that development, both from an individual item point of view as well as integration testing.
  • Where does User Acceptance Testing occur
  • Can Training development use the same environment or does this need to be locked down while material is being developer and/or user training is occurring?
  • If an issue occurs in production where will any fix work occur?
  • Where can we perform testing of any new functionality or features outside of development, or initial evaluation of new features?

Instance Management

Once your instance structure is determined you’ll need to put together policies on the following areas:

• What each instance is intended to be used for
• How will each instance be supported?
• When can maintenance be performed?
• Is change management required for the instance?
• Who will get admin access to the instance?
• What security hardening is required for this instance?
• How will system properties and plugins be managed?

Cloning practices

Instance cloning is the mechanism used to ensure your ServiceNow instances stay in sync, this ensures that when work is done in a sub-production environment, you know that environment is a good representation of production, and that any development effort will work when it gets to production.

For cloning we’re concerned with the following:

• How often should we clone?
• When can we perform the clone – to ensure the least impact on development?
• What data is ‘instance specific’ that we want to keep when we clone?
• What data is sensitive and should not be copied from the Production environment.
• Which instance should we clone from and to?

Application Management

This area concerns how we ensure the applications deployed to ServiceNow are well maintained and managed to ensure they’re delivering value and when they’re no longer required, we can safely remove them.

With application management the key areas to define our policies are:

• Who owns the application?
• How will the application be supported?
• When can maintenance be performed on this application?
• Who uses the application, end-users and fulfillers, are there other applications that are dependent on this application?
• What specific security rules apply to this application (e.g. for HR users with the ‘admin’ role may not be allowed access)
• How will data be managed for this application?

How to get started?

• Review the attached ServiceNow Environment Governance ‘Success Insight’ – this provides more details on all the areas noted above. (Unfortunately as the Customer Success site no longer exists many of the links in the document don’t work, you can always try to search for the document on Now Create however)
• Work through the Instance Definition Assessment – this works through questions and additional details on the items noted above and gives you a starting point for what you already have defined and what you still need to answer.
• Determine where you will store your Technical Governance policies – a ServiceNow Knowledge Base works well for this!
• Use the ServiceNow Technical Policies Template to start documenting your policies

That wraps it up for Part 1 – Environment Management, I hope this helps make it easy for you get started with defining your Technical Governance policies. Keep an eye out for Part 2 – Platform Management coming soon.

How have you found your ServiceNow Technical Governance journey? What resources have you found helpful? What do you wish you had known when you got started? Let me know in the comments below.