The Unicorn Project: must read….

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:

Lessen uit The Unicorn Project
Lessen uit The Unicorn Project
Gepubliceerd op
Gecategoriseerd als Blog

EventStorming: zeker geen hype!

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.

Gepubliceerd op
Gecategoriseerd als Blog

DevOps: Hype of toch meer…

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.

Gepubliceerd op
Gecategoriseerd als Blog

Paneldiscussie Model Driven Development

3 september zal ik een paneldiscussie over Model Driven Development leiden. Deze bijeenkomst wordt georganiseerd door Devnology. Dit is een stichting die tot doel heeft om software ontwikkelaars met elkaar vakinhoudelijke kennis te laten delen en dat  geheel platform onafhankelijk. Dit laatste is juist iets wat mij bij ze trekt. Het is erg leuk en interessant om over software ontwikkeling na te denken en te discussiëren zonder je te laten begrenzen door een platform.

Tijdens deze sessie gaat het over Model Driven Development. Een mond vol en de eerste vraag is dan simpel. Wat verstaan we daar onder? In hoofd lijnen zijn we het binnen het vakgebied daar nog wel over eens. Echter als je meer in detail gaat kijken komen verschillende stroming naar boven.  Dan wordt het ook interessant. Waarom zijn deze stromingen er en sluiten ze bij elkaar aan of sluiten ze elkaar juist uit?

Het panel bestaat uitJurgen Vinju, Sander Hoogendoorn, Erik van de Ven en Eelco Visser. Door het neerzetten van enkele stellingen en discussie uit te lokken proberen we in deze avond een duidelijk beeld van MDD en de toepasbaarheid in de praktijk te krijgen.

Wanneer je interesse hebt om deze sessie bij te wonen schrijf je dan in op de site van Devnology. Tot 3 september.

Gepubliceerd op
Gecategoriseerd als Blog Getagged , ,

Data Vault

Vorige week zijn we dieper in het concept achter Data Vault gedoken. Samen met een aantal collega’s en Kasper de Graaf hebben we gekeken wat de toepasbaarheid van Data Vault is binnen software ontwikkeling.

Data Vault is een modelleerstijl ontstaan in de datawarehousing wereld. Dan Linstedt heeft de basis voor deze stijl gelegd en inmiddels meerdere keren succesvol toegepast. Het is een modelleerstijl waarin data zo wordt vastgelegd dat:

  • deze uitgebreid kan worden zonder de bestaande structuur aan te passen;
  • op een zeer eenvoudige manier mutaties en herkomst van de data vastgelegd kan worden;
  • geen complexe structeren bedacht hoeven te worden om de betekenis van een enititeit duidelijk vast te leggen;

Om dit te bereiken zijn een aantal eenvoudige regels opgesteld. Zo wordt een enititeit gemodelleerd als een HUB. Een hub bevat slechts een business ID en een technische ID voor de entiteit. Stel een hub beschrijft een klant dan beschrijft het slechts een klantnummer en een technische ID. Vanuit datawarehouse perspectief zou nog metainformatie, zoals het bronsysteem waaruit de data komt, kunnen worden toegevoegd.

Hubs worden aan elkaar geknoopt via Links. Een link is een tabel die een N op M relatie legt tussen hubs. Ook een link is een eenvoudige entiteit die slechts beperkt metadata bevat.

Van de hubs kunnen natuurlijk meerdere attributen vastgelegd worden. Deze attributen worden in Satelliet-entiteiten ondergebracht. Een hub kan meerdere satellieten hebben en is daarmee flexibel uit te breiden.

Het mooie van Data Vault is dat het slechts deze drie entiteitsoorten kent. Daarmee is het eenvoudig inzichtelijk te maken.

Tijdens onze discussie konden we al snel een verband leggen met een object georienteerd domeinmodel. Deze zou je makelijk middels Data Vault kunnen persisteren. Het is zelfs relatief eenvoudig om hier een frameworkje voor te schrijven. Stel je voor dat je een .NET LinkToDataVault provider hebt. Deze provider kan op basis van annotaties (attributen in .NET) makelijk de mapping tussen het objectmodel en de relationele database maken. Het voordeel van deze aanpak is dan dat je minder database aanpassingen hoeft door te voeren wanneer je objectmodel wijzigd. Je zult namelijk slechts database uitbreidingen hebben en beperkt tot geen wijzigingen.

