Hardware and software engineering in a nutshell

Hardware

Hardware is usually complex to engineer and expensive to produce and distribute. Depending on what type of hardware you build, a broad spectrum of skills are needed: for example mechanical engineering, electrical engineering, materials engineering, product design, manufacturing methods or logistics. The process of hardware engineering typically takes years and is characterized by sequenced phases. Any mistake or bad decision in the early stages of the engineering process will cost a fortune to fix later. For example individually built tools for the production process are trash or worst case you can’t launch the product at all because some important regulatory requirements were missed out in the beginning. In a nutshell hardware is difficult and expensive to change and development cycles are typically several years.

Software

Software instead can be changed easily at any point in time. Of course changing fundamental technical or business decisions also leads to additional costs, but software is fully changeable and usually can be rolled-out easily to all users. For example changing the frontend technology can be achieved more or less by deploying a new version of your software product. Cloud technology and open source software made it quite easy for everyone to start a software business from scratch. Thus the entry barrier to build software is very low compared to hardware business. Another differentiator for software is that value can be delivered in short cycles right from the beginning. Feedback from users can be gathered very early in the engineering process. Because of this the risk of building products users don’t need can be reduced tremendously.

Symbiosis of hardware and software

Hardware delivers a specific value proposition to its users. For example with a car you get conveniently from from one place to another. With a vacuum cleaner you can easily keep your home clean. A characteristic of hardware is that its value usually decreases over lifetime as new hardware generations with new or improved features hit the market. Thus hardware manufacturers constantly have to build and produce new generations of their hardware in order to stay competitive and attractive. This means massive and risky investments in hardware engineering and production. Hardware with software defined value propositions changes the game fundamentally. As software can be adapted easily, new features based on user feedback can independently be delivered of hardware development cycles. Value can be realized in shorter cycles without the need to develop and sell new hardware. You even can increase the value of the hardware during lifetime. An impressive example is the car manufacturer Tesla that has constantly increased the reach of electric vehicles by applying software updates. The game-changing capability of this company is to combine complex hardware with adaptive and innovative software. Compared to other car manufacturers Tesla gained a competitive advantage because they can deliver value without the need of developing a complete new car. Furthermore they can create constant revenue streams by selling digital add-ons for their cars.

Project vs. platform thinking

Typically hardware manufacturers organize hardware engineering as projects. Thus there are lots of projects going on in parallel, each with a dedicated goal, timeline and budget. As worst case scenario each project builds its own pieces of hardware and software because reaching the project’s goal in time and budget is the one and only priority. Unfortunately the overall user experience often suffers as it feels kind of disconnected: separate apps, product registrations or user logins are some common examples. Furthermore the hardware experience can be affected in a bad way if the handling of each device is different, although built by the same company. Harmonizing the experiences across multiple physical or digital products is a complex challenge if you think and work in standalone projects.

To tackle this problem some companies apply a modular system for hardware engineering. From my point of view modular systems are very comparable with a platform approach. It’s all about reusing components or in the digital context technical and business capabilities. These capabilities should be managed and built outside of projects because it’s crucial not to serve only a specific project but building generic and sustainable solutions. Shifting towards platform thinking changes perspective from the internal organization to the user’s point of view. How does the user want to experience the hardware or digital product instead of following a silo project goal.

So the key is changing the way you deliver value to your users fundamentally. Projects with a fixed timeline, budget and silo goal have to be replaced by a holistic view on user experiences and sustainable technical solutions. In other words moving from output driven projects to outcome driven platform development. This means you have to restructure the whole organization in terms of responsibilities, decision making, funding, technical architecture and methodology.

Organizational structure

Organizations are typically structured in functional departments: research and development, production, sales and marketing or information technology. Projects are used to staff people as a matrix organization for a specific period of time. People from all relevant functional departments work together for the specific project and go back in their departments afterwards. As a result there is no responsibility for the entire life-cycle of the physical or digital product. Every project tends to build stuff from scratch again and the company eventually ends up in operations hell for the scattered solutions. In addition you have to ramp-up teams again and again as the performing project teams separate after the project has come to an end.

