Efficiënt werken aan uiteenlopende projecten

Om dit te bereiken, hebben we eerder een aantal standaard componenten, libraries en andere bouwblokken geïntroduceerd middels eigen Nuget packages. De visie was het zo veel mogelijk inzetten van deze componenten zodat de opstarttijd van een project verlaagd wordt en de context switch eenvoudiger werd. Helaas is in de loop van de tijd gebleken dat het erg lastig was om deze voor ieder project in te zetten, wegens de uiteenlopende casussen waar we mee werken. De componenten waren nuttig en bruikbaar, maar er is vaak per individueel project een laag omheen gezet om hierin te faciliteren. Omdat een standaard-component hiermee al snel een klant-specifiek component wordt, neemt de toegevoegde waarde van de standaardcomponenten al snel af. 

Meer recent zijn we begonnen met een nieuwer concept: Een basis-referentiearchitectuur met losse beschikbare bouwblokken er bovenop. Deze bouwblokken zijn echter niet gebundeld in een NuGet package, maar beschikbaar als losse files of file-bundels, al dan niet via templates. 

In de praktijk blijkt dat we met deze aanpak het gros van onze projecten kunnen bedienen en wél volgens een standaard kunnen laten verlopen. Wij bouwen veel webapplicaties die vrijwel uitsluitend zijn opgebouwd met Blazor. In basis dekt de ontworpen architectuur dus deze use-case af. Het is echter eenvoudig hier componenten aan toe te voegen en/of uit te halen. Deze kunnen via handig gebruik van een aantal kernprincipes van software development praktisch in of uit de logische kern van de applicatie “geplugd” worden.

Het grote voordeel van deze referentiearchitectuur is dat een developer weinig tijd nodig heeft om te begrijpen waar deze moet zoeken voor specifieke logica. Databasehandelingen bevinden zich altijd binnen project A, mutaties gebeuren altijd binnen project B, verbinding met een service in Azure gebeurt binnen project C, enzovoorts. Het enige wat een developer nodig heeft om te kunnen beginnen of bijspringen, is een kleine inleiding met wat de functie is van de projectonderdelen welke van de referentiearchitectuur afwijken, en enige context van de klant. 

Een ander bijkomend voordeel met deze aanpak is dat we meer grip hebben op de codekwaliteit en hierbij ook een eenduidige aanpak hanteren. De architectuur is goed uitgedacht, meerdere developers hebben er verbeteringen op doorgevoerd en het moedigt aan om functionaliteit in kleine, geisoleerde blokken op te leveren. Een starter of junior developer kan eenvoudig “afkijken” bij een ander project om te zien hoe het in de basis werkt, en zal hierdoor sneller de juiste keuzes en afwegingen maken.

Naast de referentiearchitectuur bouwen we natuurlijk ook koppelingen met externe services. Dit kunnen services van klanten of gelieerde partijen zijn, maar ook specifieke services vanuit de Azure cloud. Vaak blijkt dat bij een goede opzet van communicatie richting Azure services, deze koppelingen zeer generiek herbruikbaar zijn. Wanneer we een dergelijke koppeling maken, zetten we deze zo generiek mogelijk op. Het doel hiervan is dat we deze stukken functionaliteit kunnen isoleren in een bouwblok, en deze borgen in de collectie. Zo hoeven we bijvoorbeeld niet voor ieder project opnieuw een koppeling met een mailservice te bouwen.

Bron: researchgate.net

Neem bovenstaande afbeelding als voorbeeld. Door een herbruikbaar basiscomponent te realiseren voor bijvoorbeeld Analytics, kunnen we simpelweg het analytics project importeren, de interfaces (zwarte bolletje) in de kern van de applicatie plaatsen en het geheel werkt direct. Daarna kan de developer het nodige bijstellen aan de hand van de klantbehoefte en realiseren we snel een nieuwe functionaliteit op een standaard manier.

Het grootste voordeel van het gebruik van dit model is dat we zelf onder controle houden welke projecten met welke versie van de bouwblokken werken, en dat een incrementele verbetering met breaking changes voor een eerdere niet hoeft te voorkomen dat we niet eenvoudig kunnen updaten. Door het gebruik van geïsoleerde stukken functionaliteit met interfaces, weten we exact wat een nieuwe versie van een bouwblok zal doen met bestaande klanten.

In de kern hebben we hiermee een mooie stap gezet richting het onderhoudbaar en efficiënt opzetten van onze projecten voor zowel de klant als onze developers. De komende jaren zullen we continue evalueren en hieraan doorontwikkelen, zodat we zo veel mogelijk up-to-date blijven met de marktontwikkelingen en nieuwe technologieën binnen het domein. Op deze wijze streven we naar een snellere doorlooptijd, een verbetering in onze dienstverlening en een hogere kwaliteit software.