Kansrijke ideeën en initiatieven moeten tegenwoordig razendsnel worden vertaald naar bruikbare software. Auditing is cruciaal in dit dynamische, sterk codegedreven tijdperk. Op basis daarvan kun je ervoor kiezen om veranderingen aan te brengen in bestaande software of een geheel nieuwe applicatie te bouwen. Ook de structuur en werking van de organisatie wordt in de beoordeling meegenomen.

Het pad naar innovatie en waardecreatie loopt tegenwoordig via ‘continuous delivery’, waarbij het op basis van de business- en klantwens continu opleveren van bruikbare software centraal staat. Een degelijk proces betekent dat ‘van concept naar cash’ geen weken of maanden duurt, maar slechts enkele dagen. Naast complexe releaseprocessen vormt de veelal moeilijk aanpasbare legacy-software de grootste belemmering. Inzicht in de behoefte, het gebruik en de kwaliteit ervan brengt zowel problemen als prioriteiten in kaart.

Doordat nieuwe technologieën elkaar in steeds sneller tempo opvolgen, en legacy niet direct kan worden uitgefaseerd, wordt het systeemlandschap almaar complexer. Software-ontwikkeltrajecten lopen daardoor uit, met alle gevolgen voor reputatie en gemiste opportunities. De security en de performance blijven achter en het risico op verstoring van het productieproces neemt toe. Onderhoud is tijdrovend en de kosten lopen op. Ondertussen vragen veranderende (markt)omstandigheden om aanpassing en zit ook de concurrentie niet stil.

Auditing-aanpak

In een tijd waarin software bepalend is voor de kwaliteit van dienstverlening – en dus het succes van de organisatie – draait het om drie dingen: een korte time-to-market, de juiste controleer- en beheerbaarheid, en ten slotte het gewenste kostenniveau. Daar komt auditing om de hoek kijken! Dit proces verloopt in de praktijk van Xebia in de volgende stappen:

  1. Iedere audit start met een intake waarin de aanleiding, doelstelling en context helder worden geformuleerd. De concrete onderzoeksvraag, het toetsingskader en de uiteindelijke opdracht worden vastgesteld.
  2. Gerichte interviews met stakeholders leveren het fundament voor verdere analyse. De interviewvragen bestrijken een variëteit aan deelgebieden en zijn samengesteld op basis van jarenlange ervaring.
  3. Vervolgens wordt bepaald welke onderzoeksgebieden de analyse omvat. Denk aan een geautomatiseerde analyse van de broncode, alsmede een inspectie van zowel code, architectuur en werkwijzen door experts.
  4. Inmiddels is er op basis van analyse en inspectie een helder beeld van de stand van zaken. De bevindingen worden met elkaar in verband gebracht en met de betrokkenen gevalideerd om tot de kern van de zaak te komen.
  5. Op basis van de feiten worden ervaring en vakmanschap ingezet om te komen tot conclusies en aanbevelingen.
  6. De aanbevelingen zijn vervolgens gebaseerd op feitelijke bevindingen en praktijkervaring rond het bedrijven van architectuur, het bouwen van software en het in productie nemen van applicaties.
  7. Als sluitstuk van de audit worden de bevindingen en aanbevelingen aan de organisatie gerapporteerd en gepresenteerd. De organisatie die de audit heeft uitgevoerd kan al dan niet een rol spelen bij de implementatie.

Praktijkvoorbeeld

Neem als voorbeeld de situatie bij ING dat voor een belangrijk beleggingsproduct een grote applicatie heeft draaien. De voorkant van deze beleggen-applicatie is door ING ontwikkeld en gekoppeld aan een systeem in de back-end.

De functionaliteit en de performance waren aanvankelijk goed. Na jaren van ontwikkeling is de frontoffice-applicatie evenwel gegroeid tot een omvang die onderhoud en beheer steeds lastiger maakt. Wijzigingen kosten steeds meer tijd en het doorvoeren van innovaties is moeilijk.

”Een goede audit gaat veel verder dan het checken van de applicatiecode”

