It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,875
×4,713
×4,316

question asked: Mar 13 '17, 3:05 p.m.
question was seen: 2,547 times
last updated: Mar 09 '20, 5:11 a.m.

Related questions

Are there suggestions on tearing apart JTS and registered applications ?

0
Kevin Ramer (4.5k●9●186●201) | asked Mar 13 '17, 3:05 p.m.
edited Mar 09 '20, 5:11 a.m. by Ralph Schoon (63.5k●3●36●46)

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

0
permanent link
Kirk Woods (101●7●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).

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.