‘Form follows Function’
Ik zit de laatste tijd, sinds mijn Scrum Master certificering, zo eens na te denken over ontwikkelprocessen in de ICT, en de rol die bepaalde methodieken zoals waterval en agile hierin spelen. Wat mij opvalt is hoe afwijkend software engineering zich heeft ontwikkeld ten opzichte van de industriële engineering. Waarbij ik tijdens mijn opleiding werktuigbouwkunde van de meet af aan heb geleerd dat de vorm de functie volgt (form follows function), zie ik in de software engineering maar al te vaak precies het tegenovergestelde gebeuren.
Als je met ‘echte’ techneuten een planning probeert te maken hoor je vaak direct uitspraken als: “We beginnen met het maken van een datamodel en het inrichten van de database”, gevolgd door “Dan maken we een framework op basis van technologie x en y”, met als knal op de vuurpijl “Dan kunnen we daar de schermen op bouwen”. Stel je voor dat ze bij een bekend automerk zo te werk gaan: eerst ontwerpen we wat wielen en een motor, dan knutselen we een chassis er op, en kijken we daarna wel hoe de bestuurder er in past en waar we het dashboard moeten laten… Wat een bijzondere creaties zouden er op de weg rondrijden. Niemand zou zo’n auto willen kopen nietwaar? En toch stoppen bedrijven tonnen, soms wel miljoenen, in software die op exact deze manier wordt onwikkeld.
Daarmee beland ik op een punt waar ik vaak de eerste weerstand tegen agile methodieken zoals Scrum zie ontstaan. Ontwikkelaars moeten ineens van, wat ik noem, horizontaal naar verticaal ontwikkelen omschakelen. Met horizontaal ontwikkelen bedoel ik de ontwikkel aanpak waarbij we bottom-up vanuit de techniek een systeem gaan opzetten. Met verticaal ontwikkelen bedoel ik de top-down ontwikkel aanpak, waarbij we een stukje functionaliteit nemen, en alleen stukken framewerk en/of database implementeren die voor die functionaliteit relevant zijn. Deze laatste schijnt erg lastig te zijn, omdat ontwikkelaars van nature gewend zijn om, met name vanuit de waterval gedachte, bottom-up te werken.
Ik moet toegeven dat ik tot ik voor een paar jaar terug ook altijd op die manier heb ontworpen, gepland en gebouwd. En dat is logisch: schoenmaker blijf bij je leest, en een techneut blijft dan ook vaak vanuit techniek denken. En techniek bestaat nu eenmaal uit datamodellen, frameworks en daar bovenop pas wat schermen. En met zoveel jaren client-server ontwikkelen kan je op deze manier met een bepaalde zekerheid en voorspelbaarheid een systeem opleveren. Echter met de komst van Service Oriented Architectures (SOA) past deze manier van werken niet meer. Simpel vanwege het feit dat in vergelijking met het ‘oude’ client-server SOA geen eenvoudig en relatief voorspelbaar technisch foefje meer is.
In heel veel bedrijven waar ik kom laten ontwikkelaars mij trots een aantal web services zien, bijvoorbeeld de getRelatieService, en vragen vervolgens: “Wat vind je van onze SOA?”. Dan slik ik maar even en zeg hen dat ze in ieder geval op de goede weg zijn. En daar ligt hem nu net het grote probleem; SOA wordt maar al te vaak verkocht als een technologisch truukje. We maken van onze objecten ineens componenten, en vervolgens met SOA worden deze componenten Web Services, et voila! Niet dus… Ik heb gemerkt dat ik de afgelopen twee jaar de meeste tijd heb besteed aan het uitleggen aan klanten dat SOA helemaal niets met technologie heeft te maken.
Het detail zit hem in de A van SOA, de A van Architecture. SOA gaat eigenlijk over ICT architectuur binnen de Enterprise Architecture (EA): hoe richt ik mijn ICT omgeving in, zodat ze optimaal mijn bedrijfsprocessen kan ondersteunen. En in de SOA methodologie doen we dat door middel van, u raadt het al, de S en de O: Service Oriëntatie. In SOA zijn de bedrijfsprocessen leidend voor de services die we gaan maken. Een service is letterlijk vertaald immers een dienst, een dienst ten gunste van het bedrijfsproces. En in welke technologie deze dienst wordt gerealiseerd is in dit opzicht volstrekt irrelevant. In principe kan een service zelfs een dienst zijn in de traditionele zin van het woord, bijvoorbeeld een telefoniste waar we informatie aan opvragen.
Mijn conclusie is dan ook dat SOA een stap is die de software engineering wereld nu langzaam aan het maken is, en die in de ‘traditionele’ engineering al lang is gemaakt, of waar het zelfs altijd al zo is geweest. Namelijk het creëren van iets met als uitgangspunt de functie die het moet vervullen. Met deze stap ‘verlaten’ we de technologie als uitgangspunt voor het ontwerpen, plannen en bouwen van onze software systemen, en daarmee ook de (relatieve) voorspelbaarheid van deze technologie. Ineens komen we terecht in een dynamische wereld van business eisen en wensen: vraag en aanbod, marketing, concurrentie, wet- en regelgeving, etc., etc. In dit dynamische business domein moeten we snel kunnen inspelen op al deze veranderingen. Een op de waterval gebaseerde methodiek past dan ook niet meer. Hoe kan ik immers in die dynamische wereld vooraf al mijn requirements helder hebben? Zelfs al plan je meerdere milestones in om beter bij te kunnen sturen, wat is dan nog de meerwaarde van die hele specificatie slag vooraf? In mijn ogen is SOA de software variant van ‘Form follows Function’, waarbij een iteratieve, agile, projectmethodiek onmisbaar is.
Tags: agile, engineering, enterprise architecture, functionaliteit, scrum, SOA, waterval, web services