The Scope of Product Line Engineering

In Software Product Line Engineering the first activity comprises scoping which basically means to anticipate all upcoming products that should be in the scope. I was asked by another engineer whether this implies that we need to know all applications in advance which will be part of the product line and if yes, what if the number of applications would be VERY large. So, what does scoping actually require? Scoping does not mean that you really know everything in the beginning. Otherwise it would be very easy to define the commonalities and variabilities. As always, architects have to deal with vagueness and uncertainty in this context. My understandimg of scoping is as follows. We need to have an idea of the products in the program family we are going to build. Thus, the first step would be to define use cases / scenarios that are typically expected by an application in the program family. If use cases differ or if they appear in some applications but not in others they will help discovering variabilities. If they reveal common (generic) parts or are identical for all applications they will reveal the commonalities. But how do we obtain those use cases? Either, the domain itself inherently defines such use cases. Take ATMs as an example. Or, we could take a representative sample of applications from which we derive the use cases.
This brings me to another important point. I was also asked whether product lines are always a simple partitioning in domain engineering and application engineering. No, they are not. Take car manufacturing as an example which many consider as the prototype of Product Line Enginering. If a car type is manufactured as part of a product family, it will contain common parts all members of the family share as well as variabilities such as different colors, chassis, and so forth. Thus, we have domain engineering where we produce the common core assets and application engineering where we build and customize the individual cars. So far, so good. If we think this a little bit further, some of the assets we use will themselves be parts of other product lines. Maybe, the supplier of the entertainment and navigation system will also leverage product line engineering. Or maybe, the car manufacturer will provide other assembly lines where core parts such as the doors of the car are produced in a product line approach. In other words, a product line can be a combination of different product lines intertwined with each other in a pipeline.
But it is also possible to find the other way round? Suppose, we are going to build a generic web shop application for different customers. We are setting up two separate product lines, one for SOHO and another one for enterprise customers. After a while we find that both product lines can be based upon an additional product line where the common parts for the SOHO as well as for the enterprise web shop are developed. In the SOHO and enterprise product lines we are then just adding the deltas. Obviously, such a setting only makes sense if the SOHO and Enterprise Web shop solutions reveal a lot of differences. Otherwise we would better establish one single product line and handle the differences of both shop variants by variabilities. By the way, finding the appropriate approach is also an important outcome of scoping.
In one of my next postings I will address the issue of why SOA engineering can be considered Product Line Engineering. So, stay tuned!