Shall I promote RTC?
![](http://jazz.net/_images/myphoto/ac37cd0f817302f1db6c1f7282660abb.jpg)
Accepted answer
![](http://jazz.net/_images/myphoto/ac37cd0f817302f1db6c1f7282660abb.jpg)
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.
Comments
![](http://jazz.net/_images/myphoto/ffb0fe8299e5d83f7afe50ab98df6fec.jpg)
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.
![](http://jazz.net/_images/myphoto/a36d1dcfd3e1e1e00aeb18c860d1443d.jpg)
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.
![](http://jazz.net/_images/myphoto/ffb0fe8299e5d83f7afe50ab98df6fec.jpg)
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.
![](http://jazz.net/_images/myphoto/a36d1dcfd3e1e1e00aeb18c860d1443d.jpg)
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.
![](http://jazz.net/_images/myphoto/ffb0fe8299e5d83f7afe50ab98df6fec.jpg)
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.
![](http://jazz.net/_images/myphoto/a36d1dcfd3e1e1e00aeb18c860d1443d.jpg)
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.
![](http://jazz.net/_images/myphoto/05be676674edc59ba0682f80ea6b01e0.jpg)
Yes, this is very important and can't be stressed enough.
3 other answers
![](http://jazz.net/_images/myphoto/ac37cd0f817302f1db6c1f7282660abb.jpg)
![](http://jazz.net/_images/myphoto/ac37cd0f817302f1db6c1f7282660abb.jpg)
Comments
![](http://jazz.net/_images/myphoto/ffb0fe8299e5d83f7afe50ab98df6fec.jpg)
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. ;-)
![](http://jazz.net/_images/myphoto/ac37cd0f817302f1db6c1f7282660abb.jpg)
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.