Are there suggestions on tearing apart JTS and registered applications ?

Kevin Ramer (4.5k●6●175●196) | asked Mar 13 '17, 3:05 p.m.
edited Mar 09 '20, 5:11 a.m. by Ralph Schoon (62.0k●3●36●43)

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

This suffers in that

it will be very large
will likely give data that does not belong to IP partner
user registry likely to be incompatable

Pro: less work regarding work items; would have data warehouse

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

Pros

Only the data that should go will be present
smaller footprint

Con

looses historical data from data warehouse
looses existing project dashboards

Evironment Declutter
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

Thanks in advance

One answer

Most liked answers ↑|Newest answers|Oldest answers

permanent link

Kirk Woods (91●5●8) | answered Mar 06 '20, 3:57 p.m.

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.

It sounds like you have at least one business partner that you want to isolate from some data. This can be done without having a separate JTS. I am a big fan of having as few JTS servers as possible because it simplifies user maintenance. But performance also has to be a consideration, so it is important to understand the full environment.

You can also have multiple data warehouses and report servers that are designed for a particular user base

I would recommend contacting IBM Watson IOT Expert Labs (soon to be IBM Cognitive Applications Expert Labs) for services; we have many tools and years of expertise to design and develop a solution that will meet your business needs.

Comments

Kevin Ramer commented Mar 06 '20, 4:18 p.m.

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.

Kirk Woods commented Mar 06 '20, 4:47 p.m.

That was in terms of the adminstrators who do user maintenance. I like to minimize system administration as much as possible. If the same users are in multiple JTS repositories, it can be painful to get new users in the right repositories and remove those that leave, not to mention the assignment/management of licenses.

Upgrades can be painful, but fortunately you can upgrade JTS and then upgrade the other applications on a rollout schedule (at least most of the time).

It's all about the answers!

Related questions

Are there suggestions on tearing apart JTS and registered applications ?

One answer

Your answer