De uitdagingen van Middleware ontwikkeling

Middleware ontwikkeling
auteur

Ellen Van Hees

gepubliceerd

22/09/2021

Delen



Reading Time: 4 minutes

Middleware vindt langzaamaan zijn eigen plaatsje in de softwarewereld. In absolute lekentaal is Middleware de “boodschapper” tussen applicaties. Middleware draagt informatie, gegevens en diensten over tussen softwaresystemen, bijvoorbeeld tussen een backend systeem (waar de data wordt opgeslagen) en een frontend-systeem (dit is de applicatie die de softwaregebruiker ziet).

Er bestaan ook veel complexere scenario’s, waar verschillende backend systemen communiceren met meerdere systemen, zowel richting frontend als richting backend. Bijkomende moeilijkheden ontstaan wanneer ontwikkelingen gelijktijdig gedaan worden door externe partners in front- of backend.

Deze blog is gericht op de meer complexe situaties. Er zijn enkele klassieke problemen bij het managen van complexere Middleware-projecten. Het doel van deze blog is om enkele tips & tricks op te lijsten om de meest voorkomende valkuilen te vermijden. Maar vooraleer we in de diepte duiken, zoomen we in op de 3 belangrijkste uitdagingen van Middleware-projecten.

Afhankelijkheden

Bij het ontwikkelen van Middleware ben je per definitie verplicht om te interageren tussen verschillende systemen. Er ontstaan extra moeilijkheden wanneer er meerdere systemen betrokken zijn bij het project en er ook ontwikkelingen nodig zijn van externe partners. 

“MVP? Welke MVP?”

Het Minimal Viable Product kan meestal niet op Middleware-niveau gedefinieerd worden, maar ligt eerder op frontend-niveau. Middleware moet nog steeds alle informatie die nodig is tussen verschillende partijen communiceren, zonder enige ruimte voor een MVP. Oftewel: op een agile manier anticiperen op de MVP van de frontend.

Planning

In een perfecte wereld zijn mogelijke backend ontwikkelingen afgerond en getest wanneer de Middlewaresoftware wordt ontwikkeld. Nadien kan de frontend ontwikkeld worden op de gevalideerde Middleware. Maar in realiteit kunnen ontwikkelingen tussen verschillende partijen samenvallen. Daarom moet er meteen bij de planning rekening worden gehouden met eventuele aanpassingen aan één van de componenten die door andere partijen worden gebruikt.

Let wel: dit is verre van een pleidooi voor waterfall ontwikkeling! Rework op nieuw ontwikkelde code is steeds te voorzien, zeker aangezien het wellicht de eerste keer is dat de code daadwerkelijk wordt gebruikt.

Tips & tricks bij Middleware ontwikkeling

Nu de belangrijkste uitdagingen helder zijn, kan ik jullie enkele handvaten meegeven om veelvoorkomende valkuilen te vermijden.

Open communicatie

Communiceer open met interne stakeholders, maar zeker ook met externe partners. Zorg dat je op de hoogte bent van de sprintdoelen en geplande leveringen van andere teams. Neem indien mogelijk deel aan hun demo’s. Dit stelt je in staat om alvast tijd in te plannen voor rework voordat dit daadwerkelijk gevraagd wordt.

Bovendien zal niet alle informatie onmiddellijk beschikbaar zijn. Maar op zich vormt dat geen probleem. Zorg ervoor dat je een uiterste datum communiceert waarop informatie ten laatste beschikbaar moet zijn. Ik gebruik hiervoor backward planning en zet een specifieke milestone in de planning op het moment dat de volledige informatie compleet moet zijn. Als deze datum niet wordt gehaald, houdt dit noodzakelijkerwijs een vertraging in. Het is regelmatig nuttig gebleken om deze informatie direct beschikbaar te hebben tijdens status meetings!

Plan risico’s en afhankelijkheden in

De daadwerkelijke development tijd voor een specifieke ontwikkeling wordt niet noodzakelijkerwijs gewijzigd door vertragingen en/of rework van derden, maar de leveringsdatum van de Middleware ontwikkeling zal wel worden beïnvloed. Neem dit ineens mee in de planning door rekening te houden met een langere doorlooptijd van de ontwikkeling.

Mijn meest succesvolle Middleware-project was er één waar er veel afhankelijkheden waren met externe partners. Dit kwam omdat we zicht hadden op wat de inhoud van de sprint precies was voor de andere (externe) teams. Ook al waren hun sprints niet gesynchroniseerd met de onze, we hadden in onze sprints tijd ingepland voor ondersteuning/rework aan de ontwikkelingen die ze voor het eerst gebruikten in hun respectievelijke sprints.

First Time Right

Lever kwaliteit vanaf het begin. Voor Middleware ontwikkeling betekent dit het toevoegen van geautomatiseerde tests, inclusief controles op response bodies. Het kan zo simpel zijn als het opzetten van een Postman Collectie die is geïntegreerd in de delivery pipeline. Mislukte tests = geen deployment. Dit betekent dat de beschikbare (handmatige) testcapaciteit kan worden geoptimaliseerd en ingezet waar deze het meest nodig is.

Zorg dat je vroege feedback krijgt

Het is belangrijk dat je in een vroeg stadium feedback krijgt, zodat rework in een later stadium zoveel mogelijk kan worden vermeden. Zorg ervoor dat je al input krijgt van de consumers op het API-ontwerp, voordat er begonnen wordt met de daadwerkelijke ontwikkeling van de API-implementatie. Deze vroege validatie zal het leven nadien een stuk gemakkelijker maken.

CONCLUSIE

Zelfs met de uitdagingen en afhankelijkheden die erbij horen, is het managen van een Middleware-project geen verloren strijd! Het is perfect haalbaar om onzekerheden in te plannen en rekening te houden met externe factoren die je zelf niet in de hand hebt.

De typische risico’s en afhankelijkheden die bestaan ​​bij het ontwikkelen van Middleware kunnen worden gepland. Met een sterke focus op kwaliteit en het gebruik van de First Time Right-aanpak kun je veel efficiëntie winnen. Blijf steeds communiceren met de stakeholders en de ontwikkelingspartners – hierdoor blijf je gespaard van vervelende verrassingen achteraf!

Als je wilt werken met een team dat zich bewust is van de uitdagingen van Middleware ontwikkeling en ervaren is in het beperken van de risico’s, neem dan zeker contact op met Codrigo. Wij helpen je graag verder!

Interesse in onze aanpak?

Contacteer ons

Wil je deel uitmaken van ons team?