Categorie: Blog artikelen
Auteur: Ardiles Mozesz, Developer

De juiste applicatie-architectuur

De juiste applicatie-architectuur

Vandaag de dag werken de meeste organisaties binnen IT-projecten volgens de Agile/Scrum-methodiek. Een van de kenmerken hiervan is dat men klein begint en start met het ontwikkelen van een ‘Minimum Viable Product’, afgekort MVP. Hierbij wordt vaak gekozen voor de meest simpele applicatie-architectuur: een monoliet. Het MVP-principe wordt bijvoorbeeld toegepast met slechts één view, één controller en één model. Dat kan wat ons betreft ook zeker, zolang het maar bij die kleine en simpele applicatie blijft.

Kleine applicaties worden groot

Onze ervaring leert echter dat de oorspronkelijk kleine applicatie vaak wordt uitgebreid en vele malen complexer wordt. Zodra een eerste versie van de MVP af is en voor het eerst in gebruik wordt genomen door de business, wordt de meerwaarde van de applicatie pas echt duidelijk. De businessanalisten gaan vervolgens verder aan de slag om de betreffende bedrijfsprocessen te optimaliseren.

Het gevolg is dat de omvang en complexiteit van de applicatie zal toenemen. En doordat de business juist die meerwaarde ziet, zal ook de druk op de productowner en het ontwikkelteam toenemen. In veel gevallen zal men zich gaan focussen op het zo snel mogelijk doorontwikkelen van de applicatie en live brengen van nieuwe features.

Verhogen van de ontwikkelcapaciteit

Om nog sneller nieuwe features te ontwikkelen kan de organisatie een aantal maatregelen treffen. Zo kan het ontwikkelteam worden uitgebreid met extra software-ontwikkelaars. Dat gaat in het begin vaak goed, maar op een gegeven moment bereikt het ontwikkelteam de maximale velocity. Doordat de omvang en complexiteit van de applicatie steeds groter wordt, ontstaan er ook steeds meer afhankelijkheden tussen verschillende stukken code. Hierdoor wordt het voor de ontwikkelaar een grotere uitdaging om bestaande functionaliteiten aan te passen en eventuele nieuwe functionaliteiten toe te voegen.

In de praktijk zien we dat de bestaande functionaliteit eerder omvalt, maar ook dat nieuwe ontwikkelaars steeds meer inwerktijd nodig hebben voordat ze überhaupt een letter code kunnen schrijven. ‘Dan maar een extra ontwikkelteam erbij’, wordt dan wel eens gezegd. Dat maakt het project echter nog complexer, aangezien we allemaal in dezelfde stukken code werken.

Dat is het moment dat we zeggen dat de basis van de applicatie, de applicatie-architectuur, niet meer voldoet.

Van een monoliet naar een modulair design

Het wijzigen van de applicatie-architectuur naar een modulair design biedt onder andere uitkomst voor de problemen die we hierboven beschreven. Hiervoor dient de basis van de applicatie aangepast te worden, maar dit heeft impact op de bestaande code. Overweeg tijdig of de applicatie-architectuur nog voldoet, want hoe langer je wacht, des te groter de impact op het omschrijven van de bestaande applicatie architectuur.

Maar wat houdt een modulair design in?

Een modulair applicatie-architectuurontwerp houdt in dat een applicatie opgedeeld wordt in kleinere modules. Hierin heeft iedere module een logische functie en een eigen verantwoordelijkheid, met als doel dat elke module zijn taak apart kan uitvoeren. Een combinatie van de modules vormt de uiteindelijke applicatie. Dit brengt een aantal voordelen met zich mee die we hieronder aan de hand van voorbeelden kort uitleggen.

1. Verlagen van de complexiteit

Een complex stuk code kan opgedeeld worden in kleinere, afzonderlijke en meer eenvoudige taken. Hierdoor wordt de complexiteit van de totale applicatie verlaagd.

2. Opschalen in ontwikkelcapaciteit

Het is eenvoudiger om de ontwikkelcapaciteit op te schalen. Meerdere ontwikkelaars / teams kunnen op hetzelfde moment aan één programma werken. Iedere ontwikkelaar kan aan een aparte module werken zonder dat men diepgaande kennis nodig heeft van de overige modules.

3. Een verlaagde inwerktijd

De inwerktijd van een ontwikkelaar wordt verlaagd. De ontwikkelaar kan zich focussen op een specifiek deel van de applicatie, in plaats van op de volledige applicatie. Dit kan doordat de applicatie is opgesplitst in meerdere modules.

Changes op bestaande functionaliteit, maar ook nieuwe functionaliteit, zijn hierdoor sneller en makkelijker te implementeren.

4. Analyseren van issues

Issues in de programmatuur zijn makkelijker te analyseren en te fixen. De oplostijd van bugfixes wordt hierdoor verkort. Daarnaast kunnen issues die bijvoorbeeld betrekking hebben op de performance makkelijker en sneller geanalyseerd worden. Dit omdat de focus slechts op een gedeelte van de volledige applicatie ligt.

5. Herbruikbaarheid van modules

Modules zijn herbruikbaar waardoor je niet twee keer hetzelfde hoeft te bouwen en te onderhouden. Het is bijvoorbeeld mogelijk om modules van een programma te gebruiken in een ander programma zonder dat er aan deze modules iets veranderd hoeft te worden.

6. Beter beheersbaar

Het refactoren van de code wordt beter beheersbaar. Neem bijvoorbeeld een library die gebuikt wordt door de gehele applicatie en geüpgraded moet worden. Men heeft hierin de keuze om per component wel of niet te upgraden. Op deze manier kan men per component afwegen hoeveel moeite het kost en wat het uiteindelijk gaat opleveren.

Waar moet je verder rekening mee houden?

Ten opzichte van een monoliete applicatie-architectuur kost het bij een modulair applicatie-architectuurontwerp initieel meer tijd om een basis neer te zetten voor een applicatie. Wat voor de ontwikkelaars dan vooral van belang is, is dat ze gevoel krijgen waar de applicatie ongeveer naartoe gaat. Hierbij is het de taak van de productowner om de wensen van de business op korte en lange termijn goed in kaart te brengen.

Zodra er meerdere ontwikkelaars aan verschillende modules gaan werken voor dezelfde applicatie, is goede coördinatie en communicatie tussen de ontwikkelaars van belang. Ondanks dat modules onafhankelijk van elkaar ontwikkeld worden, zijn er indirect afhankelijkheden zoals onder andere api’s, migraties, releaseplanningen en functionele koppelingen.

Aangezien het ontwikkelproces vaak een technisch feestje is van de ontwikkelaars, is het ook van belang dat de productowner en business regelmatig en goed geïnformeerd worden door de ontwikkelaars.

Een modulaire applicatie-architectuur kan voor een simpele kleine applicatie overkill zijn. We adviseren daarom ook om deze architectuur vooral toe te passen bij de meer complexe en grotere applicaties en/of meer bedrijfskritische applicaties. Voor een goede afweging komt aardig wat kennis, kunde en ervaring kijken. Schakel daarom altijd een ervaren expert in die een concreet advies kan geven dat past bij jouw organisatie.

Specifiekere vragen?

Vul uw e-mailadres in en Oliver IT neemt zo spoedig mogelijk contact met u op!

Gelukt! We nemen spoedig contact met u op!
Eddy Driessen Consultant
Eddy Driessen