ASML – Optimizing Software Release Policy #SWI2006

ASML is a company located in Veldhoven that builds machines for manufacturers of computer chips. The software of these machines ASML sells now consists of one large package, a so-called monolith. Their current policy is to release a new version of this entire monolith approximately every nine months. This monolithic approach has a few disadvantages. Suppose a client asks for new functionality in the software. ASML will develop, implement, and test this new functionality and add it to the new version of their monolith. This means that
the client has to wait a few months before it can install this new version of the entire package, containing the requested functionality, but also a lot of changes they haven’t asked for.

Therefore ASML is considering other approaches for their release method. An option is to split their software into smaller pieces (we will call these pieces functional units or FU’s). The implementation of a requested functionality will only affect a few FU’s. Once implemented and tested, the client can install a new version of the affected FU’s without changing the other FU’s. This means that there will be a broad range of configurations ”in the field” (on the different machines of the clients). Of course, ASML only has a limited number of programmers to maintain, and a limited number of machines to test the software. The main question in this approach is: In how many FU’s can ASML split their monolith so that they can still manage all versions of these FU’s?

Assume the monolith will be split up in k functional units: FU1, FU2, . . . FUk. Each unit FUi can exist in different consecutive versions, for simplicity numbered by 1, 2, . . . , ni. Version j of FUi will be denoted by FUj i . All the FU’s communicate with each other through interfaces. These interfaces remain unchanged when one or more FU’s get a new version. The configuration where FU1 has version j1, FU2 has version j2, and so on, will be denoted by (FUj1 1 , FUj2 2 , . . . , FUjk k ). Suppose that for each unit a corresponding probability distribution is given that models the probability that a client orders a new version in a certain time interval. Releasing a new version of a FU brings a certain amount of work that, globally, can be divided into three parts: implementation, testing and maintenance (=bug fixes, …). It is reasonable to assume that the work needed for the implementation and maintenance of a new version of an FU is independent of the other FU’s. The
testing on the other hand depends heavily on the number of versions of the other FU’s, because a FU version (ideally) should be tested in all combinations of all versions of the other FU’s. In practice, ASML will only support (and thus only test a new FUi version in) the configurations with one of the lj last versions of FUj for j 6= i. The practical limitations inside ASML (number of programmers, machines, …)
give an upper bound to the amount of work ASML can handle.

The question thus becomes: Find the maximal k and l1, . . . , lk such that the total work needed stays below this upper bound”