StoreCompany's software costs will only increase when it adds IFLs or new priced software. In our OaK example, software costs are only an initial cost (probably mitigated by a test license) increase for their DB2 UDB. Software cost always depends on the license conditions. The other software costs are flat until the extra IFL capacity is brought online. And that cost is split amongst all the Linux images!
In our StoreCompany example, a clone can be made of an existing Linux image and some new code needs to be written. The new code manages the presentation of items in the OaK category, assuring that the order is sent to the right artist to be filled, making special offers to customers fitting a certain profile, and serving dynamic Web pages.
When trying out a new project, one first tries to use spare capacity. On the mainframe, all spare capacity is aggregated into one machine. The amount of spare capacity to try out new ideas can mean avoiding new hardware acquisitions.
If one adds more capacity for a specific application and it turns out that the application does not need it, it is simple to reconfigure that capacity to the other images. If the new business opportunity does not work out well for StoreCompany, it is easy to reconfigure the system and use any excess capacity for other Linux applications. In contrast, other design implementations may mean that StoreCompany's business intelligence application would be implemented on a stand-alone machine. If the number of visitors to the new catalog turns out to be low, machine resources would be "wasted."