Vad är då ALM (Application Lifecycle Management) och varför är det värt att titta närmare på det? Om man tar några minuter och surfar runt på nätet för att få en bild på vad ALM är för något så hittar man många olika definitioner av vad det är och hur det bör implementeras och det är inte så konstigt då det rör sig om hela applikationer livslängd. Väl genomfört så erbjuder ALM en kontinuerlig affärsnytta genom kontrollerad investering i mjukvaror med en avvägd balans mellan kvalitet och tid.
För några månader sedan köpte jag en bok på Internet kring ALM som egentligen inte är en egenskriven bok utan en samling wikipedia artiklar som är lite omarbetade (Application Lifecycle Management – Activities, Methodologies, Disciplines, Tools, Benefits, ALM Tools and Products, ISBN: 9781742446646). Tar man en titt i innehållsförteckningen i denna bok så inser man hur mycket som faktiskt ingår i ALM tänket, i stora drag så kan man säga att ALM är allt som har att göra med applikationer i hela dess livslängd. Det går att jämföras med PLM (Product Lifecycle Management) som beskrivs som en filosofi för hur man hanterar en produkt och information om produkten under produktens hela livscykel och har funnits med länge i affärsutvecklingssammanhang.
En av fördelarna med ALM är att team samarbetar bättre vilket leder till snabbare och bättre leveranser, förbättrad kvalitet, smidigare informationsflöden.
Att bygga mjukvaruapplikationer är ett hantverk och det krävs många olika kunskaper för att leverera de krav och förväntningar som marknaden förväntar sig idag. Ofta så har man flera personer med olika expertområden och olika team för olika faser för att se till att arbete kan fortgå enligt de planerade aktivisterna och stegen man tar. Det kan röra sig om kravställning, arkitektur, konstruktion, design, test, debugging, distribution eller ren programmering.
När man planerar hur man skall bygga applikationer så brukar man prata metodiker och det är ofta någon form av projektmetodik såsom Vattenfall, RAD, Scrum, RUP, TDD m.fl. En metodik brukar definiera hur teamen leds och varierar mycket även om det står samma namn på etiketten.
Utöver roller och metodiker så tittar även ALM på vilka supporterade discipliner som behövs för att få maximal nytta av applikationer och det röra sig ofta om konfiguration, dokumentation, kvalitetssäkring, användbarhet, förvaltning och projektledning.
För att fullborda ALM matrisen så behöver man se över vilka verktyg som alla roller, metodiker och discipliner behöver för att fungera bra tillsammans och det kan en lång rad olika verktyg såsom kompilatorer, utvecklingsmiljöer, grafiska verktyg, moduleringsverktyg, källkodshantering, bygghantering, releasehantering m.fl. Men det finns även färdiga produkter som t.ex. Microsoft Team Foundation Server som har många av dessa element redo att börja användas direkt i egen regi eller på kran via molnet. Genom att centralt samla data så kan flera team och individer kontinuerligt samarbeta med samma ”arbetspaket” och information lagras genom hela livslängden och alla faser som applikationen går igenom vilket ger en mer komplett och sanningsenligt bild och det blir lättare att faciliteter processer och flöden i olika stadier.
Man kan sammanställa detta och säga att ALM är helt enkelt är konsten att optimera applikationsutveckling i alla dess stadier och få alla element att samspela genom att optimera aktiviteter, metodiker, roller och verktyg så att relationer mellan system, processer och människor kontinuerligt förbättras. En väl fungerande ALM implementation kan jämföras med en bra fungerande motor där man kan öka hastigheten och få nytta snabbare genom att se till att alla element fungerar bra i sig och i relation med helheten samt med transparent spårbarhet genom hela livscykeln.