Introduction to Through-Stack Development (Part 1)
Building the connected carputers of today and tomorrow is no trivial thing. On one side you have great expectations on new features brought on by vehicles taking a digital leap, a push towards faster time-to-market and expected cost savings from integrating multiple systems into one. On the other hand you have automotive safety standards, increased complexity in the required solutions and a whole new level of security threats. A difficult equation.
The answer, as many companies are finding out, is to introduce isolation measures to segment the carputer systems into specialized domains, some specialized in safety-related functionalities while others produce the rich connected features that the consumers of today expect. However, those isolated systems still need to talk to each other in a secure fashion, co-exist without interference on one device and work in concert to produce a seamless system. Not unlike an orchestra with the themes of multiple instruments weaving a composition larger than the sum of its parts.
“The trick here is that many of the new features that you are developing cut across multiple layers in multiple domains.”
Considering the intricacy needed, its unsurprising that trying to actually develop such a system requires some difficult orchestration. Traditionally software is abstractly split into layers, spanning from device drivers, hypervisors and kernels, through middleware and system services right up to user-interface development. These layers together form the software stack. Now, coming back to all those isolated domains, each of them has their own set of layers. The trick here is that many of the new features that you are developing, from FOTA to remote control, cut across multiple layers in multiple domains. And that, is why you find yourself reading about through-stack development.
Horizontals and Verticals
Another juxtaposition can be found in the needs for your development teams. Deep expertise, component ownership and the continuity of work tend to congregate into layers. As such, the most natural team structure for your development is horizontal – for each team to be limited to a specific set of layers in one or more domains. That way, your developers can concentrate on the components & tools they know best, the team can support each other with technical solutions, you do not introduce conflicting changes and you can constantly improve your solutions in a specific area with one team having clear ownership of components.
However, as we already discussed, some of the connected carputer features need to cut through a lot of layers, which would here mean co-operation between a lot of teams. What you need, is a structure to help you develop those features in concert between multiple teams, while still achieving seamless communication and a rapid development pace.
“Our solution has been to introduce vertical, or through-stack, groups to our software development process. We call them virtual teams.”
At Link Motion, our solution to this has been to also introduce vertical (or through-stack) groups to our software development process. We do this using a structure of agile teams & what we call virtual teams. Our virtual teams are feature-oriented, with each one having ownership of implementing a specific feature through the whole software stack. These teams are comprised of at least one member from each team that is needed to implement a specific feature.
The interesting part here is that our virtual teams are transient – once the feature is fully implemented, the team will disband and new ones will likely be formed to implement the next new functionalities needed. Meanwhile, our regular Teams are permanent and their Team Leads are given quite a bit of freedom for choosing the right solutions for their area. If there’s something familiar about this structure, that’s because it’s somewhat been influenced by a similar handling of horizontals and verticals in the Spotify Culture of Squads & Chapters.