Webapplicatie overnemen: overstappen naar een andere softwareleverancier

Uw applicatie is in gebruik, en de gebruikers gebruiken haar elke dag. De leverancier die haar heeft ontwikkeld, reageert niet meer, of ontwikkelt haar niet meer door in het tempo van uw bedrijf. Soms heeft het project vertraging opgelopen en is de aangekondigde datum verstreken.

Een nieuwe leverancier kan verdergaan met de bestaande code. Een applicatie die in gebruik is, bevat bedrijfsregels: berekeningen, uitzonderingen. Vaak staan die nergens anders beschreven dan in de code. Die nieuwe leverancier neemt de code over, doorgrondt die, en ontwikkelt ze daarna door zonder kapot te maken wat werkt.

Een webapplicatie overnemen: wat een nieuwe leverancier overneemt

Een applicatie overnemen betekent dat een ander team haar doorontwikkelt op basis van de bestaande code. Dat geldt voor applicaties waarvan de ontwikkeling is stilgevallen voordat ze live gingen, en voor applicaties die in gebruik zijn maar moeilijk verder te ontwikkelen zijn geworden.

De nieuwe leverancier neemt drie dingen over: de broncode, de toegang waarmee hij de applicatie online kan zetten, en wat er over de applicatie bekend is. Dat laatste is vaak het kwetsbaarst. Werkt er maar één ontwikkelaar aan, dan vertrekt zijn kennis van de software met hem als hij die niet heeft vastgelegd. Daarom loont het om die kennis gaandeweg op papier te laten zetten.

Een applicatie die doet wat u nodig hebt en zonder moeite verder te ontwikkelen is, hoeft niet te worden overgenomen.

Overstappen naar een andere softwareleverancier: wat u moet terugkrijgen

Maak een lijst van wat u moet terugkrijgen, voordat u uw huidige leverancier inlicht. Daar begint een overname: alles verzamelen wat op uw naam moet staan, namelijk de broncode, de hosting, de domeinnaam en de accounts bij de externe diensten die de applicatie gebruikt (online betalingen, e-mailverzending, kaartdiensten).

Staan die accounts op naam van de leverancier, dan heeft hij de toegang in handen. Vraag hem ze over te dragen op naam van uw bedrijf, en open op naam van uw bedrijf de accounts die nog niet bestaan.

Vraag ook de documentatie, als die er is: hoe u de applicatie installeert, hoe u haar online zet, welke tests controleren of ze werkt.

Intellectueel eigendom van de broncode: wat uw contract zegt

Een kopie van de code hebben is niet genoeg om er met een andere leverancier mee verder te gaan: u moet er ook het recht toe hebben. De facturen betalen maakt u geen eigenaar van de code. Het contract draagt de code aan u over, door een schriftelijke overdracht van de rechten die elk overgedragen recht benoemt.

Lees uw contract dus opnieuw door voordat u uw vertrek aankondigt. Blijft een deel van de code eigendom van de leverancier, controleer dan of de licentie die hij u verleent u toestaat dat deel aan iemand anders toe te vertrouwen. Twijfelt u, laat de clausule dan door een advocaat nalezen.

De reversibiliteitsclausule in het IT-contract

De reversibiliteitsclausule regelt uw vertrek: het terugkrijgen van de gegevens, de toegang tot de configuraties, de overdracht van de documentatie, de opzegtermijn. Staat er zo’n clausule in uw contract, dan is dit het moment om haar toe te passen. Staat ze er niet in, dan hangt alles af van wat uw leverancier u wil overhandigen.

Regel dat vertrek in het contract dat u met de volgende leverancier tekent vanaf de eerste dag, en probeer de overname één keer uit, voordat u haar nodig hebt.

Een audit van de broncode: lezen vóór het wijzigen

Zodra de toegang is verzameld, wordt de applicatie gedeployd op een acceptatieomgeving, een kopie van de applicatie waarop elke wijziging wordt gecontroleerd voordat ze online gaat. De nieuwe leverancier beheert die omgeving, en ze bootst de productie na. Daar leest hij de code, en controleert hij of hij die kan bouwen en online zetten zonder hulp van het vorige team.

Michael Feathers is de auteur van Working Effectively with Legacy Code (Effectief werken met legacy code), verschenen in 2004, hét naslagwerk voor ontwikkelaars die bestaande code overnemen. Hij omschrijft legacy code, de code die van een vorig team wordt overgenomen, simpelweg als code zonder tests.

Zonder tests is er geen manier om snel te controleren of een wijziging elders niets kapot heeft gemaakt. Wijzigingen gebeuren dan in kleine, voorzichtige stapjes. De doorontwikkeling vertraagt.

Voordat er iets wordt gewijzigd, beschrijven geautomatiseerde tests wat de applicatie nu doet, voor de handelingen waar de gebruikers van afhankelijk zijn. Pas daarna wordt ze gewijzigd. Elke wijziging gaat door een deployment-pipeline die deze tests opnieuw draait voordat ze de acceptatieomgeving bereikt.

Een webapplicatie vernieuwen of overnemen: houden wat werkt

