Categorie: Blog

“Welke boeken lees je zoal in ons vakgebied?” Deze vraag wordt vaker gesteld. Nu ben ik iemand die graag meerdere boeken tegelijk lees en veelal er langere tijd over doe om een boek goed te doorleven. In mijn huiskamer slingeren meestal een tiental boeken rond die nog aandacht behoeven. (Mogelijk ben ik voor iemand die vroeger te weinig las, dik aan het inhalen)…

Op dit moment ben ik ook weer met een uiteenlopende set bezig. Hier een overzicht van de boeken en waarom ik ze interessant vind.

Modern Software Engineering van David Farley
David Farley is o.a. de co-auteur van het boek Continuous Delivery, kanaalhost op Youtube en natuurlijk software engineer. In dit werk geeft hij een mooie onderbouwing waarom Software Engineers goed moeten zijn in het omgaan met complexiteit en experts in leren moeten zijn.

Pragmatic Thinking & Learning van Andy Hunt
Andy Hunt heeft meerdere goede boeken geschreven. In dit werk staat leren centraal. Daarmee mooie relatie met het boek van David Farley. Wat dit werk erg interessant maakt is dat Andy heel mooi beschrijft hoe het model van Dreyfus toegepast kan worden. Dit model gebruiken we ook graag in onze eigen praktijk. Tipje van de sluiter:

Domain-Driven Design Distilled van Vaughn Vernon
Vaughn beschrijft op een heel laagdrempelige manier DDD. Dit boekje lees je snel weg en geeft een goed basisinzicht wat DDD te bieden heeft. Na het lezen van dit boek snap je de waarde van het begrip Bounded Context.

Team Topologies van o.a. Matthew Skelton
In dit werk wordt ingegaan op de inrichting van een organisatie. Volgens mij het eerste werk dat echt goed de relatie legt tussen organisatievorm en software architectuur. Zeker het eerste werk dat dit goed aan DDD relateert. Zie ook mijn posting over Bounded Context en de relatie met organisatievorm.

<< Uitstapje, onderstaand Venn-diagram wat we binnen Sogyo hanteren voor de inrichting van software organisaties is hier mooi aan te relateren>>

Practical Process Automation van Bernd Ruecker
Bernd is de lead engineer achter Camunda: The Universal Process Orchestrator (zoals ze het zelf omschrijven). Nu hebben we de afgelopen 20 jaar meerdere Process Orchestrator (PO) implementaties gehad en zien falen.
Wat dit werk interessant maakt is dat Bernd een echte software engineer is. Naast dat hij beschrijft wanneer je een PO vooral niet moet gebruiken, repecteert hij heel mooi de Bounded Context. Aldus zijn eigen woorden.
Een andere mooie opmerking: tuurlijk kun je een proces ook in code beschrijven, maar een visualisatie is voor andere sneller te begrijpen. Interessant om over na te denken.

Data Mesh van Zhamak Dehghani
Ja, ik moet hieraan nog beginnen. Wat hem zeer interessant maakt is dat de wereld van data ook het begrip Bounded Context omarmt in de Data Mesh.

We kennen de Data Lake voorbeelden wat swamps geworden zijn. Hoe met grote hoeveelheden data om te gaan en hier nog steeds de juiste betekenis aan te geven is het topic van Data Mesh. De komende jaren gaan we dit op ons in mogen laten werken.

Accelerate van o.a. Nicole Forsgren
Nicole heeft voor haar PhD onderzoek gedaan naar de performance van software delivery binnen organisaties. Ze heeft ruim 2000 unieke organisaties betrokken. Daarmee een zeer rijk inzicht verkregen wat “high performing teams” maakt en welke context hierbij past. Ze laat dit mooi zien door goed het vergelijk met “low performing teams” te beschrijven.

Het leuke van deze boeken is dat ze ingaan op (code) design. Hoe om te gaan met complexiteit. Het vinden van de juiste modulariteit. Ontwerp principes die ons fundamenteel kunnen helpen. Daarbij ook veel relatie leggen met de context die we als software engineering teams nodig hebben. Inspirerende werken waar we als industrie nog wel even zoet mee zijn.

