It's all about the answers!

Ask a question

Shall I promote RTC?


Jirong Hu (1.5k9280256) | asked Nov 05 '13, 9:34 a.m.
 Hi All

With two clients, I am in a dilemma whether to promote the RTC in the organization or not. I've seen a couple of RTC sites but still with limited experience in running them for a long enough period.

I would like to know your experience with RTC in medium to large sites with hundreds of projects, comparing to CCCQBF.


Thanks in advance for your input. 
Jirong

Accepted answer


permanent link
Rolf Nelson (617159) | answered Nov 11 '13, 6:13 a.m.
JAZZ DEVELOPER
RTC and CC/CQ both have VERY large installed customer bases.  There should be no discussion or concern about any of them going away.  There are no plans to do so, period.  I am always amazed that people are willing to go out and buy scm or change management tools from companies with <40 employees in the entire company and then question if Rational with thousands of employees is going to continue to support highly successful products in the market.  As the product manager for RTC and formerly ClearCase I can assure you that thousands of major corporations run their business on these products.  RTC is also used by more than 100,000 IBM developers internally and more than 400,000 users and forms the core of just about any initiative inside Rational, including DevOps, Cloud computing, mobile development our Systems business/PLE and our System z development initiatives.

As for which solution RTC or CC/CQ to recommend to clients, we have made that decision easier for installed based customers by allowing them to use RTC and CC/CQ in flexible ways with flexible licensing terms so they don't need to know exactly how many licenses of each to plan for over time.  For new customers, they are often driven by things like an agile transformation, growth in distributed teams that require tighter collaboration or accelerating each phase of the development to build to deploy lifeycycle (DevOps) or driving quality and automated project status and less meetings.  These are just some of the areas where RTC continue to drive innovation.  RTC also forms the core of our CLM initiative where customers can have traceability across analysts, developers and testers while leveraging a common platform of services for authentication, security, dashboards, reporting, and process management.  If your customers are trying to make these kinds of steps forward then RTC and CLM are something to take a close look at.  The good news is that if you already have CC/CQ that you can incrementally add value with RTC to your existing environment at lower risk than if you tried to "rip and replace" as you would have to do with other vendors.  The choice is not which tools to use, but which tools add the most value to your customers needs and can I get their without having to throw out everything I know and rely on today.  RTC and CC/CQ  are designed to meet those needs.
Geoffrey Clemm selected this answer as the correct answer

Comments
Georg Kellner commented Nov 11 '13, 7:02 a.m.

Hi Rolf,
can IBM provide something like a check-list or feature comparsion between the mentioned tools?
Nothing would be easier than that to find out the best solution for customers/projects.
In some discussions I feel like being in a religious war about what is the "true" tool. ;-)
As long as both tools(sets) have their pros/cons, there is no "true" tool and I need an objective decision.


Geoffrey Clemm commented Nov 22 '13, 12:48 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

A checklist is of little or no benefit when comparing SCM systems.  If you are going to make the major internal investment required in introducing (or even harder, changing) SCM systems, the only sensible approach is to pick a product from a mature/reliable provider (where an "open source" tool has a "provider" ... the community building it), and try it out in your environment.   As Rolf points out, if you pick any of the Rational SCM technologies, Rational ensures that the Rational SCM technologies can smoothly co-exist in your environment, if you have groups with different SCM needs, or if your needs change over time.


Georg Kellner commented Nov 22 '13, 3:27 a.m.

Hi Geoffrey, there is a lot of benefit regarding a checklist. :-)
We have ClearCase and RTC SCM in place.
But for new projects we have to decide, which one is the preferred tool.
After ten years of ClearCase administration I know very exactly what can or can't be done with ClearCase.
But with RTC there isn't such an experience here and the features of RTC SCM are changing fast, so it is nearly impossible, to provide an objective decision.


Geoffrey Clemm commented Nov 23 '13, 3:04 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

I understand the desire to have a simple way to decide which SCM system to use, but my point is that a checklist would be a very poor way to guide such a decision.  The content on the checklist would be very misleading, since different systems solve the same use cases in very different ways, and the behavior of similar logical constructs is very different depending on your needs and usage.  You don't need 10 years of experience with each system to make such a decision (although it would help :-), but you need hands on experience with each candidate system in your own environment. 


Georg Kellner commented Nov 25 '13, 9:54 a.m.

I know finding the right SCM isn't easy at all. Maybe a check list isn't a usable utility or I took the wrong word.
Maybe a feature comparison list would also be possible as long as there are big differences between the provided Rational SCM tools.
There are "killer arguments" against both tools (CC, RTC SCM), based on the differences.
We had a project using JAVA with CC years ago. One famous sentence from the project members: "Refactoring is evil.". Refactoring with RTC SCM is easy.
We have/had several projects, where there isn't/wasn't a direct network connection. AFAIK RTC SCM can't do this job, CC MultiSite can do this.

