Software in beheer nemen

Beheer komt op twee momenten in beeld. Het eerste: u heeft iets laten bouwen, het is opgeleverd en het werkt, en vanaf nu moet iemand zorgen dat het blijft werken. Het tweede: er draait al jaren een applicatie bij een andere partij en die moet ergens anders worden ondergebracht, omdat de samenwerking stroef loopt, omdat de bouwer stopt, of omdat u een bedrijf overnam en de software erbij kreeg.

De vraag is identiek: wat moet er geregeld zijn voordat een ander de verantwoordelijkheid kan dragen? Het gaat mis op hetzelfde punt. De aandacht gaat naar wie het beheer doet en wat dat kost, terwijl het echte risico zit in wat er wel en niet wordt overgedragen.

U kunt de complete broncode ontvangen en er alsnog niets mee kunnen. Dat is de normale uitkomst zodra een overdracht wordt opgevat als het delen van een repository. U heeft de code plus de omgeving plus de kennis nodig, en die laatste twee zitten niet in de map die u krijgt.

Begin bij de omgeving. Een applicatie draait op instellingen, sleutels en certificaten die bewust buiten de code zijn gehouden, omdat geheimen niet in een repository horen. Zonder die waarden start het geheel niet, en uit de code valt niet af te leiden welke ze waren. De bouw- en uitrolprocedure bestaat vaak alleen als configuratie in een pipeline onder het account van de oude partij, of als handeling die één ontwikkelaar uit zijn hoofd doet. En code plus een lege database is niet dezelfde applicatie.

Dan de externe diensten: accounts voor mailverzending, betalingen, opslag, kaartmateriaal en foutmonitoring, elk met een eigenaar en een abonnement. Staan die op naam van de bouwer, dan valt uw applicatie stil zodra die relatie eindigt, hoeveel code u ook bezit. Bij mobiele apps geldt dat scherper: publiceren kan alleen vanuit het ontwikkelaarsaccount waaronder de app staat, en verplaatsen naar een ander account is een aparte procedure met eigen voorwaarden.

Blijft over wat niemand opschrijft: het periodieke werk en de kennis. Certificaten verlopen, sleutels moeten vernieuwd, afhankelijkheden bijgewerkt. En iemand wist welke onderdelen fragiel zijn en welke tijdelijke oplossing er nooit is opgeruimd. Wie de rechten op de code heeft is bovendien een juridische vraag die losstaat van wat u feitelijk in handen krijgt; die kant staat in eigendom en overdracht van broncode.

Behandel de overdracht als een levering met een paklijst, niet als een verzoek om de code op te sturen.

Elk ontbrekend punt is een openstaande post: vraag wie hem oplost, wanneer en op wiens rekening. Een back-upprocedure die nooit is teruggezet telt niet als afgevinkt.

Technisch beheer

Draait het, is het bereikbaar, worden beveiligingsupdates uitgevoerd, zijn de back-ups getest. De onzichtbare laag die pas opvalt als hij ontbreekt.

Applicatiebeheer

De applicatie zelf onderhouden: koppelingen die van gedrag veranderen, releases testen, storingen onderzoeken, kleine wijzigingen doorvoeren.

Functioneel beheer

Beslissen wat er wel en niet verandert, gebruikersvragen beantwoorden, rechten uitdelen, wensen prioriteren. Een rol bij de opdrachtgever, niet bij de bouwer.

De eerste twee koopt u in. De derde niet, en daar loopt het vast. Functioneel beheer vraagt iemand die zowel de applicatie als de organisatie kent en het mandaat heeft om te beslissen. Geen volledige functie noodzakelijk, wel een aangewezen persoon met tijd in zijn agenda.

Ontbreekt die rol, dan gebeurt er iets voorspelbaars. Elke gebruikersvraag, elk verzoek om een extra veld en elk nieuw account gaat rechtstreeks naar de leverancier, die dat afhandelt tegen leverancierstarief. Niemand bundelt vragen, niemand beoordeelt of de wens van één afdeling goed uitpakt voor de rest, niemand zegt "later". De leverancier vult dat gat vanzelf en bepaalt zo de richting van uw applicatie. Uw beheerfactuur bestaat dan grotendeels uit werk dat intern beantwoord had kunnen worden; hoe die posten zich verhouden staat in wat beheer en onderhoud werkelijk kosten.

De verleiding is groot om een datum te prikken: tot hier de oude partij, vanaf daar de nieuwe. Dat breekt vrijwel altijd op hetzelfde punt. De kennis die ontbreekt laat zich pas zien wanneer er iets misgaat, en dat gebeurt niet in de week van de overdracht: een nachtelijke taak die stil faalt, een koppeling die anders reageert na een update aan de andere kant, een certificaat dat verloopt op een zaterdag.

Spreek daarom een periode af waarin de oude partij bereikbaar blijft, in een vorm die vastligt: bij wie u aanklopt, binnen welke termijn antwoord komt en tegen welke vergoeding. Zonder afspraak is bereikbaarheid een gunst, en gunsten verdampen.

Het belangrijkste gaat over volgorde: regel de overdracht voordat u opzegt. Daarna heeft de vertrekkende partij geen commercieel belang meer bij zorgvuldigheid, meestal geen onwil maar prioritering. Het beste moment om overdrachtseisen vast te leggen is bij het aangaan van de opdracht, wanneer beide partijen nog graag tekenen. Wat u daarin kunt opnemen staat in van softwarebureau wisselen; laat een jurist meekijken op de formulering die in uw contract belandt.

Zet de lat op de juiste plek: een overdracht is pas geslaagd wanneer de nieuwe partij zelfstandig een wijziging live heeft gezet, niet wanneer de documenten binnen zijn.

Dit is de uitkomst die zelden hardop wordt gezegd: een slecht gedocumenteerde applicatie waar niemand meer bij betrokken is, kan duurder zijn om over te nemen dan om opnieuw te bouwen. Elke wijziging begint dan met uitzoeken hoe het in elkaar zit, en dat uitzoekwerk betaalt u telkens opnieuw.

U wilt dat weten voordat u toezegt. Spreek daarom een verkenning af die u apart afrekent, met als voorwaarde dat het resultaat van u is, ook als u afhaakt. Twee proeven zeggen het meeste. De opzetproef: laat de kandidaat-beheerder de applicatie vanaf nul draaiend krijgen met alleen het overdrachtsdossier en zonder de oude bouwer te bellen. Lukt dat niet met redelijke inspanning, dan is er geen overdraagbaar systeem, alleen een draaiende server. De wijzigingsproef: laat één kleine, echte aanpassing uitrollen. Wat die kost voorspelt wat elke volgende aanpassing gaat kosten.

Let daarnaast op signalen die zwaarder wegen dan documentatie: geen enkele geautomatiseerde test, waardoor niemand meer durft te wijzigen; een framework- of runtimeversie zonder beveiligingsupdates, waardoor vervanging sowieso op de rol staat; uitrollen door met de hand bestanden op een server te zetten; geen scheiding tussen testomgeving en productie.

Wees ten slotte alert op wie het oordeel geeft. De partij die u vraagt of overnemen verstandig is, heeft belang bij het antwoord dat herbouw beter is: een groter en beter betaald project dan beheer. Vraag om een onderbouwing met aanwijsbare onderdelen, niet om een kwalificatie als "verouderd", en vraag wat er wel te redden valt. Datamodel, integraties en bedrijfslogica overleven een herbouw vaker dan de schil eromheen.

• Wat kost onderhoud van software?
• Van softwarebureau wisselen
• Eigendom en overdracht van broncode
• Software die niemand gebruikt