CA Service Management

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

Hello Dougal,

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:

• Why have two systems, rather than one?
• Is there going to be one "source of truth"?
• What types of information needs to be shared?
• What information will stay local to each system?
• Who is going to use the information?
• Do they need full access to the other system, partial access, or only reporting?
• What is the process flow going to look like, from Open to Close, from both systems points of view?
• Who controls Contacts, Configuration Items, Attachments, Knowledge Documents and other supporting information?

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.

Thanks, Kyle_R.

Hi Dougal.

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
• ServiceAide
• ServiceNow
• 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.
Kind Regards
...........Michael

Hi 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?

Regards,

Peter