The power of verticality in SW (and manufacturing)

I learned about cellular manufacturing when I was majoring in industrial engineering. In this post I’d like to show the game-changer nature of vertical organization by drawing some parallels between this idea and the organization of software work.

In a functionally organized plant, the shop floor is structured according to functionality: lathes are organized together, as well as mills, painting and polishing stations and various other functionalities. This brings efficiency in terms of keeping tool magazines, needed chemicals etc. together, centralizing the maintenance, optimizing utilization of the machines, sharing knowhow among the people operating the machines and so on.

A functional manufacturing setup showing machines grouped by their function. Different parts go through different stations, and finally through assembly and quality control.
Functional manufacturing

In a cellular manufacturing setup, popularized by Toyota in the 70s, the whole organization is inversed. Instead of keeping similar machines together, they are organized around what is needed to produce a certain part or product. Every cell is built according to the exact flow of production for manufacturing a part. This has several advantages such as having flexibility in case of changes related to that part, less travel distance and time of material on the shop floor etc.

Cellular manufacturing

Now, it is almost too easy to draw parallels between these manufacturing models and software development:

  • A software organization with traditional structuring around frontend/backend, or application/service/database, software/firmware/hardware etc. falls into the functional category, while the nowadays much touted cross-functional agile team falls into the cellular category.
  • Material flow is analog to communication paths between software teams (be it in forms of meetings, design specs, or APIs)
  • The advantages of a functional setup in the software context are also similar to functional manufacturing: centralizing technology knowhow, maximizing team utilization, optimizing license costs of development software etc.

While the trend is clearly going in the cross-functional/agile/cellular direction, it is actually still a tradeoff decision: going the cellular way has also its disadvantages.

However, I see a major game-changer in this tradeoff that I believe completely outweighs all potential disadvantages of cellular manufacturing: “Taktzeit” (German for cycle time) is the time it takes for the cell to produce one part. It is not derived from the production constraints, but from the market, i.e. Taktzeit is actually the time it takes for the organization to sell one part; the cell structure and production capabilities are designed to fulfill this goal. And when the goal changes (e.g. lower/higher sales), the cell is adapted accordingly. Achieving and maintaining such a goal in a functional setup would be highly complex, if not impossible. And this constitutes the key strength of cellular manufacturing: it aligns the production to the market, not to the technology.

So, that is also the key strength of vertical software organization, it aligns the organization to the market: a small team that can address a part of the market directly, without having to coordinate with other teams or to ask for higher management’s approval. This team, with local, fast decision making can adapt to changing market requirements: higher quality, more features, getting rid of unused features, better performance… This team also has a much better understanding of its purpose compared to an isolated SW component team working on tiny bits of various products. You can compare this to a functional setup, where a change in market needs to be communicated to, and evaluated and implemented by multiple teams, each working on a part of the software; and hopefully integrated properly.

This is also the reason why cross-functional teams are much touted, almost to the point of creating a hype around them. The Spotify “model” with squads as the cross-functional team, even SAFe with its cross-functional agile team (which practically reverts the idea by allowing teams to have dependencies at higher organizational levels), or self-contained systems as the architectural counterpart of such an organization are widespread examples. However, the benefits of vertical software organization are real and massive, and not a hype.

So, as architects I think we should all look into building vertical software organizations. It does bring challenges in terms of keeping architectural integrity, continuous integration and continuous deployment, managing team knowhow, developing skilled people that are able to address the full stack whenever it’s needed… Yet it is very much worth it to address these concerns in our architectures and teams to benefit from the vertical software organization.

Leave a Reply

Your email address will not be published. Required fields are marked *

 

This site uses Akismet to reduce spam. Learn how your comment data is processed.