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

My mother often described disruptive change as “trying to thread a running sewing machine,” and that’s exactly the metaphor the automotive industry faces when grappling with a rapidly changing market. Several startup threats — including the not-so-startup Tesla — designed a computer and added wheels instead of plugging computers into a variety of mechanical systems. Yes, these smaller companies don’t have the sales, manufacturing, and cash flow advantages of many of the incumbents, but they do have the conversely, ongoing advantage of being able to break those silos. So if these monolithic automotive competitors aren’t careful, Goliath will fall in the midst of that well-placed brick called “Software.”

To complicate this shift in thinking, most auto industry executives grew up without the internet and built their careers around powertrains, chassis, etc. behaving like a software company,” Jeetu Patel wrote in TechCrunch+. “That’s why the companies we most commonly associate with ‘Why Software Is Eating the World’ today are startups, with a few notable exceptions…” Yes, some auto companies like Ford, GM, and Stellantis have attempted to transfer leadership by they’ve hired Silicon Valley replacements, but they also come with alternative baggage like a “ctrl-alt-del-reboot is OK” mindset instead of functional safety and reliability. Running an automotive-yet-software company is a double-edged sword with few natural champions.

As exploding software and connectivity continue to transform the automotive world, automakers must consider three critical areas: 1) rebuilding silos around networks, 2) leveraging partnerships, and 3) overseeing critical expertise.

Rebuild silos around networks

The history of the automobile is a collection of boxes with cables. If the driver wanted to see the title of a streaming song while driving, the telematics box would need to transmit the lyrics via the gateway module to the infotainment box, which would then relay the information to the driver information center module in a less distracting format. Each new functionality requires a serial revision of a Tier 1 (“Gen 2.0”) offering with asynchronous offerings across different vehicle platforms, typically with little reuse.

The same evolution played out over 30-40 years as computing systems evolved from hardware silos and individual boxes (e.g. Apple II+) to mainstream operating systems (e.g. Microsoft, Linux) with a single relationship between OS and application (e.g. Apple II+). E.g. MS Word) grew ) to universal connectivity and distributed systems. “We see this parallel in the automotive industry,” says Jeff Chou, CEO of Sonatus. “It’s driven by the same things. It is determined by technology, profitability, competitive forces, time to market, efficiency and economies of scale. We have changed over a period of 30 years in the IT world, but in the automotive world we have to [the next] ten years.”

“If you want to redesign the system,” explains Peter Abowd, CEO of Kugler Maag Cie North America, “you also have to redesign the organization. According to Conway’s law, the structure of your design will always reflect the structure of your communication channels and organization.” But Gen 1.0 of the product requires the legacy structure while Gen 2.0 is being developed, so a cross-company restructuring cannot simply be an evolutionary path. So it becomes questionable whether this development, as it leverages the extremely valuable product line knowledge for Gen 2.0, is better than creating a wholly owned start-up within the larger company where the new silos have been rebuilt.

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

Use beneficial partnerships

Almost all manufacturers are already employing the business sense of separating development areas that are either differentiating or proprietary from those that are not customer-centric, reusable, or commodities. For example, when it comes to wheels, manufacturers rely on suppliers because the technology is not their core competency and does not 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 example, let’s imagine a new feature like “Tag” where vehicles could sneak up and tag a friend and they become “It” (aka a tagger). The UI and tagging algorithms would be proprietary, but the operating system, GPS tracking, cellular backhaul, and navigation middleware can serve as a reusable foundation for this feature and many others.

To recognize and leverage the power of these underlying assets, you must understand the overall architecture and the division between strategic and non-strategic, and then leverage partnerships to provide the building blocks that enable faster, higher-quality products.

“There is room for self-development [by the manufacturers] as well as working with those who have experienced it and have the necessary expertise,” explains Chou. “No car sells based on its network management, and there’s no reason to reinvent that.”

And such partnerships can help with resource constraints during silo transitions. “Engineering teams that move from hardware to software development are unable to implement every new idea,” said Sarah Tatsis, senior vice president, IVY Platform Development at BlackBerry. “But what automakers can do is partner with a company that can provide them with the essential software and expertise they need so they can focus on translating their brand’s unique value propositions into their products.”

Monitor important expertise

Given the level of revenue at stake, having the skilled resources to explore alternative designs across an entire network, create intuitive drawings that effectively communicate the abstracted designs, and the risks of change requests mitigate a vehicle. Like all job roles, these systems/software architects have specific skills unique to their role(s), however they have traditionally been poorly understood by management with mediocre training and even worse ongoing supervision.

“Most organizations don’t understand the necessary skills of an architect,” says Abowd. “Usually these are software engineers who have been promoted by the company to avoid attrition but have never provided any meaningful direction or definition of what they need from their architecture, and so are in a position with no specific goal and who have created related properties.”

Understanding these characteristics, current performance, and adjusting human resource outcomes will be a key element in the continued success of the software-defined vehicle.

Author’s note

I have witnessed firsthand an industrial company attempting to create a software offering within its own walls that does not conform to these elements. And so, a final word to the wise: Beware of hubris. Most executives in the automotive industry believe that the difference between hardware and software is just four letters and that running a business is almost identical. The above three ingredients may seem like simple spices to add to a recipe, but the underlying DNA is difficult to substitute. Look for leaders who have already started software organizations and isolate them from the driven.

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