Managing Product Lines by Focusing on Features

Product lifecycle management (PLM) has been the system of choice for product development. Now there’s product line engineering (PLE). Michael Azoff, principal analyst at London-based Ovum Consulting (ovum.com), describes PLE as “an emerging discipline that embraces a higher-level, feature-oriented view of the product.” He explains, “Taking a higher-level, feature-centric view not only makes it easier to communicate and understand product variation, it also makes it easier to manage the software development component of the feature. PLE takes this concept to the next level by grouping design and software necessary for a specific product configuration to be managed as a logical entity.”

Product lines, of course, have been around since the very start of the Industrial Revolution. Managing product lines has been time tested, albeit in generally duplicative ways. Engineers either focus on separate copies of the components for each product; or they make a copy of the product, modify it, and then create a new product in its own silo; or they just pull existing components “off the shelf” and reuse them.

Charles Krueger, CEO of Austin-based BigLever Software (biglever.com), says there’s a better way. He estimates the PLE approach can cut 66% of the time typically spent on managing product variations and developing new products within a product line. PLE, he says, “is a way to engineer a product line portfolio in a highly efficient manner, taking full advantage of the products’ similarities while respecting and managing their differences.”

The variation problem 
“The concept of a feature—a character-istic that distinguishes products from each other—has assumed its place as the way to describe variation,” says Paul Clements, BigLever vice president of customer success. Look at automobiles. Quite a few requirements differ slightly from vehicle to vehicle depending on price (more features are on more expensive vehicles), regional differences around the world (legislative restrictions, cultural conventions, and so on), or competition (new technologies in certain cars within a product line).

These differences affect an entire car design. For instance, Krueger points out, “the electronics on each vehicle have to be the exact right mix for the features chosen for that vehicle.” If “active safety” is a chosen feature, then the manufacturer needs to install sensors to detect obstacles and the car drifting out of a lane, a vibration in the steering wheel to warn the driver—plus the “right” dashboard displays and buttons, braking systems, software to run it all, processor chips to run the software, and wiring for everything to work. None of these can conflict with other features that may or may not exist on that same vehicle.

Unfortunately, product-centric tools aren’t well-suited to manage this level of variation within a product line. It is much more effective, says Krueger, “to view systems and software product line engineering as creating a means of production—a single system capable of automatically producing all of the products in a product line—rather than viewing it as creating a multitude of interrelated products. The PLE epiphany is to focus on that singular means of production rather than focus on the multitude of products.”

Managing variations with software
The Gears PLE Lifecycle Framework from BigLever consists of several capabilities. It has a “features catalog” of all the features (options and varying feature choices)—the superset—that are available in a product line.

It has variation point mechanisms to manage feature-based variations at all stages of the product development. (Think of these variation points as decision points, such as at static code instantiation time, build time, package time, install time, and startup time.) We introduce a notion of a variation point within our requirements. Here’s a requirement; sometimes I need it, sometimes I don’t,” explains Krueger. “We wrap up that requirement with `intelligence.’ That intelligence is the relationship between that requirement and a parti-cular abstract notion of `feature.’”

Last, Gears has a product configurator to automatically assemble and configure assets and their variation points based on the features selected. (The configurator works like a BOM processor, but aimed at a higher level, at product line features.)

The data crunched by Gears—the details about software features and how software relates to physical objects (parts and assemblies)—is contained in other systems, such as PLM, ERP, and other software “tools.” Gears makes these tools “product-line aware.” 

When it comes time to define a particular product, an engineer uses Gears to create a Bill of Features (BoF). “You go through your features catalog and pick the features you want,” says Krueger. “It’s like picking through BOMs, but now you’re working in this abstract view of a product expressed in terms of features.” The configurator in Gears then extracts only those requirements from the superset of features for that product line that match the chosen features in the BoF. The result is the product line portfolio: a variety of products properly configured.

Doesn’t PLM do the same thing?
Tony Baer, another principal analyst at Ovum Consulting, doesn’t see PLE as a threat to PLM. “Most product engineering organizations still conceive of products as collections of parts.” And this is despite an awareness of mechatronics that started in the late 1980s. Bringing the mechanical, electrical, and software worlds together has been, in a word, difficult. Conversations between these very different disciplines have disconnects; concepts are expressed as abstractions, the words are different. For example, explains Krueger, “people from the mechanical and PLM world talk about effectivity; software people are talking about checking in and checking out versions and variances of software files.”
 
Combining PLM and PLE together can help those conversations. Last January, BigLever and PLM vendor Aras Corp. (aras.com) announced the Aras Innovater/BigLever Gears Bridge, which integrates the Aras Innovator PLM BOM processor with BigLever Gears. This way, says Krueger, “rather than use a BOM to determine the features that emerge in a system, start with a BoF to help determine the materials needed in a system, where materials in this case include assets from across the mechanical, systems, and software engineering lifecycle.”

In practice, says Clements, “instead of deriving features from a parts list, as has been the mental model for many auto companies, PLE lets vehicle engineers start the design process by first considering features, then deriving implementation and realization decisions. Features drive parts, not the other way around.”