Foreword

---

I had been working for years in the SCM field when, in the mid 1990s, one of my customers, Dassault Systems, a major CAD vendor, asked me to make a study of PDM tools and concepts and specifically of AP203 (STEP Application Protocol). I had no previous knowledge of PDM and was due for a series of surprises.

The first surprise was seeing how difficult it was for newcomers to enter the field. It was necessary to read large piles of obscure documents and standards (STEP), and, through discussions with a PDM colleague, to slowly understand what were the underlying concepts and the intentions behind these concepts. It took me a few years of effort (not full time!).

The second surprise was to see that PDM, fundamentally, addresses the same issue as SCM, (i.e., the control of the evolution of complex systems). This logically resulted in PDM consisting of concepts and tools similar to those found in SCM, such as data modeling, versioning, and concurrent engineering.

The third surprise was the realization that despite the many similarities between PDM and SCM, my unawareness of PDM was not an exception. Most, if not all of my colleagues working in SCM were equally ignorant of PDM. I subsequently learned that the reverse was also true; PDM specialists were just as unaware of SCM. I could find no one who was a specialist in both fields. Both areas were ignoring each other (and still do) and were essentially (re)discovering, (re)developing, and (re)inventing the same things. A huge amount of expertise was being wasted.

The next surprise was to learn that, behind the apparent similarities, at least some of the differences between PDM and SCM were deep and fundamental. I learned that though these two fields have similar global objectives, each addresses specific concerns, thus resulting in differences between concepts and incompatibilities between solutions.

At this point it was clear to me that, for many reasons, both fields would benefit from closer cooperation. For example, considerable expertise had been accumulated in both fields and some of the original solutions found and validated in one camp were clearly relevant to the other camp, and vice versa. For scientific and technical reasons, such closer cooperation would be very beneficial. The major reason, however, for cooperation is that today, all major projects include hardware and software. All analysts forecast an ever deeper interdependency between hardware and software, and potentially a complete merger between both, as exemplified by the system-on-a-chip (SOC) domain, in which the designer is free to decide if a function is to be provided by hardware or software or both, and in which such decisions can be changed at any time during design and even during the commercial life of the chip. This trend clearly illustrates the need for a tool (or tools) that can handle the design and maintenance of systems containing both hardware and software in the same way.

A further surprise was to note that at that time, there was no interest in addressing the development of a tool capable of supporting the design and maintenance of systems combining hardware and software. I therefore made a first assessment of the difficulties of realizing such a tool. Indeed, the difficulties were many and there was no obvious way to achieve the goal. A successful solution would require serious research and technical investment, and would potentially require years of rework, calibration, and debugging. Nevertheless, I was very disappointed to see that this work was not passionately undertaken.

Without a common understanding of both fields, at all levels (goals, concepts, and techniques), it is not likely that the SCM and PDM communities will meet on common ground, and therefore, there is little hope that the tool(s) we desperately need will be produced. Considering the amount of time that would be required for such an undertaking, its initiation should be delayed no longer.

This is what this book intends to do (and it succeeds). It first presents both fields clearly, precisely, and concisely. In itself, this is valuable because no clear survey of both fields is available; but the major contribution of this book is its point-by-point analysis of their similarities and differences. The authors present an honest assessment of the current state in both fields; they make no attempt to show that one domain subsumes the other, nor attempt to “sell” one solution or one technology. Indeed, they clearly show the contrary—that PDM and SCM tools are successful in their respective domain, but are unable to satisfy the needs of the other.

The real goals of this book, and its strength, are a thorough analysis of what an integration of PDM and SCM could mean and a presentation of what it might look like. The authors describe different possible approaches and comment on their strengths and weaknesses. This analysis is state of the art and is based on real experience.

The authors are the right people to write this book, as the case studies clearly show. They worked for years in industry at Ericsson and ABB or in close cooperation with them; they were mostly in the SCM camp, while their respective companies were primarily involved in PDM. They had become experts in SCM but were asked to solve the issue of PDM and SCM integration. It is then that they realized, as I did myself, how difficult the integration is, and a few years later they decided to write this book.

I am sure that this book will satisfy those wanting to learn about PDM, SCM, and their differences, as well as those involved in trying to work in both fields. I personally hope that it conveys to researchers and practitioners that this is a very challenging and fundamental topic and that it will foster serious work in finding a satisfactory solution towards integration.

Jacky Estublier,
Research Director
Laboratoire Logiciels, Systemes et Reseaux LSR
LSR, Grenoble University
Grenoble, France
June 2003

---