<< Uitstapje, en dan hebben we nog niet gesproken over de beruchte uitdrukking: “It is all about the Machine that builds the Machine” 🙂 voor een volgde keer dan maar.. >>

We zien het allemaal wel gebeuren: een team in de organisatie levert snel, goede resultaten. Het heeft een directe relatie met de business, doordat een PO-er of liever nog een domeineigenaar onderdeel uitmaakt van het team. Er wordt slim samengewerkt. De lijntjes naar operations zijn goed gelegd of nog beter volledig in het team getrokken. Een succesvol team!

De directie is enthousiast en wil meer. Wat als we opschalen naar meerdere teams? Hoe kunnen we onze andere teams ook zo effectief krijgen?

In de praktijk blijkt dit een heel lastig vraagstuk te zijn. Het punt wat altijd naar voren komt is namelijk: Wat is een logische indeling van verantwoordelijkheden per team? Teams worden ingericht naar hun vakinhoudelijke discipline; producten die ze ondersteunen of klantgroepen die ze bedienen. Er zijn nog vele indelingen te bedenken.

Waar we in software architectuur aan het leren zijn dat de opdeling van systemen in logische ‘bounded contexts’ belangrijk is en nog belangrijker is hoe deze bounded contexts met elkaar communiceren. Zien we dit nog beperkt terug in de organisatiestructuur.

Bounded contexts zijn echt iets anders dan de gemiddelde component of service opdeling in CBD/SOA/API-architectuur termen. Het beoogt invulling te geven aan het decompositie vraagstuk waar we al jaren naar zoeken: maximale samenhang en minimale koppeling.

---

Wat is een Bounded Context?
De term bounded context is door Eric Evans geïntroduceerd in zijn werk Domain Driven Design. Het wordt ook wel beschreven als:  “A semantic contextual boundary”.

Semantic: het heeft directe betekenis binnen het (business) domein. Een orderverwerking heeft in een productiebedrijf een andere betekenis dan voor een dienstverlener.

Contextual: het expliciet maken van de situationele omgeving waarbinnen we ons bevinden. In het productiebedrijf wordt in de orderverwerking een product verwerkt. Binnen de context van orderverwerking zijn we geïnteresseerd in specifieke eigenschappen van het product.

Boundary: de afbakening van de context waarbinnen we actief zijn. Voor de orderverwerking is het van belang dat de betaling binnen is, de voorraad wordt bijgewerkt, de producten geleverd worden. Daarmee worden de grenzen van de bounded context gezet. 

Meerdere bounded contexts vormen het domein waarin een organisatie actief is. Bounded contexts hebben dus interactie met elkaar. Dat zelfde geldt dus ook voor de teams die verantwoordelijk zijn voor een of meerdere bounded contexts.

---

Tot dus zien we de bounded contexts nog beperkt terug in de organisatiestructuur. We zien wel het omgekeerde gebeuren, waardoor Conway’s Law kon ontstaan: “Organisations which design systems … are constrained to produce designs which are copies of the communication structures of these organisations“. Vrij vertaald uit de opbouw van systemen kunnen we de organisatiestructuur afleiden.

Dit leert ons dat wanneer we de verbintenis tussen de organisatiestructuur en software architectuur niet expliciet maken dit impliciet wel zal ontstaan. Gevolg is dat na de zoveelste doorgevoerde reorganisatie we er achter komen dat deze toch niet lekker werkt. Teams hebben een te grote afhankelijkheid van elkaar, omdat ze dezelfde onderdelen uit de codebase moeten muteren. Het ineens blijkt dat we meerdere teams nodig hebben om die ene customer journey te kunnen leveren. 

Het wordt dus tijd dat we de software architectuur/design meenemen in het afbakenen van de teamverantwoordelijkheid en organisatie inrichting.

Gelukkig is dit langzaam een denkwijze aan het worden die in Team Topologies van Matthew Skelton en Manuel Pais heel mooi omschreven wordt.

