Can RTC 3 replace CC/CQ/BF?

Unfortunately, there is no real "answer". Each of these products do
various things very differently. Whether those differences matter to a
particular organization, team, or individual, depends greatly on the
preferences, needs, and current state of that class of users.

It's like trying to answer whether to use C++, Java, Perl, etc, or some
combination. Sometimes the uniformity of using just one language
outweighs the lack of the features provided by another language.
Sometimes a mixture is best.

So each tool has a set of benefits, outlined in the published material
for that tool. For example, ClearCase has dynamic views and
multi-site, while RTC has change-set based accept/deliver and great WAN
performance. You will want to map those benefits against the needs of
your user-base. Because we believe that a combination of tools is
needed for many organizations, we have invested heavily in connectors
(synchronizers, bridges, importers) between our tools, and via OSLC,
opened up those tools for integrations with arbitrary proprietary and
third-party tools.

Cheers,
Geoff

On 11/17/2011 9:08 AM, hujirong wrote:

Hi

Currently we have ClearCase, ClearQuest, BuildForge, RTC and other
vendor tools all over the place, and now we are standardizing
enterprise tooling. There are a couple of questions like this:

1. Why shall we switch from CCCQBF to RTC?

2. Can RTC 3 completely replace CCCQBF? If not in RTC 3, do we know
when can RTC offer the same functionality as CCCQBF? My feel right
now is that RTC can almost replace CC, but lack of flexibility in CQ
customization and some advanced features in BF. Can someone give me a
list of things we can do in CQ and BF while not in RTC?

3. Can RTC/RSA replace VisualStudio.net and MS Team Foundation Server
for .Net development? If not, what's missing in RTC or why VS.net and
TFS is better?

Thanks
Jirong

But isn't IBM's plan to replace CCCQBF with RTC, at least in future? People keep on asking this question, how do we answer?

What's IBM's plan or vision? The customer need to know this. Are they going to co-exist for a long time?

Thanks
Jirong

Now that question is easy (:-).

We (and I am speaking for IBM/Rational now, and not just my personal
opinion) have no plans to replace CC/CQ/BF with RTC. In particular,
there are capabilities in CC that will never be provided by RTC (config
specs, dynamic views, and all that entails being a prime example).
There are a large number of customers for whom ClearCase is now, and for
the forseeable future, will continue to be, the best solution, and
IBM/Rational is committed to support them in their use of ClearCase.

With that said, we also expect the majority of CC/CQ/BF customers to
enhance their existing environment CC/CQ/BF environment with RTC,
because RTC provides extremely valuable capabilities not provided by
CC/CQ/BF. A primary example is task management and planning. That is
why we have invested so heavily in integrations between CC/CQ and RTC
work items, to ensure that CC/CQ customers get a first class integration
with work items and planning (and internally, RTC work items and
planning are used by the CC/CQ development teams, while they continue to
use CC for SCM, and CQ for change request management).

Once you have enhanced your CC/CQ/BF environment with RTC, all teams
will be integrated from a planning and task management perspective,
through the common use of RTC for task management and planning.
Individual teams will also have a choice to start using RTC/SCM instead
of ClearCase for SCM, and RTC work items instead of CQ for change
request management. We ensure that teams that have made different
choices can interoperate with each other, through the various connectors
(bridges and synchronizers) between CC/CQ and RTC. Over time, you may
end up with a single SCM choice for all your teams, but for many
organizations, you will see parts of the organization selecting RTC/SCM
as their SCM of choice, while others selecting ClearCase as their SCM of
choice. One of the things I personally do is help teams within an
organization make that choice.

Cheers,
Geoff


On 11/17/2011 3:38 PM, hujirong wrote:

But isn't IBM's plan to replace CCCQBF with RTC, at least in future?
People keep on asking this question, how do we answer?

What's IBM's plan or vision? The customer need to know this. Are they
going to co-exist for a long time?

Thanks
Jirong

Oh man.

First of all, thank you very much for your detailed explanation, and all your help in the past.

Let me introduce myself first. I am an independent consultant specialised in SCM and Testing areas using IBM Rational tools, only Rational tools, for 10 years. A lot of time I work for Rational Canada to implement these tools for their big clients.

My interpretation of your above is: RTC is an add-on and supplement to the existing Ratioanl's CCCQBF SCM solution, to enhance/complete the offering, and give customers more choices. Is this IBM's position?

