Category Archives: Business

Programme Management – Customer Application / Domain re-use

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

Visit our website, or follow us on your preferred Social Media for our latest views.    linkedin twitter (2)___________________________________________________________________________


Multi-Geography Development

Are you part of a large corporation? Does software and system development take place in multiple teams? Are they geographically displaced? (Recognising that for most software engineers 4 feet and 4,000 miles are the same!)

Most corporations tend to play to particular market segments, maybe several, but often multiple products within each segment. Business credibility makes this a natural alignment.

Those markets adopt certain standards, both of process, but also of technical interfaces. Even if you are making a different product to other teams, if you are serving the same market segment, likely as not you are duplicating efforts. In some cases the standards may be common across market segments, or the processes acceptable across multiples… so there is even more potential for sharing. The corporation sees duplication as wasted money… engineers see it as control of their own destiny!

Sharing takes effort, especially communication effort (which commercial software engineers seem to lack, even though they perform differently on social media!) and a huge dollop of ego-suppression, negotiation and compromise skills.

This topic has a lot of commonality with the Product Line theme previously, regards behavioural characteristics and organisational change, although technically the answers for re-use in these cases are somewhat more pragmatic and probably already available to you.

But let’s take a step back…

If I were in a small outfit, I’d have to focus on my expertise and the specifics of my product that were valuable intellectual property to me. I would look for commercial solutions or partners who had credibility to deliver bits I couldn’t afford to spend my time developing. I would have to make sure their products offered the flexibility I needed, or live with their restrictions (or go somewhere else). In other words I have to relinquish some of my wish to control, for economy of development.

…see a parallel here?

Why don’t big organisations who serve particular market segments (distinguished by both process and technical standards) organise themselves as commodity component developers and, separately, application developers/ system integrators?

Architecturally this would make sense: platform independent applications, sitting on commodity OS, sitting on (various) commodity device drivers, sitting on (several, possibly modular) electronic platforms, using commodity protocol stacks and standardised interfaces to sensor and actuation systems.

This would also play to individual skill strengths, improve reliability as one set of design, implementation and test sources and provide a clear technical ownership, a coherent technical community, authority and leadership. Of course the disposition of the groups could be virtual, with individual members of a co-ordinated commodity team being dispersed, but more realistically the development and test environments would require them to be co-located by virtue of their commodity group. You could even chose to serve the commodity internally or externally to meet business needs.

< humour_mode>

Ah,… now I remember, it’s about those egos and control… it’s not technical, it’s people.

Nothing anybody else will develop will be good enough for me, they won’t accommodate what I need, there is no way of communicating it and they would never develop it in time. For example, how would I know what component I need, how would I access it and how would I raise change requests on it that I could track?…

… it will never meet my safety, security or reliability requirements, I will have to deal with failures as no-one will warrant its behaviour and as for test evidence….

… and I’ve never heard of Open Source, so I know there is no development model that could possibly work like that, even if I could reproduce it all inside the corporate network!

Damn, if only these Linux served Web-Host, Word Press Blog and AtMail applications weren’t so feature rich and reliable, I could write it all myself in a few years!

</ humour_mode>


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

Email me on

Visit our website, or follow us on your preferred Social Media for our latest views.    linkedin twitter (2)___________________________________________________________________________

Single Product or Multiple Product Variants?

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 3rd 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

Visit our website, or follow us on your preferred Social Media for our latest views.    linkedin twitter (2)___________________________________________________________________________


Software and Systems Collaboration

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

Visit our website, or follow us on your preferred Social Media for our latest views.    linkedin twitter (2)___________________________________________________________________________


Software Costs

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

Visit our website, or follow us on your preferred Social Media for our latest views.    linkedin twitter (2)___________________________________________________________________________


Service Levels – Software enabled delivery and measurement

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

Visit our website, or follow us on your preferred Social Media for our latest views.    linkedin twitter (2)___________________________________________________________________________


Systems Engineering, Interfaces and the effects of System change

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

Visit our website, or follow us on your preferred Social Media for our latest views.    linkedin twitter (2)___________________________________________________________________________


Brand Positioning and how Software can help product variation and allegiance

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

Visit our website, or follow us on your preferred Social Media for our latest views.    linkedin twitter (2)______________________________________________________________________________


How do I know if my Software Engineering matches market expectations?

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

Visit our website, or follow us on your preferred Social Media for our latest views.    linkedin twitter (2)______________________________________________________________________________