Hun werk is zeer de moeite waard om te lezen. Uit eigen ervaring kan ik zeggen dat het best wat tijd kost om het ook goed te doorleven.

De team typologie die ze uitgebreid beschrijven kent vier fundamentele team type:

• Stream-aligned
• Platform
• Enabling
• Complicated-subsystem

Interessante is dat in deze opdeling een sterke relatie gelegd wordt met het business domein / bounded contexts en de verantwoordelijkheden van teams.

Stream-aligned teams zijn gefocust op het primaire business doel. Voorbeelden als: het aansluiten van nieuwe klanten, afhandelen van claims, het vinden van de juiste advertentie, etc.

Ze hebben hierin end-to-end verantwoordelijkheid. Definiëren de metrieke die nodig zijn om hun succes aan te tonen. Ze zorgen dat de waarden van de metrieke zo positief mogelijk zijn, waardoor de dienst/functionaliteit het beste bij de doelgroep aansluit.

Platform teams faciliteren het stream-aligned team door het bieden van services/API’s die in de streams gebruikt kunnen worden. De Complicated-subsystem teams zijn verantwoordelijk voor die bounded context(s) waar hoge mate van domein logica een rol speelt. Complexe regelsets of andere vormen van gedrag in een domein, waar veel domein kennis een rol speelt.

Enabling teams faciliteren de steam-aligned teams met nieuwe inzichten of ontwikkelen die ze kunnen helpen hun doelen nog slimmer te bereiken.

Hierbij worden een drietal interactie-modi onderkent:

• Collaboration
• X-as-a-Service
• Facilitating

Deze interactie-modi geven inzicht hoe de teams onderling kunnen samenwerken.

Team Topologies is een denkstijl waarin een directe relatie met de onderliggend software architectuur wordt gelegd.

Zoals gezegd biedt Team Topologies veel denkstof. Een van de interessante perspectieven die mij in de praktijk al meerdere keren geholpen heeft is de Cognitive Load van een team.

Cognitive load wordt omschreven als: “the total amount of mental effort being used in the working memory“, John Sweller pagina 32.

Bij het bepalen van de verantwoordelijkheden van een team blijkt de cognitive load een interessante graadmeter. Hoeveel kennis moet een team hebben? Hoeveel nieuwe inzichten moeten en kunnen ze opdoen? Wat is de diversiteit van kennisgebieden? Door dit ook met teams zelf te bespreken ontstaat een hele mooie reflectie naar het team en haar omgeving. Al snel blijkt dat het team veelal zelf instaat is aan te geven wat ze aan kunnen en of de verantwoordelijkheden nog passend zijn.

Deze reflecties leveren inzicht op wat wel en niet werkt. Door hier doorlopend mee aan de slag te gaan past de organisatie zichzelf ook steeds meer aan….

“Organizations should be viewed as complex and adaptive organisms rather than mechanistic and linear systems” — Naomi Standford pagina 3.

In de tijd dat DevOps een nieuw inzicht was, kwam Gene Kim met een romanstijl boek: The Phoenix Project. Een boek wat op een zeer leuke en prettige manier een heel pijnlijk probleem aan het licht brengt.

Najaar van 2019 was het tijd voor een vervolg: The Unicorn Project. Interessante titel. The Phoenix project gaat over Parts Unlimited, een bedrijf van bijna 100 oud. Om dan het over een unicorn project te hebben geeft toch vraagtekens.

Het boek leest weer snel weg. De parallellen met veel klantorganisaties zijn zo gelegd. Zelf werd ik snel enthousiast na het lezen van:

When a fool spends all their time on features, the inevitable outcome is that even easy tasks become difficult and take longer to execute.

Het werk maakt een hedendaags probleem van veel bedrijven snel inzichtelijk: hoe de beweeglijkheid / kantcentraalheid die veel kleinere bedrijven kunnen hebben ook in grotere bedrijven vast te houden. Het geeft eerst een goed inzicht in de mogelijke problemen en goede onderbouwing waarom hier iets aan te moeten willen doen.

Code deployment lead time, code deployment frequency, and time to resolve problems are predictive of software delivery, operational performance, and organizational performance, and they correlate with burnout employee engagement…

