What Apps To Use With New Android Jead Untie For Bmw And How To Use It

Abstract

Today, it is natural for digital services to be available anytime, anywhere. Thanks to digital platforms, we can connect with our intelligent assistants, stream movies on our networked televisions, and wirelessly control our homes with smartphone apps. Within the last few years, our cars have also been transformed into computers on wheels. However, the apps with which we are accustomed are often not available in cars. Why are cars different? This teaching case examines how the worldwide automotive manufacturer BMW developed its onboard infotainment system into a digital platform. While the transformation of a manufacturing firm into a technology company reveals multiple challenges, new actors enter the stage. In 2017, Google announced the launch of Android Automotive OS, a complete operating system for cars with access to a vibrant platform ecosystem. Should BMW accept Google's offer to use Android Automotive OS as a digital platform for their cars, or should they strive to create their own proprietary platform ecosystem? This teaching case introduces the dynamics of digital platform ecosystems and illustrates the "platform conundrum" that many traditional companies must confront: Is it better to build a new proprietary platform ecosystem or join an existing dominant platform ecosystem? We provide rich insights from BMW's development, sales, and strategic divisions, helping students to understand the risks, chances, and challenges of various choices that occur in the context of digital platform ecosystems and why such decisions might be crucial to the future of traditional companies such as BMW.

Introduction

Have you ever been annoyed because you were unable to use your favorite apps while you were driving? Did you ever wonder why you are forced to use the old-school integrated navigation system instead of Google Maps with up-to-date maps and real-time traffic? Or why is there no better way to listen to your favorite Spotify playlist than streaming it via your smartphone, which requires a prior connection to the car? Or why is there no streamlined solution to read and write WhatsApp messages while driving? As smartphone users, we are accustomed to choosing from millions of available apps to enhance our devices at any time. These apps are usually free and frequently updated, and if an alternative with more features and a better look-and-feel pops up, we can simply download the new app and remove the old one. So, why is that possible for smartphones but not for cars?

For almost two decades, the worldwide automotive manufacturer BMW has been trying to integrate its customers' digital world into its vehicles in an attempt to react to changing customer needs. In the past, car buyers emphasized vehicle design, running characteristics, and safety. These qualities are still appreciated by customers today, although they are complemented by the need for connectivity and availability of apps. According to a 2018 McKinsey study, 40% of car owners would change their favorite car brand exclusively based on the availability of enhanced digital services.¹ BMW tried to fulfill these new customer requirements as did the other major car manufacturers. In 2003, the first online services were introduced into a BMW car design. After several advancements, the newest generation of the BMW infotainment system was released in the summer of 2018. The newly designed BMW onboard system is constantly connected to the Internet and provides apps such as a parking lot finder,² music streaming,³ integrated e-mail and calendar features,⁴ and apps for different calling services.⁵ However, the number of available apps is quite low compared to the vibrant smartphone platform ecosystems with which most customers are accustomed.

In this teaching case, we first introduce BMW ConnectedDrive as the brand representing BMW's infotainment and connectivity features. By describing various milestones in the evolution of ConnectedDrive, the second section illustrates how BMW directly integrated digital services into its cars. The third section examines the emergence of Android Automotive OS, an operating system developed specifically for cars by Google that is independent of any smartphone. The appearance of this new technology presents BMW with three strategic options for the future of its onboard automotive infotainment system, which are described in the final section.

BMW ConnectedDrive

BMW encapsulates all infotainment and connectivity features in its vehicles under the BMW ConnectedDrive brand. The onboard infotainment system is called BMW OS and can be considered as the heart of the Connected Drive product offering.

Head-units and infotainment systems

The infotainment system is one of many software components that run on miscellaneous electric control units (ECUs) inside a car. All ECUs are connected by means of bus systems that transfer data between the various components. The infotainment system operates on an ECU called the head-unit, which receives data from multiple sensors throughout the entire car that are processed infotainment system applications. For example, the navigation system is one of the applications that receives and processes global positioning system (GPS) data from the vehicle's antenna control unit to display the current position of the car on a map. BMW maintains triennial development cycles for its head-units. When a new head-unit generation development is complete, it is integrated into every car model that will be subsequently produced. Older models, previously produced with older generations of the head-unit, are eligible to receive upgrades (Image 1 ).

Image 1. Timeline BMW OS 7 in 5 series and X5 series.

