Well, hello everybody. Here we are in Austin, Texas at the TeleLogic User Group 2008. I think it's Innovation 2008, if I recall correctly. And we've got another guest with us. Would you like to introduce yourself? My name is Harry Kaneman. I'm a technical consultant with Rocket Gang. We provide a training service and product resale on the TeleLogic brand, as well as the IBM Rational brand. We're on the system side. So we've been involved with systems development since the late 80s, early 90s. And from that perspective, we've been very tied to the Rational brand, who was acquired by IBM about 2001, I believe. So we've been worked in the system space for quite some time, and we've worked with the Rational tool. TeleLogic is in that same space as well. So with TeleLogic, what they bring to the table is a, I'd say, a newer tool set, if you will. The thing we're seeing with customers is this, that a lot of our traditional Rational customers are running into a few issues with their customers. Their customers are expecting UML2O, SysML, DODAF, and the tooling that Rational provided in the past didn't support those languages. So tools like System Architect, tools like Rhapsody provide the customer the ability to do that, as well as the ability to execute their models. Another thing that our customers, customers are demanding. So our customers, the system developers, their customers are demanding executable models. I mean, we're hearing actually from procurement people saying, quit giving us PowerPoint and Visio diagrams as system architectures of our systems, hand us instead executable models. So that better convinces the customer that we understand the scope of the system, the behavioral aspects of the system, before we spend lots and lots of money to go execute it. Right.
2:00I come from a, I don't know what you systems guys call it, but just like software, software. You know, more traditional. Sure. Software for computers sort of space, right? Correct, yeah, yeah. And, you know, I can sympathize with the idea of like, quit giving me Word documents. Right? For requirements. Exactly. Like, give me something that I can plug into the system that actually helps me, you know, get started at least with what you're wanting. Because the translation between, you know, PowerPoints or Word documents or whatever into actual, into whatever that next step is, is where a lot of the sort of loss occurs. What's been the evolution in the system space of that? I mean, is it just now happening that there's actually executable things? A lot of this, in my opinion, isn't really new. It's just catching on. Right. And I think the tooling's catching up. I think, for example, what we described earlier, the fact that ROSE and ROSE Real Time, for example, didn't support the ability for systems engineers to execute their models and write behavioral models, where tools like Rhapsody provide that. So, going back to your question about how has it evolved, I think that the systems that we build today, especially in the last decade, have gotten so complex from a behavioral understanding perspective. Yeah. I mean, it wasn't 15 years ago that a cell phone had 10 buttons and a send and an end. Right. And that was the interface to a cell phone. Yeah. It's not hard to understand the behavioral interface of that type of system. I mean, look at any cell phone you go get at Sprint or Verizon today. Think about specifying and understanding and contextualizing in system context that type of a system, and then expressing that to all the people that go build it. Right. You know, the methods we used a short time ago, they don't scale. So, we need new approaches and new techniques and languages to communicate, like SysML, like Dora. And that seems to be in the systems area. There's that explosion in features, which, you know, that's the bright side of it. And the sort of, the problem that creates is a lot more complexity and everything, and then a lot of interdependencies between things like that. I'm curious, in the systems space, like, it seems like, you know, what we software guys
4:00would call embedded, the embedded market, whatever pieces of hardware. Right. It seems like more and more of those are, no matter what hardware you have, it's sort of on the network, and it's networked together. Oh, yeah. And I mean, that seems like a whole other dimension of complexity that suddenly, the interaction for a device isn't just someone's fingers, it's like other devices out there. Correct. And a system is no longer just a single node. Right. A system is a collection of a lot of interoperable nodes. What we're looking at from that perspective now is system of systems. Yeah. To say that I have a large system that spans, you know, globally. I mean, a system might be global. Well, the mission for that system or the business case for that system spans a bunch of other systems as well. Right, right. So, you have to drill down and understand the business requirements or the mission requirements at the top and then push those down to the individual systems. Right. Which then you go build. And if that system is a very large system as well, then you've got to drill that one. It's interesting. It has some of the echoes of, we were talking with someone earlier in our little series here about enterprise architecture. Mm-hmm. And there's this same idea of, you know, you find yourself feeling like you're a puppet master or whatever. You're sort of looking down at all these interdependent things and getting that diagram, if you will, or that model that fits everything together seems like it's integral for very complex systems. Oh, absolutely. And along those lines, so enterprise architecture, you know, is what large organizations say, "Hey, we've invested a lot of money in a bunch of disparate systems and we have a bunch of processes that run across those. We know because we're a large business. Well, what are we doing? And how can we optimize them? And what other systems do we need in place to better optimize those and reduce some of our costs?" Right. Well, it's the same thing in kind of mission critical, you know, mission critical systems that are not IT. They're more defense, aerospace, et cetera. You know, building a Boeing plane. Sure. There's a lot of different systems that have to collaborate on the plane. And then, as you pointed out from a network perspective, the plane has to collaborate with the ground. Boeing 777 had a requirement that it had to radio the ground. When it detected an error internally as it monitored its health, it would forward a request to the ground crew that said,
6:05"I have a problem, and when I land, you need to replace this part on me." Right, right. Yeah. So, you know, you need that kind of -- so that there's a system that is, again, a system of systems. So, that way, the plane isn't taken offline while we go try to figure out what's wrong with it. Sure, sure. We can keep it flying and keep it operational. We talked about sort of moving towards more executable models of things. But, like, what are other -- both processes and tools in the system that you use to cope with these more complicated areas? I mean, you know, it would seem like, at the very minimum, there's a lot more documenting things. For as sort of, like, bad as a word that can be, but there's a lot of things to keep track of. And I wonder how you do that without the process becoming the end product, and you instead focus on the product. In the IT space, for example, agile practices have emerged. And agile practices advocate continuous development. And our measure of success is working software, not weighing how much documentation we produce. Right. Those types of measures and metrics. Large systems use, to some degree, a lot of those same metrics. The difference is they have to do more planning up front. Right. You know, they need to do more planning, and they need to better understand their system. I think that with large, complex systems, the biggest challenge we have is understanding what we're going to build, and then planning the build. And just like any software development, you know, we run into bottlenecks, we run into surprises along the developments. We have to keep re-planning. Right. You know, you want it to be an agile plan, per se. You don't want to, it's not like building a building where we have a plan, we just execute it, and everything works out as planned. So there is a blend of some agile practices, and the projects that are the most successful, and the most ones that are on time and on budget, are those that recognize that our plans that we produce up front. Granted, we're doing more work up front, more system engineering type efforts up front. Right. But the projects that are most successful are the ones that recognize that we will have to change, and we should plan for change. Like, how do you figure out how much up front planning you actually have to do without going overboard? The primary difference is, I'll use this analogy, you know, we're in Austin, Texas, they have great barbecue here.
8:07Sure. So there's probably some guy down the street here that's got one of the best barbecues in the city. But when he makes his barbecue, he probably just tastes it. You know, a little bit of this, a little bit of that, doesn't have any necessarily standard formula that he uses. Right. He probably has some ingredients, you know, probably some list. Well, contrast that to, what if you have to scale that? What if now you're an entire franchise of barbecues? Right. You know, we're not just that expert, not just that key programmer that's an expert in their field. We have to scale this to thousands of places. Well, that's the type of things we do with our large systems. You know, you have extremely individually talented developers that in isolation, you know, they're extremely good and they can be very productive, kind of like the guy with his barbecue. Right. The challenge is, how do you scale that to a 500 person team, a 1,000 person team, and have all the collaboration and integration that's going to happen with it? So, from that perspective, I think you can appreciate the fact, if we don't go in with a reasonable plan, we'll have a bunch of people just running around all over the place. Tasting everything, right? Right. And there'll be no food left for the customers. Absolutely. People just feed themselves with those giant documents, right? Exactly. So, you need some sense of plan. And another big thing is we live in a little different environment. With large systems, they are big dollar things. And correctly, a customer is going to want to see incremental milestones, accomplishments. You know, so they're going to want to, before we commit a lot of money, they're going to want to have some confidence in the plan and the confidence of the ability of the developer, the development company, to go off and build the system that they propose to build. So, if there isn't a good plan and a compelling case, then, you know, I don't think anybody would want to go forward with a multi-million dollar, multi-billion dollar system that we're going to do. While we do plan up front, the most productive organizations that I've seen, anyway, are the ones that recognize the plan is going to change.
10:08So, we are continually planning. Right. You know, it's not like, it's not a waterfall approach. It's a traditional waterfall approach where we do all our plan and then we just go execute it and everything will work out fine. Right. You know, we do some initial planning. Let's go build those pieces while we're doing some more planning to build those pieces. It's more planning to build those pieces. And the construction aspect or building those pieces, that's giving feedback to the system engineering folk to say, "Hey, this plan you came up with isn't working right." Right. Or, "The pieces we thought we were going to be able to integrate were not going to be able to integrate." Or, "That hardware doesn't work like we thought it was going to work." Right. So, we're constantly having to replan. And another thing I was curious about, and I've talked with some people in the systems area about it, is the idea that, and we're talking about this up front, that software plays more and more of a key role in systems. Right. And at the same time, it seems like software hasn't been in the systems area for as long as software has been in sort of like the generic computer area. Correct. And so, in that sense, it seems like people who are using, who are developers in the systems area are sort of like newer at it. And it means that they're sort of, to put it in a positive way, they can not learn the bad habits that we have on the other side of the house. Right, right. And I wonder, like you're saying you do a lot of training and things like that. And I wonder when you encounter people who are sort of new to the software world, like how you sort of try to get them to avoid the bad habits of like the old software world. On the systems side, so a lot of the system engineers, they aren't the software people and they're not going to develop the software. Right. Their job is to understand this complex system. But to bring up a good point, we in the software space for a long time have been dealing with complex systems. The complexity of our software systems prior to, as you pointed out, a lot of software being pushed into these large embedded systems. Right. We've been having to deal with complexity for quite a while and we have tools and techniques like use cases and user stories and those types of things. It's been interesting to observe the either embracing or the resistance of some system engineers and those types of folks to these other techniques.
12:12You talk to some system engineers and say, "Oh, use cases? How the system is going to react from a user perspective? That's a software thing." That's not what we do with system engineers. Right. Like, "Well, do you really want to leave the behavior of your system up to the software developers?" You know, and if you explain it to them that way, they think about it for a minute and say, "Well, not really." Okay, well then, what's the best way to express the behavior requirements to your development team then? Yeah, yeah. You know, this is something we in the software world have learned from the past. You know, describing user stories in the Agile world or use cases in the IT world, in the IT systems world, is the best approach to describing systems. Some people look at that and look at it as a good resource for them. Other people kind of shunt it and say, "Hey, that wasn't invented here." That came from the software world. That's something we should use. I'll share with you a little story. I was just delivering, a couple, three weeks ago, a class on SysML. And it was to a group of system engineers, and we were talking about use cases and talking about activity diagrams, all things in SysML. And one of the person in the back of the room said, "When you get to something I haven't already done before, why don't you wake me up and tell me?" So some people come with a lot of resistance, you know. "When you get to something useful, why don't you come and tell me?" Yeah, it's nice to meet you too. Yeah, exactly. So that's an extreme example, but I think it's a personality for people. Some people like to embrace change and like to find new techniques and see how can I apply them on my project and try to make it better. And other people, they like what they've been doing forever. It's an interesting point you raised about the use case thing. I mean, it makes me think of to use a sort of now like archaic word, sort of peripherals for computers, right? Where I think every single scanner that I've gotten, like flatbed scanner, like it's a great piece of hardware. And then you use the software and it's just like terrible. Right. And you can tell that the focus was on, you know, more of the systems engineers, the people making the hardware and they sort of just, you know, let those people over there do the software. Yeah. And it would be nice if there was that more unified caring of all parties throughout the process.
14:15That's a prime example of no one looking at the system from the user's perspective. Right, right. To say, "What is the way I would like to use this system?" "Hey, I gave you a button that's able to scan things, you want something more than that?" Well, yeah, I've got a lot of scenarios that might be useful to you. But as you point out, depending on the organization or the program or the project, you know, there's different levels of interest in trying to express that behavior. Right. And you see radically different usable systems because of what you point out. Well, great. Well, thanks for taking all this time to talk with us today. It's always, like I said, it's always fun to delve into system stuff. It's fun to learn more about it. Great. Well, thanks for having me.