A few weeks ago, while I was in Boston, I sat down with a couple old friends for lunch. We like to talk about what’s happening in the industry and at one point, the discussion turned towards PTC’s acquisition of MKS.
“I don’t get it. It makes no sense to me.”
In my interactions since PTC announced the move, I’ve gotten quite a lot of reactions like that. In this post, I’ll tell you what I told my friends over lunch that day. It’s a move that will change the industry.
Background
Back on April 7th, 2011, PTC announced their intent to acquire MKS (press release). The transaction was finalized on May 31st 2011 (press release). MKS’ core product is called Integrity and provides Requirements Management, Software Configuration Management (wikipedia entry) and Application Lifecycle Management (wikipedia entry) capabilities.
Capabilities Provided
So, what exactly does Integrity do? How is it related to PTC? My answer to those questions fall into two main categories: one’s related to the product record and the other gets into managing the development process across engineering disciplines.
Bringing Finer Granularity to the Product Record
Before I explain how the MKS acquisition has changed the capabilities provided by PTC, and namely Windchill, I want to provide a little context through an excerpt from a post I published titled Mechatronics Management (Part 3): Software Aspects. Here are the most relevant points.
The development of modern software is actually very similar to mechanical or electrical design. The software is broken down into modules. Those individual modules are then written, assembled and compiled. Overall it’s very similar to mechanical or electrical design in that individual parts are put together to form assemblies. The various software modules that comprise the overall software end item change at different rates, much like mechanical and electrical parts do. And as a result, the assembled software end item is composed of numerous software modules that exist at different versions. Tracking which software module is at which version is essentially a configuration management problem…
The main purpose for this type of system is to ensure that right configuration is correctly tested, verified and flashed into the mechatronic product. And with new software development approaches daily builds (wikipedia entry) are commonplace, this becomes really important…
In the past (and will continuing forward), PTC’s Windchill has had integrations with Software Configuration Management (SCM) tools. That integration manifested itself by showing compiled software end items in the product structure or Bill of Material (BOM). Those integrations, however, did not show the uncompiled code or libraries that were used to compile the final software end item. The parallel here to the mechanical world would be as if a mechanical assembly model existed as a single imported solid without any distinguishable individual parts and features within those parts.
Ultimately the integration between Windchill and Integrity, as that product will also continue to be available for sale on a standalone basis, means you will have finer granularity of a product’s embedded software within Windchill. And we’ll talk about why that’s important once we get to the commentary and analysis section below.
Running Cross-Disciplinary Processes
But it’s not just about managing a finer level of granularity in embedded software. There’s actually a lot of procedures and processes used to develop embedded software. Again, I’ll use an excerpt from my earlier post to explain.
Much like any product, software end items have a lifecycle of their own through which they progress. It starts with requirements management, decomposition and allocation. There is then a planning phase where the software end item’s architecture is designed. It is then coded where project management techniques are used. It is also built and tested on a frequent basis. And finally it is released, after which a change management process governs how, when and why post-release changes are made.
These same procedures and processes are often common across engineering disciplines. Before the acquisition and until the impending integration of Windchill and Integrity, these processes have to be run once in the mechanical engineering domain (in Windchill) and then again separately and in parallel in the software engineering domain (in Integrity). Why? Because these procedures and processes act upon some of the lowest level items in product structure. Uncompiled code and libraries don’t exist in Windchill, so you can’t allocate requirements against them. Likewise with Integrity, mechanical components don’t exist there, so you can’t execute and document verification and validation tests against them there. And most importantly, you can’t run a single change process that affects uncompiled software and mechanical items anywhere as there is no place they exist together.
In the future, once the integration is done, processes and procedures that affect both worlds can be run. You will be able to decompose and allocate requirements across one product structure composed of mechanical items, compiled software, uncompiled software and libraries. And the same will be true of change processes that affect both worlds. Same with verification and validation efforts. And the list of common processes go on and on.
Commentary and Analysis
Quite a bit to take in. I know. I tend to be a little long winded when I get into complex issues like this. But without this level of detail, you’re still left wondering why exactly PTC made this acquisition. But now that we talked about the capabilities that are provided, let’s talk about what it means from a business and personal perspective.
Holistic Configuration Management and Cross Disciplinary Processes
First, let’s talk about the configuration management side of things. To understand what it means though, we need just a little more context.
The same is true of running processes across engineering disciplines. Allocating requirements out across mechanical components and software items either happens in a spreadsheet, in a PLM system, in an ALM system or in both. Regardless of which way you go, you’re doing a lot of manual work to coordinate changes between the systems and the latest product configuration. The same sort of thing is true of a change process or a verification and validation testing process. Most of these development processes that span engineering disciplines are run in a manual fashion today. And as a result, you have the same sort of personal frustration and organizational errors, delays and whatnot you see with manual configuration management.
So ultimately, an integration between Windchill and Integrity to manage a finer level of granularity of mechanical items and software in the same product structure addresses these two things. All the complexity of that configuration management problem between the mechanical and embedded software world can be addressed in a single product structure. I see a huge advantage there in integrating the two.
A Purist’s Perspective: Calling A Spade A Spade
While I admit I am positive about the acquisition, I have to admit I take issue with the entire industry on one thing.
Why did this sort of move take so long?
And I’m not just pointing a finger at PTC alone here, but the entire industry. For years, we’ve been told by PLM providers that all you need in the product structure is the compiled software end item. We’ve been told that all that other stuff really didn’t need to be exposed at a higher level.
The real story behind the lack of movement of PLM providers into this space however is far different. For quite some time, IBM and their Rational product has been the 800 pound gorilla in the software Requirements Management (RM), SCM and ALM space. There really were no software providers that were really focused on embedded software for products. And organically developing a new RM, SCM and ALM product for mechatronics products is a long and hard endeavor. Ultimately, the PLM providers have had to make sound business decisions and invest in areas that would differentiate them and let them go after easier money. And let’s be honest, can you blame them?
In the end, however, it turns out there are some real advantages and benefit to integrating both configuration management and development process across the mechanical and software disciplines. I hope other PLM providers can make similar moves to offer something competitive, however the number of providers of RM, SCM and ALM solutions for mechatronics products are very few.
But all of this leads us to another interesting point, which is this.
Why is no PLM provider managing electronics and PCB information at a similar level of granularity?
The same sort of advantages and benefits seen from managing mechanical and software disciplines holds true of adding electronic engineering to that mix. There are layers of granularity within the PCB, namely traces, types of components and electronic component libraries, that could be exposed in the same way that uncompiled software and software libraries will be within Windchill. The same thing is true of FPGA programming, which is an exploding space in electronics engineering today. However, with three huge software providers and sparse other smaller providers, the landscape seems similar to how the SCM for embedded software space looked like years ago. But who knows. I’m sure we’ll be surprised.
Summary and Conclusion
PTC has acquired MKS and will be integrating the Windchill and Integrity products. That integration will provide capabilities to configuration manage products at a finer level of granularity in terms of mechanical and embedded software. It will also provide capabilities to manage procedures and processes that cut across these engineering disciplines such as requirements management, verification and validation as well as change management to name a few. Ultimately, the benefit will be cutting down on both the personal frustration and organizational errors associated with managing these two areas manually.
So now it’s your turn to weigh in. How are you managing cross-disciplinary configuration management and processes today? Do you see advantages in the capabilities offered by this integration? What about finer granularity in electronics? Should it be added to the mix? Sound off and let us know what you think.
Take care. Talk soon. And thanks for reading.
