# 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

a 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”