November 21, 2011

Reuse is an Event. Sharing is a Journey.

What's New
Integration
Traceability

This article is a guest post by Dr. Charles Krueger, the CEO of BigLever Software. BigLever is a Perforce integration partner specializing in Product Line Engineering for systems and software. The Perforce SCM system provides the power to manage the evolution of source code and other digital assets for complex systems and products. BigLever's Gears solution extends this capability by managing product diversity and asset variation across the product line portfolio. The Perforce/Gears solution integrates time-based CM provided by Perforce and feature-based variation management provided by Gears, across the full development lifecycle -- enabling the orchestrated execution of CM operations as the product line evolves. The content of this article is Copyright 2011 BigLever Software, Inc.

Reuse in Product Line Engineering

The idea of reusing systems and software engineering assets – such as requirements, designs, source code and test cases – has long been the leading candidate for discontinuous improvements in engineering efficiency and quality. The field of Systems and Software Product Line Engineering (PLE) has focused on lucrative opportunities for reuse within a family of similar products or systems.

Reuse in concept is simple, clear and powerful. Reuse in practice, however, has been messy, muddled and anemic. The problem is, the things about reuse that seem obvious don't work, and the things about reuse that work aren't obvious.

This has resulted in many different engineering organizations predictably taking the same ruinous path to failed reuse and PLE initiatives, while consistently overlooking the readily available path to reuse and PLE breakthroughs. Not only has this inhibited the field of systems and software PLE, but it has also unnecessarily stunted the growth and advancement of entire companies and industries.

This contrast in perspectives on reuse – the seemingly obvious things that don't work versus the things that do work that aren't so obvious – can be succinctly stated as: Reuse is an Event, Sharing is a Journey.

Reuse is an Event

Central to the least effective forms of reuse in PLE is the idea that reuse is an event. Unfortunately this is also the intuitive first impression most people have about PLE, and this misperception sticks. The classic example is when an organization creates a library of reusable core assets for a domain. The reuse event occurs during application engineering, when someone finds and reuses a core asset from the library for a new or enhanced product or system. High fives all around.

The reuse event provides 100% reuse on day one, but 0% reuse every day after that. After N different reuse events from a library asset, there are N copies of the asset, plus the one in the core asset library. Enhancements, variations or fixes on any of these N+1 copies results in divergence rather than reuse. To reconcile and consolidate this diver-gence requires a level of manual effort that is proportional to N2. That is, a change to any of the N+1 copies must be reconciled with the other N copies, or N+1 times N.

Now we can start to see the problem with treating reuse as an event. For N reuse events we get savings that are pro-portional to a linear N, but thereafter throughout evolution and maintenance of a product family we incur costs that are proportional to a polynomial N2. Not a good balance, particularly considering that the timespan, effort and cost for the evolution and maintenance phase of a system typically dominates the upfront creation effort and cost.

Forms of reuse that fall into the anemic reuse-is-an-event category include clone-and-own (new systems built by cloning, modifying and maintaining copies of previous system assets), reusable asset libraries, the lego block soft-ware component analogy, and Software Product Line approaches based on separate domain engineering (building a library for a domain) and application engineering (copy-based reuse events from the library).

Before Product Line Engineering
Before Product Line Engineering

Sharing is a Journey

Key to the most effective forms of reuse in PLE is the idea that sharing is a journey. Reuse in this case is not an event experienced in isolation, but rather an odyssey embarked upon with others over time. Unfortunately this is a rather non-intuitive perspective that on first impression sounds like it might be more trouble than it's worth.

The sharing approaches to reuse in PLE are generative in nature, where shared PLE assets are automatically com-piled, assembled or otherwise configured into systems through some type of abstract feature-based specification. This takes us back to the original premise – that feature orientation is prerequisite to success in PLE approaches.

The classic examples in PLE are feature-based product line configurators that select and configure from a supply chain of shared product line assets – such as requirements, design models, source code, documentation and test cases for a product or system family – based on the specification of features and capabilities that are needed or not needed for any particular product or system.

In contrast to reuse events, sharing is long term, and that's what enables success. Reconsider our example of maintaining N different systems that use the same asset, but this time through sharing rather than reuse events that create N different copies. Enhancements, variations and fixes are now done once in the shared, pre-generator form of the asset, so that the N users can all automatically regenerate the new and improved asset, using their previously created feature-based abstract specification.

Without the feature-based abstraction, automation would not be possible. Dramatically better than the N2 cost with copy-based reuse events, the evolution and maintenance of the shared asset is now centrally coordinated for all N users, so there is a linear N cost for the initial use of the asset and a linear N cost for evolution and maintenance. This provides very efficient lifetime amortization through cost sharing across the N products and it allows N to grow very large.

After Product Line Engineering
After Product Line Engineering

An Anecdote

I recently met with a customer group who is effectively using BigLever's sharing-is-a-journey tools and methodolo-gy for their PLE assets and automated configuration. Their management and customers were asking them for met-rics on “how much reuse” they were achieving among their products. They were struggling to find a good way to express this. Can you see what's wrong with the question? Their management was asking for metrics on reuse events, whereas their meaningful benefit metrics were coming from their sharing journey.

Answering a different question provided a better answer and allows them to be mentors to their management and customers on the difference between reuse-is-an-event versus sharing-is-a-journey. Looking across their collection of shared assets, they can create a visually intuitive bar graph to illustrate how much of this asset collection is shared among all N systems in their product family (i.e., truly common), how much is shared among N-1 systems, among N-2, among N-3, and so forth, all the way down to how much of the shared asset collection is unique (today) to just 1 system in the family.

Shifting perspective from reuse-is-an-event on individual products to sharing-is-a-journey for the entire product line portfolio makes it easier to see how much of the engineering effort over time is shared, as well as how the effort is distributed and amortized across the entire product family.

What to Do?

The contrasting reuse perspectives have put the PLE industry into a bit of a quandary. Reusing systems and soft-ware engineering assets is always the best candidate for discontinuous engineering improvements that lead to dis-continuous business benefits. However, the reuse-is-an-event approaches to PLE that seem obvious don't work, while the sharing-is-a-journey approaches to PLE that do work aren't obvious. There's no simple answer to get us out of this quandary, other than to educate. We must all become mentors to promulgate these ideas within our or-ganizations and industries, and to create new mentors who can do the same.

Further Information

Charles Krueger, PhD, is the founder and CEO of BigLever Software, the leading provider of systems and software product line engineering (PLE) framework, tools and services. Dr. Krueger is an acknowledged thought leader in the PLE field, with 25 years of experience in software engineering practice and more than 60 articles, columns, book chapters, conference keynotes and session presentations. Through active involvement in key industry events and organizations, he brings innovative PLE concepts, new generation methodologies and success stories to the forefront of the mainstream systems and software engineering community. Dr. Krueger has proven expertise in leading commercial product line development teams, and helping companies establish some of the industry's most notable PLE practices such as General Motors, Lockheed Martin, General Dynamics, IKERLAN, and Software Product Line Hall of Fame inductees NetApp (previously LSI Logic), HomeAway, and Salion. He received his PhD in computer science from Carnegie Mellon University.

For more information regarding PLE or BigLever Software, see: www.biglever.com.