Other difference(s) I figured out:
CC supports derived objects OOTB. It can be done also with RTC SCM, the Build Engine and the used make tools, if everything is configured fine.
Trigger support is done extensively by CC, but poorly supported by RTC SCM.
...
But I think it's not the job of the customer to figure out the differences, it's a job of the provider, so yours. ;-)
And after all the differences, we can discuss about the "real" SCM tasks or methodologies.


Geoffrey Clemm commented Nov 25 '13, 1:10 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

These are all good examples of why a checklist (or a feature comparison list) is not a useful evaluation mechanism.  Does RTC provide "multisite"?   No.   Does RTC provide support for many/most of the use cases for which multisite is used?   Yes.  So does RTC get a "yes" or a "no" for "multisite"?   Either answer is misleading.   It depends on what you are using multi-site for.   Similarly for the other features.

So what do you do if you cannot depend on a check list or feature list to give you the answer?   Bring the tool you are considering up in your environment, and spend a few days running your most common use cases through it.   That's where the provider can be of great help, giving you pointers on how to kick the tires.


N Z commented Nov 25 '13, 4:36 p.m.

 Yes, this is very important and can't be stressed enough.


Do not depend on what the sales and pre-sales people tell you, do not depend on the feature list, you will be in for disappointment!

showing 5 of 7 show 2 more comments

3 other answers



permanent link
Aradhya K (1.4k44345) | answered Nov 05 '13, 11:21 p.m.
JAZZ DEVELOPER
Similar to the response in the CC forum, if you have heavy investment on CCCQBF then you should continue to use them.
One of the major advantage of RTC is in the perspective of the complete ALM which spans from requirement to development and testing. You will be able to install and manage the ALM soultion better with the RTC. If you are looking for such a complete ALM solution and eventually want to move to continuous delivery model then RTC will be helpful a lot.
Other useful perspective of RTC is with respect to Planning. The RTC is a powerful agile planning tool. It also supports the Traditional or waterfall way of project execution as well.
Again the right thing would be to continue using the CCCQBF on existing projects and evaluate the RTC based on the new project requirements.

Comments
Georg Kellner commented Nov 11 '13, 2:59 a.m.

You can integrate the "old" tools with the new ones, to use the complete ALM workflow or just to use the planing feature.
CQ defects can be linked to RTC workitems, CC UCM activities can be represented by RTC workitems, changesets for base CC can be used with RTC workitems.


permanent link
N Z (3622026) | answered Nov 10 '13, 5:14 p.m.
 You should only promote it if it is in the interests of the organisations you are working for. As far as tools go, what is the direction they want to go in (or you think they should go in)? Irregardless of whether they have existing systems and data, it is always possible to move to another tool if there is a compelling argument.

Both CCCQBF and RTC have their pros/cons. What features are the organisations interested in? RTC is stronger in planning, but weaker in change management and scm. Operationally, managing RTC is more difficult, and in my experience, it is less stable (but not significant enough to be a real problem).

Having said that, the future seems to be RTC, although the Jazz Team make me a bit nervous. The upgrade process from 2-3 was a real disaster (are we going to be subject to something similar in the future?), they only introduced clustering in RTC 4 (should have been much earlier!), the RTC interfaces for scm are poor, they still talking about project move (going for about 3 years), and still don't seem to be close to a solution, whenever you talk to support, they rarely have the same, or even similar environments that large enterprises have. There have been, and still are many teething problems. CCCQBF on the other had is very mature, but for how long will it be actively supported by the vendor?

Comments
Georg Kellner commented Nov 11 '13, 3:14 a.m.

RTC is not able to replace CC/CQ and there is no plan to do so.
IBM has lots of customers with a product life-cycle of 30 years, so you can imagine how long the tools will be supported by IBM.

If I have a look at the mentioned features (nice update, easy project move ...) I'm in doubt, if RTC will survive the next 30 years. ;-)


permanent link
Georg Kellner (825375104) | answered Nov 11 '13, 6:40 a.m.
Hi Jirong,
there isn't any answer like Yes or no.
For planing features or ALM integrations RTC can and should be promoted, cause there is no functionality like this in CC/CQ.
Regarding Change- and ConfigurationManagement, which are part of RTC (SCM), be careful.

What are the requirements of the client in general?
Have they problems with the existing tools, which can be solved by RTC?
Do they use features, RTC can't provide?
Are there any certified processes/tools in the development process?
In which part can RTC make life easier?

A current example:
I've to setup a new project and we are discussing about configuration management and so on.
I had a talk with an IBM specialist, he said "Use CC UCM instead of RTC, cause RTC can't/won't do the job."
The job is: millions of files, tons of gigabyte, 300+ UCM components, an currently unknown amount of rootless components, and of course: rootless components of rootless components.
At least the rootless components aren't as well supported by RTC as by CC UCM.

If your client has a huge C/C++ based developing, using derived objects, everything is multisited over 10 sites, promoting RTC SCM is wasted time, but promoting RTC for planning can be a plus for the client.

If this client wants to switch from C/C++ to Java with a more centralized architecture of development toolset, RTC SCM can help to ease up this change.

So go out, have a detailed look for what does exist, what is planned for the future, and decide yourself, if or what do you want to promote. ;-)

greetings georg.

Your answer


Register or to post your answer.