Big Lever Software, Inc.


Paul's Three Surprises: Part 2

Greetings from Paul Clements:

In the last newsletter, I started a series about the biggest surprises I've encountered with product line engineering in the six months or so since I joined BigLever. The first surprise was that, among the shared assets in a product line, software does not occupy a privileged position and may not occupy any position at all. (See Paul's Three Surprises: Part 1.)

My second surprise is how important the business dimension of the product line automation – the configurator – is.

We've got an app for that. And a partnership, too.

If you're going to supply the automation for true product line engineering, it's going to have to support the definition and exercise of variation points in assets that represent artifacts from across the total engineering lifecycle – requirements to design to implementation to test cases to the thank-you letter you send to the customer after the sale.

These assets come in a staggering variety of forms, many of which depend on the tools already chosen by a product engineering organization to deal with each part of their lifecycle: DOORS requirements modules, Microsoft Word documents and Excel spreadsheets, source files in Perforce and Eclipse, build files for Make or Ant, Rhapsody SysML and UML models, and many more.

If the representation of the asset is "open," great: Your configurator can manipulate it using an available open-market tool. For example, for assets stored as simple text files, your configurator can transform them by word or line substitution using your favorite text utilities. Assets that are Microsoft Word documents stored in Office Open XML format can be transformed by third-party utilities or tools. (Gears provides that capability.)

If the representation is proprietary and closed, or utilities for it are not available or impractical, then the configurator can effect variation points by simply choosing among different large-grained asset variants. For example, in a product line of pet products, some marketing documents are adorned with a photo of an irresistible kitten, others with a photo of an irresistible puppy. The picture, then, is part of the product line's supporting assets. I guess theoretically you could edit some über-image JPG file to kittenize or puppify the pixels, but that's silly. Better to just select the full photo file variant you want to use for the product you're building now. (Gears allows for that, too.)

There's a third case: The representation is open, but only to business partners. Suppose your requirements are stored in DOORS, using hundreds and hundreds of DOORS requirements objects. The representation of those objects is proprietary, but using the pick-a-variant strategy above is out of the question: Swapping in and out whole requirements documents with hundreds or thousands of requirements that each differ by just a little bit is untenable. It would be much better to make an arrangement with the vendor (IBM Rational in this case) so that you can write a piece of software that can insert and manage variation points throughout the DOORS representation of a body of requirements. This software is a bridge, and Gears comes with a variety of these.

This adds another requirement to your product line engineering automation engine that doesn't come immediately to mind (at least, it didn't come immediately to my mind): Does its proprietor have the necessary business relationships to support variation in your assets?

BigLever has a rich set of partnerships that allow Gears to work with the most widely used engineering lifecycle tools in use today, and the soon-to-be-released Gears 7.0 with its PLE Bridge API opens it up to even more partnerships.

So, surprise: You can have the best configurator in the world, but if you don't have the business partnerships to go with it, it's going to be a very lonely configurator.

Powerful, fully integrated PLE automation for all tools and assets across the engineering lifecycle enables a vast reduction in sustainment complexity. With it, you only need to put your shared assets under version and configuration management (CM) control, not your products. If one of your products needs to change, you make the change to the affected shared assets, and simply re-generate whatever products are affected. You never need to change a product (or put it under CM) any more than you need to change (or put under CM) the machine code that comes out of a compiler. This belies earlier literature that called CM for product lines a "multi-dimensional" problem that is "more complex than for single systems." With all due respect to the person who wrote those words – actually, I think it was me – it's not. With product-generating automation such as Gears, the complexity of product line CM reduces to that for a single product, and much less than for a group of separately managed products.

In the next newsletter, I'll write about my biggest surprise of all.

Best Regards,
Dr. Paul Clements
BigLever Software Vice President of Customer Success


Don't miss your Newsletter!
Please help us make sure that you continue to receive the BigLever Newsletter by confirming your subscription with us. This ensures that future newsletters will be successfully delivered to your Inbox and not misplaced into your junk mail or spam folder. To confirm, simply click the "confirm" link in the white bar below. After confirming, you can unsubscribe from our newsletter distribution at any time.