As we saw in the previous instalment, few businesses exist purely to make a single product for a single customer, but sell variations of the same product to many customers. Few products can be assembled solely from pre-configurable parts (known as domain assets), but often include specific parts unique to that customer (application assets). The business imperative is that application costs be minimised and domain utilisation maximised.

But how do you organise many project teams to collaborate to achieve this, when individual programmes have different customer deadline, developments will be out of phase and every project has their own budget?

Let’s be blunt… it’s a significant culture change… and one that won’t be universally liked, but it can bring real business benefit, but it won’t for probably at least the first 2 projects. You are trading initial investment against incremental investment per project.

Marketing: Get them to declare the totality of products and its variations that they see, now, and as all future opportunities. They need to provide this, after negotiation, as a contract to Engineering; Engineering commit to deliver the engineering costs for these products far cheaper than they have previously on a per-product basis, over a set of say 3 or more products. Engineering should refuse to provide (at a Product Line cost) anything that is not declared in here.

Engineering: Analyse the product variations declared by marketing and produce a ‘feature model’ that defines all domain assets (sufficiently common that they can be provided using a designed-for system of pre-configurable variation) and commit to it in the contract with marketing.

Project manager’s and Budget holders: Get them to declare how much of their project is claimed as re-use, in traditional approaches… and deposit all of that portion of their budget in the ‘domain’ pool – from each and every project.

Domain Team: This is, by far, the largest part of the Product Line resource – if it isn’t you are going to fail. They work on all the common (domain) assets on behalf of all projects. They do this by designing for all the ‘designed-for’ market of products that marketing have defined (and nothing else) and testing for all required combinations of configuration. They provide a configuration control system that gives access to the components for every (application) project and a system that details how each component should be configured for their required purpose, along with the test assets for that configured item.

Application Team: These should consist of a minimal amount of personnel, possibly as few as 1 or 2, to work on the specific customisation required by their project customer that cannot be produced from configuring domain assets. They also are responsible for configuring domain assets to suit their particular project, integrating components into their build and testing the ensemble as a project application.

Project Technical Authority: They only have ‘authority’ over application components (i.e. components that are unique to their project). They have responsibility for ensuring their project is represented in the definition of domain components. This is also true for ‘change’ and their change control board scope.

Things to think about are: the configuration management of domain assets; the change control mechanism (how changes are assessed for impact and changes authorised and agreed); component compatibility; understanding the impact of errors when detected in un-configured parts of components and within specific configured parts of components; tracking components and their configurations into product… and in which the error will be manifest; the configuration process.

I can recommend some good practical experience-based reading Software Product Lines in Action.

___________________________________________________________________________

Let us help you maximise the business potential of your product and its software

Email me on stuart.jobbins@sofintsys.com

Visit our website, or follow us on your preferred Social Media for our latest views.     ___________________________________________________________________________