Decentralised ServiceNow Architecture

[Paer]

Hi all,

We are a decentralised group of companies that are working on a ServiceNow architecture where we need to keep local company autonomy and data ownership while facilitating cross-company collaboration and reporting.

The main business drivers are:

- Enabling global service providers to work out of one instance

- Enabling company level process adaptation, integration and SN licensing

- Possibility to add and remove companies into the global model

- Minimise company level disturbance of operations

To meet these (and a few more business drivers of course), we have landed on a decentralised, integrated architecture where we will have one central instance for the global service providers, and local company instances (already existing). The instances need to share data and tickets, and the major design decisions we have come up with are:

- CMDB data are managed in the central instance and pushed down to company level where applicable

- Foundation data is managed in the central instance and pushed down to company level where applicable 

- Tickets (ITSM tickets and other tasks such as surveys, knowledge) are shared fully bidirectionally

I wonder if anybody out there have done something similar to this and could provide advice on lessons learned, integration methods utilised successfully and maybe even reference architectures we could have a look at?

Regards,

Paer Johansson

[Paer]

Guess this is either very unusual or boringly normal 🙂

[Klaus W Kuhl Br]

I've done something similar in the past, but unfortunately the company no longer uses the Now Platform.

However, here are some insights and recommendations based on experiences and best practices:

Integration Strategy

1. IntegrationHub and Flow Designer: Utilize IntegrationHub and Flow Designer for building and managing integrations. These powerful tools offer a wide range of pre-built Spokes (connectors) that can simplify the integration process with external systems and between ServiceNow instances. They allow for the orchestration of complex workflows that can span across multiple systems.

2. REST API: ServiceNow's REST API facilitates robust bidirectional communication between instances. For sharing ITSM tickets and other tasks, you can leverage the REST API to create, update, and synchronize records across instances. Ensure to implement robust error handling and logging to troubleshoot and monitor the data flow.

CMDB and Foundation Data Management

1. CMDB Sync: For CMDB data management, consider implementing a CMDB synchronization strategy that ensures the central instance's CMDB is the source of truth. Data can be synchronized to local instances using scheduled imports or real-time integrations, depending on the criticality of the data.

2. Foundation Data: For foundation data (e.g., user records, locations, departments), a similar approach can be taken. Ensure that any updates in the central instance can propagate to local instances in a controlled manner, avoiding disruptions.

Lessons Learned and Recommendations

• Governance is Key: Establish clear governance around data ownership, integration design, and operational processes. This includes defining who is responsible for what data, how changes are managed, and how conflicts are resolved.

• Scalability and Performance: Consider the scalability and performance implications of your integration architecture. Test the integrations thoroughly under load to ensure they perform well under peak conditions.

• Security and Compliance: Ensure that data sharing complies with all relevant security policies and regulations. Use encryption for data in transit and ensure that access controls are properly implemented.

• Change Management: Effective change management processes are critical. Ensure that changes in one instance do not inadvertently impact other instances or the overall integration architecture.

• Monitoring and Alerting: Implement comprehensive monitoring and alerting for the integrations. This will help quickly identify and resolve issues, minimizing the impact on operations.