Why software strategy eats development capabilities for breakfast

Sensor Fusion > Why software strategy eats development capabilities for breakfast

In a recent study, PwC estimated that by 2030, 60% of a vehicle's value will be defined by software, making software the key factor for future revenues in the automotive industry. However, the 300% increase of vehicle software and the growth of 83% in development costs per vehicle model series predicted by the authors will cause real pain. The complexity-productivity gap alone requires 25-40% additional software developers each year just to keep up the current pace of software development. In addition, the maintenance burden requires 40-80% of the initial software development resources to keep existing software functional despite aging. And finally, the lack of software talents makes it increasingly difficult to hire a sufficient number of software developers.

Only companies with the right software strategy will survive this situation and benefit from it.

So, what does it take to realize the revenue potential of automotive software? I believe two factors are crucial.

1. Building the right software

Even if it sounds obvious, developing software that does not meet your customers' needs is one of the biggest risks. It is really challenging to know what the customer wants a priori (even for the customer). Carefully defining your stakeholders, collecting their requirements, and translating those stakeholder requirements into system requirements is key to any successful software development. Without the right requirements, you will build the wrong software.

2. Building re-usable, extensible, and maintainable software

Badly designed software can choke your development teams: With every implemented change, something else stops working. The effort for new functionality is constantly increasing. It is no coincidence that most developers know the following meme:

Making software re-usable, extensible, and maintainable requires a carefully designed software architecture. In addition, this architecture as well as the overall software needs to be refactored regularly. Refactoring means improving non-functional software attributes (such as design, readability, or complexity) without changing or extending the functionality. Without regular refactoring, your software development projects will get stuck.

So, what do you need to build the right software in the right way: Agile development methods for early customer feedback? Continuous integration for test automation? Test-driven development for avoiding regressions? Yes, all of the above are required. And yet, I believe they are only part of the story.

Building the right software in a re-usable, extensible, and maintainable way will systematically fail if this software is not part of your competitive strategy. In other words: The biggest mistake in software development is to develop software that is not strategically relevant.

Before explaining this claim, let me define the term strategically relevant:

Not every piece of software is equally important for your customers and your competitive advantage. If the performance or quality of a software component is influencing your customers' buying decisions - if it is directly affecting your revenues - I define this particular piece of software as strategically relevant. In contrast, if your customer will most likely notice a software component only if it fails and if making this software component better will not make your products or services better in the eyes of your customers, I consider it as not strategically relevant.

You will get market feedback only for strategically relevant software

Learning the right requirements depends upon interactions with your customers. Be it sales meetings, customer workshops, or A/B tests, you need market feedback to reduce the risk of building the wrong software (which, by the way, does not necessarily mean that you should build what the customers are saying they need). However, your customers can only give opinions on those aspects of your system that they can experience and that matter to them. Even if they wanted, customers are simply not capable of providing substantiated feedback on functionality they would not even notice in the final system. Thus, they cannot help you in deriving requirements for software that is not strategically relevant to you. As a result, due to missing requirements for software not strategically relevant to you, you risk building the wrong software.

Refactoring will only happen for strategically relevant software

Making a software re-usable, extensible, and maintainable requires investments in refactoring. Such investments do not pay off in the short term. That is why no responsible decision maker will make such investments if he or she cannot predict its return. In other words, if a software component is - though required - only a cost factor, without any influence on revenue, investments in code sustainability are very unlikely to be made. Though this will hardly be noticed at the beginning, the technical debts incurred by this effect will in the long run inevitably consume a significant share of your development capabilities. As a result, software development projects for software not strategically relevant to you are likely to get stuck. Again: This is no lack of ability, but a deficiency in software strategy.

Sourcing is key to any successful software strategy

Adapting the famous quote by Michael Porter about strategy, I would suggest that: "The Essence of Software Strategy is Choosing Which Software Not to Develop."

In other words, defining a software strategy means to decide which pieces of software to develop yourself and which pieces to source. The responsibility for these decisions lies with the management, not the developers. I have compared different sourcing options in detail in my previous article. The following process model might guide you through these alternatives:

Developing strategically-relevant software right

For software that is relevant to your strategy, it is essential to own the intellectual property rights (IPRs) exclusively and to develop and maintain the required expertise. Still, I do believe that developing your strategically-relevant software in-house completely is a mistake.

Why? Even if a software component is strategically relevant, very rarely all of its sub-components are. More often than not, the competitive advantage stems rather from an intelligent combination of existing technologies than from full re-inventions. Using commercially available libraries, frameworks, or software development kits (SDKs) keeps you in control and allows you to develop exclusive foreground IPRs by combining and extending elements of available frameworks in a unique way. At the same time, you will build upon software that is directly available, proven in use, and — most importantly — comes with a licensing business model that shares development costs among all user. This will cut your time-to-market and preserve your internal development resources. Long story short, licensing frameworks or libraries for basic functionality of your strategically-relevant software will make you faster and more profitable.

Sourcing non-strategically-relevant software right

If you identify pieces of software that are not strategically-relevant to you, the easiest and most obvious option is to license them from a software product company. If this particular piece of software is available on the market, this is exactly what I would recommend.

But what about software that is not available on the market? Well, a software that is not strategically relevant to you might be for other companies. For instance, my company BASELABS is developing safe sensor fusion software. This is strategically relevant for us and we focus all our efforts on it. For our customers (mainly automotive OEMs and suppliers), sensor fusion is needed for automated driving, but it does not affect the automated driving experience itself. In other words, it is not strategically relevant for them.

As a consequence, we are partnering with pilot customers to develop the software they need together. For them, this safes cost, time, and resources. For us, we learn the requirements and have the chance to commercialize the existing software in a scalable way with other customers later. By doing so, we share the development costs among several customers, which benefits everybody involved.

So, my suggestion for sourcing non-strategically-relevant software which is not available on the market is to partner with software suppliers that might have an interest in commercializing this particular software even if they do not offer it today. With such a partnership, you can stay focused while at the same time getting what you need from an intrinsically motivated supplier.

A fallback strategy can also be to work with specialized software engineering providers. While they might have no strategic interest in the particular software itself, at least it is their strategy to provide professional processes and capable developers. However, I consider that rather a developer sourcing than a software sourcing option.

In summary, my main advice is to choose carefully which software you will or will not develop yourself. Investing the necessary time and effort in your (future) software suppliers is your most powerful lever for being successful in the future, software-driven world of automated vehicles.

Read all articles from Robin

How software sourcing can leverage your competitive advantage — if you pay enough attention

The underestimated factor in your automated driving software strategy