Organizing teams around capabilities or products with life-cycle responsibility is a more sustainable and effective way. Think of teams taking life-time responsibility for a specific technical or business capability. For example a team for customer identity and access management would be responsible for this specific capability company-wide and all people in the team would work together full-time with all needed skills to build and operate this digital service. Another example would be a team responsible for Bluetooth communication for all hardware devices. It doesn’t matter which hardware product you intend to build. All hardware requiring bluetooth communication would go through one team owning this capability. Of course there is a high risk of creating bottlenecks if you don’t take actions to avoid them and there are definitely situations in which building a capability twice makes sense.

In a nutshell, an organizational setup staffing people around capabilities is fundamentally different from the organization model typical hardware companies use today. Thus it’s so difficult for them to change this long learned and proven paradigm.

Synchronized engineering approach

As hardware and software engineering have different development cycles, years vs. months or even weeks, the challenge is to synchronize and harmonize the engineering processes. Worst thing you could do is handling software the same way like hardware: sequenced phases and fixed scopes years before the market launch of the product. This definitely won’t result in a stunning digital experience at the point in time when the product hits the market. But as outlined before hardware engineering does have these constraints and it’s also not a good idea to just ignore them.

From my point of view a crucial success factor is that hardware and software engineers work together right from the beginning. I often experienced that hardware engineering starts with requirements engineering and hardware design as a silo and the people who had to build the software were involved very late in the engineering process. Actually often too late to include valuable feedback in the hardware design. Another failure I saw a lot was the switch of responsibility during the engineering process. In the early stage of hardware engineering different people from software engineering were involved than in the stage of building the production-ready software. There was no life-time responsibility for the software product we planned to build. Thus I think people from hardware and software engineering should team up right from the beginning and stay together until market launch. And even after market launch they actually should stick together in order to deliver new and improved features to the users. Hardware companies often forget that one key advantage of software is its changeability. It just makes no sense to stop all activities after the physical product was launched.

Decoupling hardware and software by design

In an ideal world you would engineer a piece of hardware and all today’s and future use-cases could be delivered as software. Unfortunately hardware and software is often baked together inseparable as hardware manufacturers usually specify only dedicated functions to be implemented by external suppliers. A sensor or camera in a car for example has to fulfill a set of functions supporting specific use-cases and the related software is built exactly for these use-cases. By following this path there is no chance to deliver future use-cases you haven‘t thought of in the beginning.

Thus decoupling hardware from software is the key to be flexible for future use-cases. To be clear: I mean decoupling in terms of architecture or technology and not in terms of organization. Hardware and software engineers have to work closely together to be successful. To gain flexibility hardware has to be engineered with enough unused capacity for future use-cases. If you design hardware with only today’s requirements and possibilities in mind you won’t be able to deliver future use-cases on top of this hardware.

Another aspect you should take care of is different levels of speed. The closer you get to the hardware level the slower the change cycles usually are for the corresponding software. For example there are often regulatory requirements preventing you from just changing the hardware-dependent software. On the other hand the user-facing software, e.g. smartphone apps, can be changed in short cycles without any risk. In order to enable development at different speed levels the overall architecture has to support this by decoupling hardware-dependent software from user-facing software.

Hardware development needs the possibility to easily test different stages of software development. Vice versa it is important to simulate the hardware functions as the real and functional hardware is usually available very late in the process. Working with digital twins and interface contracts are possible options to tackle this.

If you build experiences based on data stored in legacy systems, a huge challenge is to integrate these systems. Think of product information data coming from a legacy manufacturing system or user data coming from a legacy CRM system. Both examples have the potential to destroy the user experience as these systems were usually not built for direct user interaction. The only thing you can do is to reduce legacy wherever you can, either by building the legacy system new from scratch or pulling out the data and making it accessible for your platform.

Conclusion

As long as 3D printing capabilities don’t disrupt current manufacturing processes fundamentally, hardware engineering stays a complex, time consuming and costly endeavor. In particular hardware manufacturers for consumer products need to learn how to enrich their hardware products with digital values to survive on the market. The ability to adapt to change quickly is more and more an important differentiator from competitors. To achieve this business agility lots of aspects are relevant.

First of all the organizational structure needs to support this. From my point of view if you stay with projects planned and funded years ahead there is no way to reach fast adaptability. Platform thinking together with cross-functional, dedicated and fully enabled teams are essential to reach this. These product or feature teams deliver constantly value, make decisions for their products in the best interest of the company without having to ask steering committees and are dedicated staffed with all relevant skills to build the products.

