Recently I have been getting a lot of email requests from people asking if they can do something “non-standard” with Jazz.  I am going to answer your questions, but I am also gong to tell you WHY you get the answers that you do from our experts.  Here is a sanitized example of a recent email:

Hi Daniel
My name is John Doe. I saw that you wrote an article on the CLM deployment wiki 
on Jazz.net. I have a question that you may be able to help with.
A customer is deploying CLM 5.0 with Oracle and they have a standard practice 
of creating a single "temp" tablespace for a set of applications like our CLM 
suite. Will everything in the CLM suite function correctly if all four CLM apps 
use the same "temp" tablespace or is it necessary for each app to have its own 
temp tablespace as it is described in our documentation?
John Doe

Just because you might be in a rush, I will give you the answer right away.  The answer is,

"Just install it the way it is supposed to be installed.
You CANNOT have all of the CLM apps use the same tablespace."

Now let me tell you WHY you get this answer (and some other seemingly unsatisfactory answers) from our support teams and subject matter experts.

Basic Steps and Stock Answers

I can fire off this answer almost immediately because I know that we have never tested CLM in a configuration where all of the CLM applications share the same “temp” tablespace.  We have enough of a challenge in fully testing all of the various topology permutations, without looking for edge cases that customers will rarely attempt to deploy.  This leads us to the first basic law of software support

Software Support Rule 1: If we did not explicitly test the scenario in question, then we don’t support it.

We’re not trying to be mean, and we’re not trying to make your life difficult.  We just want to save you the time/frustration/energy of trying an approach, or planning on some approach, that just will not work.  So often when confronted with questions like this one, we will rely on Software Support Rule 1, and tell you that you cannot do these types of things.

Now let’s dig down a level.  I honestly don’t know if this would work from a technical perspective, but I know enough about Jazz architecture to make some technical assumptions, and do a little bit of thought on why this still may not be a good idea (even if it might be technically possible).

If I assume that the customer in question has installed the minimum of CLM products (say JTS, CM, QM, and RM), then I have four different applications all sharing the same “temp” tablespace.  Having all of these applications making transactions into this tablespace will cause some requests to this tablespace to queue up, when load becomes heavier.  This will impact the end user performance, as requests are not answered in a timely manner.  Which leads us to the second basic law of software support:

Software Support Rule 2: If it could adversely impact performance, then it is a bad idea

There are some other things that come into play here.  One of the things that we constantly worry about when architecting Jazz deployments is the ability to easily move and administer Jazz resources.  What would happen to this shared temp table during an upgrade?  The upgrade process will often manipulate data in the repositories, if the structure of the data schema has changed.  Having a shared temp tablespace could impact this.

What if I added a second CM (or RM or QM) instance to my deployment?  Would two different instances of the same application still be able to share the “temp” tablespace?  In this case, I can envision where a CM instance might ignore data in the temp tablespace that was in reference to another CLM application, but I doubt that we would have made provisions to validate the identity of  a particular CM instance associated with any of the temp data.

Software Support Rule 3: If it adversely impacts future scalability, then it is a bad idea

So given all of this information, it is much too risky to attempt something like this.  There are potential issues at a variety of different levels.  All of this thinking goes into the simply stated reply of,

Just install it the way it is supposed to be installed.  
You CANNOT have all of the CLM apps use the same tablespace.

Now What Do I Do?

So that gives us our answer, but it doesn’t answer the question of how we can move forward with this particular installation.  Here are some things to keep in mind as you determine which course to take:

  • Perhaps the DBA’s don’t understand the Jazz architecture.  They might think that this would be a more efficient use of resources, and easier to maintain.  In the case of the Jazz CLM deployment, it will not be.
  • “Standards” get broken all of the time.  Often you merely need to provide a good technical justification for why you cannot adhere to the standard.  Keep in mind the end goal here – providing a more efficient, transparent, and cohesive software development environment.  The goal is not to make the lives of DBA’s and Systems Administrators easier.  We DO want to make their jobs easier, but it is not our primary goal.

Remember that any architecture is a series of tradeoffs.  While we want to conform to existing norms and standards as much as possible, it is not always feasible.  The key here is to make sure that any Jazz CLM solution deployment has a stable and supported architecture, which balances the needs of the software development teams that use the solution.

Advertisements