Some time ago I wrote this blog and posted it on my companys internal network. Im posting it here again in case others might find it helpful.
-Roman Smirak, Tieto

Recently Ive been asked at Tieto to compare Rational Team Concert (RTC) versus cheap or open-source alternative - an integration of Atlassians Jira, Subversion and one of popular building applications like CruiseControl, Maven or Hudson.

And the interest grows; on both sides: about RTC as well as the further. Therefore I decided to write a blog entry and it will be rather open and alive so further experiences and different opinions can be incorporated.

I used to use Bugzilla and CVS and Ant several years ago. And it was pretty good (especially when I have experienced software development without any versioning repository or defect tracker). Then we switched from Bugzilla + CVS to Jira and SVN and CruiseControl. And it was cool. Better usability, better integration, new features and extensibility. Cool.

We decided to pilot Jazz 1.5 year ago. And it is the next cool thing; I should rather say: mega-cool thing. When I saw Jazz for the first time (it was a demo recorded at EclipseCon 2007) I applauded: finally! This entry reflects my personal experience and opinion.

RTC disadvantages
Lets start with disadvantages first; it is shorter list and it is easier to get it finished early. And all of them are somehow doubtable so I would call them possible disadvantages.
As you guess, first and foremost, RTC 1.0 has been released recently, we cannot use it free of charge anymore and the license is pretty expensive (it is actually comparable with ClearCase license). Well, no surprise, it is IBM product, right. On the other hand, Jira is the commercial product as well and TCO (Total Cost of Ownership) is never $0 or less. You either pay time to get experienced, configure and maintain, HW/OS/DB cost, integration with other systems in use (is it even possible?), or you pay for a service of the original inventor. Although I cannot provide certain numbers you can consider a list of advantages below as return on investment of RTC.

Second possible disadvantage, all the tools mentioned (Jira, SVN, CruiseControl/Maven/Hudson) are pretty stable products and widely used; therefore it is rather easy to find people experienced with the tools. You can also find quite many plug-ins and other products based on Jira or CruiseControl (on the other hand, be careful: it is a general problem of the open-source one plug-in might be very stable and well supported by the community, other may lead to a disaster). As we have been using milestone builds (early adopters of not released yet functionality) we experienced defects to be reported back to RTC team. However, RTC has been already used by many pilots all over the world and the Jazz community is pretty active and strong. No surprise then that thanks to the iterative approach Jazz team released very mature, function rich and stable version 1.0 (how many products can say the same?) If you have any problem just go and visit a forum at http://jazz.net and you get pretty quick and accurate help from the team itself (if you calculate US Europe time-difference) and yet again, how many (paid) support/warranty services can say the same?

RTC advantages
I will structure the chapter Advantages by feature. Although RTC includes many nice to have features I will focus on those I consider having rather crucial impact on our way of working; those I believe are worth considering.

Advantage #1: Agile planning and resource management
Jira is unofficially a successor of Bugzilla; it means a defect tracking is central concept there (Jira sees an abstract work entity as an issue good friend of mine recently asked: what is the social impact then if your team adopts a concept Everything is an issue? :-) The whole UI interface has been designed for a single developer/user submitting/fixing an issue. What if we are Agile? What if we have adopted collective planning practice (e.g. suggested by Scrum)? Lets assume we have a team of 7 developers having iteration planning meeting; to resolve/plan team tasks/defects/features they have to go developer by developer, task by tasks and resolve or (re-plan) it. No team view. No iteration. No notes in context. You have to create additional (separated from task DB!) Microsoft Word document or Wiki page to persist information like: What are the teams objectives? What are risks? How to evaluate we are done? What is our iteration test strategy?

Moreover, you dont get instant information about a quality of your planning: do we deliver on time or somebody is overloaded? Re-planning needed? Plus Jira doesnt include Resource management, i.e. you have to introduce additional tool: either Microsoft Project or Microsoft Excel (as I have seen in practice), however, yet again, you get scattered data sources and that causes pain and consumes additional time to get it all in sync. In fact, that is often source of problems: for example (as recently experienced), a team didnt include developers holiday and they noticed as the developer left the team: OK, nobody can simply absorb his tasks - we cannot finish on time.

RTC supports Agile planning by introducing a team view - actually Team first is the fundamental principle Jazz follows. I can get instant overall cross-team information. RTC includes resource management, i.e. every developer manages information about his/her availability: working week, holidays, time-zone. Thanks to that you can see on-line information about quality of your planning: who needs help due to heavy load and who can help him/her therefore the team can win and finish iteration on time.

