How to reorganize the business in a software-defined world

My mother used to frequently describe disruptive change as “trying to thread a moving sewing machine”, and that’s exactly the metaphor the auto industry is facing as it grapples with a rapidly changing market. Several startup threats — including not-so-startup Tesla — have designed a computer and added wheels rather than tinkering computers into a slew of mechanical systems. Yes, these smaller companies don’t have the distribution, manufacturing and cash flow advantages of many of the incumbents, but they do conversely have the ongoing advantage of avoiding $6 billion in vehicle redesigns due to poorly executed system engineering and the associated cobblestone interfaces between these silos. So if these monolithic automotive competitors aren’t careful, Goliath will crumble in the middle of this well-placed stone called “software.”

To make this re-threading harder, most automotive executives grew up without the internet and built their careers around powertrains, chassis, and the like. acting like a software company,” wrote Jeetu Patel in TechCrunch+. “That’s why the companies we most associate with ‘Why Software Is Eating the World’ are now startups, with a few notable exceptions…” Yes, some auto companies like Ford, GM and Stellantis have tried to transfuse leadership in recruit replacements in Silicon Valley, but they also come with alternative baggage like a “Ctrl-Alt-Del is OK” mindset rather than functional safety and reliability. Running an automotive and software company is a double-edged sword with few natural champions.

So, as the explosion of software and connectivity continues to change the automotive world, automakers need to consider three crucial areas: 1) rebuilding silos around networks, 2) leveraging enabling partnerships, and 3) monitor critical expertise.

Rebuilding silos around networks

Automotive history is a herd of boxes with wires. If the driver wanted to see the title of a song streamed while driving, the telematics box would have to transfer the text via the gateway module to the infotainment box, which then passed the information to the information center module of the driver in a less obtrusive format. Any new functionality requires a serial overhaul of a Tier 1 (“Gen 2.0”) offering with asynchronous offerings across various vehicle platforms, typically with little reuse.

This same evolution took place over 30-40 years as computer systems moved from hardware silos and individual boxes (eg Apple II+) to common operating systems (eg Microsoft, Linux) with a unique relationship between operating system and application (e.g., MS Word) 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 driven by technology, economics, competitive forces, time to market, efficiency and economies of scale. We have transformed ourselves in 30 years in the computer world, but in the automotive world we have to do it by [the next] ten years.”

“If you want to reorganize the system,” says Peter Abowd, CEO of Kugler Maag Co. North America, “you also have to reorganize the organization. By Conway’s Law, the structure of your design will always reflect the structure of your communication channels and organization. But Generation 1.0 of the product requires the structure inherited during development of Generation 2.0, so cross-company restructuring cannot easily be an evolutionary path. So it becomes debatable whether this evolution is better since it uses the extremely valuable knowledge of the product line for Gen 2.0 versus creating a wholly owned start-up within the big corporation where the new silos have been rebuilt.

“Now you need a software architecture that orchestrates all the components. The OEM organizational structure is likely to be as big an obstacle as the technology silos inside the car,” Chou warns.

Leverage enabling partnerships

Almost all manufacturers already employ business acumen by separating areas of development that are differentiated or proprietary from those that are non-customer-facing, reusable, or commodity. For example, manufacturers rely on suppliers for wheels since the technology is not their core business and does not affect the purchase price of the vehicle.

The same goes for a software-defined vehicle, but some of the building blocks change slightly. For example, imagine a new feature like “Tag” where vehicles could sneak up and tag a friend and they would become “It” (aka, the tagger). The user interface 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 functionality as well as many others.

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

“There is room for internal development [by the manufacturers] as well as partnerships with those who have been through this before and have the expertise,” says Chou. “No car sells based on its networking, and there’s no reason to reinvent that.”

And such a partnership can help limit resources during silo transitions. “Engineering teams moving 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 the core software and expertise they need, allowing them to focus on delivering unique value propositions. of their brand in their products.”

Monitor crucial expertise

Given the amount of revenue at stake, it will be crucial to the long-term success of such a vehicle. Like all job functions, these systems/software architects have specific skills that are unique to their role(s), but they have traditionally been misunderstood by management with poor training and even worse ongoing supervision.

“Most organizations don’t understand the necessary skills of an architect,” says Abowd. “These are typically software developers who have been promoted by the company to avoid turnover, but have never provided meaningful direction or definition of what they need from their architecture and have therefore created a position without specific purpose or associated characteristics.”

Understanding these characteristics, current performance, and how to adjust HR results will be key to the continued success of the software-defined vehicle.

Author’s Note

I have witnessed firsthand an industrial company trying to build a software offering within its own walls with a mismatch with these elements. And so a last word for the wise: beware of pride. Most executives in the automotive industry believe that the difference between hardware and software is only four letters, and in this, running any business is almost identical. The three aforementioned ingredients may seem like easy spices to add to a recipe, but the underlying DNA is difficult to supplant. Look for leaders who have already created software organizations and isolate them from the reducers.

Or the software defined vehicle will actually be just another silo defined vehicle.

Margie D. Carlisle