Using Product Lines in a Small Organisation, Part 2

The Salion case-study paper discusses the introduction of software product lines to a small startup organisation, creating a new product for a new market. This posts takes a quick look at it.

A big distinction is made between proactive and reactive approaches. Proactive being trying to cover all your bases up front, and reactive being only incorporating variability when it arises. Reactive is essentially agile for product lines.

Salion had one product to begin with, and this original product served as the core assets for the product line as a whole. They had, at the start, “a product line with one product.” So a lot of what would traditionally be domain engineering and big design up front was pretty taken care of by already having made one app for one customer. They used customisation and refactoring to find emerging abstractions as new customers came on board.

They also removed the idea of doing domain engineering and application engineering as two separate stages. It’s all just one thing, with a bunch of different products being pulled together from their core assets.

They say lessons learned were that a component based architecture and smart deployment strategy are useful. All products in the product line can always be automatically “manufactured”, or generated, from the evolving core asset base. This to me sounds similar to continuous delivery, just of multiple products based on different configurations.

Salion made the transition to a software product line approach in 2 person-months, and apparently has maintained 90-day time-to-market deployments for new customers. They made use of BigLever Gears software for their SPLE bits and pieces.

So in a nutshell

An agile approach to SPLE worked for these guys, who were a small startup at the time.