SATURN conference - Dag 3 - Sessie highlights

Deze bijdrage is geleverd door Wim van Gool en Rogier Schrama

Na twee dagen courses en tutorials bij SATURN, staan de komende dagen in het teken van een verzameling gevarieerde sessies met als enige gemene deler ‘software architectuur’. De sessies zijn verdeeld over verschillende parallelle blokken. Deze blokken focussen zich elk rondom een specifiek onderwerp zoals bijvoorbeeld ‘Architectural Modeling’. Per blok zijn er dan weer drie sessies van een half uur. Een half uur is voor een spreker een relatief korte tijd om iets goed voor het voetlicht te brengen. Tijdens de sessies wordt het kwalitatieve onderscheid van de sprekers dan ook goed duidelijk. De sessieblokken worden onderbroken met keynotes van een uur. Al met al een gevarieerde mix van onderwerpen waarvan we in deze post de highlights melden.

Architecting and protecting architectural significant code

Hoewel aan software in de meeste gevallen een vorm van vastgelegd architectuurontwerp is verbonden, verdwijnen veel architectuurbesluiten impliciet in de uiteindelijk geschreven source code. Omdat deze constructies niet expliciet zichtbaar zijn, bestaat het risico dat ze onbedoeld op een dusdanige wijze worden veranderd, dat ze niet meer voldoen aan de oorspronkelijke uitgangspunten. Dergelijke geërodeerde architectuur wordt uiteindelijk complexer en daardoor steeds moeilijker te onderhouden.

Onderzoek binnen de DePaul University heeft geleid tot een Smart IDE die in staat is om architecturaal relevante source code te identificeren. Dit gebeurt op basis van een specifiek, zelf lerend algoritme en een database met informatie over een groot aantal open source projecten. Bij wijzigingen aan de geïdentificeerde code wordt de developer gewaarschuwd. Dit voorkomt onbedoelde wijzigingen aan source code die onderdeel uitmaakt van belangrijke architectuur constructies.

Het is de bedoeling om deze functionaliteit als plugin beschikbaar te maken voor de meest gebruikte IDE’s.

Refactoring, Reuse and Reality – Revisited

In deze sessie lag de focus vooral op het nut van refactoring als een middel om bestaande systemen uit te bouwen en/of uit te breiden. Door een legacy systeem eerst te refactoren, kan men de functionaliteit van een oud systeem intact houden (gegeven een bepaald risico, uiteraard), wat vaak goedkoper is dan iets helemaal opnieuw bouwen. Daarentegen kan men wel stapsgewijs de kwaliteit en structuur van de code verbeteren, waardoor nieuwe features in de toekomst sneller toegevoegd kunnen worden, met minder kans op bugs.

Een belangrijk obstakel waar programmeurs vaak tegenaan lopen in de praktijk is dat ze niet altijd tijd c.q. ruimte krijgen om (voldoende) refactoringwerkzaamheden uit te voeren. Naast het feit dat refactoring een zeker risico met zich meebrengt dat werkende code stuk gaat, betekent ieder uur dat gestoken wordt in refactoring niet gestoken wordt in het toevoegen van nieuwe features. Het argument dat men als ontwikkelaar of architect moet voeren is dat het juist zakelijk gezien een goed besluit is om het systeem te blijven refactoren, omdat het toevoegen van features anders steeds lastiger wordt en de onderhoudbaarheid van het systeem steeds verder achteruit zal gaan, met alle gevolgen (en kosten) van dien.

Past, Present and Future API’s for Mobile and Web Apps

In deze sessie sprak Ole Lensmar, bedenker van de bekende tool SoapUI, over de evolutie van API’s die in gebruik zijn geweest in de context van gedistribueerde systemen en tegenwoordig het internet. Hierbij werd uiteraard eerst ingezoomd op het ontstaan van SOAP, één van de eerste algemeen geaccepteerde standaarden voor API’s binnen gedistribueerde systemen. Na wat upgrades binnen dit protocol heeft REST inmiddels het stokje overgenomen. De sessie eindigde met de opmerking dat er inmiddels ook weer veel andere API’s in ontwikkeling zijn en dat er vast en zeker weer een opvolger voor REST zal zijn.

