A Question About Software Product Lines and their Architectures, Transcript of a very interesting e-mail discussion Options

[David Weiss]

(2) You are wrong because you are viewing architecture in a (too) narrow
sense, as the specific structure of a product (I'm exaggerating a little here :-),
rather than as the common agreements between the products.

It seems to me that much of the ambiguity and any disagreement in our discussion center on the definition of architecture. This topic, unfortunately, could be a morass. (From the academic side, that means lots of potential papers.) As a side note, the book I most often recommend to people these days who have to describe an architecture is Documenting Software Architectures."

(3) There *is* an issue because many researchers in the product line field
share one or both of these views, and too little attention is paid to widen
the scope of product lines (hey, wasn't that the title of an interesting paper :-)

So, what are the interesting research questions?

(1) We know that reuse between organizations is successful (paid or unpaid,
i.e. buying (large) parts of the software from other companies, or taking it
from the OpenSource domain). We know that we can make reuse within an
organization successful by carefully defining the scope and then analyzing
commonalities and differences and setting up a (classical) product line. But
can we also make larger scale reuse within a company happen, or are the
organizational complexities too large and the economic benefits too small?

The economics are central, here, I think. I know that in Avaya these ideas continually resurface because management realizes the potential cost and quality savings, and sometimes even the value. The organizational complexity issue is definitely interesting. Transforming organizations is the biggest problem I face, and as you know, I have been searching hard for new ideas.

(2) Of course a product line (however wide) has a single architecture :-),
otherwise the assets wouldn't work together (architectural mismatch)... Of
course, each product has a specific architecture that differs from that of the
next product in the same product line, whether in small details or in structure...
The real question is: what do you have to agree on at the product line level to
make the assets (requirements, code, tests, ...) work together, while maintaining
a sufficient amount of freedom to implement products differing in functionality
and qualities and therefore architecture (like your fault-tolerant example, or
my TV - DVD example).

Again, we have the problem of defining what a "single architecture" is.

(3) Derived from (2): what kind of analysis can you do at the level of the
product line, so taking all possible values of variation points (which may include
changes in the structure) into account, and what kind of analysis must you do
at the level of individual products (or subsets of the product line).

I think we are strong in setting up and analyzing specific architectures for
single products and (very) small sets of products. I think much work still needs
to be done in widening the scope.

Agreed.

Note that more and more architectures are emerging that allow lots and lots
of variation, or put differently, that are not design for a single specific purpose
but rather for a whole class of systems, like Eclipse (everything you ever wanted
to do with inheritance, and then much more :-) but also Apache which I'm
studying now, which claims to implement any generic network server, rather
than just a specific http daemon...

Somehow, my nutshells always turn out to be quite large... :-)

Think of coconuts.

[Rob van Ommering]

Okay, here's my answer :-)

First of all, Paul, don't take my statement that you were wrong too literally :-)
In fact, I agree more with you than you might think after my last e-mail :-)
I was just trying to make a point (actually two) that I consider to be important
and not widely acknowledged. Here they are:

(1) Product Lines should be taken in a wider scope than most people currently do.
Or we should define a new term for this (populations? hierarchy of? subproduct lines?).
Why? Because more reuse is possible and economically needed than just within a narrow scope.

(2) Architecture should be considered in a wider sense than most people currently do.
Or we should define a new term for this (style? light-weight? federated?) Why? Because we are slowly learning how to introduce 'managed variation' at the architectural level, so that specific product structures are different, but there's still an important architectural commonality between products. I concentrated on the latter, while you seem to concentrate
on the former.

In formulas :-)


____ OF ______ INTERPRETATION _______ BY ____________ CONCLUSION
( PL, ARCH ) = ( narrow, narrow ) => your collegues => single architecture
( PL, ARCH ) = ( wide , narrow ) => you => >1 architecture
( PL, ARCH ) = ( wide , wide ) => me => single 'architecture'


So, you're half way :-), as I believe you *do* see the need for a wider scope, but still view
architecture as *the* structure, hence you get >1 architecture.

