Printable Version of Topic

Posted by: Paul Clements Aug 7 2006, 08:39 PM

Gentlemen,

Can I ask you guys a question based on your product line experience?

I have often seen it written that every software product line has a single architecture. This is often implicit (when reference is made to “the” product line architecture) but it is often explicit as well.

My question is this: Why can’t a software product line have two architectures? That is, why can there not be two architectures in the core asset base that are populated by (many of) the same software elements, just wired together in different ways to meet different behavioral and quality goals of different products? It seems like this would make a lot of sense.

I could imagine two architectures, for example -- one for very fault-tolerant products, one for the cheap products. You'd still have a lot of the same components, many common requirements, lots of test cases in common, etc., etc. Sounds like a product line to me, with a perfectly respectable core asset base. For another example, suppose I want to migrate to a service-oriented architecture. But I don’t want to throw out my current family of products, which do not use a service-oriented architecture. So it seems like I’d have two architectures in my core asset base.

An alternative is to say “two architectures means two product lines” but this seems like a lot of trouble just to preserve a rule, whose purpose I cannot see.

My question is this: Am I nuts? If not, can you give me an example from the real world that supports this idea?

OK, I guess that's two questions.

Posted by: Charles Krueger Aug 7 2006, 08:49 PM

Hi Paul,

There may be a third option: You are right AND you are nuts. (:^)

I've never been a proponent of the architecture dogma in software product line practice, so it's easy for me to agree with you. I think architecture is a secondary issue in SPLs (blasphemy!), so having several architectures under the umbrella of one product line is fine.

But then we have to get into the arguments about "what constitutes one product line vs. multiple product lines" and "what constitutes one architecture vs multiple architectures"...

Engenio is a good example. They used to keep their low-end and high-end products on separate SCM branches since there was sufficient diversity among the requirements, architecture, and source code to initially justify that. Of course, (as you suggest) they ended up doing a poor job of capitalizing on the commonality between these two branches.

Now, under Gears, all of their products are managed as a single product line. If you do a pair wise comparison among any two products, some are very similar and some are quite different -- all through the requirements and architecture levels. However, there is absolutely no duplication or divergence in places where they is commonality among any two or more products.

Engenio could have chosen to (or still could) split the low-end and high-end products into two different product families within one van Ommering "product population". The same level of sharing occurs, but the diversity among any pair of products within one product family is less. Would this mean they have one or two product line architectures? I'm fuzzy on that answer.

Engenio actually has four choices (1) all products under one product line, (2) products partitioned into multiple product lines within one product population, (3) products partitioned into a combination of populations and independent (outside of any population) product lines, and (4) products partitioned into multiple independent product lines. Moving from 1 to 4, it becomes easier to manage wide diversity, but harder to take advantage of commonality. A perfect economic model could help predict the optimal tradeoffs. Whether or not there is one, two, or many different architectures seems to be a secondary issue.

I'm still not sure in the above scenarios that I could draw the line between one architecture with lots of diversity or several architecture with little diversity. Maybe the three of you have better insights into this than I do...

Posted by: David Weiss Aug 7 2006, 08:53 PM

In answer to the first question, no. I do not think that the theory bars this. Recall that the definition of product line that I use is a family that takes advantage of its commonalities and predicted variabilities. Architecture is not mentioned in the definition. As I recall the definition that the SEI uses, it requires that there be a set of managed assets, but again says nothing about architecture. Recall also that I think one way to produce members of a product line is to generate them from a domain specific language. Once again, there need not be (although there often is) an underlying architecture, in the sense that we usually use architecture. (I haven't seen many papers about this approach in recent SPLCs, although I think there were a number in the early SPLCs.)

That was easy. Now for the hard one, i.e., an example. When I worked with the 5ESS organization, we created a product line of switch maintenance software (you may have seen me talk about this - it is one of the examples I use in public talks and we published a paper about it). Members of the product line were variations on software that was used to replace devices connected to the switch while it was still running. The switch maintenance software was generated from a set of managed assets, in fact fragments of C code. I think you could argue this either way, i.e., that those fragments constituted an architecture, or that they did not. In fact, they were fragments based on algorithms that described the steps necessary to remove a device from service and place a new one into service. The application engineer had a graphical language that he/she used to specify the member of the product line that he/she wanted. A generator was invoked that composed the fragments and instantiated them properly.

Hope all is well.

Posted by: Rob van Ommering Aug 7 2006, 09:08 PM

Hi Paul,

I must confess that I'm not too surprised by this statement; I have been observing this 'opinion' already for a long time. Whether the statement is true depends on your definition of a software product line and on your definition of software architecture. To explain this, I need more than just a few words :-)

Management Summary :-)
Products in a product line may have different architectures!