From RTC's similarity to VS and MS Team Foundation, I initially felt IBM copied (probably this word is too strong, but it's a totally right thing and I like it) the idea from MS, and I thought this tool was targeting the small and media companies for them CCCQBF is too heavy, or organizations who's embracing agile development process. I totally agree with this idea, that's a new business area.

And I thought in a long run, IBM is going to enhance RTC to make it able to completely replace CCCQBF, since they are 20 years old, too many problems you can't change, and probably no longer suitable for today's development.

CCCQBF is already too complicated for most of organization (OK, the problem is not the tool maybe, it's they can't find or afford or don't want to pay a proper person to help them implement in a right way). So they are hoping RTC will be easier.

My client is trying to standardize all tools at the enterprise level, consolidating 50+ tools in use today. In SCM, we have CCCQBF, RTC, and all other vendors' tools such as SVN, PVCS, CVS, etc. The major concern is why we need RTC since we already have CCCQBF. We are consider ourself as medium (in size) to large (in complexity) traditional development shop, has no Agile at all.

To me, I need a clear message on how IBM position RTC. I was hoping:

1. It's a definite choice for small and media company. Use RTC instead of CCCQBF for this level of companies.

2. It's a definite choice for Agile development. CCCQBF wasn't designed for Agile.

3. For large organizations, RTC doesn't have all the functionality/capability to replace CCCQBF immediately, but IBM will continue to enhance RTC to make it happen. At this moment, large organizations can use CCCQBF for departments using heavier process and RTC for Agile development.

Personally, I don't want to have RTC running on top of CCCQBF, just to have that task management or whatever additional features. It will be too complicated. I can't even convince myself why we need that. No need to say tell the client to pay that additional huge amount of licenses fees.

Thanks again.
Jirong

Comments below in-line.

Warning: Long posting (:-)

On 11/18/2011 2:08 PM, hujirong wrote:

My interpretation of your above is: RTC is an add-on and supplement to
the existing Ratioanl's CCCQBF SCM solution, to enhance/complete the
offering, and give customers more choices. Is this IBM's position?

Depends on what perspective you are coming from.
From a marketplace perspective, yes, that is exactly right.
From an existing individual CC/CQ/BF customer's perspective, that depends.

- If they require unique CC functionality (like dynamic views) then yes,
RTC is an add-on and supplement. Minimally, RTC adds task management
and planning. And if there are some teams that do not require that
unique CC functionality (e.g. teams that have, or are thinking of
switching to some alternative SCM anyway), then they definitely should
look at RTC as the alternative, both because it is likely to be better
than any of the other alternatives, and because they will be able to
interoperate with the teams that continue to use ClearCase.

- If they are a happy CC customer, then whether they switch some of
teams over or not depends on whether the benefit from unique RTC-SCM
functionality outweighs the migration cost of going from CC to another
system.

- If they are an unhappy CC customer, then they should look at RTC as a
replacement. RTC was designed to do all the things that make CC
customers unhappy ... if we could have architected both into one
product, we would have. The fact is that the only way to make CC
simpler/faster is to give up certain key CC features. So if you don't
need those features, switching to RTC-SCM is a win ... if you do need
them, then ClearCase is (and will continue to be) the only SCM system
that provides them.

From RTC's similarity to VS and MS Team Foundation, I initially felt
IBM copied (probably this word is too strong, but it's a totally
right thing and I like it) the idea from MS.

To find the roots of RTC-SCM, you have to go back way earlier than TFS.
In particular, start with The Asgard System
(http://www.springerlink.com/content/w4763w262062h6u4/ ...
unfortunately, it appears you have to pay to download the article, if
anybody wants a copy, let me know, and I'll dig through my archives for
a pre-publication version). At Bellcore, we implemented the Asgard
System as a layer above ClearCase, and when I joined Atria in 1996, we
implemented a prototype of Asgard as a config-spec extension. But we
concluded that to really support change-set based SCM, we needed a new
SCM core, so we built the Nucor system (by this time, Rational had
acquired Atria). Although we had Nucor up and running, after being
acquired by IBM, we concluded that we needed more than an SCM system ...
we needed a system that integrated SCM, change-request management, task
management, build management, planning, and that was extensible to
handle requirements management, test management, and more. The RTC SCM
component functionally is very similar to Nucor (actually, it is a
simplification of Nucor ... no hierarchical or nested components ... at
least, not yet :-). During this process we did check out MS TFS, but it
couldn't do what Asgard did, much less what Nucor did or RTC-SCM does,
so it had no effect on our design.

and I thought this tool
was targeting the small and media companies for them CCCQBF is too
heavy, or organizations who's embracing agile development process. I
totally agree with this idea, that's a new business area.

Yes, that is all accurate. We weren't trying to replace CC ... we
wanted to provide an integrated ALM environment that could be used with
CC/CQ, and that provided an alternative SCM for teams for which CC was
overkill.

And I thought in a long run, IBM is going to enhance RTC to make it
able to completely replace CCCQBF, since they are 20 years old, too
many problems you can't change, and probably no longer suitable for
today's development.

In the area of SCM, after 20 years of experience, we have concluded that
you cannot have an SCM system like ClearCase that provides the power of
config specs and the magic of dynamic views, while also having it be
simple and fast enough to outperform tools like Perforce and GIT that
provide none of the advanced capabilities of ClearCase. But in addition
to simplicity and speed, although you cannot provide all of the
ClearCase magic without paying a performance/complexity cost, you can
still provide magic (suspend, resume, flexible deliver targets, and in
RTC-4.0, the "where have my changes flown" function, to name a few).

CCCQBF is already too complicated for most of organization (OK, the
problem is not the tool maybe, it's they can't find or afford or
don't want to pay a proper person to help them implement in a right
way). So they are hoping RTC will be easier.

And that is exactly right. If you aren't using CC/CQ/BF currently, you
should first give RTC a trial ... if you need more, you can always
select (or later add) CC, CQ, or BF to your RTC environment. If you are
already using CC/CQ/BF, see the comments above.

My client is trying to standardize all tools at the enterprise level,
consolidating 50+ tools in use today. In SCM, we have CCCQBF, RTC,
and all other vendors' tools such as SVN, PVCS, CVS, etc. The major
concern is why we need RTC since we already have CCCQBF. We are
consider ourself as medium (in size) to large (in complexity)
traditional development shop, has no Agile at all.

You need RTC to replace SVN, PVCS, CVS, etc. (that's an easy transition
.... RTC is as simple or simpler to use than those other tools, while
still being more powerful and scalable). That is not something you can
do with just CCCQBF. Now you are down to just CCCQBF and RTC. Then
whether some or all of your teams want to switch from CC, CQ, or BF to
the corresponding component of RTC, will depend on whether they need the
advanced functionality of those tools.

To me, I need a clear message on how IBM position RTC. I was hoping:

1. It's a definite choice for small and medium company. Use RTC instead
of CCCQBF for this level of companies.

Yes, that is almost always right, unless the company has some very
advanced SCM needs that require dynamic views.

2. It's a definite choice for Agile development. CCCQBF wasn't
designed for Agile.

"Agile" isn't a determining factor. What matters is whether you need
the unique functionality of CC, CQ, or BF. If you don't, then RTC is
your best choice. And you may want just one of CC, CQ, or BF to
complement what RTC provides ... it's not an all-or-nothing choice.

3. For large organizations, RTC doesn't have all the
functionality/capability to replace CCCQBF immediately, but IBM will
continue to enhance RTC to make it happen. At this moment, large
organizations can use CCCQBF for departments using heavier process
and RTC for Agile development.

To be agile, you need the task management, planning, and dashboarding
capabilities of RTC. Conversely, if you want a heavier process, you
still want RTC for task management and planning (you can make RTC
process as lightweight or heavyweight as you want). Whether you use CC
depends on your SCM needs, not on whether you are agile (all of Rational
development has switched to agile, including the groups that use CC for
SCM, such as the CC and CQ teams).

RTC will continue to be enhanced in all directions desired by RTC
customers, as long as that does not degrade the performance and
simplicity currently provided by RTC.

Personally, I don't want to have RTC running on top of CCCQBF, just to
have that task management or whatever additional features. It will be
too complicated. I can't even convince myself why we need that. No
need to say tell the client to pay that additional huge amount of
licenses fees.

RTC doesn't run on top of CCCQBF ... it runs next to them. If you don't
need any of CC, CQ, or BF, then you can start with (or evolve to) a pure
RTC installation. But minimally, you can stop trying to glue together
dozens of low end and open source tools, to get the speed and simplicity
that is all that some of your teams require.

Cheers,
Geoff