https://jazz.net/learn/content/docs/iteration-planning/bitmaps/plan_editor1.png
Figure 1: RTC Iteration Plan

Iteration and Iteration plan is first class citizen in RTC. It has a starting date and an end date. Iterations can be grouped under a phase (we follow RUP approach). An overview page of the iteration plan contains all relevant information mentioned above: Objectives, Risks, Evaluation criteria, Follow-ups. You can add pages like Test plan, for instance. You dont need any separate Microsoft Word document.

RTC provides excellent usability; during your iteration planning you simply drag from your back-log (another Eclipse view) and drop it to the current plan. Even if you upgrade your Jira with GreenHopper plugin it is still far from RTC Eclipse UI based usability. Try it and calculate number of clicks. Try following scenarios with Jira: Super-task (collecting several sub-tasks) reassignment to another iteration/version; Resolving a task requires several clicks and web pages to be downloaded. I can guarantee you will use the scenarios on daily basis; on daily basis every millisecond of an overhead counts.

Advantage #2: Integrated SCM
As already mentioned, we used CVS several years ago - a simple but powerful concept. And we moved to Subversion (or SVN) later: better latency, better handling of binary files, lovely concept of a revision number (we stopped doing tags - we just stored revision number to each build we created magic!)

When we moved to Jazz one year ago I was confused; no operation as it used to be, no term like commit or update, new terms like deliver and so on. Stop. New terminology or actions shouldn't be any showstopper - that would be silly; that is called the progress, isn't it?

Therefore I started thinking (wow!); and I realized the new power: A concept of change-sets, flows, my workspace at a repository side, private build and the integration.

Let me explain the benefit by comparing with common story with SVN/CVS where you commit as soon as you think your code is "cooked" enough to be checked in the repository. And you might run your build to get it continuously integrated, right. And you might get surprised by failure of the build since you have forgotten to integrate the latest change of your colleague or you have simply forgotten to comment your changes or ... There are myriads of reasons why you need to make a small fix and check in again... Run the build and... Ups, it has failed again. You don't even write a revision comment anymore. But it is very painful later as you need to merge or roll-back the changes.

Typical scenarios, you name it.

Jazz creates your private area in the repository (you might say a branch in terms of SVN) by default (it's not a local workspace - it's on the server) - there you get you change checked in immediately (you can turn off the feature) and you can ask Jazz to create your private build from it without messing up the upper stream which means the team integration stream. Have you noticed? You need integration with building engine to enable the feature. All the simple changes are collected in a single change-set automatically associated with your task (or work item in general). Your colleagues review/approve the changes, or simply comment or ask the questions (automatically associated with the task - change-set): you develop your code in the context.

https://jazz.net/learn/content/docs/source-control/advanced/images/20080604_07.png
Figure 2a: Associating a Change-set with the task

https://jazz.net/learn/content/docs/source-control/advanced/images/20080604_08.png
Figure 2b: Change-set associated with the task

What is the result? As you run your private build successfully (which means the whole product integrated, all unit tests passed, all rules successfully applied) you might be sure you don't break the build and you avoid several stupid check-ins in the repository making roll-backs or merging really painful later. As you get instant info about changes made by your team mates in the repository (Jazz shows a popup message informing about new delivered change-set in the repository) you get integrated with latest changes - and yet again, you avoid future conflicts and you won't mess up the repository.

You might say: we have integrated Jira and SVN as well. Ok, but you should see the Eclipse based UI - recently I joined my friend who was still working with Jira and it was very painful to watch: many clicks, ugly interface. Moreover, to make the integration story happen you need to either use tools like Mylyn or convince each and every developer to put Jira issue id in every revision comment. And it is painful and not maintainable.

So, as your code becomes mature, integrated and well tested, you can deliver it into your team stream - ie. the changes become visible to your team mates. Beside the mentioned fact that you get consistent and error resistant changes (fewer changes) in your repository, you also get final delta associated with your task: in case of Jira-SVN integration you get several commits associated with your task and you have to compile all of them to get the complete view what has happened. And that is not only hard to do, that's impossible. You need a tool to do that. Jazz provides the complete view. And all the deltas you need.

You deliver the changes to your team's integration stream (an upper stream) - and as soon as your team gets stable, integrated and well tested state of the stream, you simply repeat same story again and you deliver it one stream up. Simple. Powerful.

Moreover, you can set the rule that nobody can deliver before he gets an approval from a leader. And that's another strong area of Jazz. Oh man, there are so many things... (Read more here).

