You Know What an Integration Is. Now How Do You Actually Build One?

A little while back, I wrote about what an integration really is, using the analogy of two people trying to have a conversation when one of them is still learning the language. Different words, different tenses, sometimes a translator standing in the middle, sometimes a scheduling headache just to find a time to talk.

That post was about understanding the problem. This one is about doing something about it.

If you’ve ever sat in a project kickoff and heard “we just need the systems to talk to each other” said with the same casualness as “we just need to grab a coffee,” this post is for you. Building an integration well has very little to do with which platform, which protocol, or which vendor you’re using. Those are just the mechanics, the equivalent of choosing which language you’re going to speak in. The actual work, the part that determines whether the conversation goes well or badly, looks remarkably similar no matter what technology sits underneath it.

Here’s how I think about the phases, agnostic of whatever tools you’re using.

Phase one: assemble the team

Every conversation needs someone who actually knows both languages, and someone who knows what’s actually meant to be said.

You need technical input from both systems. That might be a vendor, a product support team, or an in-house technical resource, and it’s often more than one person, whoever actually understands how each system speaks. But technical input on its own isn’t enough. You also need someone, or several someones, who own the business process end to end. If you’re building an integration for hiring someone, that might sit with HR, it might sit with payroll, or it might genuinely need both, because neither one owns the whole picture on their own.

The goal in this phase isn’t to start building anything. It’s to align on what you’re actually trying to achieve, and to get your technical people talking early about how their two systems are going to have this conversation in the first place. Sometimes that’s one conversation. Sometimes it’s several, stitched together.

Ask yourself:

• Do I have someone who genuinely understands each system, not just someone who logs into it every day?

• Is there a clear person, or pairing, who can speak for the whole business process end to end, not just their piece of it?

• Have both sides actually agreed on what we’re trying to achieve, or have we each assumed the other one already knows?

  
  

Phase two: define the grammar

This is where you work out the mechanics of how the conversation is actually going to happen.

When are we talking? Who’s doing the translating? Who starts the conversation, and who’s expected to respond? Is this happening on a schedule, a nightly check-in at a set time, or is it triggered the moment something happens in one of the systems? And does this conversation need to stay private? If so, how are we actually protecting it?

None of these are technology questions yet. They’re conversation design questions. You’re deciding the shape of the exchange before you decide what tool you’re going to use to have it.

Ask yourself:

• Could I explain, in a single sentence, when and how this conversation actually happens?

• Do we know who starts it, and who’s expected to respond?

• If this needs to stay private, do we know exactly how it’s being protected, or are we assuming somebody else already has that covered?

  
  

Phase three: align on definitions

This is the one that trips people up most often if you skip it.

What do the words we’re using actually mean? This is usually easier when one of your two systems already has an established understanding of your business, it’s had time to build its own dictionary. It gets harder when both systems are brand new, because now both sides are trying to build their dictionary at the same time, and they’re usually aware of each other doing it. The teething pain comes from building those dictionaries in silos, each side working things out on its own rather than agreeing on the words together from the start.

This is where you sit down and ask, is “First Name” actually legal first name, or is it preferred first name? In most conversations, I introduce myself as Josh. Nobody needs my full legal name for that. But if I’m calling my bank, suddenly my full name matters a great deal. Systems have exactly the same distinction buried in fields that look identical on the surface.

Bonus points if you use this phase to ask a harder question too: do you actually need this data in each system at all? Most systems don’t need everything, they need whatever their specific functionality actually requires. If you don’t need someone’s Tax File Number sitting in three different systems, maybe it shouldn’t be sitting in three different systems. A small shoutout to the cyber and privacy folks here, because this is exactly the kind of question that saves the support team a very bad day when an IT audit comes knocking, or worse, saves the actual person a very bad day if their data ever goes missing.

A quick note on sequencing. Plenty of businesses insist on finishing all of the above before a single line of build starts. That protects scope and effort, and it leans toward a waterfall approach, which sometimes suits the situation or is simply forced on you by the systems involved. My own preference runs a little differently. I like starting the conversation early and stumbling through it a bit. That’s not sloppiness, it’s actually how language learning works too. Immersion is a genuinely critical part of picking up a new language, and the same is true here.

Ask yourself:

• Have we actually tested a tricky field, like a name or a date, against how both systems define it, rather than assuming they mean the same thing?

• Could I explain what every date field in this integration actually represents, not just what it’s called?

• Have we asked whether each piece of data needs to be there at all, rather than just whether it happens to fit?

  
  

Phase four: test, test, test

You can learn a huge amount of a language from a textbook. But nothing replaces an actual conversation with a native speaker, the moment where someone gently corrects your grammar mid-sentence, or tells you “that word’s fine, but this one’s better,” or you accidentally pick up a bit of local slang along the way.

Testing an integration is that conversation. It’s where the theoretical dictionary you built in phase three meets the real, messy way the systems actually behave.

If you want to genuinely level up your testing, don’t just test what you want to happen. Test what you don’t want to happen. That’s often the first thing to get cut when time and budget are running tight, which is exactly the moment it becomes most valuable.

Set the integration itself aside for a second and think about how often your own work doesn’t go exactly to plan. You’re putting together your weekly report, and the CEO asks if you can have it a little sooner than usual. You’re hiring someone, and at the last minute they push their start date back. You’re closing the books for the month, and somebody sneaks one more approval through right before the deadline. Real processes are full of these small deviations, and a well-tested integration has thought about them before they show up in production.

Ask yourself:

• Have we tested what we don’t want to happen, not just what we do?

• Have we run at least one real-world exception, like a shifted date or a late approval, rather than only the clean, expected path?

• Would someone outside the project be able to look at our test results and tell this actually works?

  
  

Phase five: how do we turn this thing on, and when?

Cutting over is often the most nerve-wracking part of the whole process, but it comes down to a handful of foundational questions.

What am I turning off, and what am I replacing it with? What happens the moment these systems, these conversations, stop running? What data will actually be in the new system versus the old one, and will it be current when it matters? And when, exactly, are we switching off the old and switching on the new?

If you find you can’t answer these questions clearly, one of two things is usually going on. Either you’re moving out of a genuinely manual world, paper forms, spreadsheets, tribal knowledge, and into something more structured for the first time, or there are a few more conversations you need to have with your IT and business teams about what actually exists today before you can confidently talk about what happens next.

Ask yourself:

• Can I clearly state what’s being switched off and exactly what’s replacing it?

• Do we know what happens if this integration stops running unexpectedly, even for a day?

• Do we know exactly when the old and new systems hand over, and has someone actually confirmed that date?

To conclude

None of this changes depending on which systems you’re connecting or which vendor’s logo is on the box. The phases stay the same because the underlying problem stays the same, two systems trying to understand each other, built by people trying to make sure nothing gets lost in translation.

If all of this feels like a lot to hold in your head at once, that’s a completely normal reaction. Reach out and I’m happy to walk you through it.