Bij code die moeilijk verder te ontwikkelen is, ligt de verleiding voor de hand om alles opnieuw te bouwen. Wie de applicatie in één keer herschrijft, moet echter al haar bedrijfsregels een voor een terugvinden. Ondertussen staat de applicatie die in gebruik is stil. De nieuwe versie levert de gebruikers niets op zolang ze niet af is.

Vernieuwen kan ook anders: in delen. Een onderdeel wordt vervangen als het de doorontwikkeling blokkeert die u nodig hebt, niet omdat het oud is. De rest blijft ondertussen in gebruik. En elke wijziging gaat apart naar productie, na de acceptatie: een kleine wijziging is minder riskant dan een nieuwe versie die in één keer wordt opgeleverd.

Een applicatie migreren hoort bij dat vernieuwen: haar code overzetten naar een recentere versie van haar framework, naar een andere technologie of naar een andere taal, zonder te veranderen wat ze voor haar gebruikers doet.

Hoe de overname van een webapplicatie verloopt

Bij DEVEDANOS verzamelen we eerst de toegang en zetten we de applicatie op een acceptatieomgeving. Daarna schrijven we, voordat we iets wijzigen, tests voor de handelingen waar de gebruikers van afhankelijk zijn. Is er documentatie, dan lezen we die.

We vervangen een onderdeel als het de doorontwikkeling blokkeert die u nodig hebt, en we houden wat werkt. Die beslissing nemen we samen met u, nadat we de code hebben gelezen.

Bij een project met vertraging nemen we samen met u de lijst met geplande functionaliteiten door en rangschikken ze naar hun waarde voor de gebruikers van uw applicatie. Wat het zwaarst weegt, wordt als eerste ontworpen, ontwikkeld en in productie gezet, een voor een, elk na de acceptatie.

Voor een fabrikant van recreatievoertuigen hebben we meegewerkt aan de ontwikkeling van zijn marketplace. Het project had vertraging opgelopen bij een andere leverancier. Samen met de klant en die leverancier hebben we de ontwikkeling teruggebracht tot de essentiële functionaliteiten, de functionaliteiten die de meeste waarde opleverden. De nieuwe deadline werd gehaald, met een minimale applicatie. De andere functionaliteiten zijn daarna continu toegevoegd.

Applicatiebeheer en -onderhoud: na de overname

Is de applicatie eenmaal overgenomen, dan moet ze nog worden onderhouden. Wij verzorgen het applicatiebeheer en -onderhoud in hetzelfde model. Correctief onderhoud (bugfixes), adaptief onderhoud (updates van dependencies, beveiligingspatches, browsercompatibiliteit), preventief onderhoud (refactoring, performance-optimalisatie) en doorontwikkeling (nieuwe functionaliteiten) zijn inbegrepen.

Bij DEVEDANOS ontwikkelt, test, deployt en onderhoudt hetzelfde team uw software continu, in dezelfde pipeline.

DEVEDANOS: uw applicatie overnemen tegen een vast maandbudget

We nemen eerst applicaties over in JavaScript en TypeScript (React, React Native, Next.js, Node.js). Voor een andere technologie (PHP, Java, Python…) gelden de basisprincipes van software engineering in elke taal: bespreek het gewoon in het eerste gesprek.

Bij DEVEDANOS ontwikkelen wij uw software op maat, binnen een maand bruikbaar, tegen een vast maandbudget, en stemmen we die continu af op de veranderingen in uw bedrijf. Het budget wordt samen met u opgebouwd, op basis van uw cijfers en doelstellingen: samen bepalen we het bedrag en het probleem dat uw applicatie moet oplossen.

Wat goedgekeurd is, gaat naar productie. Elke dag ziet u de applicatie vooruitgaan op uw acceptatieomgeving.

En om ervoor te zorgen dat wat vóór de overname werkte, daarna ook werkt, hanteren we een nulregressiegarantie: elke regressie wordt verholpen en afgedekt door een geautomatiseerde test, zodat ze niet terugkomt, zonder meerkosten.

De broncode, infrastructuur, deployment-pipeline en documentatie zijn uw intellectueel eigendom zodra de eerste maandfactuur is betaald. Een proefperiode tot 15 werkdagen in de eerste maand: geen factuur als u de opleveringen niet wilt.

U kunt het contract schriftelijk opzeggen op elk moment, zonder opgaaf van redenen. Tijdens de maand van reversibiliteit begeleiden wij uw team totdat het kan bouwen, testen en deployen zonder ons.

Op onze pagina over het overnemen en vernieuwen van applicaties leest u wat we met een bestaande applicatie doen.

Verder lezen

Kiest u de leverancier die uw applicatie gaat overnemen? Ons artikel over de technische partner van een mkb-bedrijf onderscheidt de vier vormen van IT-leverancier en de vragen die u hun moet stellen. En verandert uw behoefte onderweg, dan hangt het van het contract af wie die verandering betaalt: een vaste prijs met vaste scope, regie, of een vast budget.

Reageert uw leverancier niet meer, of komt uw applicatie niet meer vooruit? Zullen we erover praten?

Bronnen

• M. Feathers, Working Effectively with Legacy Code, Prentice Hall, 2004 (definitie van legacy code als code zonder tests, in het voorwoord).