Advantage #3: Integrated and centralized building
As I've mentioned, we used CruiseControl for quite long time. Actually, we leveraged wiki to store build parameters like label, status (built, verified, customer accepted, released, etc.) a customer id who migrated to the release and so on. Of course, you manage the info manually and it introduces errors (especially in hectic period right before a release). Later, when customer calls and reports a bug, you think this local workspace might be the right one so you switch your Eclipse (you've been developing new stuff) to the workspace and you get plenty of compilation errors so you delete the workspace and as soon as you figure out the right revision you check it out to your machine; then you ask yourself: what was the version of a library X and it's 1 hour later and you haven't still reconstructed the workspace therefore you decide to hang up and use the latest workspace; but you can't reproduce the error, oh my...

Jazz collects all the information related to a build automatically (ie. changes and work items included, tests passed/failed, etc.); as your customer calls and reports a defect you can restore the workspace by one click to trace the bug.

https://jazz.net/learn/content/docs/client-tour/images/b2build37.png
Figure 3: Build Result

You can tag a build and search it easily later.

Your testers can report a defect against the build by one click - it will be automatically associated.

21st century UI.

Little by little and you save huge amount of time in the end of a day.

Besides nice and friendly interface it's worth mentioning the architecture: Jazz separates a server (control point) and a build engine (running a build process). What it means: if you have been developing legacy (mix of technologies like C, C++, VisualBasic, Java, Flash, etc.) code and you decide to adopt continuous integration then you know the challenge very well: you must build different pieces on different platforms and it takes ages to compile.

You can register several build engines in Jazz; each build engine can run on different platform or machine and might compile different piece of your application in parallel. Sounds good, doesn't it?

We run one build engine on Windows since we need to use win native application; our second build engine runs on Linux. At the same time we start and check out new builds from single point: from developer's Eclipse. (Read more here).

Advantage #4: Open standard integration platform
You still think: Nice but I'm fine with my integration of Jira-SVN-CruiseControl or whatever... Maybe it's not so nice and lovely but it works.

My answer would be: the devil is in the detail. Try it out and you will experience the difference. Jazz actually integrates all the features by design or intentionally; it's not any post mortem intent to put all the pieces together - the approach must face certain constraints sooner or later.

Moreover, it makes it easier to setup new environment for a newcomer: you need to prepare a guideline or downloadable all-in-one package; but in hectic times (it means usually) it's difficult to keep it up-to-date; the guy needs to download and install Eclipse + all the plug-ins + all the libraries. He needs to know the repository address; to store all URL as bookmarks.

New guy joined us recently; I just added him into repository, Jazz generated a welcome email automatically; as soon as he downloaded a client he was ready to connect - and he got all the stuff available immediately: workspace, iteration plans, builds, reports; few clicks away.

Moreover, Jazz introduced an open standard called Open Collaboration Lifecycle other vendors are about to join. Nowadays it provides integration with SVN, CleareCase, Microsoft Sharepoint. And other will come. If you are CTO and the integration or data collection cross various sources is your theme, Jazz means an option how to stay free. You don't get dependent on one technology or vendor.

I believe it is vital to enable diversity; at the same time we are in a situation when it's difficult to start a new project in Ostrava since you need to deploy same tools (environment) as the other teams; they cannot use tools they are familiar with and they cannot leverage licenses. And it takes time to get it all in place.

Or as a line/department manager you can't ever collect any metrics automatically cross projects in your line/department since it's completely different environment behind each doors.

These days we start a pilot: we would like to demonstrate the integration capabilities of Jazz (e.g. integration with Jira) and collection of measures cross different sources.

Advantage #5: various resources and great support
Despite the fact that Jazz or Rational Team Concert is brand new product you can find great materials to learn about it; to name few:

• Learn about capabilities of Jazz: https://jazz.net/pub/capabilities/
  
• What's Jazz: https://jazz.net/learn/LearnItem.jsp?href=content/docs/welcome/what-is-jazz.html
  
• Erich Gamma sharing Jazz story: Jazz Update from EclipseCon with Erich Gamma
  
• Other videos: https://jazz.net/learn/videos/videos.jsp
  
• Next, you can join open forums at jazz.net You don't get unusual support (if you don't know Eclipse community) - forget about slow reactions from support guys having no clue what's your problem and constantly asking like machine talking its language. This time it's different: the Jazz developers are in touch with you directly - it means you get fast and accurate answer. I have never experienced anything like this.
  

-Roman Smirak, Tieto=