Noch wichtiger sind die Auswirkungen auf die Anwendungslandschaft. "Die starke Trennung der Anwendungslogik von den Technologiekomponenten erlaubt uns beispielsweise, das Directory-Produkt eines anderen Herstellers zu implementieren, ohne dass alle betroffenen Anwendungen einzeln umgestellt werden müssen." Was sich in der Theorie so einfach anhört, hat sich in der Praxis schon bewährt: So konnte der Wechsel auf ein neues Directory-Produkt laut Reimann ohne große Mehraufwände für die vielen Applikationsprojekte vorgenommen werden.

Aber auch die Migration der in IAP enthaltenen Basisprodukte, beispielsweise der Websphere-Applikations-Server, auf einen neuen Release-Stand lässt sich so günstiger bewerkstelligen. Durch das zentrale Bundling notwendiger Fixes und Service-Packs aller Basisprodukte konnte die Anzahl entsprechender Eingriffe stark verringert werden. Zudem ließ sich der Testaufwand drastisch reduzieren.

Das Release-Management spielt nicht nur für die in IAP integrierten Produkte eine wichtige Rolle. Auch die integrierte Anwendungsplattform selbst wird ständig weiterentwickelt, was sich in drei bis vier neuen Versionsständen pro Jahr niederschlägt. Damit die nachgelagerten Applikationsentwickler nicht fortlaufend neue IAP-Release-Stände beachten müssen, werden diese heute bis zu zwei Jahre vorgehalten. "Wir verfolgen hier einen flexiblen Top-down-Ansatz", beschreibt IT-Manager Ritzer die Vorgehensweise. Die Anwendungsbereiche würden nicht gezwungen, sofort auf neue IAP-Versionen zu wechseln. "Wir geben mit unserer Release-Planung lediglich den groben Takt vor", so Ritzer. Zu lange sollten die Applikationsverantwortlichen mit ihren Updates allerdings nicht warten, damit die Zahl der vorgehaltenen IAP-Versionen nicht zu stark ansteigt. Derzeit verwaltet das IAP-Release-Management zirka 25 Release-Stände für alle Plattformen und Betriebssysteme.