Het is niet alleen een must-read voor engineers (developers, testers, QA), zeker ook voor leidinggevende (management/directies).

Ik heb een aantal interessante lessen uit het werk op een A4tje willen zetten. Mocht je nog niet getriggerd zijn om het boek te lezen dan hier nog een trigger:

Dat een agile denkwijze belangrijk is weten we allemaal. Vanuit software ontwikkeling zijn we hier nu al tientallen jaren mee bezig. We zoeken manieren om IT en het businessdomein dichter bij elkaar te brengen. Een mooi bewijs zien we in dagelijkse praktijk, waarin een van Nederlands grootste financiële dienstverleners zichzelf transformeert naar een bedrijf waar business en IT letterlijk samengevoegd worden.

Afgelopen jaren hebben we gezien dat DevOps er voor zorgt dat software ontwikkelaars, beheerders, analisten en infrastructuur engineers veel intensiever zijn gaan samenwerken. Een stap verder zijn praktijkvoorbeelden waarin we weer terug gaan naar de essentie en ons bezig gaan houden met de software levenscyclus: we herontdekken waar software engineering over gaat.

In dat proces zijn we ook op zoek hoe de business en IT alignment goed vorm te geven. De ideeën die Eric Evans in 2004 aangedragen heeft in Domain Driven Design (DDD) zijn daar een mooie voorbeeld van. Het vraagstuk hoe te komen tot de ubiquitous language. Vanuit technisch oogpunt heeft Greg Young ons een mooi beeld gegeven hoe we DDD gedistribueerd kunnen opzetten: CQRS (Command Query Responsibility Segregation) en is event sourcing ontstaan.

Wat ik fascinerend vind is dat we een software design principe gekregen hebben, waarin we het businessdomein in de implementatie terug vinden. We proberen tot implementaties te komen waarin geen vertaalslagen gemaakt worden van de business(processen), maar juist de businesstermen en gedragingen direct terug kunnen vinden.

De basisgedachte die DDD gebracht heeft zijn geëvolueerd en brengen ons onder andere EventStorming. Alberto Brandolini heeft deze benadering uitgewerkt. Centraal in deze aanpak staat het samen met de gebruikers vaststellen van de belangrijkste business events: gebeurtenissen die voor de business belangrijk zijn.
In bijvoorbeeld een hypotheekdomein kunnen dit gebeurtenissen zijn als een hypotheekaanvraag is afgerond, een verlenging heeft plaatsgevonden, er is een aflossing geweest. Gebeurtenissen die het gevolg zijn van acties die in het businessdomein plaatsvinden. Acties die mogelijk ondersteund kunnen of moeten worden door een IT oplossing.

Ik vind het mooie van EventStorming dat het geen “IT-ding” is, maar samen met de domeinexpert aan de slag om de events te identificeren. In de praktijk betekent dit dat we de vrijheid nemen om events te benoemen op post-its, op een brownpaper te hangen en deze events in een tijdslijn plaatsen.
Essentie is dat we gezamenlijk het businessdomein modelleren. Gezamenlijk gaan zien wat belangrijk is om de organisatie doelstellingen te bereiken. Om zo uiteindelijk te komen tot een backlog. En gezien de directe relatie die EventStorming heeft met DDD, geven onder andere boeken als Implementing Domain Driven Design van Vaugh Vernon ons handvatten voor de realisatie.

Ik denk dat EventStorming een belangrijke vervolgstap in de evolutie om de om de grenzen tussen IT en business te laten vervagen. Een vorm van samenwerking en modelleren om daadwerkelijk als één organisatie verder te kunnen. Gezien de kansen en de snelheid van veranderingen die nu aan de orde zijn, is de mate waarin een organisatie snel kan inspelen op veranderingen van levensbelang. Een van de belangrijkste reden om hierin te investeren en nog meer ervaringen in de praktijk op te doen.