If you would have asked me: do two products in the same product line always share the same
structure (subsystems, interfaces), I would have replied: definitely not!

If you say that you can have two completely different architectures (let's assume you do not
mean structures here) within the same product line, I would say yes, that's possible, but it
would probably not get into the Hall Of Fame as prime example of how it should be...

Disclaimer 1 (before you start responding to the last statement :-)
It is in fact perfectly possible to have a commercial product line (of embedded systems)
without a true software product line inside. Philips has a 'Design Line' family of TVs, that
look absolutely similar from the outside, but are sometimes entirely different inside, both
in hardware and in software. This is then a great example of a product line, but in my
opinion not of a software product line.

Disclaimer 2
Yes, you could have a software product line where the products share requirements,
tests, components but not the architecture, just gluing the components together,
but I could argue than this product line will not be very successful, since difficult
problems in products are often caused by a bad architecture, and you would have to
solve this per product then. My point is that to be a successful software product line,
there has to be at least some commonality in architecture (be it styles, guidelines,
gluing technology, component frameworks, etc.)

Disclaimer 3
Having said all this, and you still insist on sharing everything but the architecture,
then if you can make this economically feasible, then yes, it is a software product line!

Terminology
David is right in that most of the definition is about terminology. Here are some thoughts
on that.

First of all, for me, a product family or population is what you make, and a product line
is how you make it. So, a product population is not equal to a product line, but you
can make a product population with a product line.

The term product line has a certain intrinsic narrowness (as a production line that is
set-up for a specific purpose). Therefore, some people introduce the term hierarchical
product line to speak of something larger. It is very difficult to get a proper definition of
this term. A search in Google only provides 2+ pages of references, most of which
directly or indirectly stem from Jan Bosch :-), who introduces the term (actually,
he speaks of hierarchical domain engineering units) without ever being more specific
than sketching just a vision.

.....Oops - just discovered that you get more hits when you search for "hierarchical
.....product lines", i.e. plural. Didn't take those into account...

One thing that seems from Jan's work is that the lower level product lines do not
deliver products but rather subsystems to be used to build products. I would not call
this a hierarchical product line, I would just call this a product line with a proper variation
mechanism at the subsystem level.

Interestingly, a SEI document states:

Two respondents used the concept of subproduct lines where the differences
among sets of products outweighed the commonality.

Here, the subproduct lines actually produce products and not subsystems, and the definition
that uses commonalities and differences is quite in line with my definition of populations.
Praise those SEI guys :-)

Some Loose Ends
You asked me to show you two different architectures and you would merge them into
a single product line. As I explained above, I think you can do that, and it might even
sometimes be economically profitable, but probably more as exception than as rule
(again assuming you mean 'architecture' and not 'structure'). So I will not try to find
an example here :-)

I can give you another example, of two product lines that we are currently trying to
merge into one product line, where we now can speak of a single architecture (with
a lot of gluing et cetera), but which by no means is a single product line, since the
whole processes and organizations around the previously different product lines
are different. Both of them have their value, but they're quite incompatible, so
we now still have two product lines that could be said to share one architecture :-)

Perhaps you know our BAPO work, where we claim that Business should drive the
Architecture, which in turn should drive the Process, which in turn should drive the
Organization. If you don't do this, Conway's Law will be the result (the Architecture
reflects the Organization, but you could generalize his law to : O drives P drives A
drives B). If you believe in BAPO, you wouldn't be able to create a successful product
line process and organization if you do not have some shared vision on architecture.

Now for Charlie
Indeed, DVDs look quite different from TVs at first inspection.

If you look at features, capabilities et cetera, indeed you will see (hopefully :-)
that they are part of a larger population (business people would call it a portfolio)
and that they share user interfaces, remote controls, ways to connect them,
et cetera. As I argued before, you cannot tell whether TVs are produced from a
single product line (see the Design Line example), but you could deduce from
many commonalities that either there is a single product line underneath, or
that Philips is very rich.

We also have TVs with built-in DVD player/recorders, and we have portable
DVD players with a screen and a TV built-in, so there may be some point
in time where you would actually conclude that we have a single family of
TvDvds.

