Make or Buy... "42"
Setting Software Steps in the Automotive Value Chain... with all due respect to Douglas Adams
Without going into details of vertical, horizontal, diagonal, circular, backward or forward integration across complicated supply chains, I am trying come up with a simple way to approach the "Make or Buy" decision, specific to the world of Automotive Software (and beyond).
The answer is "42", with all due respect to Douglas Adams. Just like the supercomputer Deep Thought pointed out: "it is about actually knowing what the question is, in order to get a meaningful answer".
Regardless of whether you are a CEO running a Billion Euro empire or an everyday Joe or Joan at home deciding what’s for dinner, the big question is “make or buy” and I don’t mean just take out. If you’re fixing a Pasta Arrabiata or an Aloo-Roti, there is some stage at which you would draw the line. Do you start with the spaghetti or do you make that from flour? Do you start with tomato sauce, or tomato paste, or raw tomatoes or do you actually grow your own tomatoes in your backyard?
It is pretty much the same question in the Automotive sector about defining the distribution of effort across the supply chain. Each participant in the supply chain tries to find their local maxima of profit-and-positioning to keep their shareholders happy or to make their business sustainable. Car companies can start with smelting their own Aluminum and theoretically make every brake-pad and leather seat themselves. It offers dictatorial control and if driven by a grand vision, creative talent and passionate engineering, the product might be pretty marvelous machines. However, that might not be the most efficient way of making cars, especially for mass producing cars for a large population with a wide range of tastes and needs. So logically over the decades the mechanical systems and complex sub-systems within cars have been made by combinations of car companies, spin offs of these car companies, or industrial manufacturers who used their skills to make automotive parts.
But does this process still hold up with the advent of software, and the increasing value of software as part of the value (or value-differentiation) of the total vehicle. In fact Alex Voigt made a really passionate plea about car companies going all lock, stock and barrel into the software space lest they be relegated to the realm of commoditized metal assemblers. I do agree there will be a shake up (“There will be blood”). In my view this bleak scenario is not entirely true either.
Beautiful design, immaculate construction, structural reliability and robustness are very palpable parameters that anyone in a car showroom can be moved by. The structural design needs to complement and work closely with the features and functions of the vehicles, in a seamless way in which the end user should not know whether the particular behavior or impression was due to the underlying shape and design, the hardware, the software or a combination of everything. In fact the end user does not care, as long as they feel that they are getting value for money.
What I do agree with is that the speed of innovation must increase. It is important to realize creative forces are multiplied by exceptional talent and are not scaled up by filling seats with basic developers. Let’s put this another way: William Shakespeare’s “Hamlet” will not be matched by assigning 10 scribes with 10 typewriters for 10 months. It will also not be matched by assigning 1000 scribes with 1000 typewriters to the task. You can’t command innovation and creativity by throwing numbers at it. We need to foster free thought, nurture creativity, support failure and encourage new ideas from the very best. It is a case of “weniger ist mehr” or “less is more” when it comes to finding the right talent, just like this concept inspired Steve Jobs regarding development in general. While I am talking about software, this is applicable to creatively and development in general.
Before we can dive into deciding about who does what, we need to discuss about where the buck stops.
When we look at the OEM in the entire value chain of delivering either a car to a customer or a mobility solution to a commuter, the final package of having a vehicle to transport people in a comfortable and efficient way is key to the company’s offering. So the buck stops at the OEM, or should stop with the OEM, when someone pays expecting a good journey.
Let us compare this for a second to another industry, because in the process of trying to ape pure-play software or other consumer goods product companies true Automotive Leaders seem to forget their role, and in fact the importance of their role in the world. Just saying that if everyone with investable money backed only Ubers, then someone else would have to stop and make real cars. I am indeed talking about Automotive Leaders who, today are expected to make real cars.
So, as usual, I would use the example of Apple, only to clearly show, once again, to our Automotive Leaders that even in the case of mobile phones it is not like Apple sets a platform up and lets any pirate jump in and write any application that tracks the International Space Station, browses the internet and controls your heart beat. The buck actually does stop with one particular OEM of the mobile phone space – Apple for anything iPhone. They closely curate their content, they optimize their system performance and entirely control the end user experience by ensuring safety and security by checking every single app that they let onto their device. But it does not mean Apple does everything! In the automotive space I would really enjoy seeing Apple and BMW work even closer together in the future, as long as they don’t step on each other’s toes and together focus on bringing a better overall experience to the world. That being said, there are lots of Automotive OEMs out there who make splendid cars and must continue on the mission, while never forgetting where the buck stops. Where the buck stops is different from exactly who does what and when.
For Apple, while controlling the design, the participants, the performance, the applications and ensuring an acceptable level of user experience the actual process of manufacturing and assembly might actually be done by Foxconn. The buck still stops with Apple. Let me emphasize something here, even in the automotive space you have Magna Steyr that assembles BMWs, Mercedes-Benz(s) and Jaguars, where the final product is completely “relatable” to the owning brand. Really, regarding manufacturing, these ideas are not new in the automotive world. The point I am trying to make is about the participants thinking first and then deciding where their sphere of responsibility extends to and then logically positioning themselves to deliver the most value in that role, especially regarding software.
Usually with the previous discussion in mind, OEMs, Tier 1s and further suppliers, want to control the overall experience (OEM), entire system features (Tier 1) and stable components (further suppliers) respectively.
Like I said before, it is possible that a particular vehicle might have everything from the leather seats to the cylinder gasket made by one single company. The same way it is possible for the vehicle software (now running into millions of lines of code for a vehicle), to be managed by a single company. However, just like in most mass produced cars where no single organization manufactures everything, even in the software space there will be a supply chain. Like metal parts, the software for a car also needs to be managed, setup (configured), assembled (integrated) and tested (tested). At the part level and the entire vehicle level.
The stage(s) or interfaces in the process where the handover happens, to the next level of integration, is the place where the decision has to be made about whether to make or buy. From what I read, even Tesla only got into developing more than they needed to because they were “once” small and were not getting enough serious support from suppliers. For systems and components that they knew someone else was better at building, and could be efficiently bought without needing any re-inventing of components or code, they just bought it almost off the shelf. I suppose they quickly configured their systems on their side to bring the supplied systems into their network. This left them with the ability to then focus only on the systems that they consciously wanted to control or were forced to develop out of necessity.
Hint to other OEMs: Just because TESLA did something because of the path they were forced onto or accidentally took to get here, doesn’t mean you need to take the same path to get to where TESLA is. Maybe, you can and should create your own path to where you want to go.
By stacking up the approximate regions that the players want to play in, we start at the bottom with what fits closer to the hardware. The basic software of AUTOSAR stacks come from traditional vendors. Then you have folks like us, who help with the configuration and integration of the AUTOSAR stacks (from AUTOSAR stack vendors) for specific projects of the Tier 1 or the OEM. Then the Tier 1 builds their applications above the configured basic stack and the whole system is integrated. This is then handed over to the OEM’s vehicle level integration and testing team. In the figure the position of two critical lines needs to be decided. These two places are where major make or buy decisions need to be made.
Between the OEM and the Tier 1, I will call it the O/T Line. Below the Tier 1, I will call it the SDK line. The O/T Line is also one with a long history over the ages. At some point or the other, companies like GM, Ford and other OEMs felt that they could have systems done outside their own organizations (not just for them but also for other OEMs to reduce their control in exchange for financial benefits) leading to the creation of Delphi, Visteon and other Tier 1s who were spun off out of OEMs. This process is an example of the O/T Line being pulled upwards, moving more scope to a Tier 1 below (or creating a full Tier 1 below the line). The opposite effect is when an OEM decides that they want to directly own and control more of the system and move the O/T line downwards. One side effect of this process is that the liability and responsibility might not move closer to the OEM causing much more overall confusion in the entire value chain. The buck effectively gets moved around like a hot potato. In any given situation the optimum positioning of the line (or interface) might benefit both the Tier 1 and the OEM without causing too much confusion.
The next line, which I call the SDK-Line is one that Tier 1 leaders have to think about logically as well. Sometimes, the logic is that the entire SDK can be completely built from the floor upwards and entirely controlled for every project (see my other articles regarding the SDK process and AUTOSAR if this part is not clear). Examples of this thinking are seen at some of the larger Tier 1s, like Continental (owning their own stack) and BOSCH (also with their own stack). With their size and scale, with their access to global OEMs and their experience, their decision was to “Make” and not to “Buy”. On the other hand, with an AUTOSAR stack from a reliable vendor, benefits of re-use and cost effectiveness can still be efficiently achieved. The financial rationale becomes even less interesting for most companies. This is partly due to the fact that AUTOSAR is a stable standard and re-invention of the standard is not needed. It is about how you use it.
This brings us to the next scenario regarding the SDK line. Because AUTOSAR is a standard, a Tier 1 actually does not need to build up a large standing army sitting around to cook up the basic software or the SDK for each project. The differentiation of the Tier 1s product or system actually arises out of the features and functions – basically the applications. The core team of the Tier 1 would need to understand about the system needs, know what is possible with the hardware and the basic software footprint and then work efficiently with AUTOSAR experts to ensure that the architecture is scalable and future proof. Some Tier 1s then efficiently move the SDK line further upward, having an experienced partner, configure and integrate a reliable and proven stack, across multiple projects. With the SDK being delivered as a full work-package, managed as a pseudo-product and tailored to the Tier 1’s project-portfolio needs the need for a “make” strategy for basic software reduces even further. It is no longer a question of where to setup a shop for basic software, it is just about having a reliable partner who delivers the AUTOSAR stack and SDK on time and efficiently.
As we look at the Automotive landscape today we see a lot of well-established players running around, like on a football field. The objective of the coach and the team should not be that every player on the field runs all the time in the direction of the ball. Instead it should be that the thinkers of the team should assess their own strengths and decide who plays where on the field. Who and how many play upfield or downfield is pretty much like taking a breath and deciding where to draw the two lines for the make or buy decision. There is no right or wrong answer in any given football strategy.
Think about it the next time you are watching a game of football.