The Auto Struggle: How To Re-Architect The Company In A Software-Defined World

My mom used to frequently describe disruptive change as “trying to thread a moving sewing machine,” and that’s the exact metaphor that the automotive industry faces as it grapples with a rapidly-changing marketplace. Multiple startup threats – including the not-so-startup of Tesla – have designed a computer and added wheels rather than cobbling computers into a host of mechanical systems. Yes, those smaller companies don’t have the distribution, manufacturing and cash flow advantages of many of the incumbents, but they conversely have the ongoing advantage of avoiding $6B in vehicle redesign due to poorly executed systems engineering and the associated, cobbled interfaces between these silos. So if these monolithic automotive competitors are not careful, Goliath will topple in the midst of this well-placed stone called “software.”

To make that re-threading more difficult, most automotive executives grew-up without the Internet and built their careers around powertrains, chasses, etc. “It is decidedly non-trivial for a company in a non-tech traditional industry to start thinking and acting like a software company,” penned Jeetu Patel in TechCrunch+. “This is why the companies we most associate with ‘Why Software Is Eating the World’ now are startups, which a few notable exceptions …” Yes, some automotive companies like Ford, GM and Stellantis have attempted to transfuse the leadership by hiring Silicon Valley replacements, but they also come with alternative baggage like a “Ctrl-Alt-Delete reboot is OK” mindset rather than functional safety and reliability. Running an automotive-yet-software company is a two-edged sword with few, natural champions.

So as the exploding software and connectivity continues to change the automotive world, there are three crucial areas that automotive manufacturers must consider: 1) rebuild silos around networks, 2) leveraging enabling partnerships and 3) monitoring crucial expertise.

Rebuild Silos Around Networks

Automotive’s history is a gaggle of boxes with wires. If the driver wanted to view a streaming song’s title while driving, the telematics box would need to transfer the text through the gateway module to the infotainment box, which then passed along the information to the driver’s information center module in a less-distracting format. Any new functionality requires a serial revamping of a Tier 1’s offering (“Gen 2.0”) with asynchronous offerings across various vehicle platforms, usually with little reuse.

This same evolution played out over 30-40 years as computing systems grew from hardware silos and individual boxes (e.g., Apple II+) to common operating systems (e.g., Microsoft, Linux) with single OS-to-application relationship (e.g., MS Word) to universal connectivity and distributed systems. “We see this parallel in automotive,” states Jeff Chou, CEO of Sonatus. “It’s driven by the same things. It’s driven by technology, economics, competitive forces, time to market, efficiencies and economies of scale. We transformed over a 30-year period in the world of IT, but in the world of automotive we must do it in [the next] ten years.”

“If you want to rearchitect the system,” states Peter Abowd, CEO of Kugler Maag Cie North America, “you must also rearchitect the organization. Per Conway’s Law, the structure of your design will always reflect the structure of your communication paths and organization.” But Gen 1.0 of the product requires the legacy structure while Gen 2.0 is being developed, so cross-corporation restructuring cannot easily be an evolutionary path. So it becomes arguable whether that evolution is better since it utilizes the extremely valuable product-line knowledge for Gen 2.0 versus creating a wholly-owned start-up within the greater corporation where the new silos have been rebuilt.

“Now you need a software architecture that orchestrates across all components. The organizational structure of OEMs risks being as big of a hurdle as the technology silos that are inside the car,” warns Chou.

Leverage Enabling Partnerships

Nearly-all manufacturers already employ the business acumen of separating the development areas that are either differentiating or proprietary from those that are non-customer-facing, reusable or commodities. For example, manufacturers rely upon suppliers for wheels since the technology is not their core expertise and doesn’t affect the purchase price of the vehicle.

The same is true for a software-defined vehicle, but some of the building blocks change slightly. For instance, let’s imagine a new feature like “Tag” where vehicles could sneak-up and tag a friend and they become “It” (a.k.a., the tagger). The user interface and tagging algorithms would be proprietary, but the operating system, the GPS tracking, the cellular backhaul and the navigational middleware can act as the reusable foundation for that feature as well as many others.

Recognizing and leveraging the power of these underlying assets requires understanding the overall architecture, the bifurcation between strategic and non-strategic and then leveraging partnerships to provide those building blocks that can propel faster and higher-quality products.

“There is room for in-house development [by the manufacturers] as well as partnering with those who have lived this before and have the necessary expertise,” explains Chou. “No cars sell based upon its network management, and there’s no reason to reinvent that.”

And such partnering can help with resource limitations during the silo transitions. “Engineering teams, which are transitioning from developing hardware to software, are unable to implement every new idea” says Sarah Tatsis, Senior Vice President, IVY Platform Development at BlackBerry. “But what automakers can do is partner with a company that can provide the foundational software and expertise they need, allowing them to focus on implementing their brand’s unique value propositions into their products.”

Monitor Crucial Expertise

Given the amount of revenue at play, having the skilled resources to consider alternative designs across an entire network, to create intuitive drawings that communicate the abstracted designs effectively and that mitigate the risks of change requests will be crucial to the long-term success of such a vehicle. Just like all job functions, these systems/software architects have specific skills that are unique to their role(s), however they traditionally have been poorly understood by management with mediocre training and even worse ongoing monitoring.

“Most organizations do not understand the necessary skillset of an architect,” states Abowd. “They are usually software developers that were promoted by the company to avoid turnover, but never provided meaningful direction or definition of what they need from their architecture and so created a position without a specific goal and associated characteristics.”

Understanding those traits, the current performance and how to adjust results of the human resources will be a key element of the ongoing success for the software-defined vehicle.

Author’s Note

I witnessed firsthand an industrial company trying to create a software offering inside its own walls with a mismatch to these elements. And so a final word to the wise: watch out for hubris. Most automotive executives believe the difference between hardware and software is only four letters and, therein, running any business is nearly identical. The aforementioned three ingredients might seem like easy spices to add to a recipe, but the underlying DNA is hard to supplant. Look for leaders that have already created software organizations, and isolate them from the gearheads.

Or the software-defined vehicle will really just be another silo-defined vehicle.