Also, we might have some super-plug-in architecture (think of Eclipse or
Apache) with which we can produce TVs and DVDs and all kinds of combi's,
so stating that TVs and DVDs have the same architecture is not that far away...
Another example in the same domain: Microsoft Media Center turns a PC into
a TV and a DVD player recorder, and you can still speak of the architecture of
MMC, can't you?

Finally, although I do not like to use the term hierarchical product line for this,
as explained above, I do see the use of Charlie's extension to Gears, and the
need for this by his customers, so I think we're on the same ground here...

Epilogue
So far my thoughts in a Coconut shell.

I surely did not earn it, but sharing a meal (and the cost) in a decent restaurant
would certainly be high on my list of things to do in the near future :-)

Greotjes,

[Rob van Ommering]

Perhaps it is time to try to consolidate :-)

I think we all agree that there are various levels (scopes) at which we can find
commonalities, such as within high-end TVs, between high-end and low-end TVs,
between TVs and DVDs, between stationary and mobile TVs and DVDs,
et cetera.

I think we all agree that economic benefits of sharing (any type of ) assets is
high within small families, and lower but probably not negligible when the scope
of the family (population) grows.

*Iff* there are economic benefits to share assets, then we should share assets,
whether in a family, a population or whatever (economic benefits are the savings
in costs minus the costs of saving :-)

Even in small families, it is likely that the structure of different products (some call this
the architecture) is different (this may be Paul's original question). In larger families/
populations, you will certainly be able to find products with (very) different structures.

A shared (and good) architecture in a product family probably has a large effect on
the success of the family, as good architectures prevent problems, and preventing
problems at the family level is economically wiser than preventing problems at the
product level :-)

The same holds for a shared architecture in a product population, but since the
structures will be so different, it is more difficult to establish what it means to have
a shared architecture. It should be something with a lot of variation still possible
(like doing it fault-tolerant yes or no), but the more variation you have, the less
you can actually 'prove' at the architectural level, and the less variation you have,
the more difficult it will be to create a large variety of products.

So hoping that we agree on all of this, my interests are in investigating how 'wide'
one can make a product line, and what consequences this has on architecture.

[Paul Clements]

Very well said!

I have a minor quibble. Or perhaps it's a question. It seems to me that the economic benefits of sharing assets is not lower when the population grows, at least not in absolute terms. It is lower in relative terms, relative to the overall cost of the systems in the larger population. If I can save a euro every time I share something across three products, then I can save a euro every time I share that same thing across 30 products. And actually, that makes me think the savings in fact DO grow in absolute terms as well -- I save 3 euros in the small population, 30 euros in the large population. I realize this is idealistic, and that I have to an organizational structure in place to achieve that savings, and that might outweigh the savings -- but would it? When would it?

Otherwise, I would accept what Rob wrote as our manifesto!

[Paul Clements]

Charles Krueger wrote:

Yes, the RF component is definitely a product line since there are different instances with commonality and variation among them.

And because the commonality is exploited and the variability is managed, and the individual components are produced in what we would call a product line fashion. I'm not willing to say two arbitrary things that look like each other are a product line (in the context of a software product line discussion) if they aren't produced in that way. I'm not even willing to say that two products are a product line if the second was cloned-and-owned off the first, but they don't evolve together.

In terms of the distinction between family and population using our TV and DVD example, Rob argues eloquently that we have two choices -- it's either (1) one family with all of the TV and DVD members as part of that family, or (2) two different families that together represent one population. Thus a population is the union of multiple "similar” families.

I think (1) and (2) should both be true, and I don't see a contradiction. I want a population to be a product line that's composed of product lines -- a hierarchical product line, if you like.

Just to clarify on terminology, note that I'm using "product family" and "product line" to mean the same thing, which I think is what you (Paul) are using, too.

It's sloppy of me, but yes, I mean PL and PF to be the same thing.

Rob uses "product line" to mean the "how" -- I've been using the term "production line" to describe the "how" since I'm a big fan of the manufacturing analogy.

