From subroutines in the 1960s through modules in the 1970s, objects in the 1980s, and components in the 1990s, software engineering has been the story of a continuously ascending spiral of increasing capability and economy battled by increasing complexity. Now, at the dawn of the new millennium, comes the next great turn of the cycle. Software product lines promise to revolutionize the way that organizations, large and small, conceptualize and carry out their software development activities. Software product lines enable companies to field entire families of systems--perhaps containing dozens or even hundreds of members--for little more than the cost of building two or three the old way. This relatively straightforward concept is bringing about breathtaking improvements in productivity, time to market, cost, and quality; and it can be applied to software in every application area and deployed on every kind of platform, regardless of size.
For us, the story began in 1995, when two fortuitous events aligned at exactly the right juncture. First, we quite accidentally stumbled onto a software product line that would forever fuel our thinking; and second, our organization funded an effort dedicated to improving the practice of software product lines.
As researchers at the Software Engineering Institute (SEI), we were scouring our sources looking for case studies in software architecture, a topic just blossoming into the software engineering community's consciousness. We wanted to show that architectural drivers (for example, the need for high performance, security, or modifiability) could be consistently described across different applications and that the same architectural solutions to these drivers would probably surface again and again. This kind of thinking is what motivates the design pattern and architectural style communities. So we wanted to start a "butterfly collection" of architectures, categorized by the problems they solved. Off we went with our nets. One of our colleagues, Lisa Brownsword, mentioned that she knew of an architecture constructed to achieve a quality not in our list. In fact, this quality was not to be found in any of the usual lists of "ilities" that often describe the goals for a software architecture. And yet, Lisa told us, this quality was so important that a company had gambled its whole existence on it.
We were intrigued.
That company was CelsiusTech Systems AB, a Swedish defense contractor supplying shipboard command and control systems to navies around the world. In 1985, CelsiusTech faced a monumental crisis: they were compelled to build two systems much larger than anything the company had ever attempted, and although they had an excellent reputation in their market, CelsiusTech had had trouble meeting schedules and budgets before. Their only hope was to build one solution that would satisfy the (very different) requirements of both customers and--and this was their key insight--would also satisfy customers that they hoped would come after these two. The overriding quality that drove the CelsiusTech architecture was its applicability across a wide (but planned) range of products--that is, its suitability to serve as the architecture for a software product line.
So Lisa and one of the authors (PCC) flew off to Sweden, butterfly nets in hand. As we listened to the CelsiusTech story, it became clear that we were onto something much bigger than just an interesting architecture. Yes, the software architecture was the critical foundation for the product line, but it was only one part of a broader story. In some ways, the architecture had been the easy part compared to changing the way the company did business. Adopting the product line strategy required reorganization (more than once), copious training, and an adjustment in the very way that people thought about carrying out their jobs. Architecture and reuse were the technical keys--but by no means the only keys--to adopting a software product line strategy.
And what had this strategy wrought? Not only did it allow the company to deliver both pilot systems, but on subsequent projects (more than 50 of them, in fact), it took years off delivery schedules, allowed a smaller staff to produce more systems, and sent their software reuse levels into the 90 percent range. As an example of their productivity gains, the integration testing of one of these enormous (1.5 million lines of Ada) real-time, safety-critical, highly distributed systems can be routinely handled by one or two people at most. Porting one of these systems to a whole new computing environment and operating system takes less than a month.
When we returned home and reported our findings, we described the architecture. It was, after all, what we had gone to investigate. It was layered and multiprocess, with a blackboard to mediate between data consumers and data producers--it was, in short, just what one would expect. One of our colleagues remarked how uninteresting it was and, I'm sure, didn't think it justified a trip to Sweden--but he didn't grasp the big picture. What we learned was that even a vanilla architecture, if embellished with judiciously planned extension and variation points and created in the context of an overall shift in the way a company does business, can save an organization from oblivion if the organization is willing to reshape itself.
What a discovery and how fortunate for us that it occurred right at the time the SEI's interest in flexible systems was coming into focus with the creation of the Product Line Systems Program, under the direction of one of the authors (LMN). This new program, like the other three technical programs at the SEI, was launched to carry out the mission of the SEI: to provide leadership in advancing the state of the practice of software engineering to improve the quality of systems that depend on software. But this program had a unique charter: to build on earlier SEI work as well as both commercial and government software product line efforts to enable the widespread efficacy of software product lines. We agreed on two strategies to fulfill our mission: (1) we would codify and establish best practices for organizations wishing to undertake that reshaping to become skilled at producing software product lines; and (2) we would build and equip a community of people interested in working on software product line issues. We set out with enthusiasm to effect those strategies.
In that process, we've worked to gather information and identify key people in the field. We've held nearly a dozen workshops attended by experienced product line practitioners from all over the world. They've told us how they've solved problems in all areas of product line production, and they've let us know about areas where they've stumbled and made the wrong choices as well. We've participated in many other conferences and workshops with software product lines in the agenda (sometimes as a result of our prodding or initiation). We sponsored and held the First Software Product Line Conference in August 2000. (We expect that there will be many more such conferences.) There, almost 200 people gathered to discuss and learn about software product lines. Finally, we work with organizations directly to help them adopt the product line paradigm as a way of doing business. This puts us in the trenches with the people who must undergo the changes precipitated by the shift. Our customer collaborations have two effects. First, they give us the best seat in the house from which to judge and record what works and what doesn't. Second, they put everything we think and counsel about product lines through a trial by fire. If these things are not right--or if they are right but unimportant--our customers/collaborators will let us know in a hurry.
What we've learned is that software product lines represent a powerful paradigm for software that can and does achieve remarkable improvements in time, cost, and quality. Systems turned out in days instead of years. Order-of-magnitude productivity gains. Smaller staffs producing more projects that are larger and of higher quality. Mass customization wherein 20 software builds are parlayed into a family of over a thousand specifically tailored systems. These and other stories are what we've discovered.
This book is the distillation of all that we've learned about software product lines. We describe the essential activities, which are (1) the development of a set of core assets from which all of the products will be built, (2) the development of products using those core assets, and (3) strong technical and organizational management to launch and coordinate both core asset development and product development. We delve beneath the surfaces of these three broad essential activities. To be more prescriptive about what an organization must do, we describe 29 practice areas that must be mastered. The practice areas are divided into the categories of software engineering, technical management, and organizational management according to what types of skills are required to carry them out. For example, defining the architecture is a software engineering practice area; configuration control is a technical management practice area; and training is an organizational management practice area.
The essential activities and the practice areas have constituted the pivotal output of the SEI's product line practice work and are continually updated in a Web-based document. Parts I and II of this book are derived from that document, which is called A Framework for Software Product Line Practice Clements 00b. This work has been used by organizations, large and small, to help them plan their adoption of the product line approach as well as to help them gauge how they're doing and in what areas they're falling short. We use it to guide our collaborations with customers. We have also used it as the basis for conducting product line technical probes, which are formal diagnostics of an organization's product line fitness. It represents our best picture of sound product line practice as described to us by its many reviewers and users--practitioners all.
In addition to the practice areas and essential activities, which offer "what to do" guidance, this book provides software product line practice patterns as "how to" guidance. These patterns give common product line problem/solution pairs in which the problems are product line work to be done and the solutions are the groups of practice areas to apply in concert to accomplish the work. We also chronicle three detailed case studies (and short takes of several others) that show how different organizations have overcome product line hurdles in their own unique ways. Cummins Inc., the U.S. Government's National Reconnaissance Office, and Germany's Market Maker AG all made deliberate decisions to go down the product line path, and each has a compelling story to tell about its experiences. (The CelsiusTech story is chronicled elsewhere Bass 98a.)
The book includes discussion questions throughout, so that a study group (maybe a brown-bag lunch discussion group or a university class) can explore the subtleties of the issues together. We have also added numerous sidebars that tell stories, relate the experiences or viewpoints of others, or simply underscore significant points. Anecdotes in the sidebars are all true and come from first-hand knowledge, although confidentiality occasionally prevents us from naming sources. Many of the sidebars form a series we call "Other Voices." In them we have borrowed (with permission) from product line practitioners' experiences that have appeared in the open literature. They provide a set of first-person war stories that we hope will resonate with readers.
Software Product Lines: Practices and Patterns is the culmination of our efforts to grow and nurture a community of people interested in software product lines. As a reader of this book, you are also a member of this growing community. Welcome.
PCC, Austin, Texas LMN, Pittsburgh, Pennsylvania
0201703327P07312001 
