In the diagram above, there are three specs: 

• ERP-1 - a System Interface implemented in System A, and built and maintained by the people who look after System A. This system interface is responsible for reacting to events generated inside System A (e.g. business events, batch job timers, user actions, etc.), extracting data from the private database of System A, serialising this data into a message of a specified format, and then sending it to an external system - in this case the SAP Integration Suite middleware. 
• ERP-2 - a System Interface implemented in System B, and developed using code and frameworks relevant to System B, by the people who do this kind of work in System B. This system interface is responsible for receiving messages and data from an external system, to validate the data to ensure it is correct and authorized, to perform any processing or enrichment necessary to ensure system correctness, and to then store the data inside the private database of System B. 
• ERP-3 - an Integration Process which connects ERP-1 and ERP-2. It is invoked by ERP-1, then transforms the data provided by it into the format expected by ERP-2. It might also perform enrichment along the way, or routing to other receivers. It too is implemented and maintained by a different team using a different technology stack. 

It is not enough to write a single spec for "System A to System B integration". The reality of the built code is that code in System A, System B, and the middleware is quite distinct and separate from each other, and only loosely coupled via defined touchpoints. The specs must reflect this reality and not be a "muddle" without clear separation of responsibility of the various systems and actors in the design. 

If a System Interface is standard, out-of-the-box, and not being modified, then a spec can be omitted. The spec for the Integration Process should instead reference the relevant API documentation and specifications provided by the vendor. 

If an Integration Process is based on vendor-delivered content (e.g. an IFlow delivered by SAP via the SAP Business Accelerator Hub), then only a simple spec is necessary. This spec should not reverse-engineer all of the implementation details but describe the overall design, and focus on the information needed to support and operate the integration (e.g. monitoring, error handling, volumetrics, etc.)