Are there suggestions on tearing apart JTS and registered applications ?
I have read that once registered to JTS an application should not be un-registered/re-registered. However, we are facing certain scenarios relating to my company's Intellectual Property (IP) agreements that requires that we somehow share/move product development data out of our systems.
Our CLM environment is distributed, but rather tightly coupled as we have 30+ RTC/QM repositories registered amongst 6 JTS. We followed the recommendation when upgrading from V2 to V3 to have "as few JTS as possible". At the time we were spending a good deal of time doing security compliance work against middle-ware and databases and to have created JTS per existing application would have tripled the number of databases and applications.
As an example, one IP agreement has data in two CCM repositories that share a JTS. One thought I'm having is:
Scenario 1
- Create "duplicate" JTS, Warehouse and CCM databases
- rename the JTS and 2 CCM and configure to use the duplicated databases
- remove all applications and friends except the CCM in question
- Give over the "replica" to the IP partner
- it will be very large
- will likely give data that does not belong to IP partner
-
user registry likely to be incompatable
Another idea [ in our own or IP partner environment ]
Scenario 2
- create a new JTS/CCM ( combined into same J2EE )
- connect CCM to existing CCM's as Friends to allow remote delivery from the existing to new
-
give over the application data to the IP partner, if created in our own environment
- Only the data that should go will be present
- smaller footprint
-
looses historical data from data warehouse
-
looses existing project dashboards
What about in terms of making our repositories more self-contained (think Scenario 1) ? I.e. Create new JTS for each CCM from the current JTS database do the rename of the JTS. This would include duplicating DW and probably DCC for each new JTS =:-o
One answer
I have been involved with many reorganizations of Jazz Applications that include merging and splitting of data. As you mentioned in your scenarios, there are pros and cons to each approach. Knowing which approach to take from this post is difficult because the business goals are not defined.
Comments
I was contacted earlier by a SWAT engineer who offered to discuss. You said "simplifies user maintenance" - is that in the sense of the jazz users and not the users who do the maintenance ?
It's rather hard to coordinate an outage to upgrade jts and all its registered applications in separate repositories.
