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: January 1, 2005
In a 1947 speech to the House of Commons, Winston Churchill said, “Democracy is the worst form of Government, except all those other forms that have been tried from time to time.” Sometimes the two-part organization for product lines seems to deserve that sentiment. In this column, we’ll look at Cummins Engine Inc., a manufacturer of commercial diesel engines. Cummins has made the two-part organization work, but not without some hard lessons that are worth a closer look. One of the most common strategies is to have a separate core asset group to provide core assets to the product-builder groups, and this is the strategy that Cummins chose.
The two-part organization certainly has some advantages. A separate core asset group provides a focused setting where the product line as a singular entity can be managed and can evolve. It provides a central repository for the commonality and variability knowledge that is essential to running a product line. It is the first place where a new product idea can be explored for feasibility by seeing how many of the core assets the product would use. It’s the place where cross-product commonality can be identified and exploited. It provides core assets that are generic across the entire family and not tilted toward any particular project.
But it can be tricky to run. For one thing, a product line manager has to staff a core asset group carefully. At one of our software product line workshops, a speaker rose to say that he could not entice any of his people to work in the core asset group because they felt it was too far removed from the real business--product delivery. But the next speaker said that in his shop, everybody wanted to work in the core asset group because the software they wrote was used many times, and that’s where they could have the biggest impact on their business. The core asset group generally requires the most talented designers and implementers, who are of course the most coveted by the project teams that will probably have to give them up.
Morale is a big issue with the two-part structure and is almost always overlooked. The core asset group forms a convenient target when things go wrong for the product builders, but they don’t always seem to share in the warm spotlight of success when things go right. Members of the core asset group at Cummins told us of the time when a couple of errors were found in a delivered product, which is very bad news. E-mail flying around at the time accused the core assets of being responsible. It turned out not to be so, but somehow the retraction (if it appeared it all) was not circulated with the same enthusiasm or at the same shrill volume. And, they said a little wistfully, when things do go right, it’s the product team that gets the tickets to the Indy 500 as a reward, not the core asset group. In thinking about organizational issues for product lines, Ron Temple, the Cummins vice-president in charge of the effort, lists team morale as an area of high concern:
A crucial challenge is maintaining team structure and morale. The “kudos” for product delivery will tend to go to the team closest to the end user customer in terms of customer and management visibility. The pressure and the “recriminations” for perceived delivery issues will tend to be aimed at the central team who are working to balance implementation, and therefore delivery, across multiple BUs. This tension can be ameliorated several ways – rotation of members between both types of teams, either on a temporary or long term basis, is one good answer. Living in your supplier’s or customers’ shoes for a while has very beneficial effects on your appreciation of the other person’s challenges.
Finally, the core group must be careful not to engender resentment by being seen to impose its own standards and processes and tools on the product groups. At Cummins, “core” was sometimes seen as a four-letter word, just like “evil” or “Borg” (as in “You will be assimilated; resistance is futile”). This can be frustrating for a group trying to juggle the concerns of multiple project teams and keep the big picture in everyone’s view.
What made the two-part organization work at Cummins? In our view, four things: (1) having a champion in a place of authority; (2) the culture of cooperation within the company; (3) an effective funding model; and (4) achieving product-based consensus on priorities. We’ll discuss the last two here.
The “Funding” practice area is concerned with who pays for the core assets. It may have seemed like an esoteric, possibly dry little practice area, but funding at Cummins is not only what gets the core assets built, it’s what gets them used. Funding is used to drive the right behavior and establish a healthy organizational tension among the groups. Here’s how it works: The budget for the core asset group is established. Each business unit is billed a portion of that budget in proportion to that business unit’s overall sales. Thus, each business unit has every incentive to use the core assets because they’re charged for them whether they do or not. Once again, the tendency to rely on cross-organizational sources is reinforced by policy. A funding model like this is a sure sign of whole-hearted endorsement from top-level management of the concept of core assets and therefore of product lines. It’s more than lip service; management is voting with their pocketbooks. A by-product is that business units (or for that matter, individual projects) are strongly discouraged from bypassing the core asset group by building their own software. No project manager wants to stand up in front of his or her peers and admit to having the resources to commission duplicate work. That’s a sign of a project that apparently has too much money, and that’s a situation that can be quickly remedied.
This brings us to the fourth factor that makes the system work: There are weekly technical planning meetings between the core asset groups and all of the product groups. These meetings are used to discuss new feature requests and trade information, and are invaluable at finding new areas of commonality. And it is at these meetings that the project managers put in their bids for what they need from the core asset group. They do this by prioritizing the change requests and problem reports that are in the core asset group’s queue. The elegance of this approach is two-fold. First, it relieves the core asset group from having to decide what’s important to the product groups, and thus removes them from being seen as legislating product priorities, something that would surely be resented. Second, it compels the product groups to work out among themselves what the actual priorities are. No project manager will stand before his or her peers and claim that all of the change requests are critical. The meetings force consensus among the product groups, and once again the good-of-the-whole culture is reinforced by organizational policy. The net effect is that it lets the core asset group be responsive to the product groups as a whole. The product groups regard them not as alien outsiders forcing assets on them, but as a service group driven to be as responsive as they can by the wishes of the group. “Having actual meetings is critical,” one of the participants told us, “because you have to look the other managers in the eye when you say what your project’s priorities are.”
What if a product group really does need a core asset, but the core asset group is at capacity and the need isn’t deemed a high priority by the group as a whole? Does the product group build it? No. If the need is really for something common, and the product group has the resources to build it, then those resources are re-allocated to the core asset group.
Cooperation among the core asset providers and the product builders has made the two-part organization succeed at Cummins; the Cummins people called it “concept alignment,” the sense that all groups are working toward common goals for the common good. How they work is defined in the operational concept that must be communicated to all those involved.
Dr. 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.