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.

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.

Tags: , ,

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

Tags: , ,

Afgelopen week is het expert panel voor software ontwikkeling gevormd. Als lid van dit panel zal ik mijn bijdragen leveren aan artikelen/discussies die gepost worden op de site van de Computable en het blad zelf. Door deel te nemen aan dit panel kan ik mijn mening laten horen over moderne software ontwikkeling.  Ik ga er vanuit dat er vele interessante discussie gaan komen. De eerste discussie die door de redactie gestart is heet: “Ontwikkelaar omarmt agile en Web 2.0“. Niet echt twee onderwerpen die direct samenhangen, maar het gaat wat mij betreft dan ook om de achterliggende discussie die men wil los maken.

In Automatiserings Gids is deze maand het artikel “Domeingeoriënteerde applicatiearchitectuur: nut en onnut” verschenen. In dit artikel gaan Wilco (algemeen directeur bij Sogyo) en ik in op software-ontwikkelstijlen waarin het (business)domein centraal staat. Denk daarbij aan vragen als:

  • Wat maakt deze stijl zo bijzonder?
  • Wanneer kies je voor een domeingeoriënteerde applicatiearchitectuur?
  • Welke voor- en nadelen zijn er in de praktijk?
  • Welke aandachtspunten zijn er bij een domeingeoriënteerde benadering?
  • Heeft de domeingeoriënteerde applicatiearchitectuur toekomst?

Interesse in de antwoorden?

Read the rest at http://www.sogyo.nl/in-de-media/domeingeorienteerde-applicatiearchitectuur-nut-en-onnut/

Afgelopen week was de Europan Smalltalk User Group (ESUG) bijeen in Amsterdam. Tijdens de bijeenkomst zijn verschillende presentaties gegeven over uiteenlopende Smalltalk gerelateerde onderwerpen. Dat smalltalk springlevend is blijkt 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 (Open Croquet) Er gebeurt wat ons betreft zoveel in dit speelveld dat Sogyo op 2 oktober een studentenseminar organiseren rondom het thema Smalltalk.

Read the rest at http://www.software-innovators.nl/2008/09/01/smalltalk-bijeenkomst/

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.

Read the rest at http://www.software-innovators.nl/2008/08/13/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.

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.

Read the rest at http://www.software-innovators.nl/2008/02/27/specificeren-versus-verifieren/

« Older entries