Any system engineer, architect, and integrator can attest to this: achieving interoperability is hard, and integrations are usually not straightforward.
We can chalk this up to a variety of reasons, but here are my personal favorites:
Lack of documentation. And when there is documentation, it often contains errors. ICDs that are woefully incomplete? Check. Visio diagrams that were never updated to reflect the final state of the system? Check. References to system diagrams and other documents that are not available to you? Check. Check. Check.
"The system cannot be changed!" How often have you heard that? Having to treat each subsystem as a black box isn't an impossible task, but it can surely complicate things.
"I'm afraid it's secret." Everything about one or more of the systems is labeled "Proprietary" by the company that designed it. They won't share any details because it's all "classified" or "confidential." They may even say, "Sure, you might have the proper clearance, but it's only available on a need-to-know basis. I'll put in a request. It could take a while." Yeah, right.
These are all things that are outside of your control; all you can do is come into the project prepared with a toolbox of ways to approach these challenges. When I am in one of these situations, I have a strategy that works: focus on the data architecture.
What does that mean? I'll tell you! Watch this eLearning video, Data Modeling for Interoperability. You'll learn about requirements, what a system-of-systems is and how it's different than other systems, and how to leverage data modeling so you can be strategic – and successful! – in architecting and building your systems.