In 2025 kwam ik in een opdracht terecht waarin twee applicaties centraal stonden: “Shoppy”, een moderne webapplicatie, en “Harvester”, een strategische cloudapplicatie met een global scope. Binnen één jaar groeide ik van Software Developer naar de facto architect voor beide applicaties. In deze blog beschrijf ik hoe die ontwikkeling tot stand kwam, welke uitdagingen ik tegenkwam en welke keuzes daarbij bepalend waren.
Een nieuw team, twee focusgebieden
Per 1 januari 2025 werd mijn team “Integrations” samengevoegd met een deel van een ander team dat de voorloper van “Harvester” had gebouwd. Het nieuwe team kreeg drie verantwoordelijkheden:
- het bouwen van “Shoppy”, een moderne webapplicatie
- het bouwen van “Harvester”, een strategische global cloudapplicatie
- het onderhouden van de bestaande Integrations‑applicaties
Hoewel we formeel één team waren, ontstonden er twee duidelijke focusgroepen: Shoppy en Harvester.
De Team Lead kwam uit het oude Harvester‑team en had vooral ervaring met de on‑premise voorganger.
Mijn initiële rol: volledig op Harvester
Omdat Harvester een strategische en technisch uitdagende applicatie zou worden, koos ik ervoor om in dat focusgebied te starten.
In deze periode werden vooral nog requirements opgehaald en discussies gevoerd. Daarom focuste ik me voornamelijk op het onderhoud van de oude Integrations‑applicaties en inspecteerde ik de code van de oude Harvester‑applicatie.
Het oorspronkelijke plan was om deze applicatie “naar de cloud te tillen”. Al snel werd duidelijk dat dit niet haalbaar was vanwege:
- .NET Framework
- On‑premise architectuur
- Geen tests
- Geen SOLID‑principes
- Geen abstrahering
- Ontwerpfilosofie niet geschikt voor cloud
Op basis hiervan ben ik de PO (Product Owner), IT‑Manager en teamleden van deze opdrachtgever gaan meenemen in de conclusie dat een herbouw noodzakelijk was.
Teamwissel: van Harvester naar Shoppy
In dezelfde periode werd duidelijk dat een collega niet goed paste binnen het Shoppy‑team. Er werd besloten dat hij en ik van team zouden wisselen. Vanaf dat moment werkte ik aan Shoppy, terwijl hij naar Harvester ging. Wel wilde ik graag op de hoogte blijven van de voortgang bij Harvester.
Doordat beide teams fysiek naast elkaar zaten en ik regelmatig sprak met de gewisselde collega, bleef ik nauw betrokken bij de discussies rondom Harvester. Dat zorgde ervoor dat ik zicht hield op de technische uitdagingen en de architectuurkeuzes die daar gemaakt moesten worden.
Kennisgaten en architectuuruitdagingen
Bij beide focus teams viel op dat er aanzienlijke kennisgaten waren op het gebied van:
- Moderne softwarearchitectuur
- Cloudconcepten
- Global applicatie‑design
- Lange‑termijn onderhoudbaarheid
Daarnaast was er in de eerste maanden nog geen duidelijkheid over de cloudkeuze. Azure leek onwaarschijnlijk, AWS was een goede kanshebber. De formele duidelijkheid: “Azure, maar cloud‑agnostisch” kwam pas later, maar de onzekerheid over de uiteindelijke cloud maakte het wel verstandig om hier alvast rekening mee te houden. Ook voor het team gaf deze onzekerheid een hoop stress, terwijl het eigenlijk benadrukte dat we zowel qua ontwikkeling als architectuur moesten richten op een cloud onafhankelijk design.
Architectuurkeuzes: eerste ontwerp voor Shoppy en de overstap naar Container Apps
Omdat het Shoppy‑team qua ontwikkeling voorliep op Harvester, moest voor Shoppy als eerste een cloudarchitectuur worden bepaald. De DevOps Engineer en de afdelingsarchitect hadden hiervoor een eerste ontwerp opgesteld, gebaseerd op technologieën zoals Azure Function Apps en Azure Web Apps. Dit was een logische keuze binnen Azure en sloot goed aan bij de behoeften van Shoppy.
Op dat moment gold de eis voor cloud‑agnostisch ontwerpen nog niet voor Shoppy. Voor Harvester was dit formeel ook nog niet vastgesteld, maar er werd wel serieus rekening gehouden met een mogelijke landing op AWS.
Een belangrijk uitgangspunt binnen het team was dat Shoppy en Harvester qua architectuur en ontwerp zoveel mogelijk op elkaar moesten lijken. Dit moest de uitwisselbaarheid van teamleden vergroten en voorkomen dat er twee volledig verschillende technische landschappen zouden ontstaan.
Met die synergie‑wens in het achterhoofd én de onzekerheid over de cloudkeuze voor Harvester, vond ik het verstandig om een technologie te kiezen die:
- Zowel op Azure als AWS goed ondersteund wordt.
- Flexibel en toekomstbestendig is.
- Een uniforme technische basis biedt voor beide applicaties.
Daarom heb ik voorgesteld om te werken met:
- Azure Container Apps
- Container Jobs
Containers worden door zowel Azure als AWS uitstekend ondersteund, wat de kans op toekomstige migratie aanzienlijk verkleint. Deze keuze bood bovendien een consistente basis voor beide applicaties.
Ik heb deze keuzes toegelicht in presentaties en vastgelegd in ADR’s, waarna ik steeds vaker betrokken werd bij architectuurdiscussies.
Architectuursessies Harvester: versnellen door structuur
Toen ik aanschoof bij de architectuursessies van Harvester, viel op dat beslissingen moeizaam tot stand kwamen. De kennis ontbrak, discussies liepen vast en er werd te veel in volledige teamsetting besproken.
Door consequent moderne cloudprincipes toe te lichten, ontstond langzaam meer begrip. De Team Lead begon mij steeds vaker om advies te vragen.
In de zomer heb ik voorgesteld om de architectuur met een klein comité uit te werken en deze vervolgens aan het team te presenteren. Dit zorgde voor:
- Meer snelheid
- Duidelijkere besluitvorming
- Minder ruis
- Betere aansluiting op de strategische eisen
De Team Lead kon zich hierdoor richten op zijn nieuwe rol als Business Analist en ik nam de technische verantwoordelijkheid op me.
Vanaf dat moment was ik de facto Architect voor zowel Shoppy als Harvester.
Waardoor is deze rolverschuiving nou ontstaan?
Terugkijkend realiseer ik me dat mijn groei in deze opdracht vooral voortkwam uit de manier waarop ik werk. Ik kijk van nature verder dan mijn eigen taak en probeer te begrijpen wat een team of project écht nodig heeft om vooruit te komen. In deze opdracht merkte ik al snel dat er behoefte was aan richting en duidelijkheid, zowel technisch als organisatorisch.
Omdat die sturing essentieel was om verder te komen, heb ik die verantwoordelijkheid opgepakt, ook zonder dat iemand dat expliciet vroeg. Ik heb structuur aangebracht, keuzes onderbouwd en collega’s meegenomen in moderne architectuurprincipes. Door dat consequent te doen, ontstond de architectuurrol eigenlijk vanzelf.
Deze opdracht heeft me laten zien dat groei niet altijd voortkomt uit formele titels, maar uit gedrag. Door verantwoordelijkheid te nemen voor het geheel, niet alleen voor mijn eigen onderdeel, werd ik vanzelf de persoon waar het team op kon bouwen.
.png?width=450&height=450&mode=crop)