De bijeenkomsten over DevOps vliegen om je oren. De term DevOps wordt sinds 2009 gebruikt door voorttrekkers als Patrick Debois. In Nederland zie je in de grote/enterprise omgevingen ook steeds meer aandacht hiervoor komen. Een van de grote banken heeft zelfs de stap gemaakt om deze denkwijze breed toe te passen.

De vraag komt dan toch snel: is dit weer een nieuwe hype of iets waar we serieus aandacht aan mogen besteden? Die is snel te beantwoorden: DevOps is zeker geen hype voor organisaties waar software ontwikkeld en beheerd wordt.

Wat DevOps in mijn optiek interessant maakt is dat we hiermee het Agile denken/ werken organisatie breed oppakken. De afgelopen jaren hebben we in ons vakgebied geleerd dat Agile werkwijze voor software ontwikkeling grote voordelen oplevert. De betrokkenheid naar elkaar veel groter is geworden. Software ontwikkeling vindt veel meer gefocust plaats, waardoor de functionele waarde voor een onderneming veel sneller wordt bereikt.

Vanuit ontwikkelperspectief zijn we ook concreet aan de slag gegaan met de integratie van de code. Continuous Integration kwam om de hoek. Wat we later veel omvattender in Continuous Delivery terug zien komen. In de praktijk zien we dat door het beoefenen van deze aanpak de kwaliteit van de op oplossingen omhoog gaat.  Goed dat we daarmee software ontwikkeling naar een hoger niveau brengen.

Kijken we dan weer naar bestaande “wetten” dan weten we dat minimaal 60% van de kosten van software niet gemaakt wordt in ontwikkeling, maar juist tijdens beheer. Dan wordt het van belang dat we veel meer naar de hele software levenscyclus gaan kijken. Dan moeten we ontwikkeling en operations veel meer als een beschouwen.

Leuk gezegd, maar operations en ontwikkeling als één beschouwen: we zetten de twee gewoon bij elkaar en klaar. Nee, dat is niet waar DevOps over gaat. Het gaat veel meer over het intensief laten samenwerken van Dev en Ops. Of zoals Matthew Skelton het onlangs verwoorden: Devops = Highly effective communication. Daarbij kan het dus handig zijn om bij elkaar te zitten. Belangrijker is dat we in onze sprints elkaar weten te vinden. Gezamenlijk een beeld vormen over hoe de code die geschreven wordt naar productie kan. Wat daar dan de impact van is. Hoe we de code op een traceerbare manier in productie nemen.

Ik vond Dan North het onlangs op de DevOps summit in London heel mooi verwoorden. In DevOps an Ops-engineer does not have root access on production.

Daarmee zegt hij dat een Ops engineer niet zelf de packages/code op een productie omgeving neerzet. Dit doet een Ops engineer door een script te schrijven waarin opgenomen wordt wat, waar moet komen staan, met welke credentials.

Dus voor de Dev-engineers: niet alleen meer gebruik maken van een Jenkins om de build en eventuele deployment naar Test en Acceptatie Test te doen. Ook een geautomatiseerde deploy naar productie.

Door ook het deployen naar productie te automatiseren krijgen we meer grip over de omgeving. Daarnaast wordt de herhaalbaarheid verhoogd, waardoor we vaker en sneller kunnen deployen.

Al met al is het begrijpelijk dat DevOps veel aandacht krijgt op dit moment. Een onderwerp om meer ervaringen in te delen.

Afgelopen week was de Europan Smalltalk User Group (ESUG) bijeen in Amsterdam. Tijdens de bijeenkomst zijn verschillende presentaties gegeven over uiteenlopende Smalltalk gerelateerde onderwerpen. Over het algemeen kun je stellen dat er veel diepgang in de presentaties zat. Zo stonden donderdag de webframeworks centraal. Dan komt natuurlijk een zeer groot framework als Seaside voorbij. Wat ik erg interessant vond was de presentatie van CosmoCows. Ze presenteerde hun webframework dat ze in Smalltalk ontwikkeld hebben. Wat dit framework erg mooi maakt is dat je rijke webclients kan maken die gesynchroniseerd worden met de server. Oke denk je dan, dat kan ieder AJAX-achtig framework. Het mooie van dit framework, is echter dat je ook events vanuit de server kunt pushen naar de client. Of beter gezegd dat je events vanuit je domein kunt pushen naar de presentatie (CV van de MCV). Dit zag er erg mooi uit. Wat ik niet weet, maar zeker interessant is, is of dit framework ook beschikbaar komt om breder toegepast te worden.

