Jakob Anker
ServiceNow Employee
ServiceNow Employee

The Council

 

In ServiceNow, we have an architectural council review where the most complex issues are brought up in an expert forum of Platform Architects. The goal is to uncover potential steps to solve the presented situation.
Here I would like to share some topics from the sessions without disclosing any identifying information about the client.
 

Introduction

We are dealing with a very large enterprise comprised of several hundred thousand users.
In any such organization, you are not dealing with one organization. More likely, you are dealing with numerous organizations that all fall under the same umbrella.
 
Here we have such an umbrella of organizations that wisely has chosen to embark on the complex journey of simplifying their IT Infrastructure. A step herein is the introduction of a new ServiceNow instance that is to take the place of two others; previously, business units have been working in separate instances but wishing to break down silos through shared services.
 

Problem Statement

The vast organization is managing its virtual citizens through active directories. There is no single source of truth.
 
Because there are many ADs, there are, in fact, many digital user entities per employee. Up to 10+. This removes the possibility of a single sign-on while making request processes difficult.
 
The different islands of ADs all contain objects that may be needed in a given approval and fulfillment process.
As such, there is a need to be able to process all of this data inside of ServiceNow to ensure that the correct user is given an approval task.
 
Currently, a custom engine has been put in place that updates an enormous amount of records inside of ServiceNow based on the deltas of the different ADs. As a result, there is a heavy integration process that ultimately 'just' produces a massive replication of data for limited use cases on the platform.
 
On a practical level, a requester would need to select the correct AD user on the form based on the requested service. Here the choices are AD users are yielded by the replicated data on the platform.
 
The client is looking for a more efficient fulfillment process.
 

Considered Options

Asynchronous REST and attribute-based user/service mapping

One solution is to stop carrying the data inside ServiceNow and instead set up on-demand REST integrations to the given ADs.
 
Ideally, the user would not need to select the AD entity on the form if the master data is clear enough to establish a dynamic relationship between the requested item/service of the catalog to the available objects in the ADs.
 
Based on the service selection a specific REST integration would fire, prompting a specific AD to look for entities related to that specific service, upon which the response body would contain coalescing attributes that would enable ServiceNow to select the correct approval user for the request flow.
 
Alternatively, if the relationship between requested service and AD entities cannot be automatically established, integrations could query the related AD entities and have the user select the correct one in a follow-up catalog task. This might be preferable as the integration would slow down the user journey when requesting via the catalog item form, should the request need to wait for the AD queries.
 

ServiceNow Identification and Reconciliation Engine

The platform contains functionality to identify objects from various data sources that should be reconciled into one entity in ServiceNow based on a coalescing attribute. This functionality could be utilized to decrease the amount of redundancy should the client wish to do a data cleanup.
 

Long term solution

In the long term, the solution probably isn't to engineer our way out of a complex data situation. The obvious candidate would be to pull the weeds with their roots by merging the ADs into a single repository. Here, instead of having a multitude of user entities per digital citizen, there would only be one entity that belongs to several dynamic groups granting different system permissions.
 
This would enable a centralized management of user, group, and permission provisioning. Effectively enabling SSO and optimized employee life cycle and permission management.
2 Comments