We are at RSDC 2008 in Orlando, Florida, of course, and we've gotten a fancy room recorded here. You can see we've got some metal statues and pictures. Very nice. Exactly. And would you like to introduce yourself? Sure. My name is Mike O'Rourke. I'm the Vice President of Product Development here at Rational. So what does that mean your responsibilities are exactly? Well, so I'm responsible for the core products at Rational. Core products meaning there's three areas of development, one being the telelogic acquisition, which isn't fully integrated yet, and the other really being the system Z and I areas, and that's owned by Hayden Lindsey. I own pretty much all the kind of core Rational products across the development lifecycle from requirements to change and release management to testing, portfolio and project management, so really the full lifecycle. And you came in through BuildForge, right? I did. This is my second go around. Right. What's that Al Pacino line and Godfather, they won't let me go. They pull me back in. They keep pulling me back in, yeah. I was originally, I was early on at Tivoli. I came through that acquisition and this time through BuildForge. So one of the big announcements here at RSCC was around Team Concert, of course, continuing with the jazz metaphor for everything, which is sort of the first go around of commercializing jazz. That's right. And you want to just quickly explain what sort of Team Concert does? Sure. Jazz is the platform, kind of the integration platform that we have that provides a set of capabilities, things like collaboration and security and project management and dashboards and a variety of other things. So the goal over time is that all rational products will essentially be jazz. Our first product, as you mentioned, is Team Concert. And what Team Concert is really focused at is just the developer side of the house. So the developer being the applications the developer typically uses are an SCM, a Source Control Management System, a Work Item or Defect Tracking System, and a Build System. And so we've taken those three applications and essentially plugged them into the jazz framework, where they get to now share all that information across the jazz framework as well as become kind of automatically tightly integrated.
2:05And so Team Concert is really the first jazz-based release, but we've got other things like quality management for the testing community, as well as requirements definition for the requirements or project management. So where does an IDE fit into that? Because I think you talked about version control and task management and the third component, but where is sort of like sitting down and writing the code fit? Well, so if you think about an IDE, what an IDE is about, whether you're choosing Visual Studio or you're choosing Eclipse, and for some people, not even an IDE, just a nice visual web-based interface, right? What it's really all about is kind of integration on the glass, right? Help me make all -- I don't want to change windows. I don't want to do all those things. I want it to come together in the glass. What jazz and Team Concert are about is taking that same concept and making it available to the team, not just to you, on a server. So whatever your IDE is, whether it's Visual Studio or Eclipse or web-based, all of those have, if you will, a view into those integrations and capabilities. So if you're using Visual Studio, if you're using Eclipse, you can still use all the capabilities, the integrations of Team Concert through your own IDE, but now you don't get just desktop integration. You get server and team-based integration across the world. So I'm sort of assuming that Team Concert reaches into Eclipse or Visual Studio with the plug-in or whatever you call it. Absolutely. That's the integration mechanism. That's the integration into the IDE. Right. But the server aspects of, you know, keeping conversation logs and collaborating and security and agile planning and all those kinds of things are kept on the server. More generally, not necessarily just with Team Concert, but for rational more generally, I mean, would you say that there's -- what's sort of the breakout of the constituency that you have as far as the developers? Is it way heavier on one side? And I've been trying to make myself remember this now, but with TeleLogic, you have sort of the embedded -- The embedded systems type developers, right? Yeah, yeah, yeah. Where they're dealing with both hardware and software and meshing the two together. Right. And that was the thrust behind buying TeleLogic.
4:05I would say typically the rational tool set and certainly the way where we sell to is typically what you might call the corporate developer, right? Right. Or the IT developer. They're developing to deliver to an in-house production system, right? Right, right. They're not reselling the stuff or selling it, I guess. Right, right. Now, we have a variety of our tools that also get sold to ISVs, but I would say ISVs tend to more generally be partners, where we're in their partner program, they're in our partner program, we tend to swap code. We don't tend to get the higher dollar, higher value of return for those folks, even though, obviously, software is their business. Sure. But I think what we're finding is software is pretty much everybody's business. Right, right. And so, you know, where we tend to focus on is in the corporate areas and now with TeleLogic, the systems areas. So, being from BuildForge. Yeah. You know, I'm always curious in asking sort of like what the next sort of broad innovation in some category is going to be. And it seems like, and maybe you have a different view, but it seems like in builds, managing builds, just the idea of a continuous build was a pretty, you know, a simple idea, but a pretty big innovation that occurred. And, you know, I'm curious if you're seeing or thinking about any of the next like simple big ideas that would be wide affecting in the builds. A couple of them that we're thinking of, one of which is that what we're finding is, if you think about when the build happens, either for the developer or for, you know, the company or for the project, that's when everything comes together, right? Yeah. That's when you find, you're pulling DLLs, you're finding source code that may have been pulled from open source, third parties are delivering things to deliver your final set of executables, right? So what better time than to start checking overall code health, things like which teams are actually delivering higher quality code versus other teams? Those are the kinds of things you don't get if you're doing things on an individual desktop by desktop basis. You have to get it kind of when it all comes together. Sort of doing analysis, if you will, at the group level instead of, yeah.
6:08You know, static trend analysis, looking for everything from memory leaks to is this open source, those kinds of things. Right. So that's kind of one side of it. The other side of it is really this notion of, so now that I've got a build, what do I want to do with it, right? So now that I've got something, well, I want to test it. I want to deploy it to a set of systems. Unfortunately, those set of systems, just take any of the rational products, could be anything with, you know, five different flavors of an operating system, four different databases, two different LDAP integrations, whatever it might be. So how do I provision that? How do I ship it there? Because many organizations are spending 30, 40, 50% of their time, that back into the cycle, doing nothing but taking machines up and down. The more that you can tie that build process into the automated provisioning, deployment, reservations, finding the right systems, getting it there and executing the tests, you know, you can save huge volumes and then, obviously, dramatically decrease how long it takes for you to get to build. Right. Absolutely. We see the build as being a very critical place in the development lifecycle where so many things are coming together. And if it's done wrong, it's going to hurt you for the rest of the development lifecycle. Right, right. Well, great. Well, I appreciate you spending so much time with us. Well, thanks. Thanks. Appreciate it. Good stuff.