Clarity on PLM

I had the chance to talk with … a number of IBM executives at their Rational Software Conference (RSC2009) over the last two days. I have heard some great talks on the role that software plays in developing a smarter planet, and how IBM can help companies develop smarter products. I have heard them talk about instrumenting the physical world to monitor, analyze, and improve the way it operates (a whole topic unto itself, really).  I have learned a lot and shared ideas with some dynamic, passionate IBM’ers and my peer analysts. My key takeaway is not new, however. I have felt for some time (and my experience at the Rational conference furthered this belief) that IBM has an unprecedented opportunity to bring a systems engineering focus to developing mechatronic products, and unite the disparate mechanical, electrical, and software design processes.

What do they Offer? An Unprecedented Mechatronic Opportunity? Really?

Yes, unprecedented. Really.  Yesterday, I posted about mechatronic product development, and discussed the challenges of linking the different design disciplines (mechanical, electrical, software) that comprise today’s products. Ironically, the picture I chose to illustrate the point was an electronic “Blues Clues” toy, because I couldn’t readily find a picture of a real talking refrigerator. Today, I will focus on what “Blue” has to offer to enable better mechatronic design.

What I believe IBM has to offer is a greater collection of pieces to the puzzle than anyone else. IBM has depth of experience and strong relationships in the mechanical design software (Dassault Systemes and PTC, most notably).  Similarly, they have relationships and experience in the EDA (electrical design automation) market. The final piece to the puzzle is Rational. IBM acquired Rational, and with it a wealth of tools and capabilities in developing software. In particular, Rational has significant experience in developing embedded software and controls. IBM would probably also include deep consulting experience and direct mechatronic design experience (designing their own hardware) as additional puzzle pieces. Oh, and let’s not forget middleware and a service-oriented architecture (SOA) to help glue the pieces together.

Realizing the Opportunity – Pulling the Puzzle Pieces Together

With all of these pieces the puzzle, how can they capitalize on the opportunity in front of them? I will share two perspectives on this. One is optimistic and the other is more pessimistic.

Optimistic View -IBM has the pieces to the puzzle, and has all of the assets and skills they need to pull together a remarkable mechatronic design solution. They understand the systems approach to engineering, have strong relationships with software vendor partners, and know how to pull together a solution for their customers.

Pessimistic View - IBM is a very large company.

I wanted to leave my pessimistic view short and simple, because I think most of you will understand what I mean. Big Blue is … well … big… and they are made up of multiple different business units. The assets and capabilities for these different pieces are not consolidated within IBM. This complexity is just the nature of a company with the size and breadth of IBM. I believe this makes it much more feasible for IBM to pull a mechatronic solution together for individual customers than to fully productize an offering. Given the relative maturity of systems engineering and mechatronic design (and manufacturers’ readiness to adopt it), maybe that is the best way to approach it anyway.

Progress so Far

So what does IBM have to offer today? Clearly, they have a lot of puzzle pieces. And as I mentioned earlier, they have an SOA solution (Websphere) to assemble the pieces. SOA is not a panacea, of course, integration still takes hard work and not every partner solution is equally SOA-enabled. But SOA makes it easier. They have also developed a guide to the puzzle, what they call the PDIF (Product Development Integration Framework). PDIF is the solution offering that IBM brings to their customers to deliver the puzzle pieces in a coherent way. I hope to share more depth on PDIF with you in the future, we are planning some follow up to better understand the technology, the capabilities, and the customer successes that IBM has with the solution.

Implications for Manufacturers 

What does this mean to you? As a manufacturer, how would you start putting this in place? IBM points out some very practical areas, which I agree with:

Requirements (and Requirements Validation)- start with a joint set of requirements that cross the boundaries of mechatronic design disciplines. Use the “V model” to leverage those requirements to drive testing and validation of the resulting design and products.

Change and Configuration Management – change and configuration management are hard processes, and they get harder when different disciplines impact the work of others. Unifying a change management (and/or related configuration management) process offers a significant improvement opportunity for most companies, and requires less change to design activities in each of the different disciplines.

