Brothers in arms - SOA and Product Line Engineering

How would you engineer a SOA based system? First of all, you'd need to define all the composite applications and processes which become part of your infrastructure. Then, you are able to defer common services. Obviously, a separate team should be in charge of service engineering and maintain all services as well as their implementations in central repositories. For example, Amazon organizes its development this way. Developers of applications then build upon these services as well as other common parts. They give feedback to the service developers so that existing services might be reorganized, changed, extended or supplemented. Consequently, we introduce a separation of service engineering and application engineering.
Now, compare all this to Software Product Line Engineering (SPLE, see my special posting on that issue):

• Services and other common parts (such as legacy applications or platforms) are core assets
• Applications (composite applications and business processes) denote the members of a product line
• Service engineering resembles domain engineering and application engineering is identical.

Sooner or later you'll reconginze that SOA engineering is best organized as a SPLE process.

Scoping might be a little more difficult but you should read my last posting how we could cope with this challenge. You might also consider to provide a generative architecture as described in another recent posting as well as in what I wrote on ULS.

From my viewpoint the only conclusion to draw is that SPLE and SOA engineering should be considered as two sides of the same coin.