A new generation of a head-unit is always expected to provide new features for the lowest possible additional cost. Reducing production costs is a major driver of developmental efforts. There is a fundamental difference between software and hardware. While a head-unit must be purchased for every vehicle produced, one version of the corresponding software can be installed into millions of cars without any sizable additional cost. Therefore, the fewer the hardware resources required by the software, the cheaper the per car cost of the hardware. For example, making a decision regarding the memory module capacity of a new generation head-unit illustrates this point. One option would be to use a 16-GB module that costs €30 per unit. A second option would be to use a 12-GB module costing €25 per unit. The market forecast predicts a production volume of 2.5 million cars. The €5 cost difference multiplied by 2.5 cars translates into a potential savings of €12.5 million, funds that can be allocated to implementing software optimization that will enable the cheaper hardware option.

Software performance increases with the elimination of any abstraction. The more adapted the code is to the inherent hardware, the better its eventual performance. As a result, the developed software is inextricably intertwined with its corresponding hardware. Therefore, the release of a new infotainment system is associated with the triennial head-unit development cycle. However, software development does not strictly end with the release of the integrated infotainment system. Refinements such as performance improvements and the incorporation of new features are implemented in subsequent product upgrades. When such an upgrade is completed, the new software is installed into all newly produced cars and distributed to existing customers during routine maintenance checks at a BMW servicing partner.

Introduction of the ConnectedDrive Store

Customers ordering a new BMW online or through a dealer can choose from several infotainment options. While the top tier includes all available software features and high-end hardware, the low-budget variants provide less functionality as well as restricted hardware with lower computing power and a smaller sized cockpit screen display. Previously, the chosen configuration was considered to be a permanent feature for the lifetime of the car. This setup fundamentally changed in 2012 with the introduction of the BMW ConnectedDrive Store, which enabled customers to extend their car's capabilities by installing new digital services, such as adding real-time traffic information or map updates to the navigation system, months or even years after a car's initial purchase by buying such services through the BMW ConnectedDrive Store.

The ConnectedDrive Store gives BMW several advantages. First, a BMW owner can purchase BMW's digital services at any point in time, which creates the opportunity for generating additional revenue from existing customers. Second, most digital services require online connectivity. In contrast to mobile phones, whose network operation costs are borne by the user, BMW is the carrier for the car's subscriber identity module (SIM) card. Even though utilizing BMW's connectivity features is not billed according to usage, the company can apply value-added subscription models that require additional payments for higher tier features or to extend subscription services at the end of a predetermined period (see Image 2 ). Third, BMW was one of the first automotive manufacturers to directly sell digital services in their cars, which provided an opportunity to promote BMW as an innovative and progressive car brand.

Image 2. BMW ConnectedDrive Store in BMW OS 4.

That the introduction of the ConnectedDrive Store enabled BMW to distribute digital services independent of the initial purchase represented the potential for implementing innovative business models. However, BMW's sales strategy was not adapted to this change. The fixed development phase of vehicle equipment features such as brakes or seats usually ends upon the commencement of a car's production cycle—unlike the continuous software development cycle, which persists past a product's sale. Therefore, the idea of rolling out maintenance and feature upgrades in a previously sold car was counterintuitive to most automotive sales managers. Releases of new digital services (or new versions of existing services) were coupled with releases of new vehicles, meaning that digital services were sold as features of a new car and not as standalone products. Since a free testing period was not applicable to features such as brakes or seats, this option was not made available for new digital services:

Apps belong to a certain optional equipment line because our organization is just able to work with optional equipment structures. Even if we want to go other ways, we haven't the abilities currently. (Sales Operator for Digital Products)

The modular distribution of apps

The in-store purchase of a feature did not trigger the deployment of new code to the head-unit. Instead, a functionality was preinstalled in all cars and activated simultaneously. Dynamic content, such as weather or news, was displayed by a preinstalled browser. However, this changed with the sixth generation of the infotainment system, which was launched in the BMW 7 series in the summer of 2015. This new system contained a dedicated platform component that was able to remotely download, install, and run app packages. While the capability of the preinstalled browser of the previous generation was limited to displaying online content, natively running apps were now able to access interfaces deeply embedded in the car. Hence, it was possible to provide apps that processed information on the current velocity of the car, the destination set in the navigation system, or signals of the parking control system. The parking app ParkNow,⁶ for instance, uses such automotive data to recognize whether a driver is searching for a parking lot in the vicinity of the programmed destination and provides relevant information on nearby parking facilities. Even though the new platform's capabilities enabled many new use cases for additional apps, the most prominent features of the infotainment system, such as the navigation system and the radio, continued to be deployed as preinstalled software components alongside the platform (see Image 3 ).

Image 3. Infotainment system architecture.

