Well, hello everybody. Here we are at RSC 2009, the Rational Software Conference in lovely Orlando, California. And we actually have a returning guest for Redmonk TV. Would you like to introduce yourself? Sure. My name's Mike O'Rourke. I'm the Vice President of Development for Rational, so I own all the traditional Rational products, the jazz-based products, telelogic products. One of the areas, thinking about sort of comparing this year's announcements to last year, it seems like there's a lot more emphasis on, I guess, as an old developer, what I would call sort of dashboards and metrics and reporting and things like that. Yeah, absolutely. And I wonder if you can talk about sort of what you guys have in the portfolio now and sort of what people, you know, your customers would be using those tools for. Right. Well, I think you're exactly right. There's certainly that theme is here. And the reasons for it are pretty simple. We're seeing more and more people in the same situation that IBM and other people are in, right? Which is cutting back and really needing to understand as they cut back, what are the impacts of that? You know, how do I better measure, understand where I am so I can make smarter decisions as I move forward? We've done a lot of work, both internally as we kind of transform our organization to a more agile, at scale level organization, as well as just using our own product suite and trying to, we'll drink our own champagne, to try to create a better level of best practices, metrics, and capabilities that people can use to really start to look across the life cycle. Right. So I think really all of our products and many, many other products out there, you know, have very nice, concise metrics for the change that they're doing or the defect or the test. They're sort of tracking activities. They're tracking the activity that works in that tool, but not across the life cycle. So one of the things that we've tried to do with our insight product, a new product for us that was just released yesterday, is to try to fill in those information
2:02gaps. And so be able to, for instance, say, I've got a requirement, which developers worked on this requirement? Did they check it into this build? Does it have a set of tests associated with it? And did it pass those tests? Right. So I can get a report that shows me that information on a requirement-by-requirement basis that allows me to get access to the information across the life cycle, not having to manually try to piece it together. And like sitting through some of the keynotes and overviews for these things, one thing I've been curious about is the, I guess there's a couple of ways you can split up what you were just talking about. And one of them is obviously tracking metrics and seeing, you know, seeing if things are going well or poorly. Exactly. And then the other thing that seems sort of implicit in what you're talking about is sort of a collection of, I mean, everyone's always trying to avoid the term best practices, but sort of practices that are best for whatever context you may have. And then it seems like the other side of the thing is sort of the tooling that supports all of that. And then of course, sort of the consulting that helps out with that. And so with that, with all that on the table, I'm sort of curious how the practices are sort of like supported by the tools. Because I would assume at some point people have to sit down, whoever the stakeholders are, and sort of say like, here's the metrics that we're going to be tracking and here's the best practices. So what's, how do we finally get to the state where the tool can tell us how well or poorly we're doing? So obviously Rational's always been a big proponent of processes, right? RUP and Unified Change Management and all these kinds of things are processes that we've promoted and talked about. But, but one of the things that I think we see changing is, is that companies can't necessarily swallow all of those at one time. And so we've broken those processes up into what we call practices that help you towards iterative, help you towards waterfall, help you towards agile, whatever it might be. And then there's a set of measurements that we, we have come to through all of our, you know, installations working amongst ourselves and trying to roll this out to the 30,000 developers
4:05and software group that says, okay, if you're trying to do, let's just take, you know, an iterative development team. Well, you should probably be measuring velocity. Right. You should be measuring burndown rates. You should be measuring build health. You should be measuring, you know, 10, 15 metrics. And those metrics come out of the tools, right? That we, we have. And then the connection between those two in terms of the different repositories of information is done through Jazz. Right. And so what that starts to allow you to do then is take those best practices, if you will, and you can change those and the weighting of what those things might be. But let's just take something like project health. At my level, I've got 50 products. I need to have a way that in real time I can see the project health. I can see how far along a project is on their schedule, how much money I'm spending on that project and the overall project health, which might include support data, critical situations, defects. It might include hedging headcount data. Am I staffing this to the level I committed to? It might include how's my velocity here versus other teams, et cetera, et cetera. Right. But I just want to see red, yellow or green. Right. Right. If it's red, if it's red, then I'm going to make a phone call or I'm going to drill down. If it's green, then I'm not going to worry about it today. So a couple of things there. One is what we found is that we were spending a lot of time, like most companies do, trying to piece together the information as opposed to having the information flow itself. Right. So certainly that's where jazz comes in. And then that's where these best practices also came in. So when I start to say, okay, I need to do project health for my iterative team, there's actually 11 different metrics that flow from a variety of different tools that help with some out-of-the-box capabilities. that says, okay, it's 10%, this, 15% of this, 5% of this rolled up into red, yellow, or green. So that's the way we see it happening. Do we think that there's only one way to do it? No, but we do think that if you can start to, out of the box, get Project Health for
6:09an iterative project with 11 different metrics that flow up into it, you may take one out, you may change one, you may change the weightings, but chances are it's not going to be too far off from what you think Project Health should be, or Build Health, or something that is very subjective in general, and you try to make it as quantifiable as you can so that you can make decisions based upon that. It sounds like rather than sort of subscribing, if you will, to one sort of methodology, the idea is that nowadays, that you guys have sort of a library, if you will, metaphorically, you have things that you can pick and choose from, which I guess is sort of classic RUP process. That's exactly right. That's exactly right. A lot of the folks that were behind the RUP process in our organization have kind of taken that to the next level and created something called MCIF, the Measure Capability Improvement Framework. And what it is, is those selectable processes and practices, along with these metrics that come out of the box in our products, and along with some assessment tools, so you can either self-assess or the tools can help you assess where you are in your journey to become more agile, more iterative, better quality, better on time, whatever it might be. And so this is where the new Insight tool comes into play. It gives you those red lights and green lights, and then has that information so that you as a decision maker, so to speak, when you want to investigate something, you can get more information and drill down as people want to say. That's exactly right. It comes out of the box with essentially the ability to immediately get information from Microsoft Project and Excel, as well as a variety of rational tools and other tools. Where I think the real value is, is the fact that it then takes that information with these MCIF reports and metrics and best practices to your point, and gives you a starting point to start to say, you know, how am I doing today, and how am I going to do tomorrow, and start
8:10trending it, you know, analyzing it, and then, you know, being able to then start improving on it. Are these sort of traditional, you just get a server provision and run the Insight product on it, or what is this, what do these products end up looking like? So the Insight product is based off Cognos, which IBM bought, and essentially what happens is you install it with, and it comes out of the box with these adapters. Essentially, adapter is a way that we get a certain set of information and we kind of grow to be smart about that information as we adapt to it. And so we've got to adapt- It has that dual meaning to it. That's right, that's right. And so it comes out of the box with that information, and to your point, it is installed on a database and on a server. It is Cognos, so it's a mission critical kind of, you know, business intelligence tool. But where the fine tuning comes in is these best practices that are out of the box, specifically home for the development team, the testing team, the requirements for product management team, to better collaborate and work together. And then for their management, to start really understanding what's happening in the development teams, right? Because so often what happens is the development teams are looking at velocity and build health and things like that, and the executive could care less about that. It's, "Am I going to make it to market, and how much money am I spending?" And you have to flow that information up to something they care about so that they're not beating you up for the wrong reasons, right? And rewarding you for the right ones. That's right. And then I guess every now and then switching those two. That's right. That's exactly right. I remember last time we talked last year, we spent a little bit of time sort of defining the types of customers that you got, that Rational tends to deploy into. And I wonder, with things like Insight and the MCIF and other sort of tracking that we're talking about. I mean, what's your sense for the range of scale or sort of like the scale that these things go into? I think for that kind of tool, the more projects, the bigger your organization, the more distributed it is, the better. But really, if you think about
10:10it, even a single project may have a testing tool, a build tool, a configuration management tool, a change tool, a requirements tool from different vendors. And they're spending time trying to pull together this information. So they will definitely get value from it. But obviously, the more value you're going to get is the more projects you see and the more aggregated that data can get. And do you have a sense for, is there sort of like a floor? Like if you're only five people, it may not be worth your effort or? Well, I think it's, from an effort perspective, I think it would be worth it. It may be cost prohibitive. Right, right. I guess that's maybe a different wallet effort, if you will. That's right. So switching topics a little bit. Also, over the past year, you guys have been, I guess, you know, integrating in the TeleLogic acquisition, which is a, from traditional rational development, a different type of development, systems development, as people like to say. And I wonder, having overseen that, like how that process has been going for the past year and how the different products have sort of shaken out in the portfolio. I mean, is there, has there been some deduplication going on and some merging together of things or how's that been working out? There's definitely, there's, there's been very little duplication. There's certainly areas where they're, they have a similar type of functionality. So maybe it's an SCM functionality with something like ClearCase and, and Synergy or requirements management with something like Doors and Requisite Pro. But really what we saw before and since is, is that the customer type you are defines the kind of functionality that you want. So let's just take the Doors and, and Requisite Pro example. Many customers need to not only have, you know, let's say you're building a car, you're building an airplane or a, or a spaceship. You know, when, as you're trying to build those things, your requirements are, are key, right? You have to fulfill those requirements. Those requirements change. And so really ironclad tracking, traceability, heavy, heavy process capabilities have to be built into your requirements management. And so Doors is really, is required. That level of capability is required.
12:16But if you have something that's a little bit more lightweight, maybe a little bit more agile, you're using stories and, and storyboards and Visio or something else to do that work, then something like Requisite Pro or Requisite Requirements Composer can do the job that you need to get done at a different price point. But also it's, it doesn't, you know, burden you with some of the extra capabilities and bells and whistles that, that's something like a door. It doesn't impose all the discipline that you might actually want. That's right. So the, the teams have been off, uh, be honest with you working very, very well together. I'm very happy with the way they're working together. Now, the common goal for the telelogic teams and the rational teams is that everything becomes jazz based over time. Um, so for instance, we've got products like Build Forge, uh, and RAM, um, uh, and a new requirements tool coming out on jazz this, later this year, as well as a project management tool. Um, but we've got, for instance, doors coming out, uh, on top of jazz next year. Um, and so the, the goal is, is to try to have all the products, if you will, integrate through that, that jazz infrastructure so that they can get the collaborative life cycle benefits, the tying together, the integration and allow tools like insight to then feed all that information up to, to me or to you. Right. Well, the, the last thing I wanted to ask you about, again, since you oversee the actual sort of development of this, I mean, the, uh, you know, I, I guess since, since last year, I mean, the, the idea of cloud computing has really heated up and people are very interested in doing that. And I wonder, I mean, you guys have, um, I think they're, they're called technical previews or trials or something of, of some rational products that are being offered through jazz.net or, you know, in the cloud, if you will, as a service. And I wonder if, you know, having overseen the, the development of that stuff, if there's like some advice, you can give people who are considering deploying to the cloud themselves. I mean, how do you take the sort of packaged on premise applications and move them to a sort of cloud world? How, how has that worked out for you guys? You know, it's interesting because I think IBM, like many companies is kind of figuring their, this out as we go. Um, we're going to certainly focus on what we would call the, the private cloud
14:21first. So, uh, a cloud, if you will, within your organization or hosted by another organization, but not open to the public, if you will. Um, and for that, you know, as long as you've got some pretty well behaved server based applications, um, getting to the clouds, not as big of a step as you might think. There are issues that people in the cloud tend to want to solve with licensing. So things like either term licensing or token based licensing where you can use whatever product and it's, you're only getting, if you will charge when you use it, not just because you happen to have licenses of it. Right. So there's things like that, that we're adding to our products that, um, and be quite honest with you, we, we haven't found many issues as we've gotten there, but we're sort of, so we're certainly learning a lot as we and all these other companies start to move towards taking these technical previews to betas later, later on this year. And then uh, you know, globally making it ready for early next year to be as far as having previews, what a lot of companies wanting to deploy to the cloud do is, is, I mean, it's, it's nice that they're, they're kind of honest with, with their sort of beta users or the customers. And they just like, well, we need to test this out and not only see if it works, so to speak, but kind of see if there's different scenarios that we, you would want to use for this. You know, to some degree, it's kind of like, um, the agile model where you're trying to get stakeholder feedback. Right. I think that's really what we're trying to do within IBM and rational with our cloud offerings is, is that we think we've put together something that makes sense. It's very easy to use and provision, um, you know, makes a lot of sense, but there's going to be things that we don't know until our customers tell us that. Um, and we've been doing actually a lot of, uh, the work on our cloud, uh, quite interestingly in our China lab. And the reason for that is, is that, um, the, the Chinese government has actually sponsored a number of what they call software parks. And these software parks can have up to a hundred thousand people in them. And what these software parks want to do is centrally manage this, these private clouds. You come in with your 10 people and say, okay, I want to have this product, this product, and this product.
16:24All right. You plug into the wall and it's just there. Right. And you're basically paying me, it's kind of like hooking up to cable, right? You're paying me $24.95 a month for the, for that service. And I've got a hundred thousand people I can go do that with. And so we've actually been doing a lot of work with some of those software parks, um, using them, if you will, as guinea pigs for us. And at the same time, taking their feedback and upgrading this. And we've been doing that now for about six months. Yeah. That's interesting. It sounds like you get a pretty varied amount of interesting feedback. Yeah. There's different scenarios there. Yeah. Well, great. Well, thanks for taking all this time to talk with us. It was nice. - Nice. - Thank you. - Appreciate it.