Connecting different products on different JTS's
Many people use a single JTS with multiple CLM products (RTC/RRC/RQM/etc). Some people have each product on their own JTS (RTC on one ccm/jts pair, another RTC on another ccm/jts pair, RRC on a rm/jts pair).
If you use the second option (each instance has its own JTS), can you still have the level of communication you get when you use the first option - assuming there are the correct friend relationships set up. This incudes have cross-product links (eg; requirement to work item links, in fact a CLM project with each product (rtc/rrc/rqm) being on a different jts)
I am trying to work out the pros and cons of each option.
thanks
anthony
If you use the second option (each instance has its own JTS), can you still have the level of communication you get when you use the first option - assuming there are the correct friend relationships set up. This incudes have cross-product links (eg; requirement to work item links, in fact a CLM project with each product (rtc/rrc/rqm) being on a different jts)
I am trying to work out the pros and cons of each option.
thanks
anthony
Comments
sam detweiler
Dec 09 '13, 8:04 p.m.no. you cannot have effective links between different JTS applications.
(nor CCM's in the SAME JTS)
Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Dec 10 '13, 4:08 a.m.Hi Antony, I have looked into this from a JTS and multiple CCM perspective. From what I can tell this should be pretty similar to multiple JTS/CCM's with friends relationships.
As long as your projects are pretty much self contained, I can't see a lot of issues. One is work allocation in both scenarios. There is no global work allocation. You have to manage users on all ccm's and make sure across all ccm's the alocation is below 100%. Tedious.
If you manage the project relationships, work item linking as well as other linkages should work. There might be dialogs that don't allow to pick items from other repositories. I found at least one in SCM.
If you go multiple CCM, the main caveat is, sharing SCM across repositories, which automatically becomes distributed SCM. So there is additional effort in integrating changes across repository borders. I have not looked into all use cases and all tools however.