These enhanced capabilities of the platform engendered increasingly more departments within BMW, to start own app development efforts. In 2015, software engineers from the research division started the BMW Labs⁷ initiative. Customers were able to apply to the program and beta test new onboard services that could be canceled at any time. This way, BMW engineers could accelerate prototyping efforts and receive faster feedback from actual customers. One of the first features launched by BMW Labs was the integration of the "if this then that" (IFTTT) service that enabled the conjunction of miscellaneous web services. With onboard data, BMW drivers could use their car as a sensor for triggering any kind of action in many digital services; for example, when the fuel level went beyond a predefined level, the IFTTT service could set a refueling reminder in the driver's Google calendar. BMW also began cooperating with established digital service providers such as Spotify and Microsoft to implement Spotify Music and Microsoft Exchange apps in the BMW infotainment system. While these partners provided access to their servers, the onboard apps were developed by BMW.

The rapid emergence of more and more app development projects revealed problems with the platform itself. Although the emergence of innovative features was appreciated, the architecture of the underlying operating software was not designed for modular extensions. As illustrated at the beginning of this article, traditional automotive software development is tightly interwoven with associated hardware development. The memory consumption of every single software component is strictly predefined, which means that a component's budget is estimated and defined before the development efforts begin. Maintaining compliance with the available resources is a central goal of automotive software engineers. Accordingly, the overall memory budget is a sum of all component's memory budgets. However, this approach conflicts with the idea that apps can be continuously distributed into a system and consume arbitrary amounts of memory. Software architects mitigated this issue by introducing a specific platform component to receive a dedicated memory app's memory budget, which should be allocated dynamically. However, the scarcity of memory and its management became permanent issues for the newly created platform development team. Another problem category concerns inconsistent interfaces provided by foreign onboard modules. The interfaces revealed insufficient documentation or a lack of robustness in the context of generic use by a larger number of apps. Consequently, many app developers ended up taking a time-consuming trial-and-error approach to evaluate the functionality and limitations of interfaces:

You just don't know which results in which condition are delivered by the interface. The documentation is either not available or just rather raw. All you can do is implement, deploy your app to a test vehicle and see what happens. (App Developer)

Apps for Automotive

As illustrated in the previous section, directly distributing modular apps into the infotainment system led to several challenges for BMW. The development and operation of a digital platform exposed how fundamentally traditional automotive software development differs from modern software development. Engineers elaborated further approaches to integrating digital services into BMW's cars. Smartphones, which connect directly to the car, appeared to be a promising direction for integrating apps into the car's onboard OS.

In 2011, BMW had already enabled its infotainment system to display applications that were rendered on a connected smartphone. The "Apps for Automotive" (A4A) technology afforded mobile app developers to display user interfaces, by directly embedding them into BMW's proprietary infotainment system. Therefore, a software development kit (SDK) provided by BMW had to be integrated into the app's source code. The SDK exposed access to BMW's human–machine interface (HMI) and allowed mobile app developers to assemble their own user interfaces using standardized building blocks. While the app itself was still processed by the smartphone, it remotely controlled the displayed HMI in the car's central information display. When the customer connected his or her smartphone to the car, all A4A apps were listed in a dedicated menu (Image 4 ).

Image 4. Apps for Automotive architecture

First, BMW used A4A to improve the integration of its own smartphone apps into its cars. For example, the BMW Connected App that enabled customers to control certain automotive functions by means of a smartphone was enhanced by a feature that, at the start of a drive, fetched the phone's calendar and suggested destinations in the car's navigation system. However, the focus of A4A technology was integrating third-party apps into BMW's proprietary infotainment system. Therefore, BMW enabled app developers interested in integrating their mobile apps to contact a dedicated partnership management division called the App Center. When the App Center determined that the integration of an app was valuable and met BMW's requirements, the A4A SDK was provided to the app developer. The App Center also provided comprehensive support to third-party developers to facilitate development and ensure the app's smooth integration with BMW's user interface. While many app developers contacted BMW, the reverse was sometimes also true. The music streaming provider Spotify and the online image hosting service Flickr were directly contacted by the App Center. In contrast to partnerships for onboard app development, BMW reached out to partners to build their own integrations of their services into the BMW infotainment system using A4A technology. All in all, over 50 audio, navigation, and entertainment apps that were available on the iOS and Android platforms were made compatible with BMW's proprietary infotainment system.

From a customer perspective, A4A technology was part of the overall BMW infotainment system product offering. When a customer configured his or her new car appropriately, all compatible apps installed on its smartphone were automatically made available in the car. In this way, each app developer who chose to integrate the A4A SDK into its app increased the attractiveness of BMW cars. App developers also increased the attractiveness of their apps by making them available during a car ride to BMW drivers. BMW's reputation and brand power enticed several smaller app development firms to partner with the automaker.

