Mistakes to Avoid When Integrating ServiceNow
Understanding the mistakes to avoid when integrating ServiceNow can help organizations avoid incurring a costly technical debt.
ServiceNow integrations allow organizations to transfer data between ServiceNow and systems that can put the data to better use, such as solutions for reporting, analysis, AI, BI, and ML.
However, if the integrations are not fit for purpose, organizations will experience delays when transferring data, missing and/or corrupted data, poor data quality and other issues.
This blog highlights the common mistakes organizations make when implementing ServiceNow integrations.
What Not to Do When Integrating ServiceNow
Effective integration implementation requires careful planning, and a collective understanding of what the integration intends to achieve.
Below, we list the most common mistakes to avoid when integrating ServiceNow:
Don’t skip, or rush the planning stage
Properly planning a ServiceNow integration requires a number of steps including:
- Determining business-driven integration goals
- Capturing the integration’s requirements
- Considering the impact of the integration on the end-user – e.g. future maintenance requirements, system downtime during implementation, etc.
- Mapping how the integration will work
- Determining the right integration method to meet stated goals
- Testing and revising the integration once implemented
During planning, key stakeholders should be identified and subsequently collaborate on deciding the requirements of the integration.
This reduces the likelihood that the team implementing the integration will overlook requirements such as the type of integration necessary to achieve the organization’s goals; the integration’s throughput; future scalability; etc.
Don’t isolate the integration team from the rest of the organization
One critical mistake to avoid during ServiceNow integration implementation is isolating the integration team from key stakeholders and the broader business environment.
The team implementing an integration is very rarely the end-user, so it can be easy for them to overlook the requirements the broader organization has of the integration.
Collaboration between the end-users and the implementation team will help ensure integrations are implemented in a way that aligns with the processes in place. It also means the end-users can be notified of and effectively trained to work with new processes when required.
Encouraging collaboration during the planning stage will also help ensure requirements are comprehensively captured, reducing the likelihood that the team implementing the integration will overlook key details.
Examples of stakeholders that should be a part of the integration planning and implementation include:
- The Now Platform owner, executive sponsor, and other leaders (if needed)
- ServiceNow admins and users
- Users and administrators of third-party systems that are targeted for integration with ServiceNow
- Owners of processes impacted by the integration (ServiceNow and external)
- The enterprise architecture team
- The team responsible for implementing the integration
See also: Requirements Gathering for ServiceNow Integrations
Don’t underestimate the data volume
Understanding the volumes of data stored in ServiceNow and the volumes of data that will be replicated/transferred out is key to selecting the right integration method.
Integrations that cannot handle the volumes of data the organization needs to replicate and transfer, can affect more than just the integrated data and processes that require it.
For example, API-based integrations are external solutions that “call” the ServiceNow platform and query the database for the required results. As such, both the volumes of data involved in the query and poor configuration of the API will affect ServiceNow’s overall performance.
Organizations that understand the amount of data they have in ServiceNow, the amount of data they will have to transfer/replicate, and the timeliness that said data is required can make informed decisions about whether a given method of integration is right for them.
An understanding of how data volumes are likely to grow over time is also key in ensuring a sufficiently scalable integration is selected.
Don’t skip or rush through documentation
Particularly for organizations implementing and maintaining their own integrations, documentation is key.
Well-outlined documentation helps current and future users understand how the integration was configured and how it should be used. This means users are less likely to cause significant errors with the integration and are less likely to misuse the integration and contribute to poor data quality.
Troubleshooting any issues with the integration is also made more simple, and the on-boarding process for new hires can be sped up.
Without thorough documentation, integrations are at the mercy of developer turnover. Should key members of the integration implementation or maintenance team leave the organization, the organization will struggle to maintain the integration going forward.
New hires are often required to reverse engineer the integration before they can effectively contribute to its upkeep.
Don’t overestimate the capacity of internal resources
Implementing and maintaining an integration in-house consumes significant resources. Few organizations have the developers available to build an integration from scratch, and those that do, often take those development resources away from other tasks.
Even when implementing pre-built integrations, configuring them to meet the organization’s specific requirements is an often long and arduous task.
Subsequent maintenance and testing of pre-built integrations also needs to be accounted for.
When organizations underestimate the resources required to effectively plan, implement and manage an integration, they incur a technical debt.
According to estimates, an average organization wastes 33% of its development time and efforts addressing technical debt issues.
Integration related technical debt includes the cost of troubleshooting and amending faulty integrations; the reputational cost of declining service levels; the operational costs incurred due to system failure, data loss, poor data availability and downtime; and more.
Due to these challenges, many organizations outsource integration implementation and management to save time and money, and to optimize the use of internal resources.
Don’t choose an integration solution without considering the total cost of ownership (TCO)
Measuring TCO goes beyond simply comparing the integration solution’s purchase price or implementation costs and its ROI – it’s crucial to factor in the integration’s ongoing support costs.
See also: Free ServiceNow Integration TCO Calculator
Many organizations mistakenly budget for new integrations without considering the cost of maintaining the integration over time.
For example, an organization may purchase a pre-built integration solution as the initial costs seem lower than working with an integration service provider.
However, they may fail to consider the cost of maintaining the integration over time, such as ensuring it is operational after integrated systems are updated.
Eventually, this leads to a loss of revenue due to developers focusing on integration maintenance and repairing faulty integrations, limited data availability affecting operations and other hidden costs.
See also: 6 Hidden Costs of DIY ServiceNow Integrations
Thus, when planning to integrate business-critical systems, organizations must consider the costs of ongoing maintenance or fixing botched implementation at a later date.
And finally, don’t forget you can ask for help …
Make Implementing ServiceNow Integrations Easy, with Integration Outsourcing
Integrations are introduced to make operations more cohesive and easy to manage. However, an integration solution that is itself cumbersome and difficult to maintain can undermine this principle.
Outsourcing ServiceNow integrations to an expert integration as a service provider helps organizations enjoy the benefits of quality integrations without overburdening internal teams and resources.
Understanding the mistakes to avoid when integrating ServiceNow will only help if you have the expertise required to implement and subsequently maintain the integration.
Fortunately, Perspectium is on hand to help …
The ServiceNow Integration Service and Solution, Used Internally by ServiceNow
Perspectium’s experts don’t just understand the mistakes to avoid when integrating ServiceNow, they have a tried and tested solution and service, used by ServiceNow themselves.
Despite having their own API-based offering – the IntegrationHub – ServiceNow uses the Perspectium integration service and solution to replicate data from their internal ServiceNow instances to external platforms.
Designed by ServiceNow’s founding developer, David Loo, Perspectium is a robust, ServiceNow-native solution supporting many integration and replication use cases.
ServiceNow opted to take on Perspectium’s services thanks to the solution’s high-throughput data replication, and the fact that it is delivered and maintained as-a-service.
This means end-users benefit from expert services to implement and subsequently maintain their integrations. Users also benefit from Perspectium’s commitment to support – providing assistance 24/7 x 365.
While Perspectium experts manage the integrations, customers retain full control of their data, deciding what to integrate and how frequently. The data remains secure and encrypted (at rest and in transit), with the user controlling encryption keys.
See also: Keeping Your ServiceNow Integrations Secure
Unlike API-based integrators, Perspectium uses push technology to move data out of the ServiceNow platform and into a message broker system, where it can be retrieved by various external solutions.
This means the solution can reliably transfer over 1 million records per day without degrading ServiceNow’s performance.
So instead of fighting to make ServiceNow integrations work, let Perspectium’s experts work for you.
Contact us today to discuss your ServiceNow integration requirements.