These are two great areas to start for most companies, although each company should really analyze their own opportunities. And nobody should fool themselves that this is a plug-and-play solution. There are difficult business and process issues to iron out in addition to some heavy lifting on the integration front. It will get easier over time. This is a highly valuable effort, but it will require some hard work.

So that’s what I hear from them, I hope you found it useful. Sorry for the long post, this is something that I get a bit excited about (I know, get a real life). What do you think? What else should I have asked them?

Note on Systems Engineering and Mechatronic Design: I recognize that I have not done a complete job of defining or discussing “systems engineering” and differentiating it from less integrated mechatronic design processes, but I didn’t want to make  a long post even longer. I will try to follow up with more at a later date.

What I learned this week … came from the keynote and press conference at IBM‘s Rational Software Conference (RSC2009). IBM is talking about how to help companies develop and manage today’s smarter products. What was surprising to me is that the conference is focused on developing software – not physical products – but that a lot of the conversations focused on manufacturers and product development. Are we finally getting to the point where ALM (application lifecycle management) and PLM (product lifecycle management) can be discussed in the same sentence?

A Little about “Mechatronic” Products

According to IBM’s keynote, 70% of products have embedded control systems. This means that your next refrigerator may just be “smarter” than your first PC.  OK, that really depends on how old you are, but my first PC wasn’t all that smart. The point is that a traditional mechanical product has evolved to incorporate a significant amount of software. Engineering and product development has evolved from mechanical design to a combination of mechanical and electrical design (like a “dumb” refrigerator) to mechanical, electrical, and software design in more sophisticated products (like a smart, talking refrigerator that automatically adjusts itself based on usage, season, time of day, or other factors). Another statistic quoted was that 90% of all innovation in the automotive industry is in software. While I can’t validate the percentages, the sentiment is definitely true. Many products today would not be what they are without software.

So What’s the Problem with Mechatronic Design?

There are three very distinct worlds within product development:

• Mechanical Design – The physics of the product. For the refrigerator it is the body, the handles, the shelves, the compressor (or parts of it), and other physical aspects of the product.
• Electrical Design – The electronics in the product. This can be as simple as wiring, more complex like a printed circuit board (PCB), or maybe a fully programmable chip or processor (that in turn requires software).
• Software Design-The brains of the product. This can included software algorithms that are embedded on the chips of the product, or could include programmable functions of the product. Hint – ever notice that some of your products you didn’t expect to hook up to your computer have a USB port? It might just be an indicator that your product (perhaps your tv set today, but maybe a lot of other products in the future) is set up to get software updates from the Internet.

So why is this a problem when developing products? The fact that there are three distinct design elements of a product is not the problem. The problem is that each of these design elements has it’s own lifecycle, and each impacts the other. If the mechanics, electronics, and software were unrelated then they could all be nicely designed in parallel without issues. Unfortunately, what makes today’s products “smart” is exactly what makes them hard to design and manage – the software is a key part in controlling how the product’s electrical and mechanical elements function.

Implications for Manufacturers?

The implications for manufacturers today is that product design is getting more difficult (as if it wasn’t hard enough). Processes like change and configuration management that are already hard for one discipline (mechanical, electrical, or software) need to be elevated to the systems level to encompass the whole product. Teams working on individual aspects need to collaborate earlier in the design process.

This will not happen overnight, but the companies that get this right will have a tremendous advantage in bringing high quality products to market, and avoiding late conflicts between the different disciplines that drive high product development cost and product introduction delays.  This is the future of product development, and today’s disjointed processes will not be competitive when the leading companies figure this one out.

So that is what I learned this week, I hope you found it interesting. I will post later this week on what I hear from IBM in regards to addressing mechatronic design issues, and what their vision is for addressing ALM and PLM holistically. Let me know what you think.

NOTE:OK, this picture is not a real talking refrigerator, I admit it. This is a toy. But toys are just one more example of mechatronic products, and they will continue to get more sophisticated (incorporating physical motion, Internet connectivity, and “thinking” over time).