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.