The senario here is that we are setting up our own ITSM, but the incidents created need to forwarded to customers ITSM
The customer ITSM is BMC remedy and ours is CA SDM
We will need to keep the tickets all in sync , so updates on customer side need to passed back to our side
Would this be done via SOI or a combination of different tools
I think more information is needed.
It wouldn't be common to run two completely different, fully featured ticketing systems and keep them completely in-sync.
Some general questions may help influence how this is implemented:
The natural response would be to use either Web Services or Email from one system to the other to Create and Update tickets. CA ITSM can easily do this at its end, and it is likely that BMC Remedy has something equivalent at its end.
But this is a case where the technical solution needs to support the business need I think.
Unless you sort that out up front, I can easily see that tickets raised in one system will update the other system, and then not be closed out. Or any number of other things that could go wrong. It certainly requires thinking about the questions above, if the proposal is to effectively merge two systems.
The other approach is for the two systems to be maintained independently. And the two user bases get the access rights to the other system. So the BMC Remedy users would have full access to BMC, but only sufficient rights to the ITSM system to do whatever they need (such as an Employee login) which gives them basic access to view tickets and add information. And the ITSM people would see the flip side. They would have full access to ITSM, and be granted similar view/basic update rights to BMC. The two systems would remain independent.
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/enIt 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:
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.Kind Regards...........Michael
the link provided in docops for download links to https://docops.ca.com/display/NIMSM/Latest+Build+of+CA+NIM
The download-link there ends on broadcom-octa-page.
Do you know another download-option?