Jazz and Diversity in Software Development

Over the past few weeks I have come back to a common theme in my discussions with customers.  We have started out talking about Jazz based technologies.  I have been making the point that having the capability that Jazz provides for a balanced and diversified portfolio of open source, cheap source, and commercial tools, allows organizations to be flexible, while still being able to collect enterprise wide software development metrics.  I discuss this in an earlier post on How Does Rational Jazz Compare with Open Source Solutions, in the last paragraph of that blog entry.
What Jazz and a diversified tool portfolio REALLY does for an organization is to reduce their overall risk.  As a user of software tools, an organization can decide on a strategy for how they consume and use software development tools.  They can provide a portfolio of tools, and allow projects to select the tools that best fit their needs.  They can decide to go with a single vendor approach (hopefully that would be IBM/Rational).  They can then change course as the business climate dictates, without a large disruption of development activities, due to the Jazz infrastructure supplying a common interface for ALL Jazz based tools.
The people that I have talked to in the past few weeks have acknowledged this as a strategic benefit for their organizations.  Then we have discussed how Jazz allows an organization visibility into ALL software development efforts, which allows them to monitor offshored and outsourced efforts with greater ease.  They can then decide on what types of projects work well offshore, what types of engagement models work best with outsourced work, who the good vendors are, and who the bad vendors are.
Then on the way back to the hotel the other night it hit me (it took me a couple of weeks to get back to this post).  I was listening to some guy on the radio stressing the importance of having a diversified investment portfolio, especially in light of the recent economic conditions.  My 401(k) has taken a beating, but it could have been much worse, since I was diversified.  So my mind was wandering, and I began to think about what is important for software development today.  I was thinking about the diversity of the people that I meet in a day.  That’s when it hit me.
Diversity.
What are the key aspects that corporations demand from their software development organizations?  I would argue that they are:

• Contribution to the bottom line – return on investment

• Development of innovative new technologies and products

• Reducing the risks to the business

I then thought about a thread that was common to each of these things.  Diversity.  How do you get a good return on investment from an IT Organization, or an R&D organization?  You have a diverse portfolio of projects.  Some will fail, some will succeed.  If your organization is a success, the contributions of the winners will exceed the cost of the losers.  A little bit of simple business math will give you a return on investment for your software organization.  A diverse portfolio of software projects allows you to hedge risk, and maintain a healthy and consistent return on investment.
How does an organization develop innovative new products and technologies?  Thru the collaboration of a diversified workforce.  People with diverse backgrounds bouncing ideas off of each other, collaborating and using original ideas to fuel even more original ideas, in a vicious cycle.  So we are talking about not only cultural diversity, but diversity in work experience, diversity of educational backgrounds, and most importantly a diversity of opinions and viewpoints.  Allowing and encouraging collaboration between a diverse workforce will (one hopes) encourage and foster innovation.
Finally we get to reducing the risks to the business.  This also relies on diversity.  Businesses reduce risks through improved governance of not only IT processes, but all business processes.  They also reduce risks through improved security.  This means electronic, physical, and financial security systems.  Organizations that rely on a single mode of security, or governance, leave themselves open to the exploitation of that mode of enforcement.  A mix of human and automated modes of enforcement will provide a depth in layers (to steal a military term) for these risk mitigation systems.  Diversity.
So what does it REALLY mean?  It was just a thought that hit me, and it seemed somewhat profound.  It is an argument for diversity, but we really don’t need MORE of that today, most businesses and people buy into this philosophy already.  I guess that the real point here is that software organizations should not rely on a single technology, or a single vendor, or a single ANYTHING, when looking at long term strategic direction.  They should realize that a diversified approach, within common frameworks and reporting mechanisms, will be the most effective and least risky in the long run.  Jazz enables this diversity in approaches, tools, teams and platforms.  This is a strategic benefit that is hard to quantify, but very real nonetheless.

Jazz Hands – Administration and Cost of Ownership

I get inspiration from a lot of sources.  My latest came from my customers, and my daughter.  I was relaxing last weekend, sitting around a campfire with my wife and my daughter.  It was one of those times when you talk and exchange ideas with your kid.  I was thinking about how nice things were, but thoughts of work crept into my head, and I was thinking about the many customer requests for “typical” administrative headcounts that I have seen in the past few weeks.  Right about this time, my daughter pipes in with the final piece of her story about her skating program (she figure skates), “..and we decided that we needed to be more visual, you know, have more Jazz hands”.  It seemed like the perfect title for a blog entry on administration of Jazz based technology, and specifically Rational Team Concert (RTC).

