Software packaging is pas het begin

Applicatiepackaging beantwoordt precies één vraag: is de applicatie klaar om uit te rollen? Dat is een terechte vraag, en een verkeerd antwoord is duur: rework, vertraagde releases en QA-rondes die steeds opnieuw beginnen zodra er eerder in het proces iets verandert. Maar packaging is één moment in de levenscyclus van een applicatie, niet het hele verhaal. Of een applicatiestrategie werkt of ongemerkt tijd opslokt, wordt grotendeels bepaald vóórdat er gepackaged wordt, en nog meer daarna.

Die levenscyclus draait om vier vragen. Wat hebben we eigenlijk? Hoe krijgen we het overal? Wie houdt de regie zodra het live staat? En wat doen we als het misgaat? Discover, Deliver, Control en Fix: van vóór de uitrol tot lang daarna.

Discover: wat je niet ziet, kun je niet beheren

Voordat er iets gepackaged wordt, ligt er een fundamentelere vraag: weet je eigenlijk welke applicaties gebruikt worden, door wie, en hoe goed dat gaat? Deployment-dashboards vertellen je prima óf iets geïnstalleerd is. Of het ook werkt en gebruikt wordt, is onbekend.

Dat gat is groter dan de meeste organisaties denken. Naar schatting wordt 20 tot 30 procent van alle geïnstalleerde bedrijfssoftware zelden of nooit geopend. Een flink deel van het packaging- en onderhoudswerk gaat dus op aan applicaties die niemand nodig heeft. En als er wél iets misgaat, blijkt dat zelden uit een melding op een dashboard. Het komt binnen als supportticket, vaak pas dagen of weken later. Problemen die op die manier bij IT terechtkomen, kosten doorgaans meer tijd om op te lossen dan problemen die proactief worden ontdekt. Een groene installatiestatus en een productieve gebruiker zijn twee verschillende dingen, en standaard wordt alleen het eerste gemeten.

Deliver: één strategie, of vier naast elkaar?

Weet je wat er uitgerold moet worden, dan is de volgende vraag op hoeveel verschillende manieren dat eigenlijk gebeurt. Fysieke endpoints, virtuele desktops, Citrix, cloud-pc’s: als elk platform een eigen package nodig heeft, apart gebouwd en apart getest, heb je geen deliverystrategie. Dan heb je er drie of vier naast elkaar, die stuk voor stuk uit de pas kunnen gaan lopen.

Juist hier worden legacy-applicaties ongemerkt een probleem voor de roadmap. Organisaties met meer dan 25 procent legacy-applicaties lopen bij OS-migraties gemiddeld zes maanden vertraging op. Niet omdat de migratie zelf zo complex is, maar omdat elke legacy-applicatie eerst opnieuw gepackaged moet worden voordat de migratie verder kan. Wie drie of meer deliveryplatformen ondersteunt, heeft te maken met twee keer zoveel packagingcomplexiteit als een omgeving met één platform. De oplossing is niet sneller packagen, maar de applicatie loskoppelen van het onderliggende platform. Pas dan wordt ‘één keer packagen, overal uitrollen’ werkelijkheid.

Control: wie krijgt toegang, en blijft dat kloppen?

Uitrollen is geen eenmalige actie. Zolang een applicatie live staat, moeten toegang en configuratie blijven kloppen. Op grote schaal is dat lastiger dan het klinkt. Bij honderden applicaties en duizenden gebruikers levert handmatig beheer van toegang en rechten via spreadsheets en tickets niet alleen fouten op, maar ook auditbevindingen. In- en uitstroom en interne functiewisselingen staan bij auditors steevast hoog op het lijstje: rechten die na een rolwijziging ingetrokken hadden moeten worden, blijven vaak gewoon bestaan tot iemand er gericht naar gaat zoeken.

Aan de gebruikerskant speelt een minder zichtbare variant van hetzelfde probleem. Wie op een andere machine inlogt, verwacht dezelfde apps, dezelfde instellingen en dezelfde werkplek aan te treffen als daarvoor. Elke keer dat dat niet zo is, ontstaat er frustratie en lijdt de digitale werkervaring eronder, zonder dat het ooit als duidelijke storing zichtbaar wordt.

Fix: wat gebeurt er nu precies, en kun je er direct iets aan doen?

Vroeg of laat gaat er iets mis. Een applicatie gedraagt zich vreemd, een instelling wordt niet toegepast, of een gebruiker belt omdat niets er meer uitziet zoals gisteren. Het standaardantwoord is dan vaak een volledige remote-sessie: traag om op te zetten, storend voor de gebruiker en meestal overkill voor wat uiteindelijk een eenvoudig probleem blijkt.

Het kan efficiënter, met live inzicht in wat er op een endpoint gebeurt, of de mogelijkheid om terug te kijken naar gisteren. Vaak is dat al genoeg om een probleem te diagnosticeren en meteen op te lossen, zonder ooit een sessie te hoeven inplannen. Organisaties met dat soort proactief inzicht lossen applicatie-incidenten tot 60 procent sneller op dan organisaties die vertrouwen op ‘ticket aanmaken en afwachten’. Het verschil zit niet in de inspanning, maar in de vraag of je blind naar de oorzaak zoekt of het volledige beeld voor je hebt.

Het gaat om het geheel

Packaging is het fundament: zonder goede package valt er niets uit te rollen. Maar efficiënt applicatiebeheer ontstaat pas als alle vijf de bouwstenen staan: packaging, aangevuld met Discover, Deliver, Control en Fix. Zicht op wat er écht gebruikt wordt, één manier van uitrollen die overal werkt, toegang die blijft kloppen en het vermogen om snel in te grijpen als er iets misgaat. Staat dat allemaal, dan is een applicatie niet langer iets wat je uitrolt, maar iets wat je beheert: van dag één tot het moment van uitfaseren.

De meeste organisaties hebben één of twee van deze onderdelen goed op orde. Teams die alle vijf combineren, merken het verschil: minder tijd kwijt aan uitzoekwerk, minder verrassingen bij audits, en gebruikers die niet eens merken dat er iets is uitgerold.

Benieuwd hoe je eigen omgeving scoort op Discover, Deliver, Control en Fix? Daarvoor hebben we een korte self-assessment ontwikkeld. Het invullen kost ongeveer vijf minuten, je hoeft niet in te loggen en je ziet je resultaten direct. Zo krijg je een eerste beeld van waar in jouw applicatiebeheer tijd en consistentie verloren gaan, en waar niet.

Naar de assessment: https://eu.liquidware.com/app-...

Schrijf je in voor het webinar "Beyond Packaging: Discover. Deliver. Control. Fix.": https://liquidware.zoom.us/web...