Een mooi punt om in een POC te bewijzen. Mocht je dus nog een leuke informatica afstudeeropdracht zoeken 🙂 …. Neem gerust contact op

Smalltalk bijeenkomst

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.

Gepubliceerd op
Gecategoriseerd als Blog

Mooie code!

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.

Gepubliceerd op
Gecategoriseerd als Blog

SDN Architectuur track

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.

Gepubliceerd op
Gecategoriseerd als Blog

Specificeren versus verifiëren

Unittesten is iets wat we inmiddels allemaal kennen. In een methode als Test Driven Development hebben we zelfs het doel om eerst de testen te specificeren en daarna de code (het gedrag) te implementeren. Dat klinkt goed en werkt ook goed als de applicatie architectuur het ondersteund. Dat we binnen Sogyo volgens een domein gedreven architectuur werken is inmiddels wel bekend en daar past deze stijl ook erg goed bij.

Op dit moment is er een interessante ontwikkeling gaande die vooral in de Ruby-wereld al uitgebreid toegepast wordt en met groot succes. Het gaat om specificatietalen. In zijn artikel A new look at Test Driven Development beschrijft Dave Atels op een beeldige manier wat het verschil is tussen de specificatietalen en testgedrevenheid. In essentie komt het neer op vooraf specificeren versus het achteraf verifiëren. Dan zou je kunnen zeggen “lekker spannend”. Echter wat het wat mij betreft interessant maakt is het feit dat je met specificatietalen dus vooraf formeel kunt beschrijven waaraan de implementatie moet voldoen. Je specifieert dus in een executeerbare taal. (Puur technisch gezien gelijkwaardig aan Unittest technieken). Dat zegt natuurlijk ook iets over de (lage) abstractie waarin de specificatie plaatsvindt. Die zou in dit geval op scenario niveau binnen een Use Case moeten liggen om concreet genoeg te zijn. Dat is mooi!
We hebben recent voor een klant een platform gerealiseerd waarin de ontkoppeling van het domein met de presentatie services plaatsvindt door “contracten” (of views op het domein) op Use Case niveau te definiëren. Dat betekent dus dat je een specificatietaal in moet kunnen zetten om tests voor deze contracten vooraf te schrijven. Interessant terein om verder te ontdekken.

Overigens zijn er best veel ontwikkelingen op gebied van specificatietalen. RSpec is in de Ruby-wereld een heel bekende. JBehave en NBehave lijken goede alternatieven voor Java en .NET. Maar ook Microsoft zelf is druk bezig met een implementatie. Je moet er nog even voor op zoek binnen Microsoft Research, maar Spec# klinkt veelbelovend.

Gepubliceerd op
Gecategoriseerd als Blog

SDC presentatie

Afgelopen dinsdag heb ik op de SDC een korte presentatie over DDD en DSL gegeven. Tijdens deze sessie heb ik laten zien hoe je met een horizontale DSL ondersteuning kan leveren voor NHibernate persisitentie in een domein gedreven architectuur. We hebben met name discussie gevoerd en demo’s bekeken. De ondersteunende slides voor de sessie vind je hier: DDD en DSL een mooie combinatie!.

Vanuit Sogyo overwegen we de DSL voor NHibernate open source te gaan maken. Er moet dan nog eerst een aantal uitbreidingen doorgevoerd worden die we op onze wensen lijst hebben staan. Interessante van deze DSL is dat je geen zorgen meer hoeft te maken over het maken van de mapping en configuratie files. Dit levert op dat bijvoorbeeld front-end ontwikkelaars hun werk kunnen persisiteren zonder diepgaande kennis over NHibernate te hebben. Het verbergt dus een deel van de complexiteit. Dit is wat mij betreft ook de grootste toegevoegde waarde van DSL. Interessant genoeg om er verder mee aan de slag te gaan.

Mocht je er meer over willen lezen. Samen met Andre Boonzaaijer ben ik een artikel aan het schrijven voor Software Release Magazine hierover. Wil je meer tijd vrij maken dan is het boek van Steve Cook echt het aanraden waar: Domain-Specific Languages with Visual Studio Tools een aanrader.

Gepubliceerd op
Gecategoriseerd als Blog