[Steve Shoaf introduction] So we'd like to first of all let Tony and Dominic weigh in on what they're seeing as some of the engineering challenges associated with the development of Smart Products. So Tony, what are you seeing out there? Well, I think Steve, as you said, basically we're seeing the whole equation's being changed. I mean, software has gradually been evolving over the years in its role in Smart Products. Initially it came in almost...i shouldn't say almost. It came in as an afterthought, literally, in that you had some smart fuel injectors, you know, you had some smart little 8-bit chips in there that basically regulate the fuel injector, but it was a self-contained system. And I'm giving an example here from automotive, but you can basically look at this and just go to any industry. But since that time, basically software has really come to the point where it's not only becoming a first-class citizen in the product engineering process, in the product lifecycle, but it's also in many cases defining products. So it really is interesting. I find this a fascinating time to be in, just as you said Tony, I completely agree where -1-
for instance, just pick the latest iphone launch. A lot of us, I know, are expecting fixes for the antenna, for the battery which is draining super quickly, but the innovation really is going into the software. It's almost a similar kind of transition that industry went through, that discrete manufacturing went through back in the eighties when you had basically Japanese basically taking some American concepts of basically of lean manufacturing and just in time with the idea of, let's postpone, for instance, getting the inventory to the plant as late as possible... But also, let's postpone assembly of the product as late as possible just in case, basically, the market decides that it wants different types of options. And I think increasingly you're seeing that become very mainstream not just in areas like, say, Personal Computers -- which is where that started -- but down to basically big products like cars or refrigerators. DOM: That's a perfect example. I mean, we're seeing today lots of customers, when they're looking for functionality in, let's say, high-end cars, they are looking for all of the fancy little gadgets and intelligence and exciting things that go on in the car... -2-
Which not only has a real impact on that initial design, but also we're seeing a lot of thinking going into the full lifecycle, the full lifetime of the products, because getting that product out right now isn't enough. So I'm wondering if there might be cultural aspects associated with integrating software, particularly maybe resistance or difficulties by mechanical engineers or even electrical engineers who have been doing the same things for the same way for a long period of time, if they may be facing difficulties with this integration. Could you guys comment on that? Sure. I'll be happy to dive in there. Which is obvious...well, part of it is that it's just the nature of the beast or the nature of the profession that engineering's traditional been a very silo'ed occupation. DOM: I know with a number of our clients we've seen these shifts in power where, should PLM be the win-all the end-all and be the center of everything? And actually I know one of our competitors, at their user conference they very recently just presented a big picture with PLM as the center of everything, which will probably appeal to those teams who really think that, hey, let me hold on to my area. I won't go into this for the moment, but when -3-
you mentioned that issue before about whether PLM should be the center of the universe. Boy! That is a whole other can of worms. [LAUGHTER] We can deal with that a little later when we get more in the technology area. Yes, but there is very much of a people aspect to that. DOM: But at the same time -- and this comes across perfectly in your picture here -- there's that need for people who understand the big picture which is not necessarily something that they've been trained for. And I know some of our customers have been told okay, well, you're the oldest person -- or, the most experienced person, to be more politically correct -- in these projects, we'd like you to move into more of a systems engineering role. There's a good reason why basically when we designed this slide that we put systems engineering in gray. Basically what it means is that you need to dye your hair gray to basically become a systems engineer. [LAUGHTER] Each engineering discipline has different processes; is there a way to integrate those processes so -4-
that there's more collaboration that takes place earlier in the design? This kind of gets into the topic also of agility, which we know is a topic within software engineering. But in an engineering discipline where you've had much more rigid processes and much more tradition, does the concept of agility fit there, as well? First I'd like to say that when we're talking about agile and agility, I don't want anyone to think that we're going to down a certain definition of agile, because of course, some people say well, agile isn't applicable here because agile says teams must be located in the same room and of course, that won't happen on my projects. I mean, it's just an attempt to address the huge challenge of touching all of the data that could be owned by all of the different design participants who now can be distributed all over the world. I mean, you know, we don't have a single repository in our engineering building where all the engineering teams sit anymore; we've got it distributed worldwide. So can you guys comment on any strategies, you know, outside of putting everything in a single repository? Strategies for accessing all the data where it may reside? And it kind of supports this idea that you brought up, Tony, of federation. -5-
And so the idea here is to have kind of a nerve center, but that nerve center basically tells you what's happening here is not necessarily storing that single version of the truth. It's telling us something's happened over there, and so therefore, there's hopefully some sort of data. TAVASSOLI: I'd point to a couple of initiatives that do exist today to help address this. The first I'd mention is OSLC. OSLC stands for Open Services for Lifecycle Collaboration, which is, as its name indicates, it really is an open initiative here to help solve this type of lifecycle conundrum. Another topic. I don't want to take us too far off topic, but there's a question regarding cloud. Does cloud play into any of this? Do you see any use for cloud in the near future? [Shoaf closing] [END OF SEGMENT] -6-