I think Rob uses PL to mean "how" in the same way I do, and in the way I tried to add to the first sentence: It's a group of products related by commonality and variation, but produced using what you would call a production line. That is, I subscribe to the SEI definition, which is pretty
clear on this.

In my terminology, a production line creates a product line (or equivalently, produces a product family). In Robs terminology, a product line creates a product family. Not sure if this is part of the confusion in this discussion.

Don't think so. I'm OK so far.

Where does the RF component fit into the argument about the TV/DVD family/population issue? It has a "part-of" relationship in members of the TV/DVD population, but it does not have a "member-of" relationship with TV or DVD. It's too dissimilar to be considered in a family or population of TV/DVD. Thus families and populations are all about member-of relationships, while hierarchical product lines are all about the part-of relationships.

Right, I think. By "member of" you mean it's not a TV and it's not a DVD and it's not a "TV or DVD," so it's not a member of the TV family, the DVD family, or the combined family. Is that right? So... I don't understand the last sentence, because I'm not able to assign meaning to "all about".

We're oh-so-close.

[David Weiss]

I only get to read this at a rate of about one-third of the rest of you, so I only get to interject every once in a while. Here are a few points.

When I/we worked with the 5ESS organization, the switching software was so large that we could not treat it as a single product line. We focused on smaller product lines within the whole family. (Remember, I use family different than product line.) It had nearly all of the characteristics of a population, in that there were experts in different areas, that different areas each had their own architecture, and that there were very few people who "understood" the whole family. Note that to customers it may have appeared as a single family (or product line). When I left we were evolving to a technology that would provide common underpinnings to all members of the sub-product-lines, similar to what Rob has done and Charlie has done in providing tools for creating product lines.

I am not fond of making the separation between product line and product population, but agree that there are product lines that may seem very different and yet share considerable commonality. It is important to make that distinction. They might only overlap, or one might be a sub-product-line of another. (Remember that Parnas gave as one approach to producing a family that one could provide different "facades" for the same platform. Of course, the example he used was different user interfaces for operating systems.) I note that I own a TV with an integrated DVD player and VCR; someone decided that it was profitable enough that they could be combined into one product. Of course, I can hear Rob arguing that the user interface is not really well-integrated and that they just provided a common rack for different devices. On the other hand, someone did the integration. Do I own a member of a product population or a product line?

Rob's point about economic benefits is crucial, I think, except that he limits it a bit too much. Product lines aren't just a means for cost benefits, they are also a means for value benefits. If I can turn out variations on my product that help me capture market share and keep customers happy, then the product line has value that is quantifiable. You should not estimate the worth of a product line just from its R&D and production cost saving.

[Paul Clements]

I just tried to capsulize our conversation for some colleagues. I wrote that "the consensus (although it's a bit early to claim that) seems to be that in any group of products for which it pays to consider their commonality, of course there can be more than one architecture. The debate among the four of us is what we should call that group: product line, hierarchical product line, or product population."

In the spirit of Rob's attempt to identify common ground, is that fair?

... Oh, another possibility is that the group may be called two or more separate product lines.

[David Weiss]

Not sure about that yet, particularly in light of some recent thoughts I have had about what it means to have the same architecture. They are still unfinished thoughts, but here is the gist.

I would like to pursue the question of what it means for architectures to be the same. Particularly, I am wondering if we could define equivalence among architectures that would allow us to say that members of a product line all have equivalent architectures, much like equivalence classes in math.. My initial thought is that if the architectures of products can all be derived from an architecture by one of a restricted set of transformations, then we call that architecture the product line architecture. (Of course, that architecture has to have certain other characteristics that meet the definition of architecture, e.g., a modular structure and well-defined interfaces.) Transformations that I have in mind are removing modules, and configuring modules according to pre-defined rules (taking advantage of automated variabilities). Depending on the set of allowable transformations, we may have different types of equivalences, some of which may lead to a product population, for example. These are just initial thoughts.

Finally, what happens if the products are generated from a domain-specific language? What, no architecture you say? Still seems consistent with our definition(s) of product line.

[Paul Clements]

The products still have an architecture in that case. I don't see this as a problem.

[Rob van Ommering]

> I have a minor quibble. Or perhaps it's a question. It seems to me
> that the economic benefits of sharing assets is not lower when the
> population grows, at least not in absolute terms. It is lower in
> relative terms, relative to the overall cost of the systems in the
> larger population. If I can save a euro every time I share something
> across three products, then I can save a euro every time I share that
> same thing across 30 products. And actually, that makes me think the
> savings in fact DO grow in absolute terms as well -- I save 3 euros in
> the small population, 30 euros in the large population. I realize
> this is idealistic, and that I have to an organizational structure in
> place to achieve that savings, and that might outweigh the savings --
> but would it? When would it?

The numbers may be a bit different (I'm using my own terminology in the following).
A typical product family has (say) 30 products. A typical product population has 3
(rather than 30) families. Sharing within a family saves you a factor of thirty, sharing
between families saves you a factor of three...

Of course, you will never be able to measure the factor 30 in a family, because if
you build multiple products without an SPL, you will use 'copy and edit' which will
also save (some) cost. Also, without an SPL, you will just not create 30 products
(you can have any color as long as its black :-).

And the factor of 3 will never be achieved in a population, since by definition,
products between families have significant differences. The organizational costs
(especially the risks of coupling the lifecycles of different products) will further
reduce this number.

Still, sharing between families may prove to be beneficial, not only for direct cost
saving reasons, but also (as Dave points out, I will come back to this later) to
increase the value for customers, e.g. by having the same UI style in different products.
Another (second order) argument in favor of sharing between families is that it is easier
to move developers between family development teams.

Example: my Philips DVD/hard disk recorder has three styles of UI, the original
DVD-player style of menus, the more modern TV style of menus, and the menu
style of a third party Electronic Program Guide module. Highly confusing to users!

Example: an early TV-DVD combi product has a DVD module that is an (almost)
independent DVD player, connected with a simple wire/protocol to the TV.
Integrating the DVD software onto the same CPU as the TV software, to reduce
the Bill of Material, was almost impossible due to different software architectures.
Here, making TV and DVD part of the same product population would help to
save BoM. Interestingly, the current trend may be in the other direction: by keeping
them as separate self-contained modules, development - especially integration -
is much easier (at the expense of BoM).

[Rob van Ommering]

> Just to clarify on terminology, note that I'm using "product family"
> and "product line" to mean the same thing, which I think is what you
> (Paul) are using, too. Rob uses "product line" to mean the "how" --
> I've been using the term "production line" to describe the "how"
> since I'm a big fan of the manufacturing analogy. In my terminology,
> a production line creates a product line (or equivalently, produces a
> product family). In Robs terminology, a product line creates a
> product family. Not sure if this is part of the confusion in this
> discussion.

I'm not married to my terminology :-)

> Where does the RF component fit into the argument about the TV/DVD
> family/population issue? It has a "part-of" relationship in members
> of the TV/DVD population, but it does not have a "member-of"
> relationship with TV or DVD. It's too dissimilar to be considered in
> a family or population of TV/DVD. Thus families and populations are
> all about member-of relationships, while hierarchical product lines
> are all about the part-of relationships.

I agree that we should keep these issues clear; I actually think there are three of
such issues (I haven't got the proper term for the third one yet):

(1) The hierarchy of products: populations (TV, DVD) consist of families (TV)
consist of subfamilies (high-end, mid-range) consist of ...

(2) The hierarchy of a product: a TV contains a front-end contains a
tuner contains an RF module...

(3) The hierarchy(?) of technology(?): a commercial product line (Philips Design
Line of TVs) may consist of different implementation families, independently
sharing architecture, requirements, tests etc yes/no.

So I'm always talking about (1) (and so is Charlie, and so is Gary when talking about
hierarchical product lines in the SEI report that I quoted earlier!). Charlie's RF
example is about (2), and so are Jan Bosch's hierarchical product lines.

By the way, if you sell both RF modules and TVs as a company, as Philips does :-),
then you have two families (in hierarchy (1)) that do not form a population together,
but the first family is a 'subsystem' (in hierarchy (2)) of the second family...

Hierarchy (3) is actually what Paul started talking about, and also very meaningful
to discuss. In fact, many companies start a commercial product line with (vastly)
different implementations, and then decide later to optimize development effort
by also turning the implementation in a product line. Again, the reverse is also
possible, enabling a commercial product line by having a technical product line...

[Rob van Ommering]

> When I/we worked with the 5ESS organization, the switching software was so
> large that we could not treat it as a single product line. We focused on smaller
> product lines within the whole family. (Remember, I use family different than
> product line.)

So your family is what I would call a product population, a level in hierarchy (1)
(see previous e-mail).

> It had nearly all of the characteristics of a population, in that
> there were experts in different areas, that different areas each had their own
> architecture, and that there were very few people who "understood" the whole
> family. Note that to customers it may have appeared as a single family (or
> product line).

So to customers it appears to be a single commercial product line, a level in
hierarchy (3) (see previous e-mail).

> Rob's point about economic benefits is crucial, I think, except that he limits it a
> bit too much. Product lines aren't just a means for cost benefits, they are also a
> means for value benefits. If I can turn out variations on my product that help me
> capture market share and keep customers happy, then the product line has
> value that is quantifiable. You should not estimate the worth of a product line
> just from its R&D and production cost saving.

Fully agree, and indeed I utterly neglected this in my previous e-mails. Put
more strongly, the argument for saving cost can always be countered by
adding more people/money when products are successful but at risk through
sharing of software. I've seen this oh so often: no-one ever complained in
Philips that TV and DVD each took hundreds of developers, as hard as we
tried to convince managers that it could be done cheaper :-) Only when
customers (of our Semiconductors division) asked for an integrated solution
(a value issue, they're not concerned with the internal cost), managers
started to align TV and DVD development...

[Rob van Ommering]

> I would like to pursue the question of what it means for architectures to be the same.
> Particularly, I am wondering if we could define equivalence among architectures that
> would allow us to say that members of a product line all have equivalent architectures,
> much like equivalence classes in math.. My initial thought is that if the architectures
> of products can all be derived from an architecture by one of a restricted set of
> transformations, then we call that architecture the product line architecture.
> (Of course, that architecture has to have certain other characteristics that meet the
> definition of architecture, e.g., a modular structure and well-defined interfaces.)
> Transformations that I have in mind are removing modules, and configuring modules
> according to pre-defined rules (taking advantage of automated variabilities).
> Depending on the set of allowable transformations, we may have different types
> of equivalences, some of which may lead to a product population, for example.
> These are just initial thoughts.

This is precisely what I meant when writing:

> Architecture should be considered in a wider sense than most people
> currently do. Or we should define a new term for this (style?
> light-weight? federated?) Why? Because we are slowly learning how
> to introduce 'managed variation' at the architectural level,
> so that specific product structures are different, but there's
> still an important architectural commonality between products.

Removing and configuring modules are perfect examples of variation
points of an architecture. There are many more variation points
possible, and that's good, only you're still looking at concrete
architectures I think. You could also share things like a component
framework (Koala), an interface style (Koala), a concrete API (set
of interfaces) or even a concrete subsystem (our infrastructure
subsystem) while having lots of differences on other points.
Concrete architectures are different then, but I would still say that there
is a shared architecture, or architectural style, or architectural
framework, that makes code and other sharing between products at
least easier...

[Charles Krueger]

OK, finally some time to focus on the fun stuff...

Right, I think. By "member of" you mean it's not a TV and it's not a DVD and it's not a "TV or DVD," so it's not a member of the TV family, the DVD family, or the combined family. Is that right? So... I don't understand the last sentence, because I'm not able to assign meaning to "all about".

We're oh-so-close.

pc

I agree that "we're oh-so-close", so I would like to see if we can converge on the product line concepts/terminology that seem to form the basis of the discussion. To maintain that focus, I'll hold off on the architecture discussion for now. In this message I will focus on family versus population and in the next message I will focus on hierarchy.

Product Family versus Product Population.

I've thought a little more about Paul's question regarding whether or not we need both concepts, or rather if they are just shades of gray within one concept. I still conclude that they are separate and that each serves a distinct and separate purpose.

Trying to create a more concise definition for family versus population, I find that they can be distinguished by "system-lifecycle-level reuse" for families versus "component-level reuse" for populations. I seem to hear this repeated in different ways from each of you, so let me try to summarize.

In a software product family, there is sufficient economic benefit to justify the investment required to exploit the commonality and manage the variation for the entire range of lifecycle assets (requirements, architecture, design, code, test cases, documentation, test plans, and so forth) at the system level.

In a software product population, there are multiple product families that can share components or subsystems between them. However, there is not sufficient economic benefit to justify the investment required to exploit the smaller amounts of system-level commonality and manage the larger amounts of system-level variability across the full lifecycle of assets among the different families. Being less ambitious and capitalizing on simple and conventional component-level reuse does offer sufficient ROI.

The three observations I made that convinced me to maintain the family versus population distinction are:

(1) Assume we have a separate TV family and a separate DVD family, which are part of a population. There is system-lifecycle-level reuse within each family and component-level reuse across the two families. From the perspective of the TV family, a DVD member is "out of scope" for the TV family. It's too hard to create and maintain given the TV core assets.

(2) Continuing from (1), if a population is simply another term for a larger family that includes the union of both TV and DVD members, then that implies that old-school component-level reuse is sufficient to define a software product family. That to me contradicts all of our definitions of software product family. These definitions all dictate that much more is required than simple component reuse.

(3) As Rob points out, (1) and (2) don't imply that Philips can't define a single family that is the union of TV and DVD members. What they do to create a single family is make the extra investment to capitalize on the commonality and manage the variation at the system-lifecycle-level across all TV and DVD members. After the scope of the core assets has been broadened to create one family, you no longer have a population, you have a family.

[Charles Krueger]

Rob's characterization of how we are overloading the use of hierarchy is good:

(1) The hierarchy of products: populations (TV, DVD) consist of families (TV) consist of subfamilies (high-end, mid-range) consist of ...

(2) The hierarchy of a product: a TV contains a front-end contains a tuner contains an RF module...

(3) The hierarchy(?) of technology(?): a commercial product line (Philips Design Line of TVs) may consist of different implementation families, independently sharing architecture, requirements, tests etc yes/no.

So I'm always talking about (1) (and so is Charlie, and so is Gary when talking about hierarchical product lines in the SEI report that I quoted earlier!). Charlie's RF example is about (2), and so are Jan Bosch's hierarchical product lines.

Actually, the hierarchy that I've been referring to -- the one that our customers requested and that we added to Gears last year -- is (2). For large and complex products, this is an effective way to partition and modularize what would otherwise a huge monolithic product line. For example, in an automotive product line, there are firmware engineers whose whole focus is the engine product line. Within the engine product line, there are firmware engineers whose whole focus is on the fuel injection system product line. Likewise, the transmission is a subsystem of the automobile that can be treated as a standalone product line, and it likely has nested subsystem product line structure as well. This tree of nested product lines is what we (BigLever) refer to as a hierarchical product line.

When I referred to (2) as being a hierarchy based on the "part-of" relationship, the relationship I was trying to express is exemplified by:
* fuel system is a product line that is used as a "part of" the engine product line
* engine is a product line that is used as a "part of" the automobile product line

So now I'll play the minimalist. Do we really need (1)? Assuming you accept the premise of my previous e-mail -- that populations are distinguished from families by component-based versus system-lifecycle-based reuse -- then I don't really see this as a hierarchy. Rob, do you use the "subfamily" distinction in (1) in a formal way in your work? I'm not clear on the necessity of that, but would like to hear more if you think it is needed.

I think I understand the scenario you are describing in (3), but am not understanding what or where the hierarchy relationship is in this case. So I'm ready to discard it. (:^)