developerWorks: This is a developerWorks podcast. I'm Scott Laningham. My guest this time is Kartik Kanakasabesan, product manager for Rational Team Concert, one of the first products on the new Jazz platform. Kartik, thanks for doing this today.
Kanakasabesan: Thank you very much, Scott. Glad to be here.
developerWorks: Now, starting off, I wonder if you could talk a bit about what Rational Team Concert is and how it fits into the Jazz landscape.
Kanakasabesan: Well, consider the fact that when the Jazz project initially first started, it was basically looking at how we can build a collaborative solution. And it was at that time still in the research phases. And in the current context, it's more of making IBM a little more transparent in the way we develop our products. And it just so happens that via the Jazz.net portal, we expose certain componentries of the Jazz platform, and we're using some of those exact same components and building a commercial product on top of it called Rational Team Concert.
So for all intents and purposes, you could actually go and say the fact that Rational Team Concert is essentially powered by Jazz technology.
developerWorks: Now, what about the customer base that you're targeting for Rational Team Concert — or, let's just call it RTC here for short. And talk about that, as well as maybe some of the challenges that those customers are facing that RTC is designed to address.
Kanakasabesan: Some of the customer base that we're technically going after in this case are teams, are kind of small, nimble teams if you will. Agile development practices, as you know, have gone ahead and hit mainstream. And if you look at a typical composition of a so-called agile team, it usually could range within the size of five to 25 developers. And typically, what we are looking at is being able to have those islands of developers working on similar projects, being able to share artifacts across these multiple projects, so on and so forth. So we're ideally targeting that kind of base, as well.
Now at the same time, if you look at some of the tools that are currently being used in these small agile teams, they happen to be very commoditized, and a lot of the team members are usually taken off that team to figure out how they can integrate effectively with these product tools. Now, with Rational Team Concert, we're kind of changing the game in this way and actually bringing the whole concept of collaborative development, if you will, down to the masses in this case.
So when you have small, nimble teams that are out there that want to go and develop solutions, having the integrated solutions is no longer the domain of the few, but it's actually available for the masses in this case. And that's what we want to go and address with Rational Team Concert.
So some of the customer scenarios that we're primarily targeting in this case is small companies that have small development teams. Anywhere ... and again, with a single instance of the server, you'll probably be able to have up to a hundred users on a single instance of the server. So you could have up to four 25-member development teams, so to speak. And at the same time, we're also looking at small, nimble teams in larger organizations, as well, and be able to support those kind of environments, as it were.
So typically, we're looking at anywhere from small- to medium-size teams, whether it be in a stand-alone company or within a small team within a larger enterprise.
developerWorks: I know you had mentioned platform options, and what customers expect there is an important thing to talk about. What about that? What do you want to share on that front?
Kanakasabesan: Well, from a platform perspective, in this case, we will initially target Windows® and Linux® as our primary target environments. And basically, since these are the common platforms du jour, if you will, from an operating system standpoint, for some of these small to medium teams, those will be the primary platforms it will be targeting. Along with that, when we do GA with Rational Team Concert, and that'll be happening today, we'll be bundling it with Apache Derby and Apache Tomcat as the application server and Derby being the database.
Teams beyond that can even scale to using either DB2® and again, paying customers will be getting a bundled version of DB2, as well, and would also work with Oracle. So customers who already have a vested investment in Oracle will still be able to use that as a back-end repository for their Team Concert assets.
developerWorks: Well, and cross-platform is really, it's got to be a given nowadays with these offerings, doesn't it? I mean, we used to talk about that being something special, but it's really something that's demanded now, isn't it?
Kanakasabesan: Absolutely, absolutely. So and one of the things that we've also kind of really harped on is because we're using Eclipse technology, we're also trying to make sure the fact that the user experience whether the client is running off a Linux workstation or a Windows workstation, the user experiences are primarily identical because of Eclipse. And since we are using Eclipse, we can make sure that that experience is not significantly different in either platform, so to speak.
developerWorks: Now, what about, Kardik, you talked a little bit about challenges, you know, that customers are needing to have addressed and where RTC comes into that. I wonder if you could talk a bit more about that, and maybe describe some of the challenges and problems that are there right now in this arena and that RTC is going to kind of bring a new solution, a new way of addressing these things to the customer.
Kanakasabesan: Well, basically, if you were to look what we were trying to with Rational Team Concert is address the space of collaborative development. And if you look at teams and the way their tooling is manifested today is they use point product solutions and then pick out some smart folks out of their team and have them figure out how they want to go and integrate. So typically, you could see, you know, a small organization or a small team have some kind of a portal where they were sharing documents.
Kanakasabesan: And these documents don't necessarily link into the actual development work that's being done inside their version-control system, and that version-control system is not necessarily linked properly with their work items that they're addressing. And at the end of the day, what they would do is either have a scripting solution that they would also have to go and maintain. And what happens in this case is that development teams, instead of focusing on the business that they're building the solution to are now also focused on making sure this whole thing is, you know, glued together as a bale-wire solution around the whole thing, as well.
developerWorks: Right. Yes.
Kanakasabesan: So what we're trying to do with Rational Team Concert is saying that right out of the gate, you install a product, you know, get your project up and running and have your team focus on your core competency, which means building the solution that is relevant to your business, and let the tooling part be our problem.
developerWorks: How much of a mental shift do you think this is going to necessitate on the part of the user? Or do you think it's just going to be like a breath of fresh air when they get to experience this?
Kanakasabesan: The good thing is what we've seen so far, based on initial response, and mind you, we did formally announce an open continuous beta at the Rational User Conference in June this year. The uptake has been phenomenal. We have both internal IBM customers and external customers that are constantly engaging with this product and the feedback has been great. Now, we've also had some really good feedback, we've also had some negative feedback in the sense there's certain things that customers would like us to do, which is what exactly we expected, you know, using Jazz.net as a forum to help us improve the product before we GA the thing.
So so far, I would probably rate it in the area of breath of fresh air vs., you now, being a big paradigm shift for a lot of customers.
developerWorks: Well, that's great. Kardik, what about the types of scenarios that you plan to support with Rational Team Concert? Talk about that a bit, if you would.
Kanakasabesan: Sure. You know, I mean, if you look at traditional development the way we have gone ahead and done stuff with Team Concert, one of the first scenarios that we're looking at is simple import solutions. So you have a set of tools that are available today, and we'll be providing you import capability, let's say from your existing work item solution, from your SCM solution into Team Concert. And once the import's been done, then you can now basically work inside a self-contained Team Concert instance.
Now, the second is a surround strategy or a coexist strategy, as we call it, wherein which customers, let's say, have moved to a different type of version-control system to a newer one and they' re not necessarily willing to go ahead and move off to another system. In this case, we're looking at building a coexistence story around subversion. And what we've realized is that today even subversion users are kind of struggling with this whole integration story. So what we've decided in this case is the fact that we'll go ahead and build a surround story, if you will, around subversion wherein which customers will be able to have an integrated experience with their subversion assets by integrating them with our work items and the build capabilities that are inside Team Concert. Now, the integrations will not be as, let's say, as strong as if you were using the SCM capability within Team Concert, but they're good enough for people to get started and really experience the benefits of collaborative development.
Now, the third scenario is a mother-ship scenario wherein which let's say you have already a backbone SCM system, say in this case ClearCase, ClearQuest, and you have this small island SCM team that's currently doing work without any controls. The challenge today is that customers today cannot necessarily hold these little small teams in and accountable for the work that they're going ahead and delivering. Now, with Team Concert right out of the gate, because it has bidirectional connectors, if you will, with ClearCase, ClearQuest, all the assets and work items that these small island teams are working on can now be synchronized back and forth, whether it can be done on the touch of a user button or it can be done background without even the user knowing it what the assets being synchronized back and forth between Team Concert and ClearCase, ClearQuest.
developerWorks: Great. Now, a couple more things I wanted to ask you about. When we were preparing for this, you mentioned the open commercial development model and Team Concert benefiting from that. Do you want to talk about that a little bit?
Kanakasabesan: Sure. Open commercial development is kind of a new paradigm that we've gone ahead and done with Jazz.net, specifically. You know, it is strictly commercial, that's the other part. It's not necessarily open source, although if you go to Jazz.net today, you'll be able to download the source of Team Concert, but it's not necessarily open source. It's strictly a very commercial enterprise. That said, we are being transparent in the way we develop our components that are being used in Rational Team Concert. So we're being very open about that and sharing ideas with our customers. Basically, going and saying, "Listen — these are the things that we're thinking today. Do you think it's the right way to go? Help us steer to the right direction."
In the past, you know, some of the feedback that we got back from our customers was the fact that our development paradigms were pretty much black-box oriented. You know, they would go in and submit their RFEs and at the end of the day, after we would close to a product release, they'll then figure out what exact RFEs went into the actual product.
In the case of open commercial development, because it is transparent, customers and partners and so on and so forth can submit RFEs right there and collaborate directly with the development teams and support teams to figure out where things stand vis à vis their defects that they have submitted, the enhancements they submitted so on and so forth. And it also helps us kind of take the approach that, you know, we're not boiling the ocean. Let's focus on some of the high-value points. And by the way, these high-value points that we deem necessary have already been validated by our customers.
developerWorks: You know, this increasing collaborative element of the way business is being done nowadays it sometimes makes me wonder how did we get along without it until now? You know, there's just so much creativity that's being unleashed by it, don't you think?
Kanakasabesan: I agree wholeheartedly there because, you know, at the end of the day, there are several successful models that are out there and I believe this is just the next evolution of the way commercial software will be developed going forward.
developerWorks: Now, what about your strategy around supporting Visual Studio .NET customers? What about that?
Kanakasabesan: Well, we were currently looking at different paradigms here. Now, mind you, our first focus is obviously Eclipse, but we do realize that there are a set of .NET customers that are out there that are building solutions around .NET and using Visual Studio .NET to basically build solutions for that platform.
Now, we have several thoughts that are happening around that area, and one of the things that we will be doing is essentially looking at providing capabilities to manage .NET assets. Now, when Team Concert 1.0, does GA, we're not sure we'll be able to provide something at that time frame, but definitely very quickly after we GA with Team Concert, we'll probably provide something around being able to manage .NET assets in a very collaborative way. It may not be honestly as good as Eclipse, but it's our first step. We do realize the fact that .NET is a very important player in the market, and we want to be able to go ahead and manage assets of that environment in a very effective way.
developerWorks: Kartik, you've been great sharing all this information with us. Any closing thoughts you'd like to share? And also some places you'd like to point the listeners to learn more.
Kanakasabesan: Actually, thank you very much for having me here today, but some of the things that I do want to share with the folks that are listening is, register on Jazz.net. You know, we are trying to make this very developer portal-oriented. One of the things that I do want to mention is, along with people registering at Jazz.net, we are providing regular integration builds and milestone builds of Team Concert. And one of the major milestones that we'll be providing later at the end of the year is beta two. So ideally, I'd like to make sure that customers and business partners are able to go and register on Jazz.net and start downloading beta two close to the end of the year, as well. And I think the target time line that we're going after in this case is December 14. And if you do participate in particular events where we're showcasing Team Concert, please come and talk to us. We can definitely share some ideas. And if you do have ideas that will help us further improve our story around Team Concert and so on and so forth, we're more than willing to listen. So I know it sounds pretty cliché to hear it, but we're all ears.
developerWorks: Fantastic. Kartik Kanakasabesan, product manager for Rational Team Concert. Kartik, thanks so much for doing this today, we appreciate it.
Kanakasabesan: Thank you, Scott.
developerWorks: Find out more on this topic through helpful links in the show notes for this podcast. You can access that at ibm.com/developerWorks/podcast. That's all for this time. For developerWorks, I'm Scott Laningham. Thanks for listening.