Shall I promote RTC?
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.
I've asked the same questions in ClearCase forum: https://www.ibm.com/developerworks/community/forums/html/topic?id=0044ef78-d289-4cca-a313-532f2088a033#ed6e5c2f-3a5a-4b34-bb81-038199bee3ee
Thanks in advance for your input.
Jirong
|
Accepted answer
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,
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. :-)
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.
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.
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
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.
|
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.
|
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
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.