Scrum, for maximum Awesome

Joe Justice, een business process consultant die in zijn vrije tijd een kleine garage is begonnen waarin hij aan de hand van de Agile principes auto’s is gaan bouwen, vertelde over het succes dat hij heeft behaald met het toepassen van de scrum principes binnen reguliere productieprocessen (processen waarbij fysieke producten worden gemaakt). Het begon allemaal in zijn eigen garage waar hij met een team vrienden zeer zuinige en goedkope auto’s heel modulair is gaan bouwen, waar hij erg succesvol is was en daarmee een behoorlijke aandacht naar zich toe heeft getrokken.

Sindsdien is hij de hele wereld over gegaan om bij allerlei instellingen en organisaties het scrum-proces in te voeren, ongeacht de doelstellingen van het bedrijf of project, en heeft daar keer op keer enorme productiviteitsverbeteringen weten te realiseren. De wijze les was eenvoudigweg dat als men de agile principes, of het nu scrum, kanban of iets anders is, goed weet toe te passen, dat er enorme stappen gemaakt kunnen worden in productiviteit, kennisspreiding en een goede sfeer op de werkvloer. Eén van de meest opvallende zaken was het idee van de ‘company retrospective’, waarbij op organisatie-niveau iedere zoveel weken een willekeurige selectie van mensen uit het bedrijf werd gemaakt die bij elkaar werden gezet om een voorstel te doen over wat zij graag die week nog in het bedrijf zouden willen veranderen. Door deze voorstellen ook echt een kans te geven bleken bedrijven in staat heel efficient grote verbeteringen door te voeren en de betrokkenheid van hun personeel erg te vergroten.

Teaching Architecture Meta-model first

Deze sessie werd georganiseerd door George Fairbanks van Google en ging met name over enthousiasmeren van ontwikkelaars om meer over (het nut van) software architectuur na te denken. Om dit te bereiken heeft hij een bepaalde lesmethode ontwikkeld waarmee hij ontwikkelaars eerst laat inzien dat het niet al te makkelijk is om bijvoorbeeld bruikbare en begrijpelijke diagrammen te maken die precies communiceren wat er overgebracht moet worden, om ze daarna wat tips mee te geven over hoe ze daar beter in kunnen worden. Belangrijkste hint: zorg er voor dat alle modellen die je maakt een expliciete vraag beantwoorden en dat je altijd een legenda aan je diagrammen toevoegt.

BI/Big Data Reference Architectures and Case Studies

Deze sessie lag in het verlengde van de cursus die ik gister over Big Data Architectures had gevolgd en ging iets concreter in op het uitdenken van een Big Data Architecture. De sprekers van het bedrijf SoftServe hadden hiervoor een soort matrix-model uitgedacht, waarbij de ‘sources’ van data aan de linker kant werden vermeld en de uiteindelijk gewenste output c.q. presentatie van die data (bijvoorbeeld op schermen of in rapporten) aan de rechter kant werden gezet. Door vervolgens een lijst met systeemeisen (quality attributes) op te stellen kon het midden van deze kaart worden ingevuld met concrete databases (relationeel en/of non-relationeel) en bijbehorende frameworks en tools (zoals hadoop, HDFS, etc). Het idee was dat hiermee direct inzichtelijk werd gemaakt hoe bepaalde gegevens van links naar rechts door de gekozen systemen heen stroomden, om vervolgens te kunnen analyseren of de gekozen oplossen aan de gestelde systeemeisen zou voldoen.

More to come…

Op naar dag 4, waar onder andere wordt verteld hoe Netflix continuous delivery heeft geregeld.