Iedereen die de ontwikkelingen bijhoudt op het gebied van software-ontwikkeling weet het: je kunt het onmogelijk allemaal bijhouden. Als ervaren ontwikkelaar, ontwerper of architect is de belangrijkste vraag keer op keer of je de laatste hype van de trend kunt onderscheiden en wat je er mee moet.
Zo’n vijftien jaar geleden was het niet ongebruikelijk om bij it-afdelingen van grote organisaties zogenaamde ‘ontwikkelstraten’ in te richten. De gedachte dat je software-ontwikkeling als een fabrieksmatig proces zou kunnen inrichten kom ik nog steeds wel eens tegen. Maar daar waar je vroeger af kon met open (of gesloten)-standaards zoals bijvoorbeeld een Java Enterprise-straat of je volgde de lijn van – pak ‘m beet – Microsoft of IBM, zo wordt vandaag de dag niet meer geopereerd.
Zelfs de implementatie van een eigen ontwikkelstandaard is vaak tevergeefs of van korte duur.
Mocht je proberen te varen op het kompas van grote jongens als IBM, Oracle en Microsoft, dan merk je vroeg of laat dat hun producten even heterogeen zijn als de open source- of internet-gemeenschap zelf. Bekende open source-websites als Apache, Sourceforge en Google Code hebben de weg geplaveid voor een site als Github waar de tech-wereld helemaal los gegaan is en jan en alleman projecten in allerlei soorten en maten plaatst.
Embrace change… met mate
In de wereld van de maatwerksoftware hebben we de laatste tien jaar te maken gekregen met een explosie van het aantal frameworks en libraries, waarbij enkel het maken van keuzes al een apart specialisme lijkt. Het adagium ‘embrace change’ dat oorspronkelijk bedoeld was voor de functionele requirements in een Agile softwaretraject krijgt zo een eigen betekenis. Een nieuwe tool met versie 0.7 lijkt nog niet rijp, maar als we al op versie 3.2 zitten dan is er vast al wel iets nieuws dat beter is. En uiteraard moet de nieuwe technologie ‘light weight’ zijn. Iets wat bij een versienummer van minder dan 1 misschien wel automatisch is, lijkt me zo.
Natuurlijk, open source is geweldig, en jawel, er bestaan zeer goede en toekomstvaste projecten, maar in sommige hoeken, zoals webtechnologie of Java, lijkt er elke dag een framework of tooltje bij te komen, waarvan het hele internet schreeuwt dat je niet zonder kan. Het is de taak van architecten om het it-landschap in de gaten te houden met oog voor zaken als onderhoudbaarheid, veiligheid en wendbaarheid. Dus zelfs als de werkvloer allerlei autonome Agile-teams heeft, zou je zeggen dat de architect enigszins defensief is als het gaat om het introduceren van nieuwe technologieën.
Complexiteit
Een organisatie die gebruik maakt van een ratjetoe aan technologieën zoals WebSphere, JBoss, Spring, Java Enterprise, .Net, MQ, Mule, Oracle Fusion, Tomcat, Scala, Groovy, Python, MySQL, Postgres, Cassandra, Neo4j, MongoDB, Hibernate, JSF, EJB, Maven, Node.js, Grunt, Bower, et cetera, heeft technisch gezien een complex landschap met overlap in producten. Vaak moet bovendien geintegreerd worden met uitgebreide business-pakketten als Siebel, SAP of Salesforce.
Een heterogeen landschap kan op zichzelf al duur in onderhoud zijn, maar wat het daarbovenop nog lastiger maakt is de combinatie van verschillende paradigma’s en dergelijke, zoals soa, model driven, api-driven, functioneel programmeren, reactive systems, cloud computing, et cetera. En dan heb ik het nog niet gehad over de verschillende proces methodieken, waarbij DevOps misschien wel een toverwoord is, maar daarmee nog niet een tovermiddel.
Paradox
De paradox is dat het voor het persoonlijk curriculum van de software-architect wel goed is om veel verschillende producten te gebruiken. Bovendien is het leuk om nieuwe technologie uit te proberen en ook is soms nieuwe technologie vaak net wat beter dan oude technologie. Dat is niet altijd zo, maar daar kom je natuurlijk pas achter als je het toch een keer gebruikt.
En zo kan het gebeuren dat je bij de start van een nieuw project, bijvoorbeeld een simpele webapplicatie, je zomaar een paar weken kwijt bent, omdat je niet kunt kiezen. Het is een soort framework fetisjisme. We zijn verslaafd aan frameworks en worden er opgewonden van. Daarnaast volgen we de nieuwe trends en stellen we onszelf dus telkens nieuwe vragen. Gebruiken we een applicatieserver of is dat alweer achterhaald? Gebruiken we een database? NoSQL toch wel? En wat gebruiken we eigenlijk voor de frontend? Een leuk hip framework ofzo? En welke versie dan eigenlijk? En is een nieuwe versie van zo’n framework of tool wel backwards compatibel? Laten we in ieder geval ‘lightweight’ beginnen, want ‘heavyweight’ wordt het vanzelf wel.
Als ik dit zo lees is het KISS proncipe vergeten.
Keep IT Simple and Structured.
Of kort “Keep it simple stupid”.
Zie ik het verkeerd of zijn genoemde frameworks niets anders als de ultimatieve bloatware?
De tijd van grote enterprise en vaak bloated frameworks is op zijn einde en is vervangen door diverse ‘light’ vaak op specifieke toepassingen gemaakte alternatieven specifiek voor specialistische functies. En dus een divergentie aan nieuwe innovaties of oude wijn in nieuwe zakken.
Voor architecten een tijd om veel nieuwe zaken bij te leren en vooral ook een mogelijkheid om je lijstje met favoriete technieken aan te passen met nieuwe technieken die beter aansluiten bij je doelstellingen.
Het lijkt dan ook wel alsof je in een XL supermarkt voor het rek staat en verzucht dat er zoveel keuze is. Een luxeprobleem dus.