Handling Integrations: An Interview With Chris Grey

6 min read
Amba Wilkes

Quality integrations are essential for a high performing website. No one knows this better than Solutions Architect, Chris Grey.

A bad integration can cause significant negative impacts, from downtime to an inability to scale. As part of the NetConstruct development team, Chris is well versed in coordinating the technical elements of website projects. Using his skills to dig into the finer details of integrations, he is key in the delivery of a successful integration project.

We spoke to him about the importance of getting integrations right from the outset, including the common challenges seen and how you can prepare.

What are the main challenges associated with integrations?

There are many challenges associated with integrations. The big one is coordination and collaboration with third parties - suppliers and the client. Often, you’re reliant on the supplier and the systems that you're integrating with. This means there are potential blockers and bottlenecks that can occur during a project where you need them to get back to you on an issue that you're encountering when integrating with their API.

At NetConstruct, we’re keen to establish channels of communication early on that we can use day to day, often through an instant messaging service like Slack or Teams. This allows us to quickly turn around any issues when we encounter them with the suppliers.

That leads to another issue which is project unknowns. Often, when you go into an integration project, the system we're integrating with might be bespoke or it could be a system we've not worked with before. So, there’s a degree of risk because you're learning as you go on those sorts of projects. We do as much work up front to understand the system we're integrating with to minimise as many of the unknowns as possible. Then, when we go into the project, we've got the best picture of what we need to do.

Another issue you can run into is inadequate documentation. This can happen when different systems have varying degrees of documentation that go with it. Sometimes you may just get a word document with a few pages. Other times we get a fully documented API, which is what we prefer when we're integrating because it gives us much more information. We would recommend to our clients that when procuring a system, they look at systems that have a fully documented API because it makes life much easier when it comes to integration.

Project timing is another challenge. When you're working with multiple parties, you need to be able to coordinate deliverables so that any dependencies are delivered on time. Dependencies on third-party suppliers can have a knock-on effect on the overall project timeline. So many of the things we do at NetConstruct are to ensure that we're working closely with the client - both the technical leads and the project managers - to flag these risks as early as possible and give realistic timelines and deliverable dates.

Custom requirements are a regular risk too. Often a client will come to us and say they require certain functionality that isn't supported by the system that's being integrated with. It's important to identify whether or not there are custom requirements that the supplier needs to implement on their site. Part of our process is to do a project discovery where we'll carry out a technical review to identify if there are any missing API methods that we need the supplier to implement.

Another huge challenge is test data. Not having adequate test data is often what causes the most common bug fixes with an integration project. When integrating with a new system that the client hasn't used before, they may not have any test data at that point. When you're actually developing against that and integrating, it can be difficult to identify issues until there is a fully representative set of data within the system to work with. It's not until we get the real test data in there that we run into issues that could have been identified much earlier on if test data was available from the outset.

What advice would you give a client to prepare for an integration?

My last point leads to this nicely. Firstly, make sure, if possible, that you can provide a set of representative test data, not just random test data.

Another thing that I'd advise is to ensure from the outset that the system you're looking to integrate with is actually capable of delivering your business requirements. If not, make sure any custom business requirements can be delivered when speaking to your supplier.

Another big one is setting realistic timeframes for your integration project because it can take longer than you might expect. Consider splitting large integration projects into multiple phases. This massively minimises risk because you're tackling one problem at a time. It also gives the client the opportunity to become familiar with the system that's been integrated with so for any future additions, you already hold that background knowledge.

On larger integration projects, we would recommend planning for regular catch-up calls with all suppliers to make sure everyone is in the loop when it comes to issues being raised. Often within projects like this, you'll find that a new business requirement emerges mid-way through that requires the full team on one call to discuss and come up with a solution. It also improves transparency on project progress and makes sure that as a client, you're fully aware of where everyone's at in terms of their responsibilities and deliverables.

If possible, we would recommend having a dedicated project manager on the client side who is involved in conversations between all parties. Having someone who can coordinate from their side will really help the project rather than getting individual people involved at different times.

Finally, feel free to reach out to your agency to let them assist you with the procurement process. This is something that clients don't think to do but it can often be difficult for them to see the final technical details that could be involved so we aim to shed light on this early. On previous projects, we’ve advised and helped prepare questions for potential suppliers enabling our client to ask if their system can do X, Y and Z. An example of this is our work with iStructE. At the start of the project, we actually helped them with the procurement process to aid in selecting a new CRM provider.

How does NetConstruct approach integrations?

Depending on whether the client decides to involve us, we may get involved right at the very start to assist with the procurement process. In that respect, we perform a consultancy role for the client to help them choose a supplier before the project even begins.

Once that has been done and we get into the early project stages, we'll look to set up the instant messaging channels mentioned before with clients and suppliers for day-to-day project discussion. It helps to set this up right from the start so that when we reach the next phase, which is Project Discovery, we're able to ask questions immediately via our instant messaging channels.

The next phase is actually defining a scope that can then be refined. Anything that we discover in terms of the integration touchpoints can also be shared with the supplier so the supplier can confirm if their system can meet the requirements. This is handy to make sure that the API we're integrating with has everything that’s needed.

The next stage would be to run a tech review if it was needed. During this, we look through the API to check whether or not it supports everything we need it to as well as review documentation and flag any risks or questions regarding the technical aspects of the integration. This is done before then defining a functional and technical specification which are used moving forward for outlining what the project deliverables are.

Another thing we often do is implement integration tests which basically test that we set up in code that can be run automatically. When they're set up, it allows us to quickly identify and resolve interoperability problems which essentially means ensuring that the two systems can ‘talk’ to one another properly. So, what an integration test allows us to do is check that the data we send and receive matches what we expect. If it doesn't, it flags an error and then we can resolve it there and then before it reaches client testing on the website.

Finally, regular catch-up calls should be planned on integration projects because there are a lot of moving parts. If you don't stay in touch, things can easily go off track.


Integrations can be complex with each one creating unique challenges. It’s important to find an agency with proven experience that can demonstrate that they understand your challenges and can provide a tailored solution.

With a proven integrations process in place and an experienced team behind it, we work hard to ensure our integration projects run as smooth as possible. Do you have a website integration project on the horizon? Get in touch to find out more about the way we work and how we can help.

Thoughts. Opinions. Views. Advice.

Related Insights

1 of 1