Requirements gathering is an essential part of planning and implementing ServiceNow integrations.

It helps users tailor their ServiceNow integrations to meet their needs, whilst causing minimal disruption during and following implementation.  

Skipping the requirements gathering stage can lead to key considerations being overlooked.

As well as having a negative impact on operations, it can also adversely affect employee morale, when integrations change processes managed by said employees without their input.

What is Requirements Gathering?

Requirements gathering is the process of determining what a project requires to be completed effectively. It involves identifying and documenting both business and technical requirements that will help organization’s complete a project in a way that achieves their goals.

Business requirements describes the “what” – as in what a project intends to achieve – and technical requirements describe the “how” – as in how the project should be completed.

Why Requirements Gathering is Essential for ServiceNow Integrations

Organizations integrate systems to facilitate data exchange between them. However, the goal of integrating systems isn’t simply “to transfer data”. In fact, organizations attempt to improve how they transfer data to achieve their goals – making the transfer of data a part of the process, not the end result. 

As such, integration planning and implementation should be business goal-oriented, and requirements gathering should be undertaken to ensure implemented integrations help to reach those goals.

A well-defined set of requirements ensures faster time-to-value, reduces development, deployment, and support costs, and delivers an improved experience for end-users.

With a business goal-oriented approach to integrations, supported by good requirements gathering, organizations avoid losing sight of why they want to integrate data, how they want to integrate data, and who will be using integrated data. 

Having such a focus ensures every stakeholder involved in the integration planning and implementation process can work cohesively, towards the same goal. 

The importance of this cohesion should not be underestimated, as often, the teams responsible for implementing the integration will not be the end-user, so it can be easy to lose sight of what the integration intends to achieve.

Essential Questions to Ask During Requirements Gathering for ServiceNow Integrations

Requirements will vary between organizations. As such, there is no one-size-fits-all approach to getting it right.

With that in mind, it’s useful to consider working with an integration service provider from the outset that can help you through the requirements gathering process.

For organizations that want to start without an integration service provider, a good starting point is to create a list of questions, shaped by the organization’s business-driven goals for their integration.

It may become apparent during requirements gathering, that an integration-as-a-service provider is necessary to deliver an integration that meets the needs of the organization.

Choosing the Right Integration Approach

Building an integration from scratch and its subsequent maintenance can be a huge drain on internal resources.

This white paper compares DIY integrations, implementing pre-built integrations and working with fully-managed integration service providers.

Extract ServiceNow data with the right integration approach.

Choosing the Right Integration Approach

Building an integration from scratch and its subsequent maintenance can be a huge drain on internal resources.
This white paper compares DIY integrations, implementing pre-built integrations and working with a fully-managed integration service providers.

Organizations that want to start the process internally, should start with drafting a list of questions to capture requirements. Some standard questions to use as a starting point are as follows:

Who are the system owners? Are they involved in integration planning?

In the context of planning a ServiceNow integration, system owners encompass various roles, including ServiceNow users, process owners and administrators. There are also the users of solutions connected to ServiceNow, and the stakeholders at third-party vendors delivering managed services related to ServiceNow.

These individuals play a crucial role in supporting the implementation of the integration. Their involvement is essential in scoping the integration needs and evaluating system capabilities. 

This includes assessing potential limitations, such as performance load and middleware requirements, before proceeding to the technical design phase. 

Involving the necessary stakeholders in the integration planning process is crucial to ensure a comprehensive understanding of requirements and capabilities for a successful integration implementation.

Their duties may also be disrupted during the implementation, and so keeping them aware of progress and the implementation timeline helps to minimize disruption. 

What will cause the integration to run, and how often will it run?

Typically, integrations need specific triggers to run. These triggers may be dynamic and event-based – such as automatically transferring incident data to an external database when an incident is closed.  Triggers may also be scheduled – such as transferring data to a reporting solution every day at 5 PM. 

Sometimes, integrations may require manual triggers. For example, when one-off, bulk data transfers are required to support specific tasks. 

What technology will facilitate the integration, and what impact might it have?

Since there are different technologies available to facilitate the transfer of data, organizations need to consider which approach best fits their needs. 

A pre-built, API-based integration may be quick to implement, but configuring it to meet an organization’s specific needs can still be a lengthy process. In this case, the impact (slow time-to-value, internal development resource consumption) may make the approach unsuitable.

Similarly, an organization that wishes to transfer ServiceNow data to a number of different targets may identify a versatile API-based integration as a potentially suitable technology. 

However, frequent API calls to ServiceNow degrade its performance, preventing real-time data, and leading to poor data availability on the ServiceNow platform, and in connected systems.

In this case, it may become clear that a high-throughput ServiceNow-to-database integration is more appropriate as it allows the database to feed ServiceNow and other data into various systems without burdening the system of origin.

What is the volume of data transfer?

When planning an integration, stakeholders must sit with the appropriate stakeholders such as the enterprise architecture team to ensure that the system(s) can handle the expected volume (estimated number of transactions and their size).

Organizations that have more ServiceNow data, typically require integrations that can achieve higher-throughput.

Additionally, organizations that wish to use ServiceNow data for use cases such as business intelligence, artificial intelligence and machine learning also require higher throughput integrations, as the insight provided by such solutions is improved by being fed high volumes of good quality data.

