Versie management, OTAP, IT Change management

Tja de termen Versie management, OTAP, IT Change management spelen momenteel in mijn hoofd. Ik kwam de afgelopen weken deze termen verschillende malen tegen en moest daarbij elke keer denken aan Google. Hoe doet Google dit? 
Traditioneel gezien in applicatie ontwikkel land is er een OTAP-straat (Ontwikkel, Test, Acceptatie, Productie) om versies gecontroleerd in te voeren. Applicatie versies zijn traditioneel gezien grote wijzigingen die goed getest worden voordat een nieuwe versie in productie gezet wordt. Na een major release (3.0), volgen meestal enkele minor releases (3.1) om functionaliteit af te stemmen op de gebruikerswensen en eventueel enkele patch releases (3.1.1.) om bugs te verhelpen in een release. En zo gaat het binnen een bedrijf voor custom applicaties, maar ook bij de grote software leveranciers zoals Microsoft.


De investeringskosten in een OTAP straat zijn hoog. De kosten om het proces te managen zijn zo mogelijk nog hoger. Bij vele klanten zie ik dan ook dat er nog al eens bespaart wordt op het inrichten van een goede en volledige OTAP straat. En ook het testen wil wel eens de sluitpost op het project zijn. Dit met alle beheer gevolgen van dien.


Voor sommige applicaties is het natuurlijk bijna ondoenlijk om een OTAP straat na te bouwen. Google had bijvoorbeeld zo'n probleem en heeft dit op een zeer eenvoudige en doeltreffende manier opgelost volgens mij.


Google heeft mij namelijk een nieuwe blik gegeven op de huidige werkwijze bij vele bedrijven. Google pakt wijziging compleet anders aan in mijn oogpunt. Zo brengen ze elke week voor Google Apps wel 1 of meerder kleine wijzigingen aan. Doordat de wijziging een kleine verandering is, is de impact op gebruikers en de Google IT systemen niet zo groot. Een ander voordeel is dat Google zo makkelijk het succes achterna kan. Als een wijziging in een bepaald onderdeel goed door gebruikers opgepakt wordt (wat blijkt uit gebruikerstatistieken) kan Google makkelijk doorwerken op dit succes en de ontwikkelroadmap bijsturen op basis van succesvol opgepakte functionaliteit. Tevens groeit het vertrouwen daar er elke week een succesvolle upgrade is. Naast het vertrouwen groeit ook de product kennis van de gebruikers per week. Elke week leren gebruikers weer nieuwe mogelijkheden in het platform, en is een organisatie verzekerd van de laatste mogelijkheden op Internet applicatie gebied. Je hoeft zo niet weer 3 of 4 jaar te wachten op een nieuwe major release van je mail client zoals bij Microsoft Outlook 2003-2007-2010, waarbij weer een flinke change project hoort voor data migratie en nieuwe hardware. 


Voor het testen heeft Google ook een iets andere benadering. Testen gebeurt eerst intern op de eigen Google medewerkers. De correcte werking van de functionaliteit wordt zo eerst gecontroleerd en feedback verzameld. Vervolgens laat Google de functionaliteit los op enkele gebruikers van Google Apps. Na succes, wordt de functionaliteit tenslotte uitgerold over alle Google Apps gebruikers wereldwijd. 
Het testen is dus een onderdeel van de deployment strategy. De functionaliteit wordt langzaam aan geintroduceerd voordat een change wordt doorgezet naar de totale community of naar de betalende Google Apps gebruikers (die een uptime garantie hebben).


Als klant van Google Apps weet je dus dat functionaliteit al verschillende release stadia succesvol gepasseerd zijn voordat ze in jouw versie komen. Dat moet toch een veilig gevoel geven.