Kick-starting your ServiceNow Technical Governance journey – Part 2 – Platform 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 Platform Management domain. Be sure to also check out the previous post on Environment Management.

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.

Platform Management

Platform Management is concerned with setting the standards and procedures for managing the platform, including upgrades and patching, access management, performance management and platform security.

Platform Access

Within Platform Access we’re concerned with:

• Who gets access to each instance, and what level of access do they get?
  • This is closely related to the admin access covered as part of Environment Management - Instance Management (see Part 1)
  • Are there particular requirements to gain a particular access level? E.g. passing training or certification.
  • I suggest starting with a matrix/spreadsheet with all your instances as columns, the intended instance use from your instance management policy in the first row, and then each row with a different user Persona (developer, fulfiller, requestor, admin) that you expect will use that instance, then for each cell define their expected level of access (admin, portal only, particular product etc). You can then use this to help define the policy language and steps to provision and manage access.
• Who has access to Now Support e.g. to log support cases on your behalf
• If someone needs temporary access to an instance, how do they do that?
• What is the process for adding or removing users, or access?

Upgrades and Patching

Upgrades and patching are concerned with keeping your instance up to date with the latest family release, and fixes from ServiceNow to ensure you avoid security issues and remain eligible for ServiceNow support.

Within both areas we’re concerned about the following:

• What is the process for performing the upgrade or patch?
• What approvals are required?
• How will it be tested?
• When can it be scheduled?
• What communication is required? When? With whom?
• What training requirements are there? (this is likely to be specific to upgrades and generally not applicable to patches)
• What is our support process? When do we need to engage ServiceNow support?

Use the Upgrade Policy from Now-Create as a starting point for your upgrade and patching policy and specifically scheduling. Use the questions in the Platform Management practices document linked below to fill out the policy to answer the questions above.

For more on upgrades be sure to check out the Core Platform Upgrade success pack on Now-Create and the Releases and Upgrades community.

Performance Management

Within Performance Management we’re concerned with the day to day activities that are needed to keep the platform operating at peak performance as well as monitoring for any issues that may be causing problems for users, or may cause problems in future.

Here we want to define a policy or policies covering:

• What activities do Platform Administrators need to perform
• When they need to be performed, how often
• How do they perform the activity?

The success insight mentioned below (attached) contains a great starting point for activities, and the Now Create asset ‘Fine tune ServiceNow platform with regular performance administration’ contains even more activities along with step by step guidance on how to perform them.

I would recommend creating your own policy that defines these activities, so you can add details that are specific to your organisation and have a place to define additional activities as they come up during your ServiceNow journey. Keep a copy of the linked materials here and reference those in your own policy for simplicity.

Platform Security

Platform security is concerned with how we maintain the security of the platform:

• How are the platform security controls managed and maintained?
• How are users, roles and groups managed?
• What auditing and monitoring do we need?
• Are there specific controls for Administrator access? Are separate accounts needed? (you may have potentially already covered this in the Platform Access section)

There are many resources to help with defining your security policies:

• Leverage the ServiceNow Security Center (SSC) in your instance, you may need to install this from the store. The SSC provides recommended instance hardening settings, as well as tools to help with compliance and monitoring your instance security posture.
  • The SSC doesn’t necessarily replace your Platform Security policy but it can simplify it because you can reference the configurations put in place there.
  • Hardening Settings on Docs has details of all the settings you’ll find in SSC
• The Security Questionnaire can give you a list of areas you may need to consider, or have already setup, but should document for reference within your platform security policy.
• The ‘ServiceNow Security Best Practices Guide and Key considerations for securing Now Platform instances’ covers a number of best practices for platform security.
• Finally (if you’re still awake!) the ‘Securing the Now Platform’ white paper is the bible for all things ServiceNow security.

How to get started?

• Review the attached ServiceNow Platform Management Practices ‘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 documents on Now Create however)
  • Note that this document references the ‘Instance Security Center’ – this is the previous version and has been replaced by the ServiceNow Security Center (store app)
• 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
• Follow the individual steps noted in each section above.

That wraps it up for Part 2 – Platform Management, I hope this helps make it easy for you get started with defining your Technical Governance policies. Keep an eye out for Part 3 – Data Management coming soon, and if you haven’t already, check out Part 1 – Environment Management.

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.