Product Lines, Families and Populations
My work on product families started around 1993, when we wanted to share software between TVs and video recorders, as produced by different organizations in Philips. I observed how hardware modules could be easily reused between such products, and therefore decided to develop a software component model (in 1996) that could do the same.

In 1998, when I first published on this, I was surprised to see so many people talk about the (single) architecture with variation points. In all fairness, there was a paper that described this to be just one of the possibilities (ref [88] in my PhD thesis), but I must confess I usually quoted this paper only for the phrase 'variant free architecture' :-)

This is why I coined the term populations, to describe sets of products with many commonalities but also many differences, as opposed to families, where products only have few differences. Only later I learned the term product line (from you guys:-).

To bring this into my mental framework, I've always seen families and populations as what you make, and product lines as how you make it. I like the word product line, because it suggests a very systematic (and partially automatic) way of deriving products. But since this has mostly been studied in the context of families with a (quite) narrow scope, where a variant-free architecture works, this probably explains why people now see this as the only way.

There are however many situations in which there is an economic reason to share between a set of products of much wider scope, and I'll give examples later. If you don't call that a product line, fine by me, but then you need to study how to share between product lines, and you need a term for that (product factory?).

So, my answer could be: okay, every product line has ONE architecture, but then we need another term and start studying that. A better answer, I think, is to use the term product line in a larger context, and accept that there is not necessarily a single architecture.

What is Software Architecture :-)
The second reason that the question is difficult lies in the meaning of the word 'software architecture'. If this is interpreted as 'the set of subsystems and their interfaces', then products will have different (concrete) architectures. If this is interpreted as 'a reference architecture', then products may have the same (abstract) architecture. But again, if the scope of products widens, there will me more and more differences in the architecture of different products.

By the way, I know of no architect that has specified all interfaces between all subsystems, so the first definition is impossible anyway... :-)

My own definition of architecture is: the first 100-1000 decisions that you have to take to efficiently build efficient systems. Among these could be the structure of the systems, but also patterns, rules, guidelines, mechanisms, etc.. My experience is: the wider the scope of the family, the more the overall architecture shifts to rules and patterns rather than 'the' structure of the system.

Terms for this are lightweight architecture or federated architecture. You only define what is absolutely necessary at the highest level, and leave the rest to the architects of subsystems.

Intra- versus inter-organization
A bit of warning is on its place here. Ordinary reuse usually fails in organizations for two reasons (I believe): (1) it's difficult (maybe even impossible) to install a proper internal structure that makes the economic benefit visible, and (2) the scale of application is usually too small anyway. The introduction of product lines solves these problems by making very explicit how reusable the software must be, namely only fitting in the scope of the family to build. This is good!

But if you want to widen the scope again, going from families to populations, you get the same problems back, and while this may be successful for a while, there are all kinds of forces that work against you. It may therefore be smarter not to strive for reuse between product lines (in the narrow sense), but rather buy shared software from outside (if available of course). Then you profit from a clear structure (explicit inter-organization instead of implicit intra-organization), and all the usual economic rules work.

But this may be over-pessimistic, and since not many people have studied it yet, I would highly recommend looking into inter-product-line (in the narrow sense) reuse.

Examples
Our TV architecture is a federated architecture, as I've explained elsewhere :-) No two products have precisely the same structure. They can differ in choice of subcomponents, glue code between components, et cetera. I must confess that I never bothered to try to model products in a single (concrete) architecture, so I do not know how well that would work. I do know that our technique works, and that we never suffered from having different concrete architectures.

Actually, the first mid-range product made with our architecture (originally intended for high-end products) had different implementations of most of the components, but many interfaces remained the same. Would you call that the same architecture? Some people claim that the interfaces are actually the skeleton of the architecture :-) In our case the concepts were the same, the interfaces, only the concrete implementations were different. I would call that at least part of the same family approach, and certainly not two independent product lines, since the interfaces (and concepts, and architectural rules) were shared between them.

