There is no way to beat the cost of a 1-off custom product… but how often do you make a ‘ground-floor-up’ new product?

The cost argument is true every time, for an isolated product. But how many of your products are really an evolution of something you have done before and, tellingly, for which the engineering community are claiming large percentages of savings through re-use? Does it deliver?

If you can relate to that, then have ever thought about standing back and building the common parts as deliberately designed for re-use and just dealing with the customisations? Did you try it? You have to invest in making it work (which makes it more expensive), but obviously if you are ONLY working on the custom (application) bits for the second (and later) iteration, it must be a LOT cheaper. Did it work? Were you able to configure and deliver product as you expected, for those much improved costs?

Well, it may be obvious, but it’s not as easy as it looks to deliver on this technique, known as Product Lines, but get it right and it really delivers… more than just technically… it changes your organisation, culture and even the business connectivity between marketing and engineering! Planned, re-use without deliberate design doesn’t come anywhere close.

The prizes can be some of 10x productivity, 40% cost, 10x quality, 10x faster to market. Don’t believe me?… then look here or at these cases studies. Lots of industries use these techniques every day, and it clearly should work for those with high product repetition rates, large volumes, closely related functionality and, if you regularly develop similar products, it could for you. What you are doing is reducing the recurring cost burden, and with a wise investment, making it a non-recurring cost.

But if you think about it, it is a significant culture change:

i)                    You are asking the vast majority of engineers to work across-projects, on common (domain) assets, and very few engineers (if any) to work on a specific customer (application) project  – Project managers won’t like that (Loss of power/control).

ii)                  You are asking the company to use the vast majority of project funds as a ‘pool’ to serve the needs of many projects, rather than accounting each on its own, making it much tougher to spend control – Finance won’t like that (Loss of accountability).

iii)                You are asking the designers to define frameworks that are capable of being ‘dressed’ with a ‘pick-list’ of features with potentially sub-optimal connectivity or performance – Architects won’t like that (It’s hard and counter-intuitive!).

iv)                You are asking change control boards to separate scope and decisions for project specific or common changes, the latter needing all project representation to be quorate – Configuration Managers won’t like that (Difficult to make decisions).

There are numerous examples of this working all around us, from automotive assembly lines to software and many Open Source products (e.g. WordPress). The reality is, even if done right, the investment breakeven is reached at say the 3^rd product iteration – so you need to hold your nerve.

The keys to delivery are well-documented, but centre around recognising the scope and variation of your market, the alignment of quality attributes and a steely focus on delivering a design that delivers just those patterns of configuration that you need (or forecast you need) rather than building an ‘all possible combinations’ product that drives complexity and huge cost.

Every customer wants a unique product, every supplier wants to deliver what he has, or a minimal change – have the best of both worlds.

___________________________________________________________________________

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.     ___________________________________________________________________________

Why collaborate? Doesn’t this expose my IPR? Don’t I stand to lose more than I gain?

Well I think the answer is a resounding “No!”, but it really depends on who you put in the collaboration forums.

I have put a better prepared paper on this topic on my website here, but as I have accepted to chair NMI’s UK Systems and Software Leaders Forum, you would expect me to be a proponent. Over the last year this forum has exchanged ‘problem lists’ and there is a significant amount of common ground (an opportunity to collaborate and save costs on the solution). You can see a video report on my feedback to NMI here.

Where there has been expertise in the group, we have shared, in abstract, how we have gone about it (often 2 or 3 member companies will, independently, have had similar approaches in the solution) which gives the remaining members a flying start…  and some useful contacts/material, but just proves we are also wasting valuable engineering resource in this duplication.

The over-riding impression is that Software (and especially Embedded Systems software) has a large (UK) population who have been very innovative at solving problems (and I don’t mean just Technical ones!). Any one company only sees a small proportion of that problem space, and more than likely those problems already have tried and tested solutions, by at least one other party.

If no-one has a solution to a common problem, then chances are that several members want a solution (opportunity).

If no-one has the same problem, we could probably work out, from our respective networks, who might have an interest in the problem and its solution, or be best placed to define and champion it, industrially or academically.

The bigger our community of industries with common scope, the more we stand to benefit, and the more leverage we potentially have! The key is to have attendees who can ‘abstract’ the problem from the commercial sensitivities of their business, and equally take away another businesses abstract and understand how to apply it for themselves. So good abstract thinkers only need apply!… but then again isn’t that a fundamental trait of a good software engineer?

I hope to get an article in the NMI yearbook for 2014 on this – due for publication in about March.

In the meantime ask yourselves this: Is the collaboration from industrial representatives on Standards bodies entirely altruistic, or is it to sway decisions in favour of their own business’ products and thinking, gain competitive intelligence, spot key talent and, for the individual, a network and career opportunity for seeking out those with more advanced thinking?

___________________________________________________________________________

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.     ___________________________________________________________________________

In all engineering business poor quality equates to cost; this is equally true in software systems. Lack of quality inevitably means re-work and expensive scrap (effort), and if it escapes to the customer, we get cost of warranty, customer dissatisfaction, reputation damage as well as the distraction of fixing things in a hurry (which consumes your management and engineering effort).

Conceiving a simple, well-structured product with a clearly defined and understandable architecture will help keep all the engineers working to the same goal, but their individual skill level and experience may differ. As software is not bounded in physical, measurable, materials but is a human endeavour, structural definitions alone are not enough.

Humans make errors, software is made by humans, therefore software will contain errors. Not all errors will be detected, but not all residual errors will manifest as faults, and not all faults will manifest as failures, so a product full of errors may never fail!

An unfortunate issue for software development is that software development automation tools are in themselves software and subject to the same problems.

Most experts agree that for software, processes define product quality, not unlike manufacturing. The choice of rigour (adding more feedback cycles for validating we have the right product, adding more events for verifying we are building the product correctly) determines how many errors we remove and therefore the ‘quality’ of the production item.

The cost of software development is directly related to how quickly (after injection) an error is detected, and the set of processes involved in the round trip of correcting and verifying its removal. If rates of injection were constant then: Less detection steps => errors found later => longer correction process => greater cost of correction. The reality is that rates of injection are not consistent, but are highly dependent on expertise and experience of engineers, but more detection steps => slower development=>more cost of development. However, it is generally accepted that error correction costs increase significantly with error duration before detection.

Early investment in detection and correction is easily wiped out if the system definition is volatile, hence high-rigour systems (e.g. Nuclear, Space, Aero) tend to be less able to accommodate late change without significant impact on cost or timescale; but then we expect these systems to be ‘right first time’ or at least accommodate any faults detected in operation!

The cost of software ownership is directly related to the number of fielded failures, which in turn is related to error escapes, irrespective of their root cause (and system change is the most common). Lightweight processes may save on development costs (and indeed cost of correction) but potentially field more errors/failures.

If the business offers warranties, has service level agreements or maintains a high reputation for robustness, lightweight may not be an appropriate answer, whereas for ‘disposable’ products (e.g. Mobile Apps) or prototypes, lightweight processes are key.

Be warned: Most businesses find it difficult to get their software engineering teams to live different process rigour levels for different phases or products!

___________________________________________________________________________

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.     ___________________________________________________________________________

Building variant products in software defined systems can be used for market position both by offering different features, at different price points, but also by offering different service levels. Typically service levels define and offer minimum or expected goals for ‘availability’, ‘reliability’, or ‘performance’ say, and offer solutions to issues like failures, warranty, or problem management.

For these service level agreements (SLAs), prior measurements are required to understand the potential business benefit, and ongoing measurements to ensure the appropriate quality of service, or even use/abuse by the user. Software-based control systems are well placed to collect and inform the business and provide the ongoing monitoring.

Information from monitoring systems is routinely used for both Condition-based maintenance and Predictive maintenance in many industries in large electrical machines, jet engines and automotive components. These enable optimal service periods, replacement of marginal components to minimise future shop visits, improving availability and even initiate service events to mutual benefit of customer and service shop. The monitoring information can be used as feedback to inform the designers of usage scenarios, the business of excursions outside the warranty or SLA and the service bay with diagnostic information, both live and historic, in support of fault investigation.

The business trick is to use the existing control system sensors to maximise information or its synthesis, and only augment this sensing set when there is clear business value to be gained. Additional instrumentation, its signal processing, the transmission of information and its analysis all add complexity, cost (both unit and recurring) and delay.

The more connected our social world, the greater the opportunity for making this information more immediately available, carry more contextual information (e.g. time, location, user demands, even weather!) and enable businesses to refine their offerings, more value opportunities, or even additional products.

Technically, the key problems are collecting valid (and validated), accurate, information (differentiating signals from noise) without losing valuable transients, local processing, compression or selective storage, opportunities for (robust and secure) transmission which balance immediacy, bandwidth, and cost and off-line analysis of what potentially could be large, continuous, streams of individually correlated, but systematically uncorrelated, data.

For exceptional systems, these technical problems may be exacerbated by adaptive techniques for monitoring, storage and transmission both from local decisions and those decisions commanded from the larger off-line analysis.

Of course the determination of the appropriate margins for decisions based on the information is key to business opportunity and risk!

___________________________________________________________________________

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.     ___________________________________________________________________________

A System Engineer’s role is to understand the customer’s need, unambiguously document the intention and use, including validating it with the customer, and then define and describe an ‘optimal’ solution in terms of components that can be engineered independently, yet will integrate to deliver the required capability.

Obviously an ‘optimal’ system is subjective and needs further definition of the qualities of the system and at the same time respond to the constraints that the physical manifestation of the system solution will impose. Lots of experience or Crystal Ball gazing required! Finding a balance that will satisfy the customer is considered success.

A recurring theme, then, is “understanding the customer”, including immersion in his world; and playing the proxy customer for the development team during design, integration of components into the system, and validation. (We will deal with Verification, Validation and Integration in a later instalment.)

The customer may not be singular, but a series of ‘actors’ (human or machine) on the system who present different interfaces and needs. In large, or long-lived, systems these needs (and interfaces) may change and those changes may need to be accommodated. If this is the expectation, then the system engineer will also have to deal with the necessary future-proofing, and pass that flexibility into the component definitions.

System change is the single most disruptive attribute to Software Systems development; almost all cost and schedule overruns can be traced back to this root cause. System change (especially change that crosses system component boundaries) must cause system re-evaluation to understand the impact, or opportunity to contain, component changes and the influence on the overall capability.

In order to mitigate such change by design, system architects (a particular role within system engineering) will use techniques such as interface standardisation, modularisation and layering to partition components, create propagation boundaries and separate concerns; in general however, these are at the ‘cost’ of some optimisation, say of processing power, efficiency, speed of response, weight etc.

Change is inevitable, whether through component obsolescence, change of use of system, or in search of improved performance. Good systems engineers will design solutions that can accommodate the most probable causes at low impact, but as system size, complexity and lifetime increase be prepared to invest in system engineering to minimise the total cost of ownership.

___________________________________________________________________________

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.     ___________________________________________________________________________

As a component supplier or an Original Equipment Manufacturer (OEM) you will be providing each of your customers/markets with a custom application, whilst behind the scenes, re-using as much from other evolutions of product as possible.

Software and re-use have an exceedingly oversold pairing when looking at business economics, but there are strategies and development processes which may be of economic use. One such strategy is ‘Product lines’ which we will address in more detail in a later instalment, but is a mechanism for changing the cost model of producing variant products, centred on an architectural approach and well-managed variation points; It’s widely used in automotive, mobile phones and the like but may be economically deployed on lower volume industries.

For applications whose capability can be defined by software (‘feature content’) it is common to market a premium product with ‘full-house’ capability and other market offerings with various sub-sets of functionality. Delivering the premium product first provides the greatest development burden, but usually fastest delivery to other market price-points; or alternatively a way of incrementally introducing features of value; both need to be clearly architected appropriately to achieve the overall capability and matched to the business’ sales strategy, price-points and timing.

Getting the ‘patterns’ of feature sets right needs to be a symbiotic relationship between marketing and engineering, to satisfy the set of valued configurations, lest we fall foul of driving in needless variation and complexity (which in turn drives cost and programme) as we saw in the last instalment.

User interfaces are an area where there is an opportunity to build a brand image, and with it, brand allegiance; however the design of these should not be left to engineers without the necessary specialists skills in human interface design. As the ‘face’ of the product, it clearly needs to respond to the customer’s needs, be simple, robust and reliable, but also fit for the environment in which it is to be used.

Customers are often poor at expressing what they want, but recognise what they don’t like, so expect lots of iteration; an obvious home for low cost development prototyping (see previous instalment). Unless your market produces applications for user (mass-) customisation such as website design or workflow and management summary tools, avoid building in flexibility that could destroy the ‘look and feel’ you wish to establish, especially if this is to extend to potential vertical markets for companion products.

Human Machine Interfaces present a significant opportunity for mis-operation, whether accidental or malicious, and poor robustness here can quickly frustrate the user, or even lead to accidents. In the modern, connected world, any weaknesses are quickly disseminated and rapidly tarnish reputation.

______________________________________________________________________________

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.     ______________________________________________________________________________

You’ve bid for, and won, a new contract, or conceived a new product, but do the engineering costs truly reflect the expectations you have as a business, and how are you going to assure it’s aligned and remains that way?

To be profitable you need to get the timing right, so that determines development timescales.

You know what the market expects in terms of product reliability and the effect failures will have on the business, because you understand the sales forecasts, the intended market life, the warranty you are offering, and customers’ expectations of your brand.

There are “must haves” in your feature content which give you market position, but also lots of “me toos” that you can’t leave out. To get the product sales life, you require flexibility to accommodate upgrades, ward off the competition, or respond to the changing market.

All of these factors have an impact on product engineering and, if software is a constraining factor, will be significant for software systems engineering, where they will need clear assignment of priorities. Failure to do so will have engineers ‘invent’ flexibility you don’t need.

Key product characteristics, risk recognition and management, choice of development processes, sources of components, team capability, structure and organisation, intellectual property, partners and suppliers all play a significant part in starting down the right track and as a reference point for remaining on track. You need to act as proxy customer and set these out for your engineering teams.

Change and flexibility both drive cost in, so reduce them as much as possible… and moderate your appetite for change! Unrealistic timescales, compressing programmes and overloading resources are also the biggest drivers of cost escalation (and business failure). Good businesses concentrate on what they are good at, or those items they need to protect, and use partners or suppliers to source the remainder… the same should be true in software, but it needs appropriately capable software management internally and overseeing the supply chain, so get the best you can and use it appropriately.

The choice of software engineering processes dictates the product quality attributes and that includes the balance between initial development investment and cost of managing fielded failures (unreliable product), hence this choice should be an informed business decision. Different processes for risk reduction and production may also be inevitable and contrasted with ‘prototyping’ in other industries… be realistic, don’t expect to salvage much of the prototype into a product, or your prototype is over-engineered!

We will talk about Programme Management, Project Organisation, and Sourcing including estimation, cost relationships, measuring and managing programmes, and capability assessment in later parts.

______________________________________________________________________________

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.     ______________________________________________________________________________