How Does Rational Jazz Compare with Open Source Solutions

How Does IBM/Rational Jazz Compare with Open Source Solutions

The issue revolves around how IBM/Rational deals with open source competition, and their close cousins the “cheap source” tools.  You think of JIRA,, Rally, Subversion, Version One and others.  There are a lot of open source solutions out there, some good, some not so good.  IBM/Rational has known for a while that many of their tools are slowly becoming commoditized, and they have a limited life expectancy.

One note of caution.  I work with IBM/Rational.  Do not believe everything you read, and consider the source.  But take a look at the state of the software development industry today, and you will note many of the things that I point out below.  Make your own decisions, and draw your own conclusions.

Cost of Ownership (COO) for ANY Tool – Open source or otherwise

The case with most tools is that the cost of licensing is usually not the most expensive piece of deploying the capabilities promised by the tool.  That is what people want, not the tools themselves, but the capabilities that the tools provide.  So what are the costs?

• Licensing is one.
• The cost of the hardware, and maintaining the hardware, used to host the tools.
• The administrative costs associated with the tools in question.
• The cost of migration from old tools to new tools must also be considered.

Licensing – Where Open Source Rules

Open source and cheap source tools are cheaper to obtain.  IBM/Rational tools are more expensive.  This part is pretty simple, and it’s pretty simple to figure out.  Now let’s move on to the other costs associated with deployments of capability.

Hardware – A Small Victory for Jazz

The costs associated with the hardware hosting is a win for IBM/Rational, since most open source tools require multiple servers to host them, as opposed to a single Jazz server hosting up to 250 concurrent users (soon to be even more).  Open source tools and implementations are typically done on a group by group basis, thus the need for multiple servers (one per project).  Teams do not want to give up control of the resources, because of various administrative issues involved with central hosting of these tools.  It’s a control thing, and it requires a change in culture.

Administrative Costs – Lots of Partial People Add Up

Administrative costs are one place where Jazz is a big winner.  A large organization can have a partial FTE support a Jazz implementation that supports 1000 users.  Open source implementations typically are done on a group by group basis, with each group requiring their own partial FTE to keep it up and running.  Add up all of those “partial” FTE’s up across all of the projects, and the savings can become significant.  This is also where an organization can begin to see the benefits of specialization, where ALL teams can leverage an expert tool resource, as opposed to only those teams lucky enough to have a “tool guru” assigned to them.

Do the math.  If your company has 100 different IT projects, and it only takes one team member 4 hours a week to take care of the tool, that is 400 hours per week, or the equivalent of 10 administrators.  It adds up quickly.  Don’t bury the costs of administration, try to take an honest look at the amount of effort required.
Migration Costs – Pay Me Once, Not Every Five Years

Migration of tool repositories is the most expensive piece of any transition.  The costs of the conversion, movement, and validation of the conversion of data are significant.  It requires labor, and often will require the writing of one time use tools for the migration of the data.  I  have personally seen organizations not purchase tools that they believed would make them more successful because of this fact.  It is expensive to move to a new tool, regardless of the fact that it might be open source, commercial, or open commercial.  So every tool is even on this count, right?  Wrong.

Once software development artifacts are committed to a Jazz based infrastructure, you will not have to go through these types of exercises again.  Since Jazz stores the artifacts, if you wish to use different tools, to view the same artifacts, then you can.  You may need to make transformations on the data, but there is no bulk movement of the data, and it all remains in place within the Jazz repository.  Let’s face it, you will replace whatever tools you have today with something newer and better sometime in the next ten years.  Reduce the costs associated with that by choosing an open platform now.  One more added benefit is that you do not have to go out and rebuild any tool integrations.  Tools based on the Jazz platform can integrate and share information via uniform and consistent mechanisms.

The Costs of Conformity

The final value proposition for Jazz is that Jazz allows you to choose what you want.  Our largest customers have been attempting to standardize on tools for over a decade now, with varying degrees of success.  We have been doing it for so long, that we have forgotten why we wanted to standardize in the first place.  We talk about being able to have a core tools support group, leveraging economies of scale, and being able to more rapidly promote best practices.  The REAL reason companies want to standardize is so they can collect consistent metrics across the entire software development organization. “You can’t manage what you can’t measure”, was a favorite phrase of Jack Welsh (ex-CEO of GE).  He was right, and the rest of the CEO’s, CTO’s, and CIO’s understand this.

Jazz gives them the ability to be able to collect consistent metrics across the enterprise, without having to dictate to software teams the specific tools that they have to use.  You can use the Jazz SCM component, or the Subversion plugin, or the ClearCase connector.  Use the tool chain that makes sense for the individual project.  With Jazz’s collaboration and transparency, it doesn’t matter because the underlying metrics and artifacts are visible to the organization.  Now business leaders don’t have to sit through endless technical presentations on why tool X is evil, and tool Y is the best thing since sliced bread.  They don’t care!  They just want to see how their projects are doing, and how they are contributing to the business.  Jazz gives them the ability to stop the constant arcane technical arguments, and let teams choose what they like (as long as it is Jazz enabled).

Finally – Open Source is Part of the Answer

So in closing, we get back to the original question.  Why Jazz instead of open source?  Why Rational Quality Manager or Rational Team Concert instead of open source?  Because they expose more of the collaborative experience that Jazz offers.  If these capabilities are NOT important to the customer now, they will be in the future.  Open source tools will become an important, and key, component to a Jazz based deployment of software development technology.  That is OK.  Open Source software is not the enemy of commercial tools in the Jazz universe.  I prefer to picture it as the yin; to the yang of commercial Jazz based offerings.  Both will be used in some combination, and a well balanced software development environment will depend on both types of tools.  Putting all of your faith into one extreme or the other will put a team at risk, and will ultimately not be in the best interests of the software development organization.