However, while several app development firms appreciated this cooperation, BMW also experienced reluctance from desired partners. Such reluctant firms argued that the number of new users that would specifically be attracted by the integration of their apps with BMW's onboard platform was quite low. The development effort required for such integration was remarkable, yet the number of potential users who did not already have an app installed and who owned an appropriately equipped BMW car was small. While a new Android or iOS feature usually has the potential to reach billions of users, A4A integration could not even reach millions of customers. In 2015, these difficulties increased, when BMW revealed the new generation of its infotainment system. All existing integrations required major updates by app developers to remain functional. While BMW increased its effort in partners, an increasing number of app developers terminated cooperation. Only a small number of A4A apps were available upon the launch of the next-generation system. Eventually, the A4A technology was removed from BMW's infotainment system in 2018 and replaced with a lightweight technology that enabled the integration of BMW's own smartphone apps, so no further external partners were acquired.

When considering projecting smartphone apps into an external infotainment system, most think of the solutions created by established digital platform companies such as Apple's CarPlay, Google's Android Auto, and Baidu's CarLife. BMW has a long history of cooperating with Apple to integrate iOS devices into their cars. In fact, the preceding "iPod Out" technology was a result of the joint development of BMW and Apple. It enabled the user to control its connected iPod via the vehicle's audio control buttons. Shortly after the release of Apple CarPlay in 2014, it was integrated into BMW OS 6, which was released in 2015. BMW announced the implementation of Android Auto in its OS 7 in 2020. Even though this implementation advanced the integration of the customers' digital world into their cars, this solution was not considered perfect by many experts. First, the functionality of projected modes was limited to the smartphone and did not exploit the vehicle's own capabilities. While there are well-established use cases for the smartphone, such as messaging or audio playback through a third-party OS, automotive-specific application programming interfaces (APIs) were not available to app developers. Second, multiple BMW experts emphasized the importance of a seamless customer experience, meaning that the integration of digital services should appear naturally. The conflict between projected modes through the existing infotainment system and the need to connect a smartphone to use them impeded providing such a seamless experience.

Remote system updates and the emergence of platform governance

