Iedere ontwikkelaar heeft in zijn loopbaan wel zo’n systeem gemaakt. Een systeem dat alles kan! Het systeem is zo flexibel door de configuratiemogelijkheden en kan hierdoor alle toekomstdromen realiseren.
De oorsprong van een dergelijk systeem is als volgt. Er is een bepaald probleem dat opgelost moet worden met een nieuw te ontwikkelen systeem, maar omdat het systeem toekomstige wijzigingen moet kunnen opvangen is het generiek opgezet. Er zijn allerlei configuratieinstellingen waarbij soms de configuratie opnieuw gegenereerd of geconfigureerd moet worden. De systemen slaan soms door en de configuratiemogelijkheden blijken in de toekomst helemaal niet meer gebruikt te worden. Dergelijke systemen zijn dan ontworpen op een te abstract niveau en daarbij is teveel nagedacht over de toekomst van het systeem. Een nadeel is vaak dat door de vele configuratiemogelijkheden de programmacode geen keuzes vooraf kan maken en toegang naar de database niet over optimale queries zal lopen.
Aan de andere kant kennen we de systemen die zeer specifiek zijn. In deze systemen zijn veel zaken hardcoded en is er juist weinig configuratiemogelijkheid. Vaak zijn deze systemen wel supersnel. Er lijkt dus een klassieke keuze te zijn tussen flexibiliteit en performance, maar is deze keuze nog wel actueel?
Flexibiliteit en performance
Flexibiliteit staat veelal bovenaan op het verlanglijstje van de cio. Het is namelijk belangrijk om snel nieuwe producten en diensten te kunnen introduceren. Sneller zijn dan concurrenten staat gelijk aan winst, maar met een it-organisatie die soms is ontstaan uit fusies is dat een uitdaging. Op een flexibele manier systemen vervangen en uitbreiden is een vereiste.
En is performance nog belangrijk? Performance is belangrijker dan ooit. We zijn niet meer gewend om lang te wachten op een scherm en roepen gelijk dat de applicatie is vastgelopen. Als gevolg van de consumerization van it nemen steeds meer werknemers hun eigen spullen en apps mee naar het werk. De apps worden beoordeeld op functionaliteit, maar ook voor een groot deel op performance. Er is geen ruimte voor apps (en ook applicaties) die niet snel zijn.
Wat is snel?
Het is moeilijk om te zeggen wat snel is. Iets kan altijd sneller, dus wordt er binnen een project vaak een eis gesteld. Deze eis is gebaseerd op wat de gebruiker acceptabel vindt en op de verwachte belasting van het systeem. De definitie van snel is hier dus: als de applicatie voldoet aan de gestelde eisen. Het kan dus ook zo zijn dat een pagina binnen dertig seconden op het scherm moet staan, terwijl ik dat meestal langzaam vind.
Keuze nog nodig?
Is het ook mogelijk om geen keuze te maken, en dan zowel performance als flexibiliteit te hebben? Natuurlijk zijn er gebieden waar geen keuze gemaakt hoeft te worden en een flexibele oplossing met de gewenste performance gerealiseerd kan worden. Vooral indien de performance-eisen niet zo strikt zijn is dit te realiseren. Zijn die strikte eisen er wel dan wordt het toch vaak lastig.
Volgens de soa-manifesto heeft flexibiliteit de voorkeur boven optimalisatie. Hierin richt men zich met name op het specifiek maken van een service binnen een soa-omgeving. Als een service te specifiek is, dan is die service al snel niet meer herbruikbaar. Niet herbruikbaar is in de ogen van de business niet flexibel genoeg. Dit gevaar speelt ook in een cloud-omgeving, waarbij via services de cloud-applicatie wordt ondersteund. Netwerklatency en bandbreedte zorgen dan al snel voor vertraging en het implementeren van een standaard voor datauitwisseling helpt ook niet bij het verkleinen van de berichten. Het implementeren van een standaard zorgt doorgaans wel voor meer flexibiliteit of herbruikbaarheid.
Zijn soa-omgevingen en cloud-computing dan niet geschikt voor high performance? Tuurlijk wel, mits er goed over nagedacht is. Als de onderverdeling in services eenmaal is gemaakt dan is het doorgaans niet eenvoudig om dat aan te passen. Vaak wordt er gedacht dat schaalbaarheid alle performanceproblemen oplost, maar netwerklatency problemen worden niet opgelost door schaalbaarheid. Hier moet vaak een fundamentele verandering voor worden aangebracht in de berichtenstroom.
Vanuit Agile gedachtengoed kan een eenvoudige oplossing worden gemaakt die voldoet aan de wensen. De flexibiliteit ontstaat doordat er geen extra overhead of overbodige configuratie wordt gemaakt. De oplossing kan namelijk nog snel worden aanpast naar een andere situatie. De performance is ook goed door het ontbreken van overhead en overbodige configuratie. Natuurlijk kan het uiteindelijk nodig blijken om uitgebreide configuratiemogelijkheden te hebben, maar die maak je dan 'just in time, just enough"'.
Mijn persoonlijke mening is dat performance eerst gerealiseerd moet worden en dat de flexibiliteit moeilijk vooraf bedacht kan worden. De Agile benadering van het maken op het moment dat het nodig is, sluit daar dan goed bij aan. Goede performance is ook handig bij de ontwikkeling en het testen van een systeem. Waar ligt jouw voorkeur?
Flexibiliteit en performance kunnen volgens mij best samen. Het gaat om, wat je zelf ook aangeeft, het maken van ‘eenvoudige’ oplossingen waar je grip op houdt zodat ze ook flexibel kunnen worden aangepast. Of die je gewoon weg kunt knikkeren. Want naarmate de houdbaarheidstermijn van software verder krimpt, kan het steeds vaker verstandig zijn om software domweg te vervangen door beschikbaar gekomen beter alternatief. Kiezen voor een betaalbare kortere termijn oplossing die je makkelijk kunt vervangen is vaak aantrekkelijker dan gaan voor de zogenaamde ‘ultieme applicatie’. Maar ook bij ‘wegwerpsoftware’ blijft servicedenken trouwens wel (misschien zelfs wel extra) belangrijk.
Leuke titel, ‘systeem dat alles kan’ en rake observatie. Bij configureerbare systemen speelt er meer dan de trade-off met flexibiliteit. Ik heb systemen gezien die zo ‘flexibel’ waren dat de configuratie zo’n complexe klus was dat het te vergelijken viel met programmeerwerk. Feitelijk komt het dan neer op IT-werk overdtfagen aan de eindgebruiker onder het mom van configuratie. De complexiteit van het te ondersteunen werkproces verandert namelijk niet door configuratie.
Helemaal eens dat Agile een betere insteek is, en dat configuratie alleen geboden moet worden waar een concrete behoefte bestaat, niet ‘voor het geval dat’. Is een basis ontwerpprincipe, YAGNI: You Ain’t Gonna Need It.
“Vanuit Agile gedachtengoed kan een eenvoudige oplossing worden gemaakt die voldoet aan de wensen. De flexibiliteit ontstaat doordat er geen extra overhead of overbodige configuratie wordt gemaakt. De oplossing kan namelijk nog snel worden aanpast naar een andere situatie.”
Dit gaat natuurlijk wel uit van een (vrij duur) uitgangspunt: het in stand houden van het Agile team dat de oorspronkelijke spullen heeft opgeleverd. Nieuwe mensen of nieuwe organisatie zullen de aanpasbaarheid drastisch verminderen.
Leuk opinie stuk en erg herkenbaar!
Zelf heb ik systemen ontworpen die met 1 tabel alles konden, maar zoals Marc de Graauw terecht opmerkt, de complexiteit verplaatst, en dan is het cruciaal dat de tools je het nodige inzicht geven omdat je het uit de data in tabellen niet meer op kunt maken. Een ander nadeel van een flexibele opzet is dat database bevragingen enorm complex worden en dat je dus in theorie wel flexibel bent, maar dat een programmeur toch weer veel tijd kwijt is om het toe te passen. Testen is dan ook een draak omdat je in tegenstelling met wat meer “harde code” geen idee hebt wat een verandering voor impact heeft (hergebruiken van componenten bijvoorbeeld).
Door de tijd heen heb ik geleerd welke delen flexibel moeten zijn en welke delen best een beetje hard gecodeerd mogen worden. Processen moeten flexibel zijn, maar het primaire proces met de specifieke branche gerelateerde uitdagingen mag best wat harder neergezet worden, de paradox is namelijk dat als er iets veranderd moet worden, dit weer sneller gerealiseerd kan worden.
Als laatste mijn ervaring en tip: schets een wereldbeeld in een taal die iedereen snapt en voeg daar “verhaaltjes” aan toe van typische scenario’s. Dit vormt namelijk de basis voor het te ontwikkelen datamodel en de kracht daarvan bepaald hoe flexibel je bent.
Ben,
Goed en zeer begrijpelijk stuk. Ook voor een systeem/ontwikkel-leek zoals ik is het goed te begrijpen en zeer herkenbaar.
“Vaak wordt er gedacht dat schaalbaarheid alle performanceproblemen oplost, maar netwerklatency problemen worden niet opgelost door schaalbaarheid. Hier moet vaak een fundamentele verandering voor worden aangebracht in de berichtenstroom”
Goed punt. Netwerk performance/bandbreedte kan er namelijk voor zorgen dat je applicatie niet helemaal gaat doen wat je vooraf gehoopt had. Het is daarom van groot belang om vooraf goed in te schatten wat er benodigd is. In Cloud oplossingen is het vaak mogelijk om te kiezen voor een burstable oplossing. Je kan dan naar gelang je bandbreedte/ netwerkperformance opschalen. En dit kan eventueel via een pay for use variant afgerekend worden.