How should data be transferred? (i.e. One-way or bi-directional transfers? Near- or in real-time?

Organizations should also consider whether a one-way ServiceNow integration – such as a ServiceNow-to-database integration – is what they require.

Some use cases require data to be transferred bi-directionally (eBonding integrations) – and even in real-time. 

For example, in instances where IT Services tasks span multiple systems, an organization may need to synchronize ServiceNow with another system in-real time to ensure all teams supporting IT Services are working from the same view of enterprise data. 

Delays in moving data back and forward between systems will slow time-to-resolution, but may also lead to other issues such as teams working with an out-dated version of data.

What data should be transferred?

Determining the data to be transferred is a critical aspect of integration. It involves specifying the exact nature of the data, avoiding ambiguity.

For instance, when referring to “order data,” clarification is needed—is it records from the order table in the sending or receiving system’s database, or both? Does the order data contain records from other tables?

Handling conflicting data is also crucial in the integration process. In cases where conflicting data exists in the two systems, decisions must be made regarding which source takes precedence.

Establishing clear guidelines on data precedence ensures a smooth and coherent integration process, addressing potential discrepancies and enhancing the overall integrity of the transferred data.

The IT team must also decide whether the systems will always send/receive all records or only the delta between records since the last synchronization (i.e., a “changes only” file). Experts recommend transmitting only the delta between records instead of sending all records to minimize system performance impacts.

Is the target system capable of integration with ServiceNow?

The capability of a system to integrate with ServiceNow depends on its compatibility, and it’s worth noting that some older systems, such as mainframes, may pose challenges in supporting seamless ServiceNow integrations. 

Legacy systems might not readily support or accommodate ServiceNow’s integration requirements. So, the IT team must assess the unique capabilities of the target system and explore additional measures or alternative integration approaches to overcome the potential limitations of older technologies.

Are there any security concerns that impact data transmission?

Stringent security measures, while crucial for protecting sensitive information, can add complexity to the integration process. Firewalls are a common example, potentially hindering the smooth data flow between systems. Additionally, encryption protocols and access controls may impact data transmission.

Organization’s should also consider the security of the integration itself – such as whether encryption and obfuscation is available to protect sensitive data and information, and whether encryption is available for data at-rest and in-transit. 

What technology/language will the two systems use to communicate?

Just like we use human languages to communicate, systems use transport languages. XML and JSON are the most common transport languages, a.k.a. data exchange formats. While these are the most prevalent, other formats like HTTPS can also be used, and can provide advantages to performance when moving large amounts of data.

It’s important to note that sending and receiving systems may use different transport languages. In such cases, the integration must incorporate processes for decoding and encoding these languages to ensure seamless communication between the systems.

This encoding and decoding mechanism is crucial for translating data accurately and facilitating effective data exchange between the integrated systems.

Consider Outsourcing Integration Implementation and Maintenance

Implementing ServiceNow integrations is a complex undertaking. Organizations should be confident that they have the available resources and know-how to ensure planning and requirements gathering is thorough, and the subsequent implementation and future maintenance is manageable. 

For many organizations, this is not the case. And many discover this only after undertaking the project. As such, organizations should consider whether outsourcing ServiceNow integrations is better suited to their needs and their unique situation. 

The requirements gathering process is a good opportunity to make this consideration. But organizations that decide to work with a integration-as-a-service (IaaS) provider from the outset can also get expert support throughout integration planning – including the requirements gathering process.

This can help ensure planning and requirements gathering is comprehensive, and critical considerations are not missed. 

Integrations-as-a-Service, from Trusted ServiceNow Partners

Fortunately for ServiceNow users, Perspectium – an IaaS provider – is available to support them throughout the integration planning and implementation process, including requirements gathering. Perspectium also provides ongoing maintenance and support for its integration users as standard.

About Perspectium

Perspectium is a ServiceNow-native IaaS solution and a trusted ServiceNow partner. With Perspectium, integrations are implemented and subsequently maintained by the vendor for a hands-off, maintenance-free and no-code experience for the end-user. 

Perspectium provides ServiceNow-native applications to let customers interact with their integrations via the ServiceNow interface, and control what data is transferred and when.

As well as benefiting the end-user in terms of ease-of-use, Perspectium also benefits ServiceNow performance.

The technology Perspectium uses to facilitate data transfers was specifically designed by the founding developer of ServiceNow – David Loo – to avoid impacting the platform’s performance even when transferring massive amounts of data. 

It achieves this by utilizing push technology to initiate data transfers without requiring external, performance degrading API calls, and leveraging an efficient cloud-based message broker system (MBS).

With this approach, data can be retrieved by various target systems from the MBS, rather than directly from ServiceNow, to preserve the platform’s performance.

As such, Perspectium users can replicate and extract over a billion records per month without performance degradation. 

Perspectium facilitates numerous data replication, synchronization and extraction use cases via a range of ServiceNow-native applications:

  • DataSync – for ServiceNow-to-database integrations
  • ServiceBond – for eBonding/synchronizing multiple ServiceNow instances, or ServiceNow and third-party solutions
  • Data Archive for ServiceNow – for more control over archiving ServiceNow data, including off-platform archiving to increase the space available on the platform
  • Snapshot – for greater control over backup and restore, including the ability to retain backups indefinitely and restore them without downtime

With Perspectium’s service and range of applications, users gain better control over how they use their ServiceNow data around the enterprise. Example uses include:

If you wish to know more about Perspectium’s no-code, automated integration solutions, contact our experts today!

Related Posts