Toepassing
Uw software werkt nog. Ze laten evolueren is het probleem.
De applicatie doet nog steeds waarvoor ze gebouwd is. Maar elke wijziging vraagt meer tijd, meer voorzichtigheid, en steunt op steeds minder mensen. De vraag is niet of ze « oud » is: de vraag is wat ze u kost om vooruit te gaan.
Misschien herkent u dit
Zelden klopt alles. Twee of drie van deze punten volstaan om een team blijvend te vertragen.
- Elke wijziging dreigt iets anders te breken, en niemand weet precies wat voor er opgeleverd wordt.
- Sommige technische componenten krijgen geen updates meer, ook geen beveiligingsupdates.
- Een deel van de code wordt niet meer aangeraakt: men werkt eromheen in plaats van erin.
- Releases gebeuren manueel, duren lang en vinden buiten de kantooruren plaats.
- Een functie toevoegen die eenvoudig lijkt, vraagt een onredelijke inspanning.
- De koppelingen met andere tools zijn broos geworden en worden geval per geval hersteld.
- De kennis van het systeem zit bij één of twee mensen.
Wat er gebeurt als u niets doet
Er stort niets in van de ene dag op de andere. Precies daarom is dit zo moeilijk te beslissen.
- De kost van verandering stijgt in stilte
- Elke evolutie vraagt iets meer voorzichtigheid dan de vorige. Het onderhoudsbudget knabbelt aan dat voor nieuwe zaken, zonder dat er ooit een beslissing viel.
- Niet-onderhouden afhankelijkheden worden een beveiligingskwestie
- Een bibliotheek die geen fixes meer krijgt, wordt niet geleidelijk een probleem: ze wordt er een op de dag dat een lek gepubliceerd wordt.
- Het systeem wordt een argument tegen de werking
- Vragen worden geweigerd omdat ze technisch duur zijn, niet omdat ze slecht zijn. De software bepaalt uiteindelijk wat het bedrijf kan doen.
- Het vertrek van één persoon wordt een exploitatierisico
- Wanneer er niets opgeschreven staat, maakt een ontslag of een lange afwezigheid van een gewone wijziging een onderzoeksopdracht.
Herschrijven is niet altijd het antwoord
Vier trajecten zijn verdedigbaar naargelang de situatie. Volledig herschrijven is het meest zichtbare, en zelden het meest verstandige.
| Herschrijven is niet altijd het antwoord | Wanneer het de juiste keuze is | Wat het inhoudt |
|---|---|---|
| Onderhouden | Het systeem beantwoordt nog aan de nood, de verwachte wijzigingen zijn beperkt en het technische risico is beheerst. | Afhankelijkheden bijwerken, het essentiële documenteren, en aanvaarden dat de applicatie geen project is. Dat is een beslissing, geen stilstand. |
| Stapsgewijs moderniseren | Het systeem klopt in de kern nog, maar bepaalde delen zitten in de weg: koppeling, geen tests, manuele uitrol, verouderde interface. | Risicozones isoleren, stabiele interfaces blootstellen, stuk voor stuk vervangen. Oud en nieuw draaien naast elkaar gedurende de hele overgang. |
| Herbouwen | Een fundamentele beperking blokkeert echt: een ongeschikt datamodel, een verlaten platform, een architectuur die verhindert wat het bedrijf vraagt. | Een lang project, met gegevensovername en een periode van dubbel draaien. Alleen te starten met een afgebakende scope en een traject in stappen. |
| Vervangen door een standaardpakket | Het ondersteunde proces is geen onderscheidend voordeel meer en een bestaand product dekt de nood zonder kunstgrepen. | Aanvaarden dat bepaalde gewoonten zich naar het product plooien, en de overname van gegevens en opgebouwde bedrijfsregels ernstig nemen. |
Wij bevelen niet automatisch het zwaarste traject aan. In meerdere situaties is een applicatie nog twee jaar netjes onderhouden de beste economische beslissing.
Oud en nieuw kunnen naast elkaar draaien
Stapsgewijs moderniseren betekent niet één systeem stilleggen en een ander starten. In elke fase draaien beide, en het aandeel dat de oorspronkelijke applicatie draagt, daalt.
- 01
Stabiliseren
Tests, geautomatiseerde uitrol en bewaking opnieuw opzetten. Voor de gebruikers verandert er niets.
- 02
Isoleren
De risicozones afbakenen en de kruisafhankelijkheden doorknippen die elke wijziging globaal maken.
- 03
Blootstellen
De gegevens en de regels achter een stabiele interface zetten, die zowel oud als nieuw kan aanroepen.
- 04
Vervangen
Eén functie tegelijk herbouwen, met een gecontroleerde en omkeerbare omschakeling.
- 05
Verwijderen
De code weghalen die niet meer nodig is. Zolang ze er staat, moet ze onderhouden worden.
De laatste stap wordt het vaakst overgeslagen. Een oude component die « voor het geval dat » blijft staan, blijft kosten in onderhoud en in blootgesteld oppervlak.
Hoe wij het aanpakken
Voor we een traject voorstellen, moet duidelijk zijn wat het systeem werkelijk doet — en dat is bijna nooit wat de documentatie zegt.
- 01
Het bestaande begrijpen
De code lezen, afhankelijkheden in kaart brengen, inventariseren wat draait en wat getest wordt. We spreken ook met gebruikers: sommige bedrijfsregels leven alleen in hun gewoonten.
- 02
De risicozones aanwijzen
Waar een wijziging zich voortplant, welke afhankelijkheden niet meer onderhouden worden, welke delen tests noch documentatie hebben, en waar de kennis geconcentreerd zit.
- 03
Beslissen wat blijft
Niet elk deel van een systeem verdient dezelfde inspanning. Sommige zijn stabiel en goed geschreven: die blijven. Het gesprek gaat over de rest.
- 04
Interfaces en gegevens veiligstellen
Voor er iets vervangen wordt, worden de uitwisselingspunten gestabiliseerd en wordt de werkelijke staat van de gegevens nagegaan: dubbels, velden die voor iets anders gebruikt worden, onvolledige historiek.
- 05
In stappen moderniseren
Eén zone per keer, regelmatig in productie, met een mogelijke terugval. Het systeem blijft de hele tijd bruikbaar.
- 06
De gegevens migreren
De overname wordt vroeg voorbereid, meermaals proefgedraaid en met coherentiecontroles geverifieerd voor de omschakeling. Het is het meest onderschatte deel van zo’n project.
- 07
De overbodige schuld verwijderen
Vervangen componenten, toegangen die niets meer dienen en vergeten omgevingen weghalen. Zonder deze stap voegt modernisering een laag toe in plaats van er een weg te nemen.
Bij een oud systeem verdient de gegevensmigratie vaak een eigen afbakening: daar zitten de verrassingen, niet in de code.
En als niemand de code nog echt kent?
Dat komt vaak voor, en het blokkeert een project niet. Het verandert alleen hoe je begint.
Het draaiende systeem is de referentie
Wat in productie draait, is de betrouwbaarste specificatie die er is. Je observeert het, traceert de aanroepen en reconstrueert het werkelijke gedrag voor je iets aanraakt.
De gegevens vertellen de regels
Een veld dat altijd op dezelfde manier ingevuld is, een waarde die niet zou mogen bestaan, een tabel waarnaar niets meer geschreven wordt: de werkelijke inhoud onthult regels die niemand nog kan uitspreken.
Tests komen vóór wijzigingen
Bij niet-geteste code bestaat de eerste nuttige oplevering vaak uit tests die het huidige gedrag beschrijven — zonder het te corrigeren — zodat het daarna zonder gokwerk gewijzigd kan worden.
Hoe dat er kan uitzien
Enkele vormen die zo’n traject in de praktijk aanneemt, naargelang het vertrekpunt.
- Een geautomatiseerde test- en uitrolketen op een applicatie die met de hand werd opgeleverd
- Een stabiele API voor een oud systeem, zodat andere tools niet meer in de databank grijpen
- Een herbouwde interface op de meest gebruikte schermen, met de rest ongewijzigd
- Een kritieke module geïsoleerd en daarna herschreven, terwijl de rest blijft draaien
- Een gegevensmigratie met coherentiecontroles en proefdraaien voor de omschakeling
- Een afbouwplan voor de vervangen componenten, met hun toegangen en omgevingen
Deze voorbeelden beschrijven mogelijke oplossingsvormen, geen uitgevoerde projecten die als referentie gepresenteerd worden.
Dit traject kan een beroep doen op
Naargelang het vertrekpunt komen één of meerdere van onze domeinen in beeld. De afbakening bepaalt welke.
Veelgestelde vragen
Moet een oude applicatie per se herschreven worden?
Nee, en het is zelden de beste keuze. Volledig herschrijven doet jaren opgebouwde bedrijfsregels verloren gaan, kost veel en levert lang niets bruikbaars op. Meestal is het beter om het deel te isoleren dat werkelijk problemen geeft en dat te vervangen, terwijl de rest blijft draaien.
Kan er gemoderniseerd worden zonder het systeem stil te leggen?
Ja, dat is precies het principe van stapsgewijze modernisering: in elke fase draaien oud en nieuw naast elkaar. Omschakelingen gebeuren functie per functie, met een mogelijke terugval. Het vraagt meer discipline dan een vervanging in één keer, maar het vermijdt dat de werking stilvalt.
Hoe neemt u software over met onvolledige documentatie?
Door te vertrekken van wat draait in plaats van wat geschreven staat. De code lezen, het systeem in productie observeren, de werkelijke gegevens analyseren en met gebruikers spreken reconstrueert het effectieve gedrag. Het resultaat van die fase wordt de documentatie die ontbrak.
Hoe wordt de gegevensmigratie aangepakt?
Als een volwaardig werkpakket, niet als een laatste stap. Dat betekent de werkelijke staat van de gegevens vroeg analyseren, expliciete transformatieregels vastleggen, de migratie zo vaak als nodig proefdraaien, en coherentiecontroles voorzien na de omschakeling. Daar duiken de meeste onaangename verrassingen op.
Hoe lang duurt dat?
Dat hangt volledig af van de omvang van het systeem en van het gekozen traject, en geen van beide is gekend voor de afbakening. Wat we wel kunnen zeggen: stapsgewijze modernisering levert doorlopend bruikbare resultaten, terwijl een herbouw pas op het einde iets oplevert.
Laten we uw applicatie bespreken
Vertel ons wat vandaag vastloopt. We zeggen u eerlijk welk traject ons verstandig lijkt — ook als dat betekent nu geen project te starten.