Some general thougts:
It's a common approach to integrate software products.
Especially in the ITSM world, where we see a growing independency of ITSM Process responsibility and fulfillment responsibility.
Several reasons can lead to the situation that a Service Requester has it own ITSM system and the Service Provider is working in a different one.
The only common thing is the process. That makes it necessary that the two independent systems can share a common process.
Each organization can continue working in there well known system with their well known processes.
The interface inbetween not only needs to be able to exchange information, but also needs to be able to map process related dependencies(lets say the incident process) to a common process, agreed with the partner.
A quite good example here is the SAP Solution Manager Incident SOAP Webservice implementation, which not only provides the ability to exchange incident data, but also defines a common simple incident process.
Here, each system needs to map its own process to the common process defined by the interface.
Of course, beside these very general considerations, as Kyle already mentioned, there are a lot of details, which must be discussed and defined.
And at the end, there is the technical challenge as well. SDM has some weaknesses, when it comes to outbound communication. Therefore the common approach is to use Process Automation for these kind of tasks.
Process Automation can be triggered by SDM tickets, to do mostly any kind of activity.
But, unfortunately, also here, things are not simple. The SDM/Process Automation side needs to learn, how to talk to BMC, and BMC needs to learn, how to talk to SDM.
And of course, learning how to use a foreign API in a system conform manner, is often a hard way to go.
I also want to point you to CA Normalized Integration Management for Service Management (NIM-SM): https://docops.ca.com/ca-normalized-integration-management-for-service-management/3.2/en
It might be intersting and helpful for your approach.
This tool provides a commmon ITSM related REST based API, and is able to map these API calls to many different vendor specific API's.
BMC 8.1, 9.1 is already supported as well as SDM. That would provide the a ability, that both systems would talk and listen to the same API( the common interface approach), while NIM-SM would do the system specific part.
If I would need to start from scratch with such a project, I would try to convince everyone to go into this direction.
It would have several advantages:
Both system would talk the same API language , which makes it much more easy to monitor and to support operating.
Once a system is able to talk to NIM-SM, it is just a NIM-SM configuration to be able to talk to a different NIM-SM supported system, like:
- SAP Solution Manager
- HP Service Manager
- Salesforce Service Cloud
See : https://docops.ca.com/ca-normalized-integration-management-for-service-management/3.2/en/overview/service-management-products-and-supported-versions
Hope that helps a bit.