In de wereld van softwareontwikkeling voltrekt zich een ware revolutie. Er is vrijwel geen succesvol bedrijf dat niet op software vertrouwt. De effectiviteit van een bedrijf wordt steeds meer afhankelijk van de kwaliteit, beveiliging en efficiëntie van software.

Voor organisaties die al tientallen jaren bestaan, betekent dit niet alleen dat zij moeten investeren in technologische innovatie, maar ook dat zij hun bestaande softwaresystemen moeten moderniseren en onderhouden. Het werken met verouderde systemen brengt immers beperkingen met zich mee. Zou het niet geweldig zijn als de discussies over beperkingen aanzetten tot innovatie die ertoe leidt dat toekomstige generaties in dit opzicht worden ontzorgd?

Daar komt zelfherstellende software om de hoek kijken. Nog maar een decennium geleden heerste binnen de technologiegemeenschap grote opwinding over de mogelijkheid dat een softwaresysteem met behulp van hoogwaardige logica zijn eigen fouten kon opsporen en deze bovendien automatisch kon herstellen zonder noemenswaardige menselijke tussenkomst.

Het concept van zelfherstel heeft zich in de infrastructurele wereld inmiddels ontwikkeld. Zo wordt zelfherstellende software toegepast bij het voorkomen van cyberaanvallen en grootschalige systeemuitval. Voor ons is de volgende ontwikkeling duidelijk: rechtstreekse toepassing van zelfherstel op broncode ten behoeve van softwareontwikkeling en verbeteringsinitiatieven.

Drie stappen

Zet de volgende drie stappen om het zelfhersteltraject te starten, ongeacht het huidige ontwikkelingsproces of de samenstelling van uw team.

1. Breng de ‘aandoening’ in beeld op broncodeniveau
Stap één in het zelfherstelproces is het in kaart brengen van de patronen die doorgaans leiden tot onveilige applicaties of de applicaties op bepaalde plekken verzwakken. Deze zijn aanvankelijk vaak moeilijk te herkennen, omdat ze pas aan het licht komen wanneer de applicatie in productie is en daadwerkelijk wordt gebruikt.

Community-sourced organisaties, zoals CWE van MITRE en het Consortium for IT Software Quality (CISQ), hanteren gemeenschappelijke talen en standaarden voor het meten van softwarekwaliteit waarmee u aan de slag kunt gaan. Een basis van systeemefficiëntie, veerkracht, onderhoudsvriendelijkheid en beveiliging is noodzakelijk voor het ontwikkelen van zelfherstellende software.

Zodra aan deze voorwaarden is voldaan, kunnen teams systematische metingen toevoegen voor trendanalyses en het opsporen van gemeenschappelijke oorzaken van onderbrekingen in de dienstverlening en fouten in applicaties. Daarmee wordt ook de weg vrijgemaakt voor machine learning. Dit maakt het mogelijk om de patroonanalyse verder te automatiseren en systeemonderbrekingen te voorspellen op grond van een groeiend en nauwkeurig overzicht van hoofdoorzaken van slechte code.

2. Verdeel en heers, maar houd grotere plaatje voor ogen
Voor teams die al zijn begonnen met de implementatie van microservices (waarbij applicaties in kleinere en gemakkelijker te wijzigen componenten worden opgedeeld) is implementatie van een niet-invasief zelfherstellend proces een stuk eenvoudiger. Op een bepaald punt moeten deze componenten echter weer worden samengevoegd tot een volledig functionerende applicatie.

Het gebruik van analyse op systeemniveau fungeert als een kwaliteitsborg voordat een systeem na zelfherstel weer in productie wordt genomen. Dit moet voorkomen dat nieuwe tekortkomingen in software of slechte code het systeem kunnen binnendringen. Analyse op systeemniveau kan in dit geval ook worden gebruikt om een blauwdruk van de architectuur te maken voordat het systeem weer in productie gaat.

3. Gebruik zelfherstel als springplank
Het onderbrengen van de automatiseringseigenschappen van zelfherstel kan bijdragen aan de basis voor extra innovatie binnen uw organisatie. Aan de hand van programmeersoftware wordt bijvoorbeeld afwijkende activiteit of logica die zich niet aan bepaalde regels houdt, automatisch gemeld. Hierdoor kan men bijvoorbeeld cloudmigraties stroomlijnen.

Bij de migratie van softwareapplicaties naar een cloud-omgeving moet code nu nog afzonderlijk worden geanalyseerd en bewerkt, om vast te stellen of de applicatie in de cloud daadwerkelijk naar behoren zal functioneren. Stel je eens voor dat deze voor de cloud geschikte apps zelf analyses konden uitvoeren en het ontwikkelingsteam proactief konden duidelijk maken wat voorafgaand aan de migratie moet worden hersteld. Dat zou talloze manuren schelen en verstoring van bedrijfsactiviteiten gedurende de transitie naar de cloud voorkomen.

LAAT EEN REACTIE ACHTER

Laat alsjeblieft een reactie achter!
Laat hier je naam achter