In your case of the [fault-tolerant] architecture: if you could manage to implement fault tolerance as an aspect (as in AOP), then it would just be a variation point in the same product line, wouldn't it :-) ? In any case, I would say that you share enough between the two (concrete) architectures to warrant to call it a product line (or factory, or whatever).

Engenio
Charlie says what I always have been saying: share where needed, and diverge where needed. There is a commercial need to differentiate products, and there is an (internal) economic drive to share where possible. But there are many (hidden) costs in sharing, so one should not be afraid of having some copies of the code :-)

Conclusion
I would go for the wider definition of software product lines: sharing of certain assets between products, which not necessarily includes the architecture. In practice, there would be a shared part of the architecture (rules, guidelines) but there may very well be differences in architecture between products, ranging from small ones to fundamental ones. Koala may be a prime example how you can parameterize architecture (using switches, lazy evaluation, reachability analysis and code generation). But also note that life is much easier if you can use a single architecture for your product line :-)

Posted by: Rob van Ommering Aug 7 2006, 09:13 PM

Product populations are one area where you have systematic reuse between products yet very different (concrete) architectures of the individual products. I also likes Paul fault-tolerance example. Yet I can see the reason for discussion, since architecture is sometimes defined as 'the fundamental organization of a system', implying that it is difficult to change the architecture. So if you manage to make the architecture a variation point, and can change it easily, are we still talking about the architecture, or is the architecture then something more deeply hidden?

Posted by: Charles Krueger Aug 7 2006, 09:16 PM

I must say that I'm rather amazed that we are all 4 in such vigorous agreement. This must be a first for the SPL and PhD community. (:^)

Posted by: Paul Clements Aug 7 2006, 09:18 PM

Indeed, and thanks to all of you for shedding light on this.

In fact, even though we agree, it wasn't all that clear-cut. I had to read the discussion very carefully to make sure that was, in fact, agreement I was seeing. To be honest, I expected three short answers of the form "Of *course* a product line can have more than one architecture. What a dumb question." So now I'm starting to think there's more to this issue than I thought.

Posted by: Rob van Ommering Aug 7 2006, 09:24 PM

Okay, let's have some fun :-)

(1) I think there *is* an issue...
(2) I think, Paul, that you're wrong, and...
(3) I think that your colleagues are even more wrong!

In reverse order and a nutshell :-)

(1) Your colleagues are wrong because they are viewing product lines in a
(too) narrow sense, and are clearly missing out on sharing assets
between these narrow product lines, which may have a lot of economical
benefit, as David, Charlie and I are arguing (with different examples).

