Few businesses exist purely to make a single product for a single customer, although this may be the origin of many companies, in general it is unsustainable as a business. The obvious step is to sell the same product to many other customers, but unless the product is truly ‘commodity’ then each customer’s requirements are unlikely to be identical. This takes us to the logical next step of mildly variant products; the majority of the product and its mechanism of manufacture, stay the same, but minor variations are accommodated. These ‘customisations’ alter the characteristic of the product to meet the variations the business market needs to address those customers’ needs.
Buried amongst all that simple logic is the business requirement for the ‘customisations’ to be ‘near-zero’ cost so that the manufacturing costs (and its associated selling price) remains largely consistent across the market for near-commodity products. Those costs come from recurring costs of the variant manufacturing, materials, processing etc and the non-recurring investment needed to re-engineer the product, its manufacturing etc.
Software has a distinct ‘edge’ over physical product in this play:
i) It has little or no manufacturing costs (it can be replicated at near zero cost)
ii) With no ‘manufacturing’ investment, its non-recurring costs are in product engineering and test
Software re-use has had a bad press for many years, deservedly so if you look at the cost of engineering ‘follow-on’ products. In large volume markets, where amortizing these costs is insignificant, this may be acceptable, but in general, variant product from ad-hoc re-use is too expensive.
Deliberately designing for re-use has not always delivered the cost benefit. Obviously these designs require a bigger initial investment, but variants should be able to be realised cheaply. Unfortunately there are some business keys that need to be maintained to make this a business success, which are rarely championed or maintained and, as a consequence, the advantage is often frittered away, by well meaning, but misdirected, engineers.
Variation drives cost, both in design and in test. Engineering in ‘variation points’ in itself is not difficult, but combinations, and in some cases permutations, of use of those variation points can quickly become uneconomical. The reality is that not all possible combinations of variation are required and although they may realise a legitimate product, may not be a useful, or marketable, solution. The interaction of variation points, in providing a ‘designed-for’ product is then key to minimising the cost and risk in engineering. This interaction can be described as patterns of use of variation points to describe particular product variants. Managing these interactions are the keys to the techniques known as Product Lines.
Successful variant product strategies come from recognising your potential market place, analysing the potential variation required to meet their individual demands, carving out product sets that are sufficiently aligned that they can be engineered with well-defined patterns of variation. Keeping the resultant design then focussed only on serving that particular set of marketable products, minimising variation points, and defining the appropriate patterns of use, can deliver a sound business economic.
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. If the application development represents a small proportion of product cost, or the parts may be readily converted to domain assets for additional marketing opportunities, they are likely to be viable. Customers may be swayed if small features (unique to them) have disproportionate effects on product price. Getting this balance right requires co-operation between marketing and engineering, to define the right set of products and build the right (but minimal) capabilities of variation… and deny any others!
Mechanisms of variation don’t only play in software, but you can easily extend this mentality to PCB layouts and component populations, or enclosures and connectors to meet different environmental needs, say. A product may be the convergence of several product lines from different domains.
In software, there are many possible ways for maximising variation benefits using traditional principles of layering, modularity, separating demand from control, linearization of interfaces, that should be reflected in segregated variation mechanisms to provide opportunities such as portability, feature substitution, hiding behaviour and obsolescence mitigation. It is not unusual for Product Line solutions’ variation points to number in their thousands, the potential patterns of variation in their hundreds and yet the product variants generated for market only in tens. Managing this is key to being profitable!
These variation mechanisms can take many forms and can be applied (bound) to the system at many different stages (e.g. as source code changes using compilation switches, or as calibration changes post manufacture) and the choice of binding time will affect the mechanisms of test, the test environment, the build process and the potential vulnerability of product for safety through fault detection and accommodation, or security. These attributes give plenty of design space, but many potential trades (e.g. code size, performance etc) that will need to be carefully managed.
___________________________________________________________________________
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. 
___________________________________________________________________________