Wat deze ESUG bijeenkomst verder interessant maakt is dat het de grootste bijeenkomst ooit was. Je zou dus kunnen zeggen dat Smalltalk populair is 🙂 . Dat het erg leeft blijkt ook wel uit de ontwikkelingen die er plaatsvinden om een Smalltalk VM op de IPhone beschikbaar te krijgen. Uit een heel andere hoek komen totaal andere interactievormen. Dan hebben we het over Open Croquet. Er gebeurt wat ons betreft zoveel in dit speelveld dat we 2 oktober zelf een studentenseminar organiseren rondom het thema Smalltalk.

Ik spreek vaak over mooie code. De vraag is dan natuurlijk wat maakt code nu eigenlijk mooi. Het is toch een beetje vreemd dat je code überhaupt mooi kunt vinden. De meeste klanten waar ik mee spreek vinden het een beetje nerdie: “code die mooi is… lekker belangrijk, ik wil gewoon werkende software.” Uiteindelijk hebben ze daar natuurlijk gelijk in, het draait allemaal om het eindresultaat. Daar ligt dan ook wel de kern waarom code mooi moet zijn. Software maken we op projectbasis. Na een intensief ontwikkelproces nemen we het in gebruik. Dan gaan we er mee werken. Dat is het moment dat er iets moois gebeurt. We gebruiken de software die we dachten nodig te hebben. Maar dan blijkt in eens dat het op een andere manier toch handiger kan werken. Hadden we dat niet eerder kunnen bedenken: NEE! Je kunt vaak pas tijdens het werken met de software echt ervaren wat beter of slimmer kan.

Natuurlijk gebruiken we technieken als storyboarding om deze ervaringen al vroeg boven tafel te krijgen. De moeilijkheid blijft vaak dat de gebruikers ook nog niet precies weten wat ze willen, omdat ze niet instaat zijn te anticiperen op de toekomstige eisen en wensen.

Het eindresultaat is daarmee niet alleen de software, maar juist de mate waarin we instaat zijn om deze software aan te passen. Het gaat juist om de evolutie die software door gaat. Dan wordt het toch in eens interessant en cruciaal om mooie code te schrijven. Want code wordt mooi als het helder leesbaar is, er een duidelijke structuur is en een natuurlijke opdeling kent van verantwoordelijkheden. Pas dan is het mogelijk om snel veranderingen in de software aan te kunnen brengen. De overdraagbaarheid van code neemt toe, waardoor verschillende mensen ze kan aanpassen. Als we ons dan ook nog realiseren dat de kosten van software niet zo zeer zitten in de ontwikkeling van de software, maar dat het met name zit in de vele aanpassingen die de software in haar bestaan ondergaat. Dan is het zelfs uit legbaar naar alle afnemers van software dat mooie code veel oplevert. Dus veel plezier en succes met het schrijven van mooie code.

Voor de SDN (Software Development Network) heb ik afgelopen jaar meerdere keren gesproken op zowel de events als de conferentie. Het zijn leuke bijeenkomsten met zeer uiteenlopende onderwerpen. Sinds dit voorjaar heeft de SDN besloten een aantal van haar track te herzien en uit te bereiden. Een van de uitbreidingen is de introductie van de architectuur track. Het doel van deze track wordt software architectuur als een losse pijler neer te zetten.

Software architectuur heeft ook mijn interesse en daarom hebben we besloten dat de SDN te helpen deze architectuur track op te zetten. Als track lead ga ik me inspannen om interessante sprekers en auteurs te benaderen en de track verder vorm te geven. Dus mocht je interessante artikelen hebben of willen spreken laat het dan horen. Anders zie ik je graag op een van de bijeenkomsten die je op de site kunt terug vinden.