Second important aspect is alignment regarding when to do what across the whole company. As pointed out before hardware engineering is structured in sequenced phases and takes ways more time than building software. Thus you need an approach to support at least two levels of speed as well as two planning horizons. Unfortunately I saw companies introducing just an agile methodology and hoping everything would be fine afterwards without understanding the real challenge they were facing. From my point of view the challenge is to find a way to support hardware engineering processes without loosing the flexibility and speed for software engineering.

Third point is to find a way to decouple hardware and software in a way that you can use hardware capabilities in a flexible way. This comes together with managing and building sustainable capabilities instead of each project building its own stuff, creating a holistic understanding of the user journey instead of having only a small part of it in mind and finally applying an evolutionary or demand driven approach instead of planning an architecture or platform on the drawing board.

From my point of view the most important point is to understand that there is no single action or blueprint you can take. You need to balance all aspects and improve continuously based on what you’ve learned for your individual company.

Moving from waterfall to agile

At Porsche we had a standardized approach for IT projects: more or less a waterfall approach with lots of documents to write. The business side had to define the requirements, after approval of the requirements specification the IT guys started with technical specification and implementation, finally the software was delivered. For Porsche Connect with a very challenging time constraint and lots of uncertainties we had to change this approach fundamentally.

A small group of people, business and IT, started to push an agile approach. All people needed to develop the software products were organized in cross-functional teams. Writing documents was replaced by writing code and delivering working software as early as possible was the main goal. One of the most demanding tasks was to overcome internal concerns about the agile approach. We had to convince lots of people that it‘s worth to follow the agile path. Beside of training the Scrum methodology, the change of the people’s mindset was a very important enabler for our small agile outpost. Delegating responsibility to the teams, encouraging the teams to make decisions on their own in the best interest of the product and to trust each other was crucial for our success.

Agile at scale

Now we had this small group of people embracing the agile approach. But how to scale this out? We had to deliver a huge amount of features with a fixed deadline and reducing the scope was not an option. Thus we started to setup more cross-functional product teams with specific feature responsibilities. Each team should be capable of delivering features without or little dependency on other teams. Actually we tried to adapt the well known approach of Netflix and Spotify and we had some very inspiring talks with guys from Otto. The more we scaled out the more we struggled with dependencies between the teams and dependencies to the car. These dependencies made us slow and we had lots of trouble because we couldn’t deliver working user journeys as soon as more than one team was involved.

We hade to find a way to reduce these dependencies or to manage them. Getting rid of them was impossible in most cases. For example the car was one of these fixed constraints we couldn’t change. So we decided to manage the dependencies by making them visible for all teams. Furthermore we introduced an agile portfolio which allowed us to align all teams regarding scope and time. With the agile portfolio all teams should have the same goals and priorities in mind when implementing new features. This approach helped us a lot to deliver working user journeys continuously.

Another obstacle was lack of communication. Of course we had our regular meetings. But after the meeting each team went back to work and there was only little collaboration between the teams. A turning point was when we introduced HipChat to enable communication between all teams. This was the starting point for building up guilds. People with the same interests or roles started to communicate via chat. For example the UI/UX guys had a regular chat about the overall user experience. They aligned concepts and designs without any further push from outside.

Enabling communication and collaboration was definitely one key for successful product development. Another success factor is trust and to share the same mindset. We started to have events together with all teams. One very successful event is a product marketplace, where all teams are invited to show the current state of the product and everybody can discuss with each other and share information. Today we reach lots of people across the whole company with these events and it helps us to build up a community for our digital products.

Summary

One main thing we learned is that there is no blueprint out there to get an agile approach up and running within an organisation. We had to find our way, the Porsche way, and there were and are lots of challenges. The journey has just begun and there is more to come. Software is getting more and more important for the car manufacturers as customer expectations are changing rapidly. Digital transformation is one key to cope with the future challenges. But besides of technology and methodology it’s all about people, how they feel, how they act and how they work together. A lot of work has to be done in the area of mindset and cultural development and I’m happy to share our experiences in this blog.

Shifting from a car manufacturer to a software company was originally published in PorscheDev on Medium, where people are continuing the conversation by highlighting and responding to this story.