What’s wrong in software product line engineering? Lack of resources in the platform organizational unit

A few years ago we analysed several highly successful software product lines. You can find the details in our corresponding publication. We had been brought in, because the business owners of each product line felt that something was amiss and that productivity could still be improved. In this short blog post series I’ll discuss the problems we found and what to do about it.

All product lines we analyzed had the same structure, illustrated by the following figure. As you can see, multiple product units sat atop a platform unit, which provided reusable assets to the product units. The product units were profit centers, earning revenues from their respective market segments, and the platform unit was a cost center subsidized by the product units.

The first and most obvious problem was a lack of resources at the platform level. As a cost center, the platform organizational unit was always starved for developers. This makes intuitive sense. It is much easier for a middle manager in a product organizational unit to argue they need a new developer, because they can tie that developer to a feature that will allow them to hit a market window of opportunity, hence earning more revenue. A platform engineering manager can only use more abstract concepts like quality, speed, and cost savings to argue for a new developer. If in doubt, more resources will always go to where the money is.

Here is what case study participants had to say about this phenomenon, and it makes this cause and effect chain very clear:

• “The cost pressure is not high enough; time-to-market is more important. That is why we [product unit] get new developers more easily.” Developer (product unit), case 1.
• “The platform organization is completely overloaded by too many reusable asset requirements from product units. Most never get realized.” Mediator, case 3.
• “The platform often misses delivery deadlines for reusable assets, which keeps product units from delivering their own features in time.” Developer (product unit), case 2.

Lack of resources led to the delayed reusable asset implementation which in turn led to delayed product delivery. The last step is the most visible effect of the resource imbalance escalated to the business level.

We are just getting started. Read next about insufficient collaboration between product and platform organizational units.