Bij de start van een opdracht hoor je verschillende verhalen. Er wordt nieuwe software gebouwd, de uitrol komt dichterbij en de bestaande infrastructuur zou voldoende zijn. Iedereen heeft een beeld van de situatie. Maar hebben we ook hetzelfde beeld?
In mijn werk als technisch applicatiebeheerder ervaar ik regelmatig hoe belangrijk die vraag is. Een situatie rond de voorbereiding van een nieuwe applicatie maakte dat voor mij duidelijk.
Een overdracht met losse eindjes
Toen ik bij deze opdracht begon, was mijn voorganger al vertrokken. In gesprekken werd zijn manier van communiceren als een knelpunt genoemd. Tegelijkertijd hoorde ik dat het ontwikkelteam aan nieuwe software werkte en dat men die binnenkort wilde uitrollen.
Ik wilde begrijpen wat er al was voorbereid. Daarom zocht ik naar de documentatie die mijn voorganger had achtergelaten. Daarin vond ik veel technische informatie. Hij had al een beeld gevormd van wat er gebouwd moest worden en had ook servers aangevraagd. Die aanvragen hadden nog niet tot de benodigde inrichting geleid.
Dat riep vragen op. Welke uitgangspunten lagen onder zijn voorbereiding? Waren die nog steeds geldig? En hoe verhouden die zich tot het idee dat de huidige omgeving voldoende zou zijn?
Iedereen kent een deel van het verhaal
De beheerder van de bestaande applicatie ging ervan uit dat de situatie onder controle was. Vanuit meerdere kanten hoorde ik dat we de nieuwe software op de huidige infrastructuur konden laten werken.
Ik sprak ook uitgebreid met de scrummaster om de bedoeling van de verandering te begrijpen. Wat gingen we opleveren? Hoe zouden we testen? En hoe moest de nieuwe software naast de bestaande applicatie functioneren?
Die gesprekken hielpen, maar het beeld bleef onvolledig. Ik kon nog niet goed vaststellen wat er voor de inrichting van de infrastructuur van mij werd verwacht.
Dat is een herkenbare uitdaging bij applicatiebeheer. Het ontwikkelteam kijkt naar de nieuwe software, de beheerder kent de bestaande omgeving en de scrummaster heeft zicht op het werk en de planning. Om een verandering uitvoerbaar te maken, moeten die perspectieven bij elkaar komen.
De databasekeuze bracht samenhang
Tijdens mijn verdere zoektocht vond ik in de documentatie een passage over de database. De bestaande applicatie gebruikte Oracle. Voor de nieuwe situatie werd PostgreSQL genoemd.
Ik besloot daar gericht op door te vragen. Was de overstap naar PostgreSQL daadwerkelijk onderdeel van de verandering? Toen dat werd bevestigd, vielen voor mij de puzzelstukken op hun plaats.
Ik begreep beter waar mijn voorganger naartoe had gewerkt en waarom hij infrastructuur had aangevraagd. Ook werd duidelijker wat het ontwikkelteam nodig had en welke voorbereiding bij mijn rol hoorde.
De uitspraak dat de huidige infrastructuur voldoende was, moest dus worden bekeken in het licht van die databaseverandering. Om dat te beoordelen, hadden we een concreet beeld nodig van de nieuwe omgeving en van de manier waarop we naast de bestaande applicatie zouden testen.
Doorvragen maakt verwachtingen concreet
Mijn bijdrage begon hier met zoeken, luisteren en doorvragen. Ik legde informatie uit documenten naast de beelden die in gesprekken naar voren kwamen. Waar die niet op elkaar aansloten, stelde ik aanvullende vragen.
Juist de vraag hoe we de nieuwe software naast de oude zouden testen, hielp om algemene verwachtingen concreter te maken. “Het kan op de huidige omgeving” geeft pas richting als duidelijk is welke componenten nodig zijn en wat er verandert.
Voor mij is dat een belangrijk onderdeel van technisch applicatiebeheer: voldoende samenhang creëren om technische keuzes te kunnen onderbouwen en het werk gericht voor te bereiden.
Deze ervaring leerde mij ook om voorzichtig te zijn met het beeld dat bij een overdracht wordt meegegeven. De documentatie van mijn voorganger bevatte waardevolle voorbereiding. Ik kon pas begrijpen wat die betekende toen ik haar verbond met de bedoeling van het ontwikkelteam.
Van inzicht naar een gedeeld beeld
Toen de samenhang duidelijk werd, maakte ik direct een migratietekening. Daarmee bracht ik de overgang van de bestaande naar de nieuwe situatie visueel in kaart. De tekening was een werkdocument: zodra er nieuwe informatie bij kwam, kon ik het beeld bijwerken.
Ik besprak de tekening met de scrummaster, zodat zij ook kon zien welke onderdelen met elkaar verbonden waren en welke afhankelijkheden een rol speelden. Zo maakte ik mijn technische inzicht toegankelijk voor iemand die vanuit een andere rol bij de verandering betrokken was.
Voor mij is dat de waarde van applicatiebeheer als informatieknooppunt. Je verzamelt informatie uit gesprekken en documentatie, onderzoekt de samenhang en maakt die zichtbaar en bespreekbaar. In deze situatie hielp dat mij om te begrijpen welke infrastructuur nodig was en om de scrummaster mee te nemen in de afhankelijkheden achter de verandering.