Hi everybody, here we are in Austin, Texas, which is always nice, and we're actually at the TeleLogic Users Group conference or meeting called Innovation 2008, and we've got a special guest with ourselves. Would you like to introduce yourself? Sure. My name is Danny Saba, and I am the general manager for IBM's Rational Business, which now includes TeleLogic. I think it was back at RSDC where you had the biggest sort of talking about TeleLogic and Rational and things like that, and obviously at the TeleLogic Users Group you would talk about that more. And I'm curious, this morning in your keynote you were talking about sort of the melding together of the TeleLogic portfolio and how it would fit into Rational. There's a couple of things to understand about the melding of the TeleLogic portfolio. Number one is, as I've said in the past, and will continue to say, the biggest reason for acquiring the assets and the people of TeleLogic is the fact that TeleLogic was really a world leader in understanding embedded and complex systems. Right. And I believe fundamentally that the challenges in front of us as a business both from a growth as well as just a customer challenge perspective are really going to come largely from embedded in a complex system. That's really part of the reason why we acquired TeleLogic. So when you look at the strategy of Rational going forward, there's now an enhanced, a significantly enhanced expertise in that particular domain. And what we're going to do in terms of integrating that particular expertise, the tools, the capabilities, the intellectual property, is really leverage it in the context of the underlying jazz platform that we're built.
2:00So we're providing a roadmap that not only enhances the existing products that TeleLogic has, but also starts to incorporate them and weave them into the broader jazz vision that we will have as a combined entity. And it seems like the combination, I mean, Rational's always been strong in software development, I guess. And then, like you're saying, adding in the systems development or software that runs on systems, if you will. I mean, it really sort of adds on a whole new sort of type of software community that Rational will be working with. Not only that, but basically, once again, software is becoming more and more relevant as an element, as a crucial element, as a differentiating element, as an innovative element in those types of complex systems. I'm curious, with the two groups coming together, as it were, I mean, what, and especially with jazz as sort of a substrate, if you will, of being of the Rational portfolio. There's obviously a lot of overlap in the software world between whenever you're writing software, but what are sort of the things that are unique for the telelogic world and more unique towards the more application space? One of the characteristics that we were talking about and what highlights and differentiates, frankly, some of the telelogic tools is the focus on two different aspects of things. One is on understanding and managing complex systems, okay, where software is only a part of the broader solution. Right. Okay. So when you think about things like, as a matter of fact, I was talking to a customer earlier this morning about enterprise architecture, right? So you look at, you know, a product like System Architect. System Architect goes well beyond and is applicable well beyond, you know, a pure software domain. So is Doors. Right. Okay. Doors gets used in many instances, basically, where, frankly, only part of the output is managing requirements around software. So, on the other hand, basically, you have another dimension, which is essentially embedded software. So you have tools like Rhapsody that, you know, are first and foremost in that particular realm.
4:05Managing complex systems, managing complex systems that have only software as a portion of their, you know, of the asset that they're trying to manage or create. And managing embedded software. Right, right. For all the things that come in. Though there are differences, it seems like, and I, of course, come from more of the, I guess, the application side of things. Yeah, IT side. Yeah, exactly. Or the system side, right? Right. Or the software side. And I imagine that the requirements process is somewhat similar when you're gathering. I mean, you still have a desire to do something, and then you have to have software that satisfies that desire at a very high level, right? Yeah. But there probably is, you know, I would assume, coming from the IT side, that in systems, you have to sort of get it right a lot earlier than you can in software. Right. You don't want to ship a bunch of units of something that have a bug in them. It's not quite as easy to fix. No, it's not. And frankly, it shouldn't be quite as easy to fix on the software side either. Right. Because I think, frankly, we put out a lot of, shall we say, questionable quality on the software side that could, frankly, benefit from the discipline and from the rigor that gets introduced into the product engineering side of this. Sure. So that is one of the key differentiators is the fact that, you know, when you're managing that kind of complex system, you know, mistakes hurt, and they hurt a lot. Right. And basically having a certain degree of rigor and discipline about how you manage and gather requirements and the specificity and the formalism, so to speak, behind those requirements is a lot more important. Same thing with model-driven development, basically. You know, the good news is it's not quite as chaotic as the deployment environments that you see in IT. Right. Right. Because basically what you're doing is you're targeting a fairly well-prescribed, product-oriented... Yeah. More of a very known system. A known system. Right. Right. But what that does is that both strengthens and enhances and requires, you know, more of a model-driven and model-driven development. Right.
6:05Or the reason why it doesn't work on the software side or the IT side is because people can't actually control the deployment environment. Right. And when you have a mismatch between the deployment environment and the assumptions that you make and the underlying modeling environment, you've generally got some degree of chaos. Right. Right. Right. It's time for a patch or a new version. Time for a patch or a new version or the performance is terrible or... Right. Right. Or you can't align what you did in actual coding with what the model is supposed to represent. So there's all kinds of breakage points in that kind of scenario which aren't as pronounced, if you will, in the product and product engineering. One of the things you were talking about earlier was one of the more flagship-ish, flagship-y sort of telelogic project doors, which I always love products that are in all caps. That's an exciting ending scheme. And, you know, I think on Redmonk TV here, we've talked about jazz quite a lot with Aragama and other people. And I wonder, when it comes to agile software development, I think the requirements process is pretty integral to doing agile development. How do you see Doors itself sort of moving into, you know, mixing together with sort of Requisite Pro or the other things offered by jazz? Because a lot of the nice features in jazz are around the sort of project and requirements management areas of things. Right. And it seems like there's a lot of nice things that jazz can sort of bleed back into Doors. As a matter of fact, that's one of the reasons why we're taking Composer, Rec Pro Composer. Right. Or, you know, Rational Requirements Composer, I guess is probably a more technical name for it. But basically, Requirements Composer is really a front end to requirements, you know, elicitation. Right, right. Which is really more of a collaborative process that involves multiple communities and tries to harden requirements over time. Right. And tries to keep track of those particular hardened requirements. Which is really, you know, starting to introduce the whole notion of agile evolution into a more formal rigorous requirements process.
8:12But you can't substitute or make the mistake of thinking that one replaces the other. Because in the more formal process, everything has to be documented or you're out of compliance in one form or another. Yeah. So, on the one hand, we want the flexibility of the more agile development model, especially on the innovative edges. But basically, where compliance and regulatory issues are involved, you really want a more formal model that can then be carried through the entire lifecycle to make sure that all aspects of product delivery and product development basically are adhered to. It seems like all throughout Rational's lifespan, if you will, there has been that, I mean, the word you keep using over and over again, there has been that idea of the model you develop for something. Whether it's an architectural model or a process model. And each sort of user comes up with the methodology that's somewhat tailor-fitted towards what their current needs and process and things like that are. And it is, I mean, Jazz does have that nice aspect that it is generalized enough that it doesn't have the one methodology or model that you have to use if you're using Jazz. That's one of the reasons why when you start to dig into the Jazz architecture, there's really three key elements. One is collaboration. Right. So you want kind of a social networking infrastructure that focuses on the domain of, you know, product delivery systems development and software development and delivery. You want a layer that then leverages the collaboration but coordinates the collaboration, if you will, around methodology. Yeah. Right. And the implementation of methodology and process. Okay. So there's kind of a flexible, if you will, workflow automation layer that sits there as well as being based on integration principles. Right. So that you can weave in anything into that collaborative process.
10:12And then, of course, there's the reporting layer that then takes the information that comes out of that automation, comes out of the social networking infrastructure, and then reports it out. Okay. Without necessarily being disruptive to the process. Right. Okay. Which I think is really important. Because what you want to do is make sure that people see reporting in an honest way as a side effect of the tools that they're actually using. And so it allows you to really understand what's going on. Right. In a more honest way. And it gets it out of that classic notion of, wait a second, I worked for eight hours and then I got to write it down for four hours. Which is really a pain. Yeah. Yeah. Well, I mean. And leads to, you know, inaccurate and incomplete information. Sure. To sort of optimizing those four hours, so to speak. Exactly. So being at the telelogic group here and over the sort of course of since they've become part of the rational family, as it were, I mean, how have you seen the telelogic community mixing together with the rational people? Right. I hate to be cliche-ish here, because I wouldn't say this unless it were true. I think it's been a lot smoother than I expected. Right. I think that they came in with a positive attitude. And they viewed this as, you know, basically a natural evolution of what their business had to go through to become part of a larger, you know, more capable, so to speak, globally reaching organization. And in the process, they've looked at it, you know, as an opportunity to really lend their skills and capabilities in that broader context. Because they've embraced it, I think you'll see that in both the broader rational, basically, and in IBM, you'll see a lot of the telelogic people start to manifest themselves, frankly, in broader roles.
12:13Right, right. Okay. We've already got the guy who's the executive VP of business strategy for telelogic, who's now the VP of business strategy for all of rational. Oh, really? I have titles like executive VP. Sure, sure. But, yeah, absolutely. Nirash Chandra is my guy who's in charge of business strategy. Right, right. That makes sense. So there's a nice integration going on. There's a nice integration there, and there will be more people that will weave into the broader organization. Right. Plus, they're the ones who have, you know, in large part, the domain expertise necessary to be able to kick off that systems business we were talking about. Just so you can give us, I guess, to kind of close out, to give us IT guys a sense of what's in the domain of systems things, right? So if I'm an existing rational person, I'm thinking about, you know, with telelogic, there's sort of like new sorts of software that I can get into through the tool. I mean, it takes a lot more than just having a tool to get into software. Sure. But, I mean, like, what are some of the things that, the sort of applications, if you will? Again, it's a loaded term coming from application development, but the in systems that you can see, like, sort of rational be involved in more and more. Well, I mean, I think that what's really interesting to me is, as I tried to illustrate in my keynote, is that, frankly, everything that we use is becoming more and more, quote unquote, embedded with software. Right. Okay. Hopefully, intelligent software, but not necessarily always intelligent software. And those things are becoming interconnected. Okay. You know, I mean, classic examples are automobiles, right? I mean, there's all kinds of information that is now being stored in one form or another in automobiles. In addition to the fact that a lot of that embedded software is now managing more intelligently all the different aspects of actually running an automobile. Everything from fuel-air mixtures to try and generate a lot more, you know, fuel-efficient carburation, if you will.
14:20All the way to new electric cars that are now heavily dependent on a tremendous amount of software to actually manage the fact that you've got four wheels, a chassis, a bunch of batteries, and, you know, something that's supposed to actually act like an automobile. You know, and then when you start hooking that into the fact that these things will be, if they're not already, are going to be more and more through the higher, you know, through a higher bandwidth wireless systems interconnected into the back ends of IT systems and the more conventional, more conventional applications, if you will, of the systems in IT world, what happens is that basically the two are very quickly going to have to relate to each other. And that's where you'll see Rational get involved very heavily, both on the product side and product development side, as well as on the IT and, you know, the more classic IT software side. Bringing the two together, along with all of the other sister brands in the software business in IBM. Yeah. Because we're building out the Jazz platform on top of some of the capabilities of all of the other sister brands. Right. And we're working with people like Tivoli as well as Lotus to bring social networking and operations and systems management into that broader. It seems like there's a, if you use the classic metaphor of a network of all the computers that we have and, you know, little smartphones and devices that, at a pretty quick rate, that network is expanding to a lot more different devices that normally wouldn't be networked at all. I mean, they wouldn't have any contact with outside of themselves, which brings a whole host of new exciting things to worry about. That's right. You can tell I'm a little excited about this. Sure. And, you know, and I really am. Yeah. I really believe that this was a very good move for us. I'm really happy with the people that have come on board from TeleLogic and the assets that they bring to the table.
16:24And, you know, I think we'll be able to deliver something quite special. Well, that sounds great. Well, thanks for taking the time to talk with us today. to talk with us today. - Thank you.