NEWS AT SEI
This library item is related to the following area(s) of work:Software Product Lines
This article was originally published in News at SEI on: December 1, 2002
The title of this column is Latin for “Out of many, one.” It is the motto of the United States and expresses the vision of its founders that out of a group of loosely related states would emerge a unified nation. This motto is part of our culture. Culture is what binds a group of people together and gives them a common identity. Culture is the name we give to our habits, our values, our history, our likes and dislikes. Culture is a lens through which we see the world.
Product line organizations have a culture, also. After years of pulling back the covers and peeking inside companies who do this for a living, some aspects of that culture have become startlingly evident. Successful product line organizations employ people who are very comfortable working under the auspices of strong, documented processes. They have long and deep expertise in their application area. They have an identifiable champion who lobbied tirelessly to turn the organization to product lines.
And it turns out that the best ones have an unofficial motto, which might fairly be phrased as “e pluribus unum.” The best product line organizations view their business, their mission, as building a product line--singular. Other companies, including those still climbing the product line mountain, tend to view their business as turning out individual products--plural.
How does this manifest itself operationally? Quite often, a good barometer is the behavior of the developers. In an organization that has not yet reached the spiritual plateau of e pluribus unum, a developer will be likely to change a core asset unilaterally if it’s not quite what he needs and a product deadline is looming. He may feel badly about it, and he may intend to send the change to the core asset team later, but he’ll do it. After all, where would our company be if we didn’t sell any products?
In a mature product line organization, covertly circumventing established processes would simply never occur to a developer. First of all, the processes in place would accommodate core assets that need tweaking under short deadlines; there would be no need to shortcut the process because the process would be robust enough to work in that case. But more to the point, the developer’s first instinct would be to ask “What should I do that is best for the long-term health of the entire product line?”
Each of these hypothetical developers is doing what he believes is in the best interest of his organization. And each is probably operating under the reward and incentive structures that are in place. The first developer believes that the product line approach is a luxury that can only be afforded after the company’s real business is taken care of. The second developer knows that the product line is the company’s real business. How did they each come to these conclusions? What messages has management sent about what really counts when the pressure’s on?
Out of many, one: the Zen of product lines if there ever was one. We first observed it when writing the CelsiusTech case study :
Externally, CelsiusTech builds ship systems. Internally, it develops and grows a common asset base that provides the capability to turn out ship systems. This mentality--which is what it is--might sound subtle, but it manifests itself in the configuration-control policies, the organization of the enterprise, and the way that new products are marketed.
It emerges over and over. From a 1999 case study of the software product line of an avionics manufacturer whom we visited (the case study remains unpublished to preserve confidentiality):
We shared with this group [of senior technical managers] that we hypothesized that one difference between a mature product line organization and an immature one is that the mature organization sees their business as maintaining and nurturing the product line, where as the immature one sees their business as turning out products via reuse. "I can tell you," said one of them immediately, "that is not just a hypothesis." (He meant it was true.) It is exactly how they view themselves--their primary responsibility is to the product line.
And from a report on an engine control software product line at Cummins Engine Company, the world’s largest manufacturer of large diesel engines :
The software product line program slashed development costs and cycle time across these highly varying products and launched many successful products over the past four years… Cummins now has a group dedicated to the study and improvement of software architecture. No longer is Cummins concerned with the separate delivery of software products, but has turned its focus to the delivery of integrated product lines and taking advantage of all the benefits that come with a product line engineering concept.
The difference was put to us in stark relief recently when we urged a company struggling to adopt the product line approach to devote more resources to their core asset team. The senior manager, in a moment of keen frustration as a result of too much business and too few people, lost his composure. “You don’t seem to understand,” he erupted. “We have products to get out!”
We do understand. But we also understand the difference between a short-term and a long-term view. We suspect this company will continue to get products out, because that’s what their management holds to be important. And so their developers will continue to take shortcuts (and be rewarded for it), and their product line efforts will continue to falter. Because by “getting products out” they are not making the investment to fully exploit what those products have in common. As they contract to build more and more products, they are in more and more need of the product line paradigm, and are less and less likely to achieve it.
I spoke recently with someone who just finished a market study of twelve organizations who are producing e-commerce software. “Mass customization” is the order of the day; they produce many versions of their products, tailored to individual customers. Or at least, they would like to. The market study asked about their ability to manage the different versions effectively. Seven of the organizations responded that they had already “hit the wall”--that the complexity of keeping track of the deployed versions, and the assets that went into the building of each, was already consuming vast amounts of time and intellectual capital, and they were on the verge of losing control completely. Four of the organizations avowed that they weren’t yet to that point, but they could all see that wall fast approaching. And one organization was so intimidated by the problem of tracking multiple versions that they actually refused to deploy more than one version of their product. If a customer wanted something different, well, sorry, that’s not possible. My contact asked each of them if they thought they could use technology that would let them manage their software as a set of variations off of a single product, rather than so many unrelated products. “It was amazing,” he said. “You could see the light go on above their head. It was a way of thinking about their business that had never occurred to them before.” It was an e pluribus unum epiphany.
Out of many, one. For the mature product line organizations we have observed who have this motto, it also describes their position relative to their competition.
 Brownsword, L. & Clements, P. A Case Study in Successful Product Line Development (CMU/SEI-96-TR-016). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1996.
2 Dager, J. “Cummins’s Experience in Developing a Software Product Line Architecture for Real-time Embedded Diesel Engine Controls.” Donohoe, P., ed., Software Product Lines: Experience and Research Directions. Boston, MA: Kluwer Academic Publishers, 2000: 23–45.
3 Clements/Northrop, Software Product Lines (pages 6-8, 38-40, 41-44, 46-48, 180-183, 195-197, 226-229, 264-272, 295-299, and 427-430). © 2001 Pearson Education, Inc. Reproduced by permission of Pearson Education, Inc. All rights reserved.
Paul Clements is a senior member of the technical staff at Carnegie Mellon University's Software Engineering Institute, where he has worked for 8 years leading or co-leading projects in software product line engineering and software architecture documentation and analysis.
Clements is the co-author of three practitioner-oriented books about software architecture: Software Architecture in Practice (1998, second edition due in late 2002), Evaluating Software Architectures: Methods and Case Studies (2001), and Documenting Software Architectures: View and Beyond (2002). He also co-wrote Software Product Lines: Practices and Patterns (2001), and was co-author and editor of Constructing Superior Software (1999). In addition, Clements has also authored dozens of papers in software engineering reflecting his long-standing interest in the design and specification of challenging software systems.
He received a B.S. in mathematical sciences in 1977 and an M.S. in computer science in 1980, both from the University of North Carolina at Chapel Hill. He received a Ph.D. in computer sciences from the University of Texas at Austin in 1994.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.
For more information
Please tell us what you
think with this short
(< 5 minute) survey.