(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 set of agreements between the products.

(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?

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

(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.

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

Posted by: Paul Clements Aug 7 2006, 09:27 PM

So here's a challenge for you. Show me two architectures that YOU would call different. You can use whatever criteria you choose, but whatever they are, you have to say "Yep, there is no way I would call those the same architecture." I bet you a meal at a decent restaurant of my choosing that I can construct a plausible scenario where those two architectures share a lot of core assets, including components, that could together form a product line. (I issue the caveat that I consider what you call a product population to be a product line, because while I think it is a wonderful concept, I see no hard line that differentiates between the two.)

My point is that I don't accept your claim that components must work under the same architecture, otherwise we'd have architectural mismatch, because we know lots of ways to repair mismatch. Consider a core asset base that includes (a) one architecture; (b) a set of components that work with that architecture; © a different architecture that passes the "van Ommering difference test"; and (d) wrappers and mediators and bridges and lots of other stuff to make the components work with the second architecture.

I also find this whole conversation unsettling because it is stuck squarely in the world of code, when there are a million things OTHER THAN code that go into a core asset base. Suppose you have two architectures, and two entirely disjoint set of components that populate them. I think that's unlikely, but let's pretend. If I have a common set of requirements, system acceptance tests, user manuals, production plans, budgets and schedules and work breakdown structures, processes, tools, and on and on, then I'm going to be really unhappy if you tell me "No, that can't be a single product line because ALL of the code isn't shared."

(But I did like that part about how my colleagues were even *more* wrong...)

Posted by: Charles Krueger Aug 7 2006, 09:29 PM

Hmm, I think this difference in perceptions must be reconciled before you can start a meaningful debate about what constitutes one versus multiple architectures, and one versus multiple product lines.

I can walk up to a Philips electronics exposition and my brain will easily partition the TV section from the DVD section. Something tells me in a blink that there are two product lines. When I look at little closer at their features, capabilities, and possible interconnects, then I recognize that they also have some things in common, thus they are part of a larger population.

The family versus population concept is very real in the world in which I work, not just intuitively as in the above example, but because it serves a valuable role in designing, establishing and running SPL practices.

If anyone attempts to argue that TV and DVD are part of the same family or have the same architecture, that effort will only convince me that you have firmly placed two feet on an academic slippery slope and will soon claim that everything in the universe is one. (:^)

Posted by: Paul Clements Aug 7 2006, 09:31 PM

If you substitute "larger product line" where you wrote "larger population" would it be wrong?

Are you saying a population is NOT a product line?

Posted by: Charles Krueger Aug 7 2006, 09:35 PM

Yes.


Yes.

If I hand anyone a TV and ask them to place it in the proper product line, there's a 100% certainty they won't put it with the DVD units.

If I take Philips' top TV design guru and ask them to design next year's product line of DVD units, those DVD products will suck because that person doesn't understand the gestalt of the DVD product line.

If I take Philips' top RF component guru and ask them to create an RF component (e.g., chip and firmware) that will serve both the TV and DVD product lines, they will create an elegant solution for this one population of two product lines that need RF components.

I think there is sufficient "gravity" that clusters different product lines, and that trying to blur the boundaries around these clusters results in an over generalization that dramatically degrades reuse. I can be an expert in TV and I can be an expert in DVD, but probably not both.

Reuse across product lines (within a population) is like an aspect-oriented reuse. The RF component example is really a little product line that cross-cuts the TV and DVD product lines.

One of my favorite capabilities we added to Gears in the last year is hierarchical product lines, where one product line can be composed out of not only components, but also smaller nested product lines. Both components and nested product lines can be shared across multiple product lines, extending the notion of population to include the sharing of both components and nested product lines. The hierarchical product line and product population capability was driven by customer requests and needs, so that's why I believe pretty strongly that having these concepts in our field has real and practical value.

Posted by: Paul Clements Aug 7 2006, 09:38 PM

So doesn't that mean the RF component is a product line, and the TV and DVD families are really populations, not product lines?

What's the difference between (a) a product line within a population, and (b) a "hierarchical product line"?

Posted by: Charles Krueger Aug 7 2006, 09:42 PM

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

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.

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 Rob’s terminology, a product line creates a product family. Not sure if this is part of the confusion in this discussion.

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.

Posted by: Paul Clements Aug 7 2006, 09:44 PM

Looking back over the message traffic makes me think that in fact we don't agree.

Rob, Charlie says a population is NOT a product line. Do you agree?

Posted by: David Weiss Aug 7 2006, 09:48 PM

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."



So, what are the interesting research questions?



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.




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



Agreed.



Think of coconuts.

Posted by: Rob van Ommering Aug 7 2006, 10:07 PM

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,

Posted by: Rob van Ommering Aug 7 2006, 10:14 PM

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.

Posted by: Paul Clements Aug 7 2006, 10:19 PM

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!

Posted by: Paul Clements Aug 7 2006, 10:27 PM

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.



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.



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



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.



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



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.

Posted by: David Weiss Aug 7 2006, 10:33 PM

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.

Posted by: Paul Clements Aug 7 2006, 10:36 PM

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.

Posted by: David Weiss Aug 7 2006, 10:38 PM

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.

Posted by: Paul Clements Aug 7 2006, 10:45 PM

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

Posted by: Rob van Ommering Aug 7 2006, 10:52 PM

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).

Posted by: Rob van Ommering Aug 7 2006, 10:55 PM

I'm not married to my terminology :-)



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...

Posted by: Rob van Ommering Aug 7 2006, 10:59 PM

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



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



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...

Posted by: Rob van Ommering Aug 7 2006, 11:02 PM

This is precisely what I meant when writing:



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...

Posted by: Charles Krueger Aug 7 2006, 11:07 PM

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

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.

Posted by: Charles Krueger Aug 7 2006, 11:10 PM

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

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

Posted by: David Weiss Aug 7 2006, 11:12 PM

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.

Posted by: Rob van Ommering Aug 7 2006, 11:18 PM

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).





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 :-)



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).



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...

Posted by: Rob van Ommering Aug 7 2006, 11:24 PM

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.