Vorige week bezocht ik de QCon conferentie in London. De meeste conferenties die ik tot nu toe bezocht gingen over oplossingen, zonder deze specifiek te koppelen aan een probleem. QCon is precies andersom, architecten en developers vertellen juist hoe ze bepaalde problemen hebben opgelost. Het kader is in dat geval dus niet zozeer de programmeertaal (alhoewel de meeste sprekers wel een Java/JDK achtergrond hebben) maar bijvoorbeeld de beschikbare resources of het sociale klimaat.

De setting was erg informeel. Denk ‘klaslokaal’ in plaats van de ‘bioscoopzaal’ die je wellicht kent van andere conferenties. In deze setting zit je met een man of 20 te luisteren naar bekende architecten uit het IT landschap zoals Martin Fowler, Dan North, Rich Hickey, Dion Hinchcliffe, Ola Bini, Venkat Subramaniam, Graeme Rocher, Joe Armstrong etc. En in plaats dat ze hun nieuwe boek of framework aanprijzen geven ze je een kijkje in hun eigen keuken.

De conferentie bestond uit een aantal tracks met onderwerpen zoals: “Domain Specific Languages”, “Architecture for the Architect”, “Systems that never stop”, “Real World SOA”, “Architectures in Financial Applications”, “Functional and Concurrent Programming Languages Applied”, “Web as a platform”, “Domain Driven Design”, “Architectures you Always Wondered About” en verschillende Agile tracks. Ik heb me zelf vooral gefocussed op de architectuur tracks. Daarbij heb ik bijvoorbeeld de volgende onderwerpen zien langskomen:

• Hoe ga je om met de balans tussen generieke oplossingen tegenover specifieke oplossingen.
• Wat betekend het om architect/teamlead te zijn?
• Hoe ontwerp je een schaalbare applicatie?
• Zijn standaarden belangrijker dan ‘common sense’?
• Hoe ga je om met de sociale aspecten van je team?
• De programmeurs in mijn team willen eigenlijk geen verandering?
• Wij zijn van de wereld van SOAP/WSDL naar de wereld van HTTP/REST gegaan, hier liepen we tegenaan.
• Dit is het ontwerp van de nieuwe BBC/Guardian.co.uk/Twitter architectuur; wat vinden jullie er van?
• “Wij zijn, terwijl we origineel een Java club waren, nu 3 jaar bezig met Ruby, en dit zijn de problemen waar we tegenaan lopen/liepen”.
• “Wij gebruiken een jaar Scala, dit zijn de problemen waar we mee te maken hebben”.
• Tegenwoordig heeft ieder bedrijf al een architectuur, meestal met een hoop problemen. Hoe ga je daarmee om als externe architect?

De meeste van de observaties waren behoorlijk subjectief. Daardoor ontstonden er erg interessante discussies met het aanwezige publiek. Ook vertelden mensen niet alleen over de goede aspecten van hun aanpak maar ook over de missers. En deze aspecten maakten QCon een bijzonder waardevolle conferentie.

Veel van wat ik heb geleerd is niet direct concreet te beschrijven maar een aantal punten kwamen herhaaldelijk terug (en natuurlijk zitten er open deuren tussen):

• Over het algemeen blijken ‘industrie’ standaarden weinig waarde te hebben. Klanten hebben een probleem wat moet worden opgelost. Meestal is dat probleem niet dat ze wel of niet voldoen aan een standaard. Of je dat nou met JSF, EJBs, SOAP of Ruby en REST doet maakt niet veel uit. Als je het maar goed doet, binnen de gestelde tijd en met de gestelde resources. Zelfs de Financiële wereld begint langzaam van SOAP naar REST te gaan bijvoorbeeld. Het idee dat industriestandaarden het makkelijker maken applicaties aan elkaar te knopen is in de praktijk vrijwel nooit waar. Het geeft vaak vooral veel overhead tijdens ontwikkeling. Ook werken industrie standaarden vaak zelfs tegen je omdat ze te generiek zijn.
• Waar ‘vroeger’ de architect/techlead vooral afkaderde wordt steeds meer geluisterd naar goede ideeën van de ontwikkelaars.
• Beslissingen over de architectuur worden zover mogelijk naar achteren geschoven in het project om te voorkomen te vroeg (dus zeer waarschijnlijk met te weinig informatie) de verkeerde keuzes te maken.
• Er wordt steeds vaker gegrepen naar functionele programmeertalen (Erlang, Clojure en ten dele Scala) om schaalbare oplossingen te schrijven. Dit zegt natuurlijk niet dat dit voor ieder type architectuur nodig is.
• Alle grotere Ruby architecturen bevatten componenten die niet in Ruby zijn geschreven wegens performance problemen. Het juiste gereedschap kiezen bij het probleem wat je probeert op te lossen werpt in de praktijk vruchten af. Mingle (Agile collaboratie/planning tool) van thoughtworks is hierop een uitzondering, maar de specificaties voor een systeem waar 100 mensen gebruik van maken zijn ook niet mals: minimaal 8 cores en 8GB geheugen; producten als JIRA kunnen met flink wat minder af.
• De eenvoudigste oplossingen blijken vaak het langst bruikbaar. HTTP, Files, (Unix) Pipes. Kies niet voor complexere oplossingen zonder daar een bijzonder goede rede voor te hebben.
• In de wereld waar alles multicore begint te worden worden functionele programmeertalen steeds belangrijker.

Als techlead/architect is QCon dé conferentie om te bezoeken. Het is dé manier om bij concurenten in de keuken te gluren. Het is enorm waardevol om bevestiging van je eigen ideeën te krijgen of, als dit niet het geval is, je ideeën te kunnen toetsen door ze in dat geval aan de aanwezigen voor te kunnen leggen. Leuk detail is dat dit alle sprekers ook de praatjes van anderen bezocht, toch best apart om naast Martin Fowler te zitten.

Links:

• QCon 2009, dag 1 op mijn privé blog
• QCon 2009, dag 2 op mijn privé blog
• QCon 2009, dag 3 op mijn privé blog