De frontoffice-applicatie staat bovendien niet op zichzelf. Zo moet deze voldoen aan wettelijke vereisten en is er vanuit de business de behoefte om de dienstverlening zowel visueel als functioneel te verbeteren. Daarnaast zijn er plannen om het Nederlandse beleggingsproduct samen te voegen met de Belgische variant.

En dan zijn er nog de externe factoren, zoals de toetreding van startups en de opmars van buitenlandse technologiereuzen in het financiële domein. Partijen die wereldwijd opereren op basis van standaardapplicaties, met alle voordelen van dien.

Onderzoeksvragen

Dit alles roept binnen ING een tweetal onderzoeksvragen op. Allereerst: hoe zorg je ervoor dat de genoemde applicatie onderhoudbaar blijft? Daarnaast is het de vraag hoe het herontwerp benaderd moet worden. Moet de toepassing bijvoorbeeld opgesplitst worden om beter beheerbaar te zijn, of compleet vervangen? Om die vragen te kunnen beantwoorden is dieper inzicht nodig.

De audit begint met het verzamelen van informatie, bijvoorbeeld door interviews met de betrokkenen binnen business en IT. Om eventuele veranderingen door te voeren is er namelijk altijd een motief nodig. Zelfs de beste technische verbeteringen zijn zinloos wanneer deze niet in lijn zijn met de businessdoelstellingen.

Waar soms een kleine aanpassing volstaat om de beoogde doelen te bereiken, is het voor andere zaken zinvol om iets nieuws te bouwen. Los daarvan is het belangrijk dat regelmatig technische verbeteringen kunnen worden doorgevoerd. Wanneer er vanuit de business sterke behoefte is aan nieuwe functionaliteit, wordt deze echter te vaak uitgesteld. Dit is de ‘technical debt’ die ooit zal moeten worden ingelost. In de praktijk blijkt er zelden een goed moment te zijn voor technische verbeteringen.

Voortdurende verbetering

Ontwikkelaars moeten derhalve het voortdurend doorvoeren van kleine verbeteringen een regulier onderdeel van hun werk maken. Grotere technische aanpassingen moeten in overeenstemming met de business worden gerealiseerd. In het kader van een continue ontwikkeling – zowel technische verbetering als businessgerichte innovatie – is een goede code-base van fundamenteel belang.

Daarnaast bevat de code zelf waardevolle informatie over de onderhoudbaarheid. Het gebruik van statische code-analyse geeft inzicht in de complexe applicatieonderdelen. Er is overigens niets fout met een ingewikkelde code wanneer deze niet hoeft te worden gewijzigd. Meer problematisch zijn de complexe delen van de applicatie die wél vaak om aanpassing vragen.

Gesprekken met de betrokkenen in combinatie met technische analyse leidt binnen ING tot een betere developmentaanpak. De bestaande codebase wordt op z’n merites beoordeeld en opgesplitst om de gewenste aanpassing van de onderdelen eenvoudiger te maken. Een nieuw team werkt intussen aan een nieuwe applicatie. Deze bevat zowel technische innovaties als nieuwe businessfunctionaliteit. Gedurende het proces worden de bevindingen voorgelegd aan uiteenlopende groepen betrokkenen. Zo blijft iedereen op de hoogte en wordt nuttige feedback vroegtijdig verzameld.

Een goede audit gaat, kortom, veel verder dan het checken van de applicatiecode. Naast de beoordeling van de softwarekwaliteit, wordt idealiter een oorzaak-gevolganalyse uitgevoerd. Bekeken wordt in hoeverre eventuele applicatieproblemen het gevolg zijn van gevolgde processen, samenwerking tussen partijen, samenstelling van betrokken teams en de onderliggende architectuur. Een combinatie van technisch inzicht en een helder beeld van de context leidt tot een advies waarmee de organisatie zichzelf en de opgeleverde software kan verbeteren.

LAAT EEN REACTIE ACHTER

Laat alsjeblieft een reactie achter!
Laat hier je naam achter