Jazz is a centrally based repository, which relies on a simple architecture to provide software development services to it’s users.  The details of this architecture are not particularly important for the purposes of this discussion, what is important is how Jazz manages the way it is configured, and how it holds data.  At the core of Jazz is the concept of a process template.  This is an XML file which describes in detail how a process works within the Jazz framework, what roles exist, the permissions that the roles established will have, the types of objects (work items) that exist, their associated workflows, and approval processes.  Modification of this XML file can be done via text editor, or by using the GUI in Rational Team Concert.  It is much more than a state engine, it helps define a process, and it allows that process to be applied to individual projects in a uniform manner.  The key point here is that the process is just another piece of data that lives within a Jazz based repository.

Why is this important?  Most tools allow you to configure how they will work (where files are stored, how records are kept, etc.), and they also let you enforce workflows and process.  The key difference is that in order to modify the process, you need to have some understanding of how the tool works, and then you need to interact with the tool to implement these process features.  ClearCase used triggers, which could be implemented through the writing of scripts that were attached to the repository environment in a very tool specific manner.  ClearQuest used hook code (specific implementation of Visual Basic or Perl which interacted with the API to effect specific business rules), or it’s own interface for defining records, workflows, fields and so on.  Other tools all follow a similar paradigm.

With a Jazz based implementation, the process can be manipulated with a GUI, and can be done without specialized knowledge of the tool API, or the tool inner workings.  I know what you are thinking, what in the world does this have to do with tool administration?  The subtle difference manifests itself in some significant ways in the real world.

1. Tool Administrators no longer need to know some programming or scripting language.  Everything is GUI driven, and it all happens on a centrally located server, not some distributed set of resources that need to be managed and coordinated.  Tool administrators can support users from around the world, without leaving the data center.
2. Database Administrators no longer have to perform tool specific steps to do backup and recovery operations on the repository databases.  They do not need to have ANY tool knowledge.  Tool administrators do not need to have any specialized database knowledge.  Each can live safely within their own area of expertise.
3. Process engineers, Subject Matter Experts (SMEs), and project leaders can now modify individual project processes on their own (assuming that their roles permit them to) without having to get tool administrators involved.  They can modify the processes used for a project, without impacting the processes used by the organization as a whole.
4. Jazz based solution architectures are more simple and straightforward, enabling easier understanding of the architecture, easier configuration, and reduced maintenance.

While this may not seem significant, the impacts on cost of ownership, and the number of “Jazz Hands” that an organization needs to support their software development infrastructure are significant.  In the past, the ratio of users to administrators usually had these types of typical values:

• ClearCase (complex deployment) – 100 : 1
• ClearCase (simple deployment) – 350 : 1
• ClearQuest (complex deployment) – 200 : 1
• ClearQuest (simple deployment) – 500 : 1
• Subversion (complex deployment) – 200 : 1
• Subversion (simple deployment) – 400 : 1

Now with Jazz, IBM is hosting an internal deployment of almost 20000 users, with a staff of 5 administrators.  This is a ratio of roughly 4000 : 1.  Granted, the administrators that we have internally are a pretty sharp bunch, and they do have a responsive support channel to our product development teams (grin).  Even if I assumed that a “regular” Jazz administrator was only half as effective, that still leaves us with a gaudy ratio of 2000 : 1.  This represents an enormous cost savings for our customers deploying Jazz technologies.  In addition, these administrative resources no longer need to know and understand tools, software development processes, and scripting languages.  They just need to know a little bit about Jazz, which is pretty easy to pick up, and easier to become enabled with than any of the other ALM tools out in the marketplace.  The cost savings are big, and the reduced complexity is an additional benefit.

So let’s bring it back to administrative costs.  If I have an organization of 200 people in software development, the only gain I will realize is that my overall environment is simpler and easier to understand.  It means less complexity.  If my organization is larger, say 2000 people, then I begin to realize some impressive savings.  For 2000 developers, a ClearCase/ClearQuest environment may have used 3 ClearQuest administrators, and 5 ClearCase administrators worldwide.  If I were to assume a relatively cheap fully burdened engineer rate of $60000 per person, this would cost me roughly $480,000 a year.  With some other less functional tools, I might need 4 or 5 overall administrators, for a cost of $240,000 per year.  With a Jazz based infrastructure, an RTC implementation would need a single administrator, for a cost of $50000 per year.  This represents a significant cost savings, and when coupled with the reduced hardware footprint needed for Jazz based offerings, it can quickly add up.