Improvements such as memory management optimization were usually implemented in product upgrades distributed to all newly produced cars as well as existing cars during maintenance visits by a service partner. However, very few customer vehicles were regularly serviced by a partner such that they could benefit from every product upgrade. By contrast, apps were distributed remotely and could be easily received by almost all BMWs on the road. The highly dynamic nature of apps, on the one hand, and the preintegrated software components' static development process, on the other, caused problems. Long-term platform development cycles impeded the team's ability to react to the quickly evolving world of apps. This mismatch was addressed by the introduction of the seventh generation of BMW OS in July 2018 (the most current generation at the time of this article's writing). BMW OS 7 enabled the remote distribution of product upgrades over the air, a highly anticipated feature. First, other premium brands such as Mercedes-Benz and Audi started promoting their wireless updating capability in the beginning of 2018. Tesla implemented remote software updatability in its Model S in 2015. BMW's image as a premium brand and technology leader required a prompt catch-up. Aside from these marketing aspects, engineers appreciated this advancement as well. New features in preintegrated software components, such as the navigation system or the radio, could be distributed to a large number of customer vehicles simultaneously. The platform team also desired the updatability of their component. Remote system updates enabled the iterative evolvement of the BMW platform and therefore more appropriate reactions to current developments by the internal app development teams.

Besides the growing complexity of runtime resource management, the platform team recognized an increased demand for the governance of platform processes. The proven procedures of preintegrated software components did not meet the requirements of the highly dynamic nature of app development. While common product upgrades were released three times a year, several app teams updated their apps many times a month. Furthermore, the platform was used not only by a small group of software engineers but also by hundreds of app developers. The established communication routines of cooperating teams in the development division did not scale for one platform team that had to provide support to dozens of app teams:

Actually, in traditional software development here at BMW engineers just work for their department. There is no intention for developing things for others outside their own department. (Process Manager in the Development Division)

Therefore, the platform team introduced multiple measures. First, documentation for app developers was moved from the internal wikis with restricted access to a developer portal accessible to every BMW employee. Furthermore, several tools were created to enhance app development, and large parts of the app release and testing process were automated. The platform team introduced a question and answer forum and fostered the emergence of an app developer community to provide mutual support and reduce platform developer workloads.

With the launch of BMW OS 7, even more teams decided to implement functionality as an updatable app in the infotainment system. In addition, management recognized its rising importance and increased the allocated workforce to the platform. While the previous generation of the platform was developed and maintained by one internal and five external developers, the new platform was operated by a team of 15 internal and more than 30 external workers. However, the general attitude of BMW's developmental divisions still attributed a higher importance to feature development than to the development of a generic platform:

Most of the management attention, most of the key performance indicators and most of the budget allocation mechanisms follow the logic of feature implementation. You usually need to provide a business case to receive funding for a development project. However, it is quite harder to provide a business case if your product—in our case the platform—cannot be sold to customers directly. (Member of the Platform Development Team)

While several new apps had just launched with the seventh generation of the infotainment system, the apps that existed in the previous generation required porting to the new OS version. Most involved managers and engineers expected all features that were available in the predecessor head-unit to be available in the launch of the new infotainment system, BMW OS 7. However, the platform component itself was bound to the regular software development procedures, which considered platform completion to occur weeks before the beginning of the head-unit's production cycle. Therefore, app developers were forced to follow this strict schedule and start their work before the platform's stability was determined, which caused large efforts on their side and amplified the development of new features.

The entrance of Google

In May 2017, Google announced the development of Android Automotive OS, an Android operating system familiar to millions of mobile app developers and tailored to run in the head-unit of a car. This system should no longer depend on a connected smartphone as did the previously mentioned Android Auto, but be directly embedded in the car. As its first partners, Audi and Volvo declared that their proprietary infotainment systems would be replaced by Google's Android Automotive. After a 2-year development phase, Google invited app developers to submit automotive apps using their new automotive operation system in May 2019. In parallel, Volvo announced the release of the Polestar 2 model as the bearer of several innovative technologies including the implementation of Android Automotive. Aside from the basic operation system itself, Android Automotive OS included Google's most prominent and popular apps like Google Maps and Google Assistant as well as the Google Play Store, which was the entry point for third-party apps. While millions of apps were available for Android smartphones, support for Android Automotive OS was not provided by default. First, Google needed to extend and adopt Android's capabilities to the automotive context. Subsequently, developers needed to implement these capabilities to also adopt their apps for the automotive context. For instance, large parts of the system were locked to user input whenever the vehicle's velocity exceeded a certain predetermined limit. This speed-lock feature is a regulatory requirement in several countries, so apps must be notified to appropriately manage this system state. The graphical user interface (GUI) also needed to be prepared for interactions that occur during a car ride, such as sizing certain elements appropriately and avoiding unnecessary distractions. In the beginning, the provided GUI libraries of Android Automotive OS focused on specific types of apps. According to Google, media apps that enabled music streaming, the playback of audio books, or the streaming of radio broadcasts were the most desired domain of apps for automotive implementation. Therefore, in May 2019, media apps were afforded the first chance to adopt to Android Automotive OS. Later, Google announced that it would support apps from the navigation domain as well as the communication domain.

After the announcement of the Android Automotive OS launch in Volvo's Polestar 2, several other car manufacturers proclaimed their release of an Android-based infotainment system. However, while brands such as General Motors and the Renault–Nissan–Mitsubishi alliance promoted cooperation with Google and the implementation of Android Automotive OS, others, such as the Volkswagen Group and Fiat-Chrysler, declared the development of their own digital platform based on the Android Open Source Project. While both approaches included the implementation of Android as an operation system on automotive head-units with apps preinstalled by the car manufacturer, only Android Automotive OS included Google's most prominent and popular apps such as Google Maps, Google calendar, and Google Assistant. When users registered their Google accounts in their new cars using Android Automotive OS, they were automatically given access to the already familiar Google, which included their preprogrammed personalized preferences and utilization history. In addition, Android Automotive OS contained the Google Automotive Services (GAS). GAS is a collection of services that can be implemented by app developers. For example, apps can use location data provided from Google Maps, integrate the Google Assistant to enable speech interactions with the user, and manage financial transactions such as subscription fees or in-app purchases with Google Pay. While car manufacturers needed to create their own alternatives to these and other services, Google was able to provide access to already proven solutions from its mobile app ecosystem.

Eventually, Android Automotive OS implicated the availability of Google's Play Store with all third-party apps that were adopted to the automotive context. Developers that decided to submit their apps to the Play Store were assured that their apps would be available in all cars with Android Automotive, independent of the car manufacturer. Google ensured that all specified standards were satisfied by manufacturers and app developers and guaranteed a functional interplay. A car manufacturer with its own marketplace needed to establish own standards, independent of Google's App Store. Furthermore, apps that implemented features based on GAS were dependent on the availability of these services. For example, an app that provided information on electric charging station locations required access to a kind of map that allowed the implementation of custom points of interest in its user interface rather than of Google Maps. If no appropriate alternative was available, the feature would not be available in the car manufacturer's infotainment system (Image 5 ).

Image 5. Android Automotive OS vs Android-based infotainment system.

BMW's strategic options

The appearance of Android Automotive OS accelerated the development of digital services for the automotive market and forced the car manufacturer to make decisions to own automotive app strategies. Should they join Google's ecosystem or strike out on their own? The integration of vibrant digital platform ecosystems appeared to be a critical success factor for the future of the automotive business. While some competitors had already announced their decisions, most manufacturers were still searching for an appropriate answer on Google's offer. In the fall of 2019, BMW was also evaluating a variety of strategic options. Three directions were discussed by the experts involved: creating a proprietary BMW platform ecosystem, establishing a collaborative platform ecosystem, or joining the existing ecosystem:

Of course, we are in a competitive situation, but we are also in a partner situation. We will always be in this "frenemy" situation with a Google, with an Apple and whoever comes next. The question is of course how do I play that? (Digital Product Manager)

Creating a proprietary BMW platform ecosystem

The first strategic option was the establishment of a proprietary digital platform developed and operated by BMW. This meant that BMW would follow its prevalent strategy of owning the digital platform but would make it accessible to third-party developers. Several experts inside BMW emphasized that in this scenario BMW would maintain comprehensive control of all decisions regarding its digital platform ecosystem. For example, BMW could independently decide whether app developers could utilize the data on the battery status of its electric cars. Consequently, this information would not be exclusively available to BMW, so the establishment of profitable business cases would be aggravated. However, the potential for innovative solutions for a car's charging process would be fostered, increasing the overall attractiveness of BMWs. The accessibility of autonomous driving capabilities could be limited to BMW to diminish the danger of misuse and associate the autonomous driving experience with BMW. While such deliberations would also be possible in cooperation with other partners, the existence of an independent BMW platform ecosystem would facilitate such decisions:

On the other hand not only profit is an outcome but also other things like data sovereignty and new business models, that I can possibly build if I keep the data. If I have my own system and keep control of it, I can potentially do more than selling cars [. . .]. (Member of the Platform Development Team)

Considering the technological perspective, the system could be based on BMW's prevalent infotainment system, on Android Open Source or any other appropriate technology. However, due to its maturity and robustness, Android Open Source appeared to be a promising approach for many BMW software engineers. The system was established and mature, and several other manufacturers had already declared a shift toward Android Open Source. Consequently, the project would receive further maintenance and evolvement. Furthermore, the technology was already popular with developers. Its large amount of documentation, tutorials, and online support communities like Stack overflow facilitated the work of software engineers in comparison with using a proprietary solution. Moreover, Android Open Source facilitates the attraction and integration of new developers:

I then I could imagine and this is my personal opinion, then we do it ourselves with a very limited number of apps, but then exactly with those apps we want. (Sales Operator for Digital Products)

Even though recruiting new developers to the platform would be facilitated by the implementation of an Android-based platform ecosystem, the challenge of attracting third-party developers would remain. Like the approach to A4A technology, the number of potential target devices for a BMW-specific digital platform ecosystem would be small. Furthermore, multiple BMW experts agree that the massive effort required to launch its own platform ecosystem would need to be justified by the aforementioned advantages. Some of the most important resources for establishing a well-functioning platform ecosystem are money and employees. Tremendous financial investment is required to establish and operate a successful platform ecosystem. Considering employees, previous digital platform development efforts bare a certain lack of attention to the development and operation of digital platforms. The required resources, available competencies and skills, as well as BMW's ability to attract them impact the overall platform ecosystem strategy. Most BMW experts agree that attracting and retaining the most creative minds in the field is important for developing an outstanding platform in an increasingly competitive field. However, this is especially critical because the car manufacturers need to simultaneously engage in various new fields, which leads to high efforts and competency requirements. Establishing all of the required competencies seems to be unrealistic for several BMW experts, which prompts them to suggest that the manufacturer should focus on its core competencies and consider what the company is willing to invest in other fields.

Establishing a collaborative platform ecosystem

The fierce competition in the automotive industry indicates that one manufacturer will not be able to leverage its sales to achieve a similar magnitude of available target devices for previously mentioned mobile app ecosystems. Several experts at BMW consider a collaborative approach in which various manufacturers develop and run a common digital platform ecosystem as a further strategic option. While each partner could maintain its own brand-specific GUI or other features, third-party apps could be compatible with cars of all manufacturers. Considering the smartphone market, the market share of such an automotive consortium could not exceed 50%. In 2019, just 13% of all smartphones were run on iOS, while Android revealed an 87% market share.⁸ Although the Android Play Store offers 2.6 million apps compared to the iOS App Store's 1.8 million,⁹ the iOS App Store revenue was twice as high as that of the Play Store.¹⁰ This example indicates that a consortium would need to strive for a relevant rather than dominant market share to attract third-party developers and generate value.

A consortium-based platform ecosystem would distribute all inherent costs and risks beyond the partners involved. Development and operations effort could be equally distributed among the partners, and any potential lack in competency could be mutually compensated. Each new partner would increase the number of cars available to third-party developers, decrease the risk to all other consortium members, and contribute resources to the development and operation of the platform:

[. . .] The platform ecosystem participation thought is quite interesting. It can find favor with volume manufacturers as well as premium manufacturers. Everything scales much better when I have two-digit millions of new vehicles and they can still be addressed to some extent over lifetime. (Project Manager in Platform Development Division)

Although manufacturers could pool their endeavors to develop a digital platform ecosystem, their organizations would need to cooperate with external suppliers. The development of a common digital platform would also require support from delegated contractors. The commission of external software development firms by a larger consortium of car manufacturers with a relevant market share, however, implicates massive risk regarding the potential limitations of German and European competition laws. Several BMW experts considered this aspect to be a major challenge to the creation of a collaborative ecosystem:

[. . .] Ideally a platform or an ecosystem already exists and we only participate in it, because that is simply more promising than doing it ourselves. But it is also an effort issue. Somebody has to do all of that. The purchasing department does not have to negotiate with a store provider and conclude a contract, it has to conclude contracts with 50 app providers worldwide, or how many we want to have. Furthermore, we have to validate 50 apps and do all of these things. That has to be done. It is an effort issue. (Digital Product Manager)

Furthermore, many experts emphasized that all approaches to the development of common automotive software components have failed in the past. Even though these attempts focused on the development of a common middleware and an operation system for cars, independent of the creation of a digital platform ecosystem with third-party developers, automotive manufacturers still failed. The fear of losing their competitive advantage and their conviction that their individual technical solutions are superior has impeded the establishment of common standards.

Joining Google's platform ecosystem

Finally, experts considered the option that BMW might join an existing and growing platform ecosystem by implementing Android Automotive OS. Like the implementation of Android Open Source, this scenario also entails the utilization of a mature and proven technology, which should decrease testing efforts as compared with the creation of an independent, proprietary platform. With apps like Google Maps, Google Assistant, and others, the Play Store and GAS, Android Automotive OS reduced the software development effort required by each manufacturer to a minimum:

Considering technical and cost reasons I would only take Android Automotive OS because the platform has already proven itself [. . .]. (Digital Product Manager)

GAS would facilitate the development of third-party apps and ensure solid payment mechanisms for all platform transactions. Furthermore, Google provides comprehensive support to app developers, including tooling, documentation, and collaborative events like developer conferences. BMW would not have to be responsible for the quality of the apps provided in the app store. With its already established control mechanisms, Google would ensure the exclusion of undesired or malicious apps.

Considering the customer perspective, multiple sales experts at BMW emphasized the seamless integration of the customer's digital world into a car afforded by an implementation of Android Automotive OS. Third-party apps that were adopted to the automotive context could be purchased on the customer's smartphone and automatically also be available in the car. Customers would just need to register their Google accounts in the car, and all playlists, pictures, and videos, as well as all personal data and logins would be synchronized and available without any further effort. In addition, Google's most popular services such as Google Maps and Google Assistant are exclusively available with Android Automotive:

[. . .] the end user will certainly demand that he not only takes his ecosystem from home, but also that he doesn't have to log in anywhere all the time and then that's it. That speaks more the language that he takes this ecosystem than the manufacturer system [. . .]. (Sales Operator for Digital Products)

Even though the advantages of Android Automotive OS appear to be magnificent, several BMW experts raised doubts against the option. BMW would lose control over the development and rollout of a central component of its cars and would have to rely on Google's decisions regarding new features, bug fixes, and also new version rollouts. Moreover, Google would control which models or markets should first receive any OS version. Besides these strategic decisions, experts mentioned that BMW would lose an important customer contact point. While Android Automotive OS provides options for user interface customization, customers might think of Google, not BMW, as the system's provider. The customer experience during a car ride would no longer be exclusively designed by BMW, but a large part would be determined by Google. Strong brand bonding is especially important in the automotive market because cars and driving are especially associated with customer emotions.

Furthermore, experts elaborated that the implementation of Android Automotive OS implicates relinquishing any ambition on digital business model implementation inside BMW's cars. Since Google would manage all transactions on its platform and capture a predefined percentage of each transaction, the car manufacturer would not be involved. In line with the smartphone market in which manufacturers' value capture is limited to the sale of the device itself, BMW's business model would be limited to the sale of the individual car and several associated maintenance services. The role of a platform owner with scaling platform businesses is obsessed by Google. Experts from BMW's strategic departments link this aspect to the changing nature of the automotive market. While large parts of this business are conducted with sales or lease contracts, an evolution toward a more usage-based business model is expected. Even though selling cars is expected to remain as a lucrative business in the future, the market share of mobility services will grow. Independent of specific solutions such as car-sharing, ridesharing, and ride-hailing, these businesses are usually used and managed via online apps. As soon as digital platforms are available, the integration of these services with cars appears as logical step. However, the implementation of Android Automotive OS would mandate these transactions to be exclusively managed by Google. BMW would not be involved in such business models.

Questions for reflection (teaching notes to support these questions are available)

Think about available features and the automotive sensor data that could be used by app developers via API. What apps could be built upon these features and data? Think about current vehicles, but also consider predictable future features such as autonomous driving.
What stakeholders are involved in ConnectedDrive? How could a digital platform for automotive apps connect different sides of the market? How could BMW benefit from connecting these sides?
Think about the challenges that appear when you start to connect the various sides of a single market. What is the most critical aspect to consider? Which strategies might help a new platform owner to master the inherent challenges?
What are the main challenges to BMW in implementing its own digital platform in its cars? For each challenge, consider whether it is specific to BMW or whether you would expect similar conditions at other firms? Consider technological as well as market-specific aspects.
How should BMW proceed from here? Consider the chances and risks of the three illustrated options and think about both internal and external factors that might influence its decision.

Declaration of conflicting interests
The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding
The author(s) received no financial support for the research, authorship, and/or publication of this article.

ORCID iDs
Niklas Weiss https://orcid.org/0000-0003-0401-287X

Manuel Wiesche https://orcid.org/0000-0003-0401-287X

Notes

Author biography

Niklas Weiss is a participant of the graduation program at the BMW Group and doctoral candidate at the Technische Universität München (TUM) in Germany. His current research comprises on the the emergence of digital platforms and digital platform design in the context of incumbent companies. Niklas Weiss has already published his research in HMD Praxis der Wirtschaftsinformatik and international conferences such as AMCIS and ICE/IEEE ITMC.

Maximilian Schreieck is a postdoctoral researcher at the Chair for Information Systems, Technische Universität München (TUM), Germany and holds a doctoral degree in information systems from TUM. His research interests include platform governance and enterprise software systems. His research has been published in Electronic Markets, Information Technology for Development, and conference proceedings such as ICIS, AOM, ECIS, HICSS, AMCIS, and PACIS.

Manuel Wiesche is full professor and chair of Digital Transformation at TU Dortmund University. He graduated in Information Systems from Westfälische Wilhelms-Universität, Münster, Germany and holds a doctoral degree and a habilitation degree from TUM School of Management, Technische Universität München, Munich, Germany. His current research interests include IT workforce, IT project management, digital platform ecosystems, and IT service innovation. His research has been published in MISQ, EJIS, JMAR, CACM, I&M, EM, and MISQE.

Helmut Krcmar is full professor of Information Systems, Department of Informatics, at Technische Universität München (TUM) with a joint appointment to the School of Management. His work experience includes a PostDoctoral Fellowship, IBM Los Angeles Scientific Center, and Assistant Professor of Information Systems, Leonard Stern School of Business, NYU, and Baruch College, CUNY. From 1987 to 2002 he was Chair for Information Systems, Hohenheim University, Stuttgart, where he served as Dean, Faculty of Business, Economics and Social Sciences. Helmut's research interests include information and knowledge management, engineering, piloting, and management of innovative IT-based services, computer support for collaboration in distributed and mobile work and learning processes. Helmut co-authored a plethora of research papers published in major IS journals including MISQ, JMIS, JIT, JSIS, ISJ, EJIS, I&M, CAIS, TOCHI and BISE. In Germany, his book "Information Management" is now in a 6th edition (2015). Interdisciplinary work incorporates areas such as accounting, mechanical engineering, and health care. Helmut collaborates in research with a wide range of leading global organizations. He is a Fellow of the Association of Information Systems (AIS) and member of acatech-National Academy of Science and Engineering.