Software Product Lines and their Architectures
Posted by Charles Krueger, Aug 11 2006, 05:35 PM
I received a simple e-mail query from Paul Clements (co-author of the SEI's book on Software Product Lines). He was having a debate with some colleagues about whether or not a software product line will always have one-and-only-one architecture, or whether one product line can have multiple architectures. Paul was seeking additional opinions, so he solicited comments from David Weiss, Rob van Ommering and myself.
We all three responded briefly and positively with our opinions that one software product line can indeed have multiple architectures. After a fleeting moment of self-congratulation about the fact we all four vigorously agreed on something, Rob sent a message that caused the whole discussion to devolve into an extremely long, extremely deep, and extremely interesting discussion on the meanings of "software product lines", "software architecture", "software product populations" and "sofware product line hierarchies".
In the end, we all sat back exhausted -- once again (dare I say it and tempt fate) in mutual agreement. The results of the discussion seemed to be comparable to those from a small workshop, so we all felt it would be valuable to publish the discussion.
To that end, I highly recommend that anyone with an interest in the theory behind software product lines take the time to explore that discussion -- published as a thread on the SoftwareProductLines.com forums. Your comments are welcome there and here:
A Question About Software Product Lines and their Architectures
If you are short on time (or attention span 
), check out the first 7 entries and the final summary by Rob.
Enjoy!
--Charlie
Charles W. Krueger, PhD
Founder and CEO, BigLever Software
ckrueger@biglever.com
The Elevator Pitch for Software Product Lines
Posted by , Nov 17 2005, 11:01 PM
One of the first things to create when you start a new company is the elevator pitch -- a description of the endeavor that is sufficiently simple, clear, concise and compelling to pique the interest of an inquisitive passenger on a 30-second elevator ride. In fact, any time you start a new project, it is a valuable to test the clarity of your vision by writing an elevator pitch. It can be surprisingly difficult.
A software architect friend of mine with considerable software product line engineering experience was recently interviewing for a new job. He described to me how difficult it was to give the elevator pitch for software product lines. About the time he would get to "building products from reusable core software assets", he said eyes would glaze over.
So, what is a good elevator pitch for software product lines? We clearly need one (or several) if SPL practice is going to spread and gain traction in the mainstream of software development.
Any elevator pitch involving software is challenging because software is so intangible. We typically must rely on abstractions and analogies to physical concepts. Starting with early introductions to software development, engineers learn from analogies such as stacks, queues, and lists. It is problematic when there is no physical analogy for a software concept. When I was a graduate student, I recall teaching a section on recursive functions and trying to find a real-world analogy to aid in the instruction. Turns out that recursion is something that doesn't have examples in the real world. The best I could find was a grocery store tabloid that boldly proclaimed, "Baby Born Pregnant".
Analogies and abstractions for software have to be more than compelling, they have to be accurate to a significant level of depth. The lego block analogy that was very popular in the early days of software reuse was compelling, but too shallow. The analogy quickly falls apart because we can't devise a manageable number of reusable components that easily plug together in arbitrary ways to create the diversity of software systems we need.
I have found that one of the more effective elevator pitches for software product line engineering is based on an analogy to automotive manufacturing for a car model product line (for example, the Toyota Camry product line). First, it's an analogy to something that everyone understands. It's also an accurate and deep analogy to the problems, motivation, methods, benefits and solutions. It can be equally effective for introducing SPL concepts to senior software architects or non-technical managers. And finally, it's a concise analogy that you can squeeze into 30 seconds when needed.
If you would like to share your favorite elevator pitch for software product lines, please post it here or send me an e-mail so that I can compile and post a collection. It would be a great benefit to the field if we had an interesting repertoire of elevator pitches to draw from.
--Charlie
Charles W. Krueger, PhD
Founder and CEO, BigLever Software
ckrueger@biglever.com
Observations from SPLC 2005
Posted by , Oct 19 2005, 11:53 PM
After just returning from the 9th International Software Product Line Conference (SPLC 2005), I thought it might fun to summarize some of my conference experiences and observations. The conference was held in Rennes, France, which is in a French "techology corridor". I could easily do a full article on the culinary experience, but will maintain a technical focus instead.
The SPLC conferences have a history of representing both the academic and industry side of the software product line field. I find this to be a healthy co-mingling of intellectual theory and rigor with the non-negotiable realities of real-world constraints, experiences and needs from software product line practitioners throughout the software industry. I was happy to see this trend continue -- there was a near-even balance with a slight edge to practitioners.
One of the unique aspects I observed about the composition of this year's "crowd" was a significantly larger percentage of industry practitioners who had come strictly to learn about software product line engineering. I taught a tutorial on "new SPL methods behind the new SPL success stories" and the majority of the attendees were of that nature. In the past, the majority of the SPLC crowd already had significant product line experience and came more with strong opinions to offer rather than an open mind and an eagerness to learn. I think this is a clear indication that mainstream practitioners are starting to hear about software product lines and are looking for opportunities to learn more. I anticipate this trend to continue at future SPLC's.
I organized and moderated one of the panels again this year -- this one called "Change is Good. You Go First" -- about the facilitators and inhibitors of mainstream adoption of software product line methods, tools and techniques. One of the primary conclusions from the panel is that the software product line community must find more and better channels to promote SPL practice into the mainstream of software development. Any thoughts from readers on on how to best accomplish this? Where do you think information about SPL development would be welcomed?
One interesting idea that was floated around during the conference, started over a crepe dinner I had with David Weiss (one of the SPL pioneers who gave a keynote presentation this year) and his wife Joanne. David and I are both Apple fans and were discussing the rapid growth of podcasting audio content. David observed that that we should record some of the main non-archived events at next year's SPLC -- such as keynote presentations and panels -- and make them available for subsequent Internet distribution as audio streams or podcast downloads. I thought this was a superb idea. One of our clients who couldn't travel to France for SPLC this year strongly concurred when I mentioned the idea to him.
An experiment this year was to run presentation sessions in parallel for a "research track" and an "experience track". While I felt this was a very successful approach, unfortunately the experience track was added late in the planning process, so it was too late to include those presentations in the conference proceedings. I will be encouraging next year's organizers to make the experience track a first class, peer-reviewed, archived part of the conference.
I received very positive feedback on the Engenio/BigLever software product line case study that I co-presented with William Hetrick of Engenio (Bill did the bulk of the presentation and I summarized by putting it in the context of the evolving SPL field and other industry case studies). During the traditional closing session at SPLC -- the Software Product Line Hall of Fame -- Engenio was the only nomination selected by the audience. Their nomination centered on their pioneering validation of new incremental adoption methods, with transition metrics that are two orders of magnitude better than previously reported from the industry. New to the hall of fame process this year, nominations go to a committe for final vetting of the criteria, so we will get the final word on Engenio at SPLC 2006.
In summary, I think SPLC demonstrated that the field is making significant progress, both in research and in practice. It also illustrated that we are still in the early stages of transitioning SPL methods, tools and techniques into mainstream commercial practice and that there is a latent eagerness by practitioners to take advantage of SPL approaches as they are now becoming aware of the possibilities and opportunities.
--Charlie
Charles W. Krueger, PhD
Founder and CEO, BigLever Software
ckrueger@biglever.com
Bridging Boundaries in Product Line Organizations
Posted by , Oct 8 2005, 07:42 PM
When it comes to the issues of successful software product line deployments, development organizations are not islands. Although we in the software product line community tend to focus on the methods, tools and techniques specific to development organizations, product line issues extend outward into many other organizations in the business.
For example, if a development organization is able to increase by a factor of five the number of new products it deploys per quarter, but the test organization does not, the bottleneck simply moves one step downstream. If the sales organization does not clearly understand the scope of possible products and capabilities in the product line, lucrative sales opportunities offered by the product line are missed. If the product marketing organization struggles to conceptualize and articulate the product capabilities, customer value, business value, and the cost/benefit tradeoffs for extending the product line, then strategic market segments are overlooked and critical market windows are missed.
Effective coordination of product line efforts among all of these organizations requires effective communication across the organizational boundaries. Particularly important -- as the above examples illustrate -- is communication across the boundaries to the development organization. Because the different organizations think in different concepts and speak with different terminology, suitable product line abstractions are required to effectively bridge the boundaries in a software product line organization.
What I frequently see and hear in the industry is that the boundary between product marketing and product development is both the most critical and the most problematic. Product marketing is responsible for defining the products that are optimal for the business and the timelines on which these products need to be available to customers. The interactions between product marketing and development often take the form of negotiations about the products and timelines that product marketing wants and that product development can deliver. In product line organizations, where the rate and quantity of product deployments increase dramatically, the bandwidth and quality of communication at this boundary must also increase.
Some businesses have told me that the effectiveness of the relationship between product marketing and development is one of the important determinants of the overall effectiveness of a product line business. An acrimonious relationship between product marketing and development is a strong indicator of a communication breakdown across this organizational boundary, which ultimately hinders effective collaboration between the two groups.
To facilitate communication between product marketing and development, the first thing to notice is that these two groups tend to think and talk in different concepts and terms. The software product line development community has embraced feature models as the means of characterizing product line scope relevant in their work. Marketing teachings, on the other hand, tell the marketing group not to focus on product features and functions, but rather on the benefits and value of the products to customers.
Fortunately, bridging this communication gap is not as hard as it might initially appear. The perceived marketing benefit and value of a particular product can be viewed as a level of abstraction over the set of features and functions that collectively provide the benefit and value. For example, the product line of iPods represents a spectrum of market-level benefits and values to the customer, such as physical size, cost, navigation and playback style, social image, and so forth. These can be translated into the development-level feature and function combinations that provide the benefits and values. With this translation between the marketing and development concepts and terminology in place, it is easier to imagine how product marketing came to the development organization with their concepts about the new iPod nano, how development translated the new benefits into new features and functions within the scope of the product line implementation, and how development came back to the product marketing teams with estimates of the time and cost required to extend the core assets of the product line to provide the new benefits. When the translation between these marketing and development abstractions is explicit and visible to both organizations, communication and cooperation is improved.
In summary, software product line development methods, tools and techniques should not be designed as though the development organization is an island, but rather should be designed to bridge communication gaps across organizational boundaries. For example, in a recent release of BigLever Software Gears, we took input from clients and the product line community to provide first-class abstractions to support communication between product marketing and development organizations, including automated mappings between marketing concepts such as benefits and values, development concepts such as features and functions, and source-level variation points.
If you would like to share your thoughts on other software product line issues that arise at organizational boundaries, I would look forward to hearing them on this forum or by e-mail.
--Charlie
Charles W. Krueger, PhD
Founder and CEO, BigLever Software
ckrueger@biglever.com
Software Product Lines: What's in? What's out?
Posted by , Aug 24 2005, 10:21 PM
There was recently a very interesting question on the SoftwareProductLines.com discussion forums. It essentially asked the question, “What constitutes a software product line approach?” When you look at all the different software development practices in the industry, how do you determine "what’s in" and "what’s out" when it comes to identifying and characterizing software product line development approaches?
These questions are particularly important to those just learning about the emerging topic of software product line development, who want to know how it is similar to and how it is different from what they are doing today. This struck me as a perfect inaugural topic for the Spotlight on Software Product Lines weblog.
In my experience promoting software product line approaches, I have talked with hundreds of development organizations about software product line development practices. From these explorations, two things are eminently clear: (1) The vast majority of companies today develop a portfolio of related and differentiated products -- nobody builds just one product “flavor”, and (2) The vast majority of development organizations have mechanisms and processes in place to deal with the commonality and variability in their product line -- nobody develops the products in their product line as though each one is an independent product.
These two facts might seem to imply that most software development organizations already have software product line development practices in place. But, we have to raise the bar a good bit higher to distinguish those approaches that offer the order-of-magnitude benefits we have come to expect with true software product line development.
The techniques that I find most often applied in practice include preprocessors (such as IFDEFs), clone-and-own, configuration management branches, file and directory naming conventions, build scripts, installer scripts, and runtime conditionals with config file or database settings. If you look at the standard definitions of software product lines from publications and books (e.g., SEI’s definition or Weiss’ definition), utilizing techniques like clone-and-own or IFDEFs in any form appears to qualify based on the fact that there is predictive and intentional reuse occurring within the product line, with the intent of capitalizing on the commonality and clearly delineating and managing the variation.
However, I don’t qualify most of what is going on in the industry as software product line approaches. As illustrated in the attached PDF (see link below), conventional approaches such as IFDEFs or clone-and-own, can be characterized on a 2x2 grid of how well they capitalize on commonality versus how well they encapsulate and manage variation. The conventional approaches tend to do well along one dimension, but fare poorly on the other. Independent product development (however rare) fares poorly on both dimensions. Software product line approaches manage to rate high on both dimensions of capitalizing on commonality and efficiently managing variation -- there is something else required beyond the conventional approaches.
[attachmentid=1]
I believe that three things must simultaneously occur in order for a software development approach to be characterized as a software product line development approach:
(1) Effectively capitalize on the commonality among the products in a product line in order to avoid duplication and divergence of development effort.
(2) Efficiently encapsulate and manage the variation among the products in a product line in order to avoid the labor-intensive combinatoric complexity during development.
(3) The significant majority of the software development effort should be focused on product line feature development in the consolidated collection of shared core software assets, with a minority of the effort focused on product development. In software product line terminology, development of the reusable core software assets and the associated "feature model" abstractions for reusing the core assets is termed domain engineering, while individual product development based on the core assets and feature model is termed application engineering. Thus domain engineering should dominate the overall development effort.
It is the 3rd item that most organizations in the industry are currently missing. It is not until development organizations shift their perspective 90-degrees -- from product-centric to core asset feature-centric -- that they start to experience the extreme benefits that we expect from a “real” software product line approach.
From this perspective, you can see that the notion of manual application engineering in a software product line approach can be very detrimental. I find that the automated production, such as the feature model compiler in BigLever’s Gears, helps to maximize a development organization’s focus on feature development in the core assets and minimize the focus on individual products. The split can easily be 99% core asset development versus 1% application development.
It’s not hard to see how the majority of development effort is simply wasted effort in a product-centric development approach or an application engineering intense approach. Imagine that you have a product line of 20 products with 90% common files and 10% branched files (with one branch per product), using configuration management branches to sort out the product differences. Sounds pretty good. However, the total amount of varying source code (20 x 10 units) is more than twice the total amount of common source code (90 units). With a product-centric focus and with variations spread across likely thousands of CM branches, it is extremely hard to coordinate the efforts of your product team with the other 19 product teams. The problem quickly becomes intractable.
--Charlie
Charles W. Krueger, PhD
Founder and CEO, BigLever Software
ckrueger@biglever.com
on The Elevator Pitch for Software Product Lines