Az ALM szoftverek az egész vállalati alkalmazás életciklusát kezelik. Egy alkalmazást követnek a korai ötletelési fázistól a tervezésen, fejlesztésen, tesztelésen, kiadáson, üzemeltetésen át egészen a kivonásig. Ez az alapvető mondanivaló, és pont ezt szokták sok csapat elmulasztani, amikor az ALM-ot pusztán fejlesztési eszközként kezelik.
Mindig ugyanarra a tényre térünk vissza: az ALM szélesebb fogalom, mint a szoftveres kódolás. Összeköti a tervezést, a követelményeket, az architektúrát, a tesztelést, a telepítést, a változáskezelést, a támogatást és a leállítással kapcsolatos feladatokat egyetlen, kezelt folyamatba. Egyszerűen fogalmazva: egy utat biztosít az üzlet számára az alkalmazás teljes élete során, nem pedig egy laza, különálló feladatok halmazát.
Ez azért fontos, mert a vállalati szoftverek ritkán csak egy helyen hibáznak. Egy rendszer jól megépíthető, mégis összeomolhat később a kiadás, a támogatás vagy a változáskezelés során. Az ALM létezik ennek a széttagoltságnak a csökkentésére. Közös nyilvántartást ad a csapatnak arról, hogy mit kellene tennie az alkalmazásnak, hogyan változik, mi lett tesztelve, és mi van jelenleg élesben.
A gyakorlati érték könnyen szemléletes. Ha a követelmények egy helyen, a kód egy másikban, a tesztek egy harmadikban, a kiadási jegyzetek pedig egy negyedik helyen találhatók, a csapat időt tölt ezek összeegyeztetésével. Az ALM arra törekszik, hogy ezeket a részeket egyetlen munkafolyammá tegye. Sok jelenlegi platform esetén ez azt jelenti, hogy a nyomkövethetőség, a verziókezelés, a tesztjegyzések, a telepítési lépések és az jóváhagyási előzmények egyetlen rendszerben vagy összekapcsolt rendszerekben helyezkednek el.
Szerintem a legvilágosabb úgy fogalmazni róla, hogy az ALM szoftver nem áll meg a build (építés) pillanatában. A indítás utáni szakaszt is lefedi, amikor az alkalmazást karban kell tartani, frissíteni, monitorozni, és néha ki kell vonni. Ez a szélesebb körű hatókör az oka annak, hogy a vállalati csapatok az ALM kifejezést használják, nemcsak az SDLC (szoftverfejlesztési életciklus) terminológiáját. Az SDLC általában a fejlesztésre utal. Az ALM az alkalmazás teljes élettartamára irányul.
Amit az olvasónak valójában tudnia kell
Az első dolog, amit tudni kell, az, hogy az ALM ugyanannyi menedzsment réteg, mint eszköz. Szerkezetet ad a termékek, mérnöki csapatok, minőségbiztosítás (QA), műveletek és támogatás között átnyúló munkának. Amikor ez a struktúra gyenge, a csapatok gyakran elveszítik a változások és a tesztelés állapotának nyomon követését. Amikor erősebb, az üzlet tisztább képet kap a kockázatokról és a kiadási készletről.
A második dolog, amit tudni kell, az, hogy az ALM segít fenntartani a rendszer illeszkedését az üzleti igényekhez az idő múlásával. Egy alkalmazás akkor sem kész, amikor élesbe kerül. Új törvények, új ügyféligények, biztonsági javítások és belső folyamatváltozások mind előre tolják azt. Az ALM helyet biztosít ezeknek a változásoknak a tervezéshez, ellenőrzéshez, jóváhagyáshoz és nyomon követéshez.
Ennek az az oka, hogy az ALM szoftvert gyakran nagyobb vállalatoknál és szabályozott környezetben alkalmazzák. Nem csak a sebesség a kérdés. A kontroll is az. A csapatoknak tudniuk kell, mi változott, ki hagyta jóvá, mi lett tesztelve, és hogyan jutott el a változás a produkcióba. Ezek alapvető kérdések, de annál fontosabbak, minél nagyobbak a rendszerek.
Bár egy korlátot világosan meg kell említeni: az ALM szoftver önmagában nem teremt fegyelmet. Ha a csapatok nem tartanak naprakészen a nyilvántartásokat, vagy ha megkerülik a folyamatot, az eszköz héjjá válik. A szoftver támogathatja a rendet, de nem tudja kényszeríteni a jó ítélőképességet vagy a tiszta csapatmunkát.
Folyamatban lévő elmosódottság is tapasztalható az ALM, a DevOps és a szélesebb körű vállalati architekturális eszközök között. A szállítók néven átfedő módon használják a kifejezéseket. Egy platform a tervezésre és a kiadási munkára fókuszálhat. Egy másik hozzáadhatja a monitorozást, a portfólió nézeteket vagy a kormányzást. Tehát a dobozon lévő név kevésbé számít, mint a ciklus valós lefedettsége.
Itt segít a körültekintő olvasás. Egy vevőnek vagy olvasónak a kontroll terjedelmét kell keresnie. Lefedi a szoftver a követelményeket, a tesztelést, a kiadást, a támogatást és a kivonást? Összeköti a munkát a csapatok között? Nyomot tart az ötletről a produkciós változásig? Ha a válasz csak félig-meddig igen, akkor a gyakorlatban nem teljes életciklus-menedzsmentről van szó.
Ezt a vállalati rendszerekben gyakori alkalmazott mintázatként látjuk. Minél jobban összekötött az életciklus, annál kevésbé függ az üzlet az emlékezettől és a személyes szokásoktól. Minél gyengébb a kapcsolat, annál több munka vész el a csapatok között. Az ALM szoftver egyik módja ennek a résnek a beszűkítésére. Vezérelt utat biztosít a vállalat számára az első kéréstől a végső leszerelésig.
A hasznos válasz tehát közvetlen. Az ALM szoftver kezeli az egész vállalati alkalmazás életciklusát, és ez sokkal többet jelent, mint csak a kódot. Ez egy módja annak, hogy az üzleti szándékot, a technikai munkát és az éles üzemeltetést ugyanabban a nyilvántartási láncban tartsa. A nehéz rész nem az ötlet. A nehéz rész abban áll, hogy azt a láncot őszintén és hitelesen tartjuk, ahogy a rendszer növekszik és változik.
Ez az a fajta gyakorlati minta, amelyet az EuroOp LLC-nél figyelünk. Az EuroOp Insights ugyanerre a gondolatmenetre épül: egy alkalmazott kutatási és fejlesztési (R&D) minta, egy gyakorlati tanulság, az EuroOp termékeinek hátterében futó csatornából.