voorbeeld webapplicatie

Je webapplicatie onderbrengen bij een ander internetbureau? Zo pak je het aan!

Stel: binnen jouw organisatie wordt intensief gebruikgemaakt van een webapplicatie, maar je bent ontevreden over het internetbureau dat de applicatie beheert. Bijvoorbeeld omdat deze leverancier destijds vooral op prijs is geselecteerd en het serviceniveau behoorlijk tegenvalt, of omdat er in de samenwerking zoveel is misgegaan dat je niet meer door één deur kunt. Of – en dan heb je dus echt een acuut probleem – je leverancier gaat failliet. In zo’n situatie wil je het beheer en de doorontwikkeling van je webapplicatie het liefst toevertrouwen aan een andere leverancier. De vraag is: hoe pak je dat aan?

Doordat potentiële klanten ons geregeld vragen of we het beheer van hun webapplicatie(s) willen overnemen, weten we inmiddels als geen ander wat daarbij komt kijken. In dit artikel zet ik de belangrijkste zaken voor je op een rij, om te beginnen door het stellen van vijf cruciale vragen:

#1 Wie heeft het intellectueel eigendom?

Het klinkt, zeker als het nieuw voor je is, misschien wat vreemd: de webapplicatie die je hebt laten ontwikkelen is wellicht niet van jou. Volgens de Nederlandse wet is de auteur van de code – je leverancier dus – namelijk eigenaar van het product dat hij in jouw opdracht heeft ontwikkeld. In de praktijk betekent dit dat hij de enige is die uitbreidingen of aanpassingen mag doorvoeren. Soms doet de leverancier afstand van dit intellectueel eigendomsrecht. Is hierover echter niks afgesproken, dan is het allereerst zaak om uit te zoeken of je wel het recht hebt om over te stappen naar een andere leverancier.

#2 Wat is de kwaliteit van de code?

Bij sommige webapplicaties – zeker als ze al wat ouder zijn – is de code niet (meer) goed gestructureerd en gedocumenteerd en is de logica erachter eigenlijk alleen bekend bij de ontwikkelaars ervan. Vaak zien we dat het overnemen van de webapplicatie door andere ontwikkelaars hierdoor tot problemen leidt. Pas je bijvoorbeeld op één plek iets aan, dan gaat er vaak ergens iets anders mis. Daarom moeten de structuur en de basiskwaliteit van de code altijd eerst worden gecontroleerd. Dat doen we bij voorkeur in een demo- of acceptatieomgeving, voor zover deze beschikbaar is.

Kwaliteit code

 #3 Hoe zit het met de technische basis van je webapplicatie?

Ook de toegepaste techniek speelt een belangrijke rol. Is je webapplicatie bijvoorbeeld gebaseerd op een technisch framework – zoals Symfony2, Zend 2 of Laravel – en zo ja, is de gebruikte versie hiervan nog actueel? Heeft je leverancier geen framework gebruikt, dan is het overigens nog maar de vraag hoe toekomstbestendig en schaalbaar je webapplicatie is… Helaas geldt andersom overigens niet dat je webapplicatie automatisch goed is gebouwd wanneer deze wél op zo’n framework is gebaseerd.

Daarnaast zijn de volgende vragen van belang:

  • Welke CSS- en Javascript-frameworks worden er gebruikt?
  • Hoe zit het build process van de front-end in elkaar? Wordt er bijvoorbeeld gebruikgemaakt van Grunt of Gulp?
  • Welke technieken zijn er nog meer gebruikt en in hoeverre zijn deze achterhaald?
  • Maakt je webapplicatie gebruik van koppelingen en/of externe systemen?
  • Heeft het internetbureau dat je op het oog hebt om het beheer van je webapplicatie over te nemen aantoonbare ervaring met de toegepaste technieken?

#4 Werkt je leverancier mee aan de overdracht?

Het is geen vereiste (maar wel erg prettig) als je huidige leverancier wil meewerken aan de overdracht. Bijvoorbeeld door het aanleveren van een beschrijving, de bronbestanden en een datamodel waarin alle velden en koppelingen worden beschreven. Daarnaast is het handig als hij een bepaalde periode beschikbaar is om vragen te beantwoorden en indien nodig bepaalde zaken na te leveren.

#5 Welke ambities heb je met je webapplicatie?

Een overstap is een goed moment om te overwegen in hoeverre je webapplicatie nog aan je wensen voldoet. Verwacht je de komende jaren een toename of een afname in het gebruik? En werkt alles nog perfect of zou je graag functionaliteiten willen schrappen, optimaliseren of uitbouwen? Misschien zijn er inmiddels wel tools of modules op de markt die (een deel van) je webapplicatie zouden kunnen vervangen!

Ambitie webapp

Vervolgscenario’s

Heb je bovenstaande vragen beantwoord? Dan ben je goed voorbereid op het maken van een keuze uit de volgende scenario’s:

  1. Je laat de nieuwe partij het beheer en de doorontwikkeling van je webapplicatie overnemen;

  2. Je laat de nieuwe partij het beheer en de bugfixing van je webapplicatie overnemen, maar laat geen doorontwikkelingen uitvoeren;

  3. Je laat de nieuwe partij de applicatie opnieuw bouwen, al dan niet met gebruikmaking van bestaande tools en modules;

  4. Je blijft – indien mogelijk of noodzakelijk – toch bij je huidige leverancier.

Bij Netvlies is de eerste screening altijd gratis

Overweeg je om je webapplicatie bij een ander internetbureau onder te brengen? Dan bieden wij je graag kosteloos een eerste screening aan. Wil je dat we met je meedenken over de opties? Neem dan vrijblijvend contact met me op.