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

[David Weiss]

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. (:^)

I have trouble distinguishing among these hierarchies as well. Let me use a(nother) non-software example. Automobiles are manufactured as product lines. A component of an automobile is a tire. A tire fits into the definitions of both hierarchies 2 and 3 (part of an automobile - hierarchy 2, and radials vs. non-radials - hierarchy 3). On the other hand, to the tire manufacturer, the tires are manufactured as product lines and sold to different auto makers to fit into their automobile hierarchies. Note that there are high end, mid-range, and other subfamilies of tires. Can we find a software example? How about database managaement systems? Product lines on their own, but also part of the hierarchy of (many) other software systems. From these examples, the three hierarchies seem to collapse into one.

[Rob van Ommering]

Charlie wrote:
> 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.

I agree, but with - perhaps - some subtle differences in reasoning.

It's not only economic benefit that is involved here. In our case, the TV and
DVD departments are different business lines, each with their own profit
and loss responsibility and roadmaps and release dates etc.. This makes it
in practice very difficult to co-develop software, even though from a higher
level point of view there would be economic benefit...

Also, I'm not sure that conventional component reuse is that simple :-).
You still have the problem of finding the right parameterization, of making
designs composable (this is really hard), and of having the right roadmaps.
But yes, I agree that composition is more appropriate than decomposition
here (that was one of the main arguments of my thesis).

I wrote:
(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.

Charlie wrote:
> 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.

For me, (1) is a clear hierarchy that I find back in my organization (Philips
has a Consumer division which has a TV business group which has a high-end
business line). I also find it back in the Philips web site if you search for a product.
So, the hierarchy exists, so we'd better make it explicit :-)

Charlie wrote:
> 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. (:^)

This hierarchy is actually what Paul was initially talking about, when he said that
one could share requirements etc but not architecture (or code). This reminded
me of a more extreme case, where products are technically very different but
still member of the same 'commercial' product line. This does not help in our
discussions, as we are more talking about common things in different product
lines, than of different things in common product lines :-). Still, I think this
hierarchy does exist (although perhaps it is not as nice a tree (or graph) as
the other two).

David wrote:
> I have trouble distinguishing among these hierarchies as well. Let me use a(nother) non-software
> example. Automobiles are manufactured as product lines. A component of an automobile is a tire.
> A tire fits into the definitions of both hierarchies 2 and 3 (part of an automobile - hierarchy 2, and
> radials vs. non-radials - hierarchy 3). On the other hand, to the tire manufacturer, the tires are
> manufactured as product lines and sold to different auto makers to fit into their automobile hierarchies.
> Note that there are high end, mid-range, and other subfamilies of tires. Can we find a software example?
> How about database managaement systems? Product lines on their own, but also part of the
> hierarchy of (many) other software systems. From these examples, the three hierarchies seem
> to collapse into one.

I don't think they collapse into one. I think the hierarchies exist separately.
Example: Philips creates DVDs, and high-end and mid-range TVs. The TVs are
part of one (commercial) family, but internally, high-end and mid-range TVs
are completely different (created by different teams, with different methods
and processes, think of HP deskjet versus laserjet...). The DVDs are another
(commercial) family. This shows hierarchy 3.

DVDs and high-end TVs are two separate product lines, but they may share
certain components, e.g. (1) a tuner component created by Philips and also
sold externally, (2) a teletext component created by Philips and not sold
externally, and (3) a real-time kernel obtained from elsewhere. Each of these
can be parameterized etc., turning them into a little product line themselves
(hierarchy 2).

If we manage the shared development of components (1) and especially (2), we
do that because we see hierarchy (1): we see a population of products that would
benefit from having shared components, for economic reasons but also perhaps
for user interface reasons.

Note that hierarchy (2), having sub product lines, is one way to achieve reuse
in the higher levels of hierarchy 1 (population) while having different product
lines one level lower (family). A different approach would be to treat the whole
population as a single product line. You can also treat the population as a
commercial product line (hierarchy 3) (by putting the label Philips on it :-)
and don't bother about implementing it as product lines.

So, I think the three levels do exist, and can be combined in different ways...

[Rob van Ommering]

Rob's Summary for this Discussion

As a last attempt to summarize the discussion: Paul’s original question, “can a product line have more than one architecture”, has been answered positively by all of us. Two issues make the discussion a non-trivial one: “what is architecture” and “what is a product line”.

With respect to the first issue, tackled mostly by David and me, we claim that architecture may be a more higher level concepts than the concrete structure of a system. So even if two members of a product line have different (concrete) architectures, they may share the same abstract architecture…

The second issue is more encompassing, and is addressed mainly by Charlie and me. We talked about product populations as the union of product lines (TVs and DVDs), and about hierarchical product lines (TVs have RF tuners that can themselves be a product line). We clearly see the need for both: product populations allow to share assets between otherwise different product lines, and hierarchical product lines allow to manage variation hierarchically.

Why did we discuss these issues? Interpreting Paul’s original question as being about product lines (and not populations), then the answer would be that some product lines indeed have a single architecture, but some don’t. In the latter case, some product lines have different concrete architectures that satisfy the same abstract architecture, and some don’t. The answer to Paul’s question would therefore be yes, a product line can have two architectures, although it is understandable that some would answer it with no.

In a product population, there would certainly not be a single architecture for all products, so the answer to Paul’s question would be definitely yes to anyone who understands the need for product populations. As this notion is not widespread yet in the SPL community, it is understandable that people do not yet fully grasp this argument.

As the (different!) notions of a product population and a hierarchical product line formed the main topic in the second half of the discussion, and warrant further discussion in the SPL community, I see this as an important (second) outcome of the discussion reported in this document, even though this was not directly implied by Paul’s original question.