What is the Cost of Developing, Maintaining, and Deploying a Software Architecture?

Many companies that traditionally identify as hardware manufacturing companies are starting to look at modular product architectures. Investing in a modular product architecture can dramatically impact the costs of hardware products, affecting direct material through maximizing reuse and economies of scale, optimizing production flows, and supply chain efficiency.

Although not always obvious, hardware-producing manufacturers today are dedicating a lot of resources to software development, testing, and maintenance. Hardware modularity will not reduce the cost of software architecture on its own. However, if software architecture is included or even integrated into the product architecture – the cost and effort to develop, test, and maintain software can also be reduced.

In this first post in our series, we will look at the differences in how hardware and software costs are calculated. Check back for future posts as we investigate how to optimize those costs in software using a modular architecture.

Let’s start with cost drivers in software and hardware development.

Differences in Cost Drivers for Hardware and Software

Hardware production is mainly impacted by direct material, production flows, and supply chain efficiency. There is, of course, a large amount of R&D and testing involved, too, Still, these costs are usually less significant over time for mass-produced products since the R&D and testing costs occur only once when the product is being designed, and are shared for all the units produced. These costs are fixed in relation to the production volume while the running production costs occur for the entirety of the product’s lifetime. These costs are variable in relation to production volume.

By contrast, the costs of software products, procurement, production, and supply chain costs are usually overshadowed by R&D, test & verification efforts, and deployment. Hence, there is a fundamental difference between how hardware and software development costs scale with volume, and consequently, the steps needed for their optimization differ.

Figure 1. Cost Drivers for Hardware and Software products are fundamentally different

Let’s dive into the different costs:

Direct Material

Software licenses, patent and compliance fees, and infrastructure costs may be affected by volume to some extent, but compared with physical direct material costs, this is usually still a tiny part of the total product costs.

Production Flow

Hardware production typically requires both heavy investments, and significant labor. With automation, Just-in-time (JIT) flow optimization, continuous improvements and waste reduction, the resources needed per produced unit can be significantly reduced. For software there would typically be two production steps: Step one would be to install system test software and Step two would be to install the production software after system verification. With that said, it is still important to minimize the software installation time in production to meet the production takt time and avoid system verification bottlenecks.

Supply Chain

Nobody is physically transporting software using floppy disks or CD-ROM anymore, but instead software is transported between supplier and consumer at the speed of light over fiber optics. The supply chain optimization you could improve relies almost solely on how fast you can come to terms with a software supplier and sign a contract. Of course, Internet connections have bandwidth limits, and you may have to increase the capacity stepwise. But the typical software is not so big that this adds significant cost to each supplied copy.

Development Cost

There is a substantial amount of cost in developing both hardware and software. For hardware development, costs primarily occur when a new product is being designed and before it is shipped to customers. Major features and services are usually still being developed and improved for software even after the hardware has been shipped. Hardware improvements occur after the first launch of a product, too, but are mainly focused on improving the quality and cost of the shipping hardware.

Test and Verification

While test and verification costs occur primarily in post-production in hardware production, for software production, it is a recurring cost from the early phases of development.

Maintenance and Support Costs

In any development, this is where a lot of the costs are hidden. These costs can be tremendously high for software depending on the type of product it relates to and how the support organization is set up, since they are depending on the quality of the software deliverables and the ease of use of the user interaction elements. Finding and fixing bugs found by customers instead of within R&D can be very high, and in some cases hardware issues need to be fixed by software instead of doing costly hardware recalls, for example fixing ASIC problems (Intel Releases a Patch for 'Downfall' Vulnerability Affecting Billions of CPUs).

Deployment

Software deployment costs can be both significant and complex if not done efficiently and controlled over time. With software teams adapting to new deployment models, like continuous cloud delivery and delivery of application pieces (i.e. patches), instead of complete releases, managing the variations can grow exponentially and outgrow costs related to delivering features addressing new customer needs.

If we dig deeper into the software costs, we can see that while there is a large portion of the cost in software licenses, hardware, and infrastructure, a substantial part is in reoccurring labor costs. Ensuring efficient development, testing, release, and maintenance practices are key to successful software development, since they are recurring for every new software release.­­

Figure 2. Cost Drivers for software (size of the item has no relationship with the size of the cost)

Maintenance costs grow with the number of software releases supported on the market. For this reason, it is important to have methods that avoid a linear cost increase per release. If not, there is a high risk that you will be depleting all R&D efforts on maintenance and support instead of innovation.

Figure 3. Maintenance & Support costs grow proportionally to supported software releases

In the above example, it is easy to see that even with a modest 10% of the total effort spend on maintenance & support, more resources are spent on maintenance if you support five or more releases on the market simultaneously. At the same time, all resources are spent on maintenance when you reach ten supported releases.

This is of course a fictive example, where companies instead of draining their entire development organization tend to:

1. Phase out older releases, in some cases very aggressively as seen in the example of the Google Graveyard. This method risks being seen as unfavorably by customers and should preferably only be done according to clear roadmaps such as Microsoft Lifecycle for Windows. Even with excellent roadmaps and perfect customer transparency, you can be certain that some customers will be left very unhappy with the phase-out of a software release.
2. Create large releases, covering a wider assortment (i.e., software platforms) that can serve multiple products. However, this can prove counterproductive as the test and verification effort can grow exponentially to ensure all release checklists are met for all released hardware platforms.
3. Lower or cap the maintenance and support ambition, resulting in fewer customer complaint tickets supported and neglecting to fix non-mission critical faults in the released software. This approach usually makes no one happy except maybe the company’s financial controller and this is a gamble against customer satisfaction and their willingness to reinvest in your products in the future.

Neither of the above alternatives is great, with all of them leaving many unhappy and dissatisfied. What if there is another way to solve this equation while gaining value in many business areas?

Modularize the Software to Avoid Linear Cost Increases

Luckily there is another way to avoid a linear cost increase in maintenance and support costs of the software releases, and this is to invest in a modular software platform.

In a modular software platform, changes are delivered in modules allowing to support a much larger number of released software products.

How this can be done and the benefit it brings are will be covered in future blog posts, but get a sneak peak of the benefits by reading Best Practices for Software Architecture in Hardware Companies.

Let's Connect!

Modular software architecture is a passion of mine and I'm happy to continue the conversation with you. Contact me directly via email below or on my LinkedIn if you'd like to discuss the topic covered or be a sounding board in general around Modularity and Software Architectures. 

Roger Kulläng

Senior Specialist Software Architectures 
roger.kullang@modularmanagement.com
+46 70 279 85 92
LinkedIn

Thomas Enocsson

EVP and President Modular Management Asia Pacific AB
thomas.enocsson@modularmanagement.com
LinkedIn