Manage the Transformation Through Software Modularization
In today’s app-store-driven business environment, many traditional hardware companies find themselves in a position where their hardware products, which were once the essence of the business, are now merely a vehicle to carry the software products.
Apple changed the world of mobile phones with iPhone. This once hardware-focused business suddenly had customizations added in an after-market app store. New features and functionalities delivered over-the-air. Over the past decade, Tesla has pushed a similar paradigm shift into the automotive world. In their 2030 Strategy Volkswagen Group, the self-proclaimed Champions of platforms, are clearly indicating that the unified software platform is just as important as the unified mechatronics platform.
In fact, many ex-hardware business executives witness that their hardware business is turning into a software business. Companies once relying on world-class mechanical engineers, nowadays have more coders than CADers.
Since so much of the customer value, customization, and performance now is software-driven, more focus is put on the software architecture, and rightly so. Companies carrying a legacy of multiple software monoliths, each developed to support a specific product platform are facing an intricate challenge – how to transition from the existing state to a new state where a single unified efficient software architecture can be utilized to create maximum performance, customer value, and minimizing development work and time?
In this blog, I will discuss how companies can practically solve the dilemma of both maintaining the legacy and developing the new. And how software modularity and hardware/software decoupling are key concepts in the solution. But first, let’s look at how software and hardware and fundamentally different when it comes to the cost side of the income statement.
Cost Drivers for Software and Hardware
The cost drivers for software are fundamentally different compared to hardware. For hardware, direct material costs and supply chain efficiency are very important to achieve a competitive cost level of the product. For software, direct material costs are usually not as important since there is usually a relatively low number of licensed third-party software items in the products.
Supply chains are lightning fast due to the digital economy and the Internet. There is also limited savings that can be made from buying software in large quantities. These facts are even more true if OSS (Open-Source Software) is used in the products (and they usually are) since the monetization model of this type of software is different. Because of all these factors, the largest cost of a software product by far is the cost to develop, maintain and test the code that comprises the product.
The code normally evolves for several years with lots of product knowledge poured into it. There are many good reasons why a company wants to build upon that knowledge rather than rewriting it from scratch when they invest in a modular software architecture. Many times, the importance of software is overlooked when companies invest in modularization, and it is often overlooked in the initial hardware or mechatronics modularization investigation. The architecture of the software is considered very late in the process, often when the launch plan of the modular hardware is already decided upon. And software developers will have to play catch-up.
The consequences of overlooking software when modularizing a product may be grim. To understand these consequences, we will start by exploring how you can organize software developers to support the introduction of a new modular hardware platform.
How to Organize your Software Developers to Support a New Hardware Platform?
Your software developers are usually organized around one or several software platforms which support the different hardware products. The teams continuously develop new features and capabilities for the products and solve issues that are found in the deployed systems.
Figure 1. Software teams develop towards a hardware platform.
When a new modular hardware platform is introduced, problems arise on how software developers should organize themselves to work with the software platform that is needed for the new line of hardware products.
Figure 2. How to organize the software development to support a new modular hardware architecture?
The Fast and Cheap Way
The fastest and cheapest way to reorganize would be to abandon the old software platform and let all developers start with the new one, but this only works in theory and is usually never a possibility. The new modular products are not ready yet, so all revenue comes from the existing products that are already on the market. Depending on how long the replacement of the product assortment takes, moving all developers to the modular product assortment can hurt the business in several different ways:
- Customers might be frustrated with the negligence of their reported issues and stop buying products entirely. If some customers are paying for support on a subscription basis, you can bet that they will scream rather loud about this kind of move.
- The products on the market need to stay relevant and competitive while the new products are being developed. You don’t want to be in a situation where the old product is doomed in the market while the new one is still being In the worst case, this can lead to management decisions (as greatly demonstrated by how new products have been released in the video game industry) that damage the company reputation in the long term.
- The products on the market are operating in the real world which is ever-evolving. New cyber-security and safety threats are constantly being discovered, and IT countermeasures and safety regulations are being launched to address them. So even if the software was virtually bug-free when you abandoned it, you can bet that there will be the need for changes anyhow down the line. For instance, Microsoft solved critical security bugs in Windows XP 2019, 5 years after end of support to save their reputation and keeping their customers (and the world) safe (Microsoft’s First Windows XP Patch in Years Is a Very Bad Sign).
The Expensive (and Impossible?) Route
Another way to reorganize would be to hire a second set of developers to take care of the maintenance of the old platform or develop the new one. Typically, very few companies can afford to do this, and since the software platform will need a set of very similar skills as already employed it can be virtually impossible to find the competence needed within a reasonable time frame.
Figure 3. Expensive (and impossible?) scenario.
The Typical Scenario
What usually happens is that companies designate a few developers to keep working with maintenance tasks on the old software platform while funneling most developers to the new one. In many cases, this also requires adding a few extra resources (typically consultants) to increase the development capabilities on the old platform.
Figure 4. The typical scenario for organizing the software developers.
While this looks good on paper, it also has issues.
- The developers still working on the old Platform A, in many cases, feel abandoned and singled out. This can be an HR problem to keep an eye on since this can have long-lasting effects.
- The competencies of the developers working on the new Platform B are still needed for the old Platform A, so there is a high risk of resources getting pulled from B to A when things get real (i.e. “shit hits the fan”) or when strong customers require features to be implemented on the old platform. It will take strong management to stay committed to the resource split in this scenario, and very often it is hard to say no to important customers.
The above factors effectively prolong the time it takes to implement the new software Platform B, thus increasing the risk of further cannibalization of resources effectively ending up in a situation that looks more like the scenario below.
Figure 5. A consequence of the typical scenario and external factors.
This is a very bad situation. It takes a long time to implement the new software platform that supports the new hardware. If that new hardware platform is also modular, all the great benefits and cost savings that are expected ahead are yet to be realized.
Adding fresh resources to the project in this stage can also be hazardous since newly hired developers are in need to be trained by the existing experienced developers. This could backfire and slow the project down significantly – a symptom known as “Brooke’s law”.
This causes companies to make really hard decisions such as:
- Leaving out functionality in the new software platform to get an MVP (Minimum Viable Product) out.
- Delaying the hardware platform release schedule.
- Delaying or even canceling necessary or future-looking refactoring efforts that could have revitalized the software platform, such as an effort to make the software modular!
- Make bets on the software quality of the new software platform, giving the new software platform a bad market reputation and incite the need of doing software patching for a long time going forward. This is a very common effect when the need to put something new on the market is growing.
Recommended read: “Brooke’s law” – “adding manpower to a late software project makes it later” was originally covered in the book “The Mythical Man-Month” by the author Fred Brooks.
Modularize the Software First
Can’t we do something that is more proactive, value-creating, and does not generate a lot of waste and quality issues?
The good news is that there is a solution to this problem. It is to perform software modularization of the software before changing the hardware.
One of the drivers for creating software modules is to decouple software and hardware platforms, making it possible to anticipate hardware changes in the future. Since a new modular hardware platform is a very large change, it is important to look at the software architecture immediately, preferably before attempting to modularize the hardware. If you have a good design, the software already has a decoupling, and you can start working with improving it to absorb anticipated changes in the hardware.
Figure 6. Start software modularization of the old software platform first.
If you perform software modularization first, you can be in a situation where the same software development team will be able to support both the new and the old hardware platforms, backporting features and fixes in the application that are needed on both platforms (that both hardware’s support). The overlap in supporting two different software platforms can be kept to a minimum, and you can be much more flexible in releasing features targeted towards both the new and the old hardware.
Figure 7. Supporting the old modular hardware from the same modular software platform.
The reason why this is possible is that the variance of the different platforms is contained in the variants of the modules, but the application software (the piece of software that does the heavy lifting) can be similar and share a lot of components that are “carry over” between the different platform generations (e.g. databases, alarm systems, file systems, external APIs, field buses, IO system etc.).
The only drawback with this way of working is that you will need to spend time modularizing the software towards the old hardware platform, actively delaying implementation work on a new modular hardware platform. Therefore, this works best if the software modularization effort takes place before hardware modularization. If you start the software modularization too late, you might otherwise end up in the situation visualized below. The release schedule of the new hardware dictates what will be possible to achieve in the software modularization effort.
Figure 8. Starting software modularization too late affects the quality and scope of software modularity.
Microsoft Operating System is a Great Example
One of the most well-known examples of a working modular software platform is the Windows operating system where Microsoft can introduce new operating system enhancements independently of the hardware drivers that come from hardware vendors. The OS can utilize these without disrupting important software applications such as the Office apps that need to run on the OS. Hence, if the apps use the defined interfaces as intended, they can be updated independently of the operating system. Office runs equally fine on a Windows 7, 10 or 11 machine and from several different hardware vendors and chip manufacturers. Apart from famous cyber security flaws in the past, most issues historically with Windows happen each time Microsoft has changed the way hardware drivers plug into the OS. One example of this was the introduction of Windows Vista when they made a major change in how graphical drivers were hosted by the OS and this caused graphics drivers to be very unstable. This indicates that changing strong and commonly well-known interfaces are not to be taken lightly by any development organization no matter their size or strength.
From the above example, it is clear that creating hardware independence using software drivers towards the hardware and creating APIs and process boundaries that separate apps from the OS is a clever design. However, there are still a lot of hardware main computing units out in the wild that run on bare metal (i.e., without OS) and with all software delivered in one big monolithic distribution. This design might be cheap to produce, but it is very difficult to maintain and update when new hardware needs to be adopted.
To Modularize Hardware Efficiently, start with Software Modularity
This blog post is intended as a wake-up call to companies that were once hardware-first. Software is here to stay – it is important now and it will only grow more important in the future since software is becoming the key to differentiator in an increasingly competitive market where hardware platforms are commoditized
Introducing a new modular system for hardware is a great idea that most technology companies could benefit from. To get to these benefits as fast as possible, it is highly recommended to start looking at the software first to make sure that you can efficiently transition to the new modular hardware architecture without ending up with resource problems when staffing the project with software developers. This blog on Best Practices for Software Architecture in Hardware Companies is a great reference for getting started.
If you do this the right way, you can use roughly the same number of developers to support and innovate on both the old and the new hardware architectures as long as available hardware resources allow for that (there could be limitations on CPU, memory, security etc. on the old hardware platform).
This all of course assumes that the essential function of the software system for the old and the new hardware is the same and that you can foresee technology advancements that you as a company need to make to stay competitive. The best way to do this is to create strategic software modules, where interfaces are positioned and designed to allow the necessary development of the product over time.
Read more about What a Strategic Software Module is in this introduction blog to Strategic Software Modularization, here you can also download a template for documenting your strategic software modules.
Transforming from Hardware-First to Software-First Requires Strategic Focus
As I have discussed in this article, there are many factors to consider when designing the transition toward a software-first business. Careful consideration must be taken to allow for maintenance of the legacy while not stopping the new development.
Since the transition is critical for many ex-hardware companies, it should be on the top executives’ table. Failing to recognize, understand, and prioritize this shift can lead to market-leading companies being left behind by new players that can adapt more quickly. This happened 15 years ago in the mobile phone business and is happening right now in automotive. I bet my money on the horse that this trend will spread across many other industries in due time.
Download a PDF of the blog to keep in your back pocket or share with a colleague
Or, let's continue the conversation
Software Modularity is a passion of mine and I'm happy to continue the conversation with you. Contact me directly via email or on my Linkedin if you'd like to discuss the topic covered or be a sounding board in general around Modularity and Strategic Product Architectures.
Roger Kulläng
Senior Specialist Software Architecture
+46 70 279 85 92
roger.kullang@modularmanagement.com
