Integration Discovery: The Requirements Phase Most Projects Rush
Updated: 4 days ago
Most integration projects start with the wrong question. "What systems need to talk to each other" is easy to answer and tells you almost nothing useful. A better question is who owns each piece of data, what happens when something fails partway through a sync, and what the system is supposed to do with the edge cases nobody thought to mention in the kickoff meeting. Getting those answered early is one of the biggest factors in whether an integration holds up once it hits real data.
Why Discovery Gets Rushed, and Why That's Expensive
Integration discovery is unglamorous. It doesn't produce a diagram or a demo, so it's the phase most likely to get compressed when a project is under schedule pressure. It's also where a lot of expensive integration failures start: not in the code, but in an assumption nobody validated before building began.
What Real Requirements Gathering Actually Covers
Data ownership: which system is the source of truth for each piece of data, and what happens when both systems have a version of the same record.
Timing and frequency: whether the integration needs to be real-time, near-real-time, or batch, and what actually depends on that timing being right.
Error handling: what happens when a sync fails halfway through, whether partial updates are acceptable, and who gets notified when something breaks.
Authentication and security: how each system authenticates the other, what data is actually allowed to cross that boundary, and what compliance requirements apply to it.
Edge cases: duplicate records, historical data, deleted records, and the exceptions that don't show up until real data starts flowing through the integration.
Change management: what happens when one system's data model changes, and how much of the integration breaks when it does.
Why This Takes More Than a Systems Diagram
Answering these questions well requires actually understanding both systems, not just their APIs, but how each one is used day to day, where the data actually comes from, and where the messy exceptions live. For CMiC integrations specifically, that means knowing CMiC's API structure and data model well enough to know which questions to ask before the integration is built, not after it's already producing wrong data quietly.
What Skipping This Actually Costs
An integration built without real discovery may work fine in initial testing, because initial testing rarely covers the edge cases that discovery is supposed to catch. The cost shows up later: in duplicate records, in a sync that silently stops working when a data format changes, in a failure nobody notices until the numbers on both sides stop matching. None of that is guaranteed by skipping discovery, but the odds shift a lot, and every one of those problems is cheaper to prevent during discovery than to debug after the integration is already in production.
Where We Help
We treat discovery and requirements gathering as one of the highest-leverage phases of an integration, not a formality before the real work starts. It isn't the only thing that decides whether an integration works. Build quality, testing and ongoing monitoring all matter too. But it's the phase most often skipped, and the one where a missed question is most likely to turn into a production problem months later. If you're planning a CMiC integration and the requirements conversation so far has stayed at the level of "these two systems need to talk to each other," that's worth a deeper conversation before anyone writes a line of integration code.
Comments