Webblog

Agile werken en denken in relatie tot ISO 27001 (of welke geformaliseerde certificering dan ook)

Agile werken en denken in relatie tot ISO 27001 (of welke geformaliseerde certificering dan ook)

Als Scrum Master ben ik onlangs betrokken geweest bij het verkrijgen van een ISO 27001 certificering voor mijn eindklant.
Het hebben van een ISO 27001 certificering als organisatie betekent dat het voldoet aan de privacy- en securityrichtlijnen die zijn gedocumenteerd door ISO: https://www.iso.org/standard/54534.html.

De certificering omvat richtlijnen voor de volgende gebieden:

  • Kantoor toegangsbeveiliging
  • Werkplek beveiliging
  • Infrastructuur (netwerk & telefonie) beveiliging
  • Applicatie en data beveiliging

De richtlijnen concentreren zich vooral op de werkprocessen en minder op (technische) oplossingen. Het verwijst echter wel naar andere standaarden. Bijvoorbeeld op het gebied van applicatie & data beveiliging, verwijst het naar OWASP richtlijnen.

De perceptie van iedere vorm van certificering is dat het bureaucratie introduceert die wordt vastgelegd in uitgebreide documentatie die (bijna) niemand leest. Ik hoop met dit artikel te beschrijven dat deze perceptie enige nuance verdient.

De nuance wil ik aanbrengen door middel van het doorlopen van het ‘Agile Manifesto’ (https://agilemanifesto.org/iso/nl/manifesto.html). Hoewel het Manifesto al twee decennia geleden is opgesteld, is tegenwoordig het voor bedrijven nog steeds het handvat voor softwareontwikkeling. Het Manifesto heeft 4 kernwaarden:

  • Mensen en hun onderlinge interactie boven processen en hulpmiddelen
  • Werkende software boven allesomvattende documentatie
  • Samenwerking met de klant boven contractonderhandelingen
  • Inspelen op verandering boven het volgen van een plan

Discussie over deze kernwaarden heb ik nogal eens waarbij het idee leeft dat zodra ‘agile’ wordt gewerkt, er anarchie is over de software implementatie en bewaking. Ook dit verdient nuance.

Mensen en hun onderlinge interactie

Het voorbereiden op een ISO-audit vereist een nauwe samenwerking tussen afdelingen en medewerkers om de processen in kaart te brengen. Deze ‘agile’ waarde komt juist tot zijn kracht op het moment dat processen worden beschreven die ondersteunend zijn aan de medewerkers. Een Scrum ritueel als bijvoorbeeld Sprint Review kan hierbij faciliteren. Doordat mensen samenwerken komen tekortkomingen en kansen boven drijven. ISO-richtlijnen geeft hierbij handvatten voor aandachtsgebieden. Kortom, als we deze kernwaarde beschouwen, versterken ISO en Agile elkaar.

Werkende software

Om tot werkende software te komen zijn nu eenmaal binnen een team afspraken noodzakelijk die beschrijven hoe code de ‘softwarefabriek’ doorloopt. Hierbij is cruciaal dat vooraf acceptatiecriteria zijn opgesteld en dat deze bij oplevering worden getoetst. ISO stelt geen voorwaarden welke stappen de ‘softwarefabriek’ moet bevatten. Echter, het stelt voorwaarden dat vooraf wordt nagedacht over de gevolgen voor de gebruiker of organisatie op het gebied van gegevens beveiliging. Het team heeft hiervoor velden in Azure DevOps geïmplementeerd om de gevolgen op beveiliging en privacy te documenteren (‘Security and privacy by design’). Het vooraf opstellen van de verwachte gevolgen voorkomt bevindingen later in de ‘softwarefabriek’.

Veel teams hebben een platform om hun software te documenteren. Vaak bevat dit platform ook een beschrijving van hun ‘softwarefabriek’. Het ontwikkelteam heeft ervoor gekozen de documentatie te borgen in hun ‘eigen’ omgeving; Azure DevOps. Deze heeft een Wiki. Op deze manier is de impact voor het team minimaal omdat het geen andere omgeving eigen hoeft te maken. Voor de softwareontwikkelaars is code eigenlijk de documentatie.

De Wiki die in het ontwikkelteam gebruikt bevat niet meer documentatie dan de samenhang van onderdelen in het landschap. UML-modellen worden niet vereist en ook niet gebruikt omdat deze te weinig actueel blijven. De Wiki helpt nieuwe teamleden tijdens het inwerkproces.

Daarnaast is de integratie met het volgen van de softwareontwikkeling naadloos. In de documentatie zijn gegevens als bijvoorbeeld openstaande bugs online beschikbaar bij de documentatie.

Samenwerking met de klant

Vooral op het gebied van vooraf nadenken over gevolgen op privacy en beveiliging komt het team nader tot de klant. Hierbij wordt het discussiëren over een wens met dubieuze gevolgen niet uit de weg gegaan. Het heeft de organisatie geholpen om voor grotere user stories (‘Epics’) een “Data Protection Impact Assessment” op te stellen. Net zoals bij de vorige kernwaarde, geeft dit eerder in het ontwikkelproces heldere verwachtingen over de gevolgen en daarmee de maatregelen die erbij horen.

Inspelen op verandering

ISO stelt geen eisen over het te volgen ontwikkelproces. Als Scrum Master faciliteer ik de werkvormen en rituelen van het Scrum Framework. Het is een kwestie van documenteren hoe deze werkvormen in dagelijkse operatie worden uitgevoerd. Uitkomst van een Retrospective worden opgenomen in de Product Backlog. Bevindingen en opmerkingen tijdens een demo worden als ‘bevinding’ opgenomen in de Product Backlog.

Zolang de werkvormen en de workflow van de organisatie zijn gedocumenteerd, is deze kernwaarde eenvoudig te beschrijven conform ISO-richtlijnen. Het is eigenlijk niet meer dan ‘prove what you have written down’. Azure DevOps biedt hiervoor uitstekende tracking gereedschappen waarbij vanaf user story tot en met productie oplevering alles is te herleiden.

Conclusie

Eerlijk is eerlijk, vooraf was ik sceptisch over het te volgen traject. Echter, juist de kernwaarden van het Agile Manifesto hebben de organisatie geholpen om pragmatisch en gestructureerd zich voor te bereiden op de ISO-certificering. Als Scrum Master had ik het belang dat de gevolgen voor het ontwikkelteam werden beperkt. Dat is gelukt; geplande opleveringen en kwaliteit hebben geen nadelige gevolgen ondervonden.

Ik kan melden dat de organisatie met vlag en wimpel het ISO 27001 certificaat heeft gehaald. Wil je meer weten hoe ik dit het met de organisatie en het team heb aangepakt? Ik ben bereikbaar via akraak@bergler.nl, 076 – 572 02 00 of info@bergler.nl.

Auteur: Arjen Kraak © 2020 Bergler Competence Center

berglerAgile werken en denken in relatie tot ISO 27001 (of welke geformaliseerde certificering dan ook)
Lees meer

Python, een korte introductie (voor C# ontwikkelaars)

Python, een korte introductie (voor C# ontwikkelaars)

Python is een ontwikkeltaal die al enige tijd sterk in opkomst is. Als ‘T-shaped’ software ontwikkelaar kunnen we hier niet langer om heen. Dit is voor ons ook de aanleiding geweest om eens een blik te werpen op deze taal. In dit artikel willen we een globale introductie geven van Python de ontwikkeltaal en daarnaast de kenmerkende verschillen met C# aanstippen.

Hoe is het ontstaan
“Python is een programmeertaal die begin jaren 90 ontworpen en ontwikkeld werd door Guido van Rossum, destijds verbonden aan het Centrum voor Wiskunde en Informatica (daarvoor Mathematisch Centrum) in Amsterdam. De taal is mede gebaseerd op inzichten van professor Lambert Meertens, die een taal genaamd ABC had ontworpen, bedoeld als alternatief voor BASIC, maar dan met geavanceerde datastructuren. Inmiddels wordt de taal doorontwikkeld door een enthousiaste groep, tot juli 2018 geleid door Van Rossum. Deze groep wordt ondersteund door vrijwilligers op het internet. De ontwikkeling van Python wordt geleid door de Python Software Foundation. Python is vrije software.
Python heeft zijn naam te danken aan het favoriete televisieprogramma van Guido van Rossum, Monty Python’s Flying Circus.”
Bron: https://nl.wikipedia.org/wiki/Python_(programmeertaal)

Toepassingsgebieden
Python is geschikt voor een breed scala aan, zo niet alle, toepassingsgebieden. De voornaamste toepassingsgebieden waar Python momenteel wordt gebruikt zijn:

  • (BI) Data science
  • (ML) Machine Learning
  • (AI) Artificial Intelligence
  • (IOT) Internet Of Things

Andere toepassingsgebieden zijn o.a.:

  • Web applicaties
  • Web (REST) API’s
  • Desktop applicaties
  • OS scripting

Kenmerken
In onderstaande tabel worden enkele kenmerken van de Python programmeertaal opgesomd met daarnaast de C# programmeertaal als tegenhanger:

Dynamically typed versus statically typed

In een ‘dynamically typed’ programmeertaal zoals Python, is het niet noodzakelijk om variabelen met een bepaald type van te voren te declareren. Een variabele kan zelfs tijdens de uitvoering van het programma van type wisselen. In een ‘statically typed’ programmeertaal zoals bijvoorbeeld C#, dienen de variabelen van te voren, als zijnde van een bepaald type, te worden gedeclareerd.
De onderstaande code is correct in Python, maar zal compiler fouten opleveren in C#:

Python:

Deze code zal zonder problemen worden uitgevoerd en print de tekst “Hello world” in de console.

Figuur 1- Dynamically typed voorbeeld

C#:

Deze code zal niet compileren en zal dus niet worden uitgevoerd.


Figuur 2- Strongly typed voorbeeld

Duck typed vs Strongly typed

De term ‘Duck typing’ is voortgekomen uit de zin “If it looks like a duck and quacks like a duck, it is a duck” en wordt voornamelijk toegepast in dynamische programmeertalen. Bij duck typing gaat men ervan uit dat je geen type nodig hebt om een bestaande methode op een object uit te voeren, zolang de methode zelf maar aanwezig is. De volgende python code is een voorbeeld van Duck typing en compileert zonder problemen:


Figuur 3- Duck typing in dynamische taal

Het probleem komt pas boven water tijdens de uitvoering van het programma (run time):


Figuur 4- Runtime error

Omdat C# een strongly typed programmeer taal is zal zulke code direct leiden tot een compiler error, omdat de compiler niet het juiste type van de objecten kan bepalen:


Figuur 5- Compile error

Indentation based vs syntax based

Python is ‘Indentation based’ de code van een Python programma is gestructureerd d.m.v. ‘indentation’ (inspringen), terwijl de code van een C# programma gebaseerd is op een vastgelegde syntax. Om binnen Python aan te geven dat een stukje code bij elkaar hoort en gezien dient te worden als 1 code blok gebruik je ‘indentation’. De scheiding van de verschillende code blokken wordt aangegeven door 1 of meerdere lege regels.


Figuur 6- Frame class in Python gebaseerd op ‘indentation’

In een op syntax gebaseerde programmeertaal, zoals C# worden de code blokken gedefinieerd doordat de verschillende code regels omsloten zijn door een bepaald symbool, in C# zijn dit de accolades {}.


Figuur 7- Frame class in C# gebaseerd op syntax

Object georiënteerd

Zowel Python als C# zijn programmeer talen waarin je object georiënteerd kunt programmeren. Een van de kenmerken van object georiënteerd programmeren is overerving. Dit kan in Python als wel in C# gerealiseerd worden. De volgende code snippets geven een voorbeeld van een Persoon class en een Student class, waarbij de Student class afgeleid is (overerft) van de Persoon class.

Overerving in Python:

Figuur 8- Voorbeeld overerving in Python

Overerving in C#:

Figuur 9- Voorbeeld overerving in C#

Programmeer-oefening Python

Voor onze interne competence center avond (pizza-avond) hadden we een oefening voorbereid, waarmee onze collega’s aan de slag konden om zo wat eerste ervaringen op te doen met programmeren in Python. Deze oefening is gebaseerd op de wel bekende ‘Bowling kata’.
Mocht je interesse zijn gewekt om eens met Python aan de slag te gaan, dan kan je deze oefening hier vinden:
Bowling Kata programmeer oefening.

In het readme.md bestand vind je een beschrijving van de oefening en hoe je hiermee aan de slag kunt gaan.
Veel plezier op je Python ontdekkingsreis!

Auteur: Marcel Slegt © 2020 Bergler Competence Center

berglerPython, een korte introductie (voor C# ontwikkelaars)
Lees meer

Zeven tekenen van rottende software

Zeven tekenen van rottende software

Hopelijk begin je een software ontwikkeling met een redelijk tot goed idee hoe de toekomstige software er uit moet zien. Een helder beeld hebben van de toekomstige software is belangrijk voor jezelf en voor je team. Als je geluk hebt, overleeft dit beeld het tot de eerste release. Maar na verloop van tijd gebeurt er iets, de software begint langzaam maar zeker te ruiken als een stuk bedorven vlees.

Hoewel geen enkele ontwikkelaar dit wil, is het een realiteit die ik maar bij al te veel ontwikkelaars tegenkom. In de loop van de tijd is onder druk van deadlines, wijzigende functionaliteit, wijzigende teamsamenstelling de software langzaam maar zeker steeds ondoorzichtiger geworden. In dit document ga ik in op zeven tekenen van software rot en wat je kunt doen om dit zoveel mogelijk te voorkomen.

Rigiditeit
Rigide software is software die moeilijk aan te passen is. Een op het eerste gezicht simpele aanpassing stuurt resulteert in een cascade van gevolgschade in diverse modules. Hoe meer plekken geraakt worden door aanpassingen, hoe meer rigide het systeem is. Veel ontwikkelaars herkennen hoe een simpele aanpassing een waterval van ellende over ze heen stort waardoor ze steeds meer code moeten aanpassen en de wijziging veel langer duurt dan oorspronkelijk was ingeschat. Als ze dan gevraagd wordt waarom hun inschatting zoveel te laag was, volgt het traditionele antwoord “het was een stuk complexer dan ik had verwacht.”

Breekbaarheid
De breekbaarheid van een systeem wordt bepaald door de kans dat een wijziging op één plek op vele andere plekken onverwachte fouten introduceert. Soms kan het voorkomen dat er fouten optreden op plekken die niet logischerwijs gerelateerd zijn aan de aangebrachte wijziging.

Immobiliteit
Een ontwerp is immobiel wanneer het componenten bevat die voor andere systemen nuttig zouden zijn, maar niet geïsoleerd kunnen worden omdat het risico en de kosten om ze uit het originele systeem te halen gewoonweg te groot zijn.

Viscositeit
Als er een wijziging in software moet worden aangebracht kan dit meestal op meerdere manieren. Sommige manieren zijn in lijn met het ontwerp en de architectuur van de software en andere niet (ook wel hacks genoemd). Een systeem heeft een hoge viscositeit wanneer een aanpassing in lijn met de architectuur meer tijd kost dan een hack. Naast de viscositeit van de software is er ook nog de viscositeit van de ontwikkelomgeving in zijn geheel. Wanneer het uitvoeren van geautomatiseerde tests heel veel tijd kost, is het waarschijnlijk dat de ontwikkelaar een wijziging doorvoert zonder de juiste testen op te zetten.

Nodeloze herhaling
Of ook wel het knippen en plakken van code genoemd. Meestal wordt dit veroorzaakt doordat het systeem niet de juiste abstracties implementeert en niet conform design patterns als SOLID is opgezet. Vaak is het een teken dat er te weinig tijd (of ervaring) binnen een team is om na te denken over architectuur. Wat overblijft, is veelal procedurele code die weliswaar functioneert, maar lastig te onderhouden is.

Duidelijkheid
De duidelijkheid van een module bepaald in hoeverre het eenvoudig is voor een ontwikkelaar om een module te begrijpen. Code die met de tijd doorontwikkeld is, heeft de neiging om steeds minder duidelijk te zijn.

Nodeloze complexiteit
Dit is misschien wel een van de lastigste punten om aan te pakken. Gepassioneerde ontwikkelaars zullen in hun inzet om de overige zes tekenen van software rot te voorkomen, mogelijk in de valkuil van deze zevende stappen. Een goed software ontwerp is lichtgewicht, flexibel, eenvoudig om te begrijpen en bovenal eenvoudig om aan te passen.

Omgaan met rottende software
Helaas is er geen “silver bullet” als het gaat om software rot. Ervaren ontwikkelaars zullen misschien minder snel in valkuilen stappen dan minder ervaren ontwikkelaars, maar uiteindelijk maken we allemaal fouten.

Er zijn wel een aantal zaken die helpen om software rot te voorkomen:

  • Zorg dat de software voldoende afgedekt is door automatische testen
  • Zorg bij iedere wijziging en nieuwe feature voor voldoende tijd om te refactoren
  • Peer review elkaars code
  • Pair program wanneer je een ingewikkeld stuk moet opzetten
  • Zorg voor heldere coding guidelines voor het team
  • Maak architectuurbeslissingen altijd met meerdere ontwikkelaars samen

“Last-but-not-least” zoals een collega van mij vaak mooi weet te zeggen: “perfect is the enemy of good”. Probeer niet de perfecte architectuur te maken, die bestaat niet, en waarschijnlijk wordt je systeem al snel nodeloos complex.

Auteur: Menno Jongerius © 2020 Bergler Competence Center

berglerZeven tekenen van rottende software
Lees meer

Kan Cloud Native On-Premises zijn?

Kan Cloud Native On-Premises zijn?

Nee, dit gaat niet over het On-Premises thuiswerken met behulp van Cloud Diensten in onheilspellende tijden van het Coronavirus. Dit gaat over vraag “kun je Cloud Native zijn met een On Premises serverpark?” Vreemde vraag leek mij. Volgens Wikipedia is Cloud Native een softwareontwikkeling aanpak die maximaal de mogelijkheden van Cloud Computing gebruikt. Dit strookt niet direct met een On Premises aanpak. Vanwaar dan toch deze vraag? Dit is naar aanleiding van het rapport van VMWare “The State of Kubernetes 2020.

Dit is het nieuwste onderzoeksrapport van VMWare onder een aantal grote organisaties naar de status van Kubernetes. Het rapport heeft wat verrassende uitkomsten zoals dat 64% van de ondervraagden Kubernetes On-Premises draaien, wat meer is dan vergelijkbare rapporten. Dit heeft waarschijnlijk te maken met het type organisaties dat VMWare in dit onderzoek heeft ondervraagd. Het zijn namelijk alleen organisatie met 1000 of meer medewerkers. Organisaties van deze omvang hebben wellicht zelf al veel infrastructuur staan, waardoor de switch naar de cloudproviders minder snel van belang is.

Het ligt voor de hand dat in het kader van de bovenstaande uitslag de onderstaande quote in het rapport is opgenomen:

“Cloud native isn’t about where you operate, it’s how you operate.”

(Joe Beda, Principal Engineer, VMware and co-creator of Kubernetes)

Dit is een uitspraak waar ik even van op mijn hoofd moest krabben. Is het zo dat de manier waarop je werkt bepaalt of je cloud native bent en niet de plek? Om dit te kunnen beantwoorden moet ik eerst antwoord hebben op de vraag:

Wat is eigenlijk cloud native?
Als we praten over cloud native dan is de Cloud Native Computing Foundation direct de organisatie waar je aan zult denken. Met de gang naar de cloud is het makkelijker geworden om open source projecten van verschillende bronnen te adopteren, waardoor je organisatie meer kan focussen op business logica en minder op het technische loodgieterswerk. De CNCF heeft als doel om deze open source projecten te beoordelen zodat jij als organisatie enige zekerheid hebt voor de continuïteit en dat je geen vendor lock-in hebt. Dit zijn projecten waarmee je comfortabel de cloud in kunt. Hiervoor heeft het CNCF een overzicht van al hun projecten op 1 plek: https://landscape.cncf.io/.

Het CNCF is de autoriteit op het gebied van cloud native en hebben ook de definitie voor cloud native opgesteld. Vrij vertaald is het ongeveer:
Cloud native technologieën geven organisaties de mogelijkheid om moderne schaalbare applicaties te ontwikkelen en te runnen, in dynamische omgevingen zoals de public, private en hybride clouds. Het gebruik van containers, service meshes, microservices, immutable infrastructuur en declaratieve API’s bevestigen deze aanpak.
Dan terug naar de vraag kan Cloud Native On-Premises zijn. Het antwoord zit hem in de Private Cloud definitie.

Private Cloud (!)= On-Premises
Private clouds kunnen er in vele verschijningsvormen zijn. Zo zijn er private hosted clouds waarbij niet gedeelde dedicated hardware door een cloud provider beschikbaar is gesteld. Of een internal hosted private cloud waarbij de omgeving op de interne infrastructuur van de organisatie geplaatst is. In dit laatste geval kan men spreken van een On-Premises omgeving.
Als men in een dergelijke omgeving gebruik maakt van cloud native projecten zoals door het CNCF worden ondersteund (bijv. Kubernetes) dan kan men spreken over Cloud Native op een On-Premises omgeving.

Wenselijk?
De vraag blijft dan: is het wenselijk om een Cloud Native On-Premise oplossing te ontwikkelen? Dit kan in veel gevallen een prima oplossing zijn. Door geen gebruik te maken van de public cloud kan men b.v. lastige vraagstukken voor legal & compliance ontwijken. Het kan een prima startpunt zijn om met cloud native projecten kennis te maken. Uiteindelijk kan het ook als startpunt functioneren om een hybrid cloud scenario te ontwikkelen.

Het heeft ook een keerzijde, zo ontneem jezelf de mogelijkheid tot het gebruik van managed public cloud diensten. Denk bijvoorbeeld aan AKS, GKE of EKS (managed Kubernetes), Azure SQL of Cosmos DB. Dit zorgt voor meer onderhoud op dergelijke producten of ze kunnen überhaupt niet On Premises worden afgenomen.
Dit zijn overwegingen die moeite waard zijn om te bekijken maar, uiteindelijk is het hebben van een cloud native strategie in een On Premise omgeving prima mogelijk.

Bronnen:
https://k8s.vmware.com
https://www.cncf.io
https://www.capgemini.com
https://github.com

Auteur:
Patrick Bes, Bergler Competence Center © 2020

berglerKan Cloud Native On-Premises zijn?
Lees meer

Threat Modeling

Threat Modeling

In het huidige software ontwikkelingslandschap is het steeds sneller opleveren van software een belangrijk issue. Organisaties moeten mee in de DevOps beweging om hun concurrentiepositie te behouden of te verbeteren. Om dit goed en veilig te kunnen doen is het van belang om zo vroeg mogelijk in het ontwikkelproces al feedback te verzamelen, om snel te kunnen bijsturen. Dit vatten we vaak samen in de zogenaamde Shift Left beweging. Shift Left is een verzameling van kwaliteitsborging methodieken zoals o.a. unittesting, performancetesting & componenttesting.

Naast deze belangrijke testfeedback is ook op het gebied van security een van belang dat men zo vroeg mogelijk een helder beeld heeft van de potentiele security risico’s. De wolf in schaapskleren moet al vroeg worden geïdentificeerd. Hiervoor zijn er al tientallen geleden jaren methodieken bedacht, welke helaas vaak over het hoofd worden gezien. DevOps is een manier om een kortere “time to market” te bewerkstelligen, maar daarnaast ook een lager faalpercentage bij opleveringen. Het beperken van security issues in productie is hier natuurlijk ook onderdeel van. Threat Modeling is bij uitstek een methodiek om bij dit laatste te helpen.

Deze methodiek bestaat uit 5 stappen die zich herhalen binnen de Software Applicatie LifeCycle. Het herhalende karakter past ook prima in het herhalende karakter van DevOps,. Of bij het gebruik van deze methodiek wellicht wel DevSecOps, omdat security nu een prominentere rol krijgt. De stappen die men kan ondernemen zijn:

Define: Vastleggen van de securityeisen.
Niet in elke app zullen de securityeisen gelijk zijn. Indien er met persoonlijke data wordt gewerkt zullen er vast eisen zijn vanuit wetgeving c.q. beleid van uit de organisatie zelf. Zorg ervoor dat deze duidelijk zijn.

Diagram: Het maken van een applicatiediagram
Om inzicht te krijgen in de potentiële dreigingen is het makkelijk om de flow van de betreffende applicatie te modelleren. Dit kan men doen in specifieke Threat modeling tooling zoals bijvoorbeeld Thread Dragon: https://threatdragon.org/login.

Hierin kan men de applicatie weergeven via een eenvoudige Data Flow Diagram bestaande uit Processen, Stores, Actors en/of DataFlows zoals hier weergegeven.

Identity: Het identificeren van de potentiële bedreigingen
Na het opstellen van het diagram kan men met Trust boundaries koppelvlakken aangeven waar men risico’s herkend. Het model kan na deze stap er als volgt uit zien (De groene stippellijnen representeren de Trust Boundaries):

Mitigate: Het mitigeren van de bedreigingen
In 1999 hebben Praerit Garg and Loren Kohnfelder bij Microsoft het STRIDE Model ontwikkeld. Met dit model kan men per trust boundary de specifieke kwetsbaarheden classificeren. STRIDE is een acroniem voor:

Men kan nu per trust boundary inventariseren welke onderdelen van STRIDE hier een bedreiging vormen. In het eerdere voorbeeld kunnen wij aangeven dat Spoofing Identity tussen de browser en webapplicatie een potentieel risico is. Dit risico kan in dit geval bijvoorbeeld gemitigeerd zijn door het gebruik van een signed authenticatie token. Zo kan men alle trust boundaries langs lopen en aan de hand van STRIDE de risico’s inventariseren en bepalen of deze adequaat zijn gemitigeerd.

Validate: Het valideren of alle bedreigingen zijn gemitigeerd
Na het mitigeren van de potentiële bedreigingen is het nog steeds van belang dat men valideert of er toch geen security leaks of kwetsbaarheden in de applicatie zijn geslopen. Het hebben van geautomatiseerde security scans, dependency checks in de pipeline en real time is nog steeds van belang. Daarnaast kunnen er, nu inzichtelijk is waar de potentiele grootste risico’s zitten, abuse cases worden opgesteld. Op basis hiervan kunnen weer specifieke test scenario’s worden bedacht om de gemitigeerde bedreigingen te valideren.

Tot slot
Het kan goed zijn om deze modellering techniek in je DevOps proces op te nemen. Hierdoor kunnen potentiële security leaks al vroegtijdig worden geïdentificeerd en kan hierop worden geacteerd. Het neemt initieel niet veel extra tijd in beslag en kan veel opleveren. Het vergroot in ieder geval de security awareness bij alle betrokkenen en dat is altijd winst.

Auteur: Patrick Bes © Bergler Competence Center 2020

berglerThreat Modeling
Lees meer

Domain Driven Design (DDD) in gewoon Nederlands

Domain Driven Design (DDD) in gewoon Nederlands

Introductie naar Domain Driven Design (DDD)

Als Lead Developer ben ik betrokken bij het opmaken van business cases, uitwerken van ideeën en het implementeren van softwareoplossingen. Een steeds vaker terugkomend thema is dat mijn relaties hun applicatie landschap willen moderniseren zonder opnieuw het wiel te willen uitvinden.

berglerDomain Driven Design (DDD) in gewoon Nederlands
Lees meer

Valkuilen in async/await

Valkuilen in async/await

Het is inmiddels alweer behoorlijk wat jaren geleden dat Microsoft async/await introduceerde in het .NET Framework. Het gebruik van async/await heeft het mogelijk gemaakt om met heel weinig code asynchroon te programmeren. Helaas betekent dit niet dat het eenvoudig is om asynchroon te programmeren, en ik heb mijzelf meermalen in de voet geschoten doordat ik te kort door te bocht wilde gaan. Bij deze wat valkuilen waar ik tegenaan ben gelopen, maar eerst even de twee belangrijkste redenen om asynchroon te programmeren.

Waarom async/await een goede zaak is

Er zijn eigenlijk twee belangrijke redenen om async/await toe te passen. In webapplicaties zal de webserver (afhankelijk van de gekozen technologie) maar een beperkt aantal threads tegelijk in een workerprocess afhandelen. Dit betekent dat bij een groot aantal gelijktijdige verzoeken de webserver processen in de wacht gaat zetten. Door gebruik te maken van async/await, wordt de calling thread van het workerprocess vrijwel direct vrijgegeven, terwijl een background thread de bulk van het werk uitvoert. In client applicaties (Windows en apps) zijn asynchrone processen vooral van belang omdat de UI-thread wordt vrijgegeven en de applicatie dus goed blijft reageren op de gebruiker, terwijl processen op de achtergrond worden afgehandeld. Elke langlopende taak (database, I/O of zware berekening) leent zich om in een asynchrone taak af te handelen.

Valkuil 1: Deadlocks

In het voorbeeld hieronder wordt het resultaat van een taak uitgevraagd. Stel dat dit een asynchrone methode is, die zelf ook gebruik maakt van async/await, dan creëer je een deadlock. Dat komt omdat het aanroepen van Result, de UI-thread in de wacht zet totdat het resultaat van de methode terugkomt. Als de methode zelf een await commando gebruikt, zal deze een thread opstarten en na afloop het werk willen teruggeven aan de UI-thread. Dat kan echter niet omdat deze UI-thread aan het wachten is op het resultaat van de functie die hij nu zelf zou moeten uitvoeren.

Ofschoon dit fenomeen vooral voor zal komen in een Windows applicatie of app, is het niet uit te sluiten dat deadlocks voorkomen in een webapplicatie wanneer je zelf de asynchrone taken beheert en niet gebruik maakt van de asynchrone controllers van ASP.NET.

Oplossing

Zorg dat de methode nadat deze gereed is, wordt opgevolgd door een nieuwe asynchrone taak die het resterende werk uitvoert. In de praktijk is het aan te raden om een class op te zetten die alle uitkomsten van een taak correct afhandelt, want er komt nogal wat bij kijken om alle foutafhandeling en cancellation scenario’s in te bouwen.

Valkuil 2: UI werk op een niet-UI-thread

In het voorbeeld hierboven werd het resultaat van een taak gebruikt in op een label de content te veranderen. Dit gaat fout in Windowsapplicaties en apps wanneer een andere thread dan de UI-thread deze code uitvoert.

Oplossing

Stuur het werk dat naar de UI-thread moet via de Dispatcher naar de UI-thread. Deze is toegankelijk vanaf een window/usercontrol of via het Application object. In de praktijk schijf ik er altijd een proxy met interface voor, zodat ik de code ook kan unittesten.

Valkuil 3: incorrecte/geen foutafhandeling

Binnen een async/await context worden fouten netjes doorgegeven aan de aanroepende thread. Wanneer je aan het einde van de call-chain aankomt, is het heel gemakkelijk om de foutafhandeling te vergeten.

Bovenstaande code zal zonder problemen draaien, maar indien er in de ExecuteAsync een fout plaatsvindt zal deze niet zichtbaar worden in de aanroepende thread. Gebruik om dezelfde reden geen async void (tenzij je zeker weet wat je doet), maar retourneer altijd een taak zodat eventuele fouten afgehandeld kunnen worden. Wanneer je de code aanpast naar ExecuteAsync().Wait() zal er wel een fout optreden, echter dan krijg je weer deadlock problemen.

Oplossing

Schrijf, zoals in een eerder voorbeeld, een juiste continuatie taak waarin eventuele fouten worden afgehandeld.

Schrijf wat er moet gebeuren wanneer er een fout optreedt (bij voorkeur wat charmanter dan MessageBox.Show).

Valkuil 4: await alleen als het nodig is

In het bovenstaande voorbeeld wordt de ReadFileAsync methode aangeroepen. De aanroepende methode zal bij het await keyword een nieuwe thread opstarten om het asynchrone werk op te pakken. De ReadFileAsync methode zal nogmaals een thread opstarten bij het await keyword. Deze laatste is onnodig omdat de waarde van ReadToEndAsync in deze methode niet gebruikt wordt. In dit geval is het beter om geen async/await te gebruiken, maar rechtstreeks een Task te retourneren.

Oplossing

Geef een taak terug zodat er slechts een thread opgestart wordt bij de eerste await. Let wel op dat je in dit geval de boundaries van de code goed in acht neemt. De using statements moeten hier binnen de taak liggen en niet erbuiten anders zijn deze objecten al opgeruimd terwijl de taak nog draait.

Valkuil 5: start niet onnodig threads op

Los van de zaken die in bovenstaande code niet juist zijn, zoals het niet afhandelen van fouten en onhandig aanmaken van de HttpClient, wordt er voor elke parallelle actie nu een extra thread gemaakt voor het uitvoeren van de post. Dat betekent een thread vanuit de task parallel library en een vanuit async/await.

Oplossing

Bij een groot aantal url’s is de beste oplossing om wel de task parallel library te gebruiken, maar hierbinnen de post synchroon te houden. Bij een klein aantal url’s kun je beter een lijst van taken retourneren waar je de code op laat wachten.

Auteur: Menno Jongerius, Bergler Competence Center © 2020

berglerValkuilen in async/await
Lees meer

Stoornissen van teams, impact op de kernwaarden van het Agile gedachtengoed

Stoornissen van teams, impact op de kernwaarden van het Agile gedachtengoed

De Scrum Master van een team houdt zich onder andere bezig met het welzijn en functioneren van het ontwikkelteam. Welke signalen moet je herkennen en waarom zijn deze belangrijk? Mijn ervaring in de rol van Scrum Master gebruik ik om deze vraag via dit blog artikel te beantwoorden.

Patrick Lencioni heeft een boek geschreven over de “5 dysfunctions of a team”. In de stijl van De Phoenix Project beschrijft hij een fictief team in Silicon Valley die onvoldoende presteert. Het boek hanteert de volgende stoornissen in het gedrag van het team:

  • Ontbreken van vertrouwen tussen de teamleden
  • Bang om conflicten aan te gaan
  • Ontbreken van motivatie
  • Ontwijken van verantwoordelijkheid
  • Onvoldoende aandacht voor resultaat

Het is de taak voor de Scrum Master of coach om dit gedrag te herkennen. Daarover gaat dit blog artikel.

Waarom leidt dit gedrag tot het falen van Agile & Scrum toepassingen in organisaties. Veel organisaties komen namelijk in de verleiding om het raamwerk van Scrum en het Agile denken de schuld te geven bij het ontbreken van resultaat. Eigenlijk moet de oorzaak worden gezocht in de basale principes van teamwork en menselijke interacties.

Het agile gedachtengoed is gebaseerd op de volgende principes:

  • Inspectie, de opgeleverde software is altijd de interpretatie van het ontwikkelteam van de verzameling van user story’s. Interpretaties zijn aannames deze moeten altijd worden gevalideerd. Bij softwareprojecten wordt dit gedaan door het testen van de oplevering op verschillende niveaus van detail (unit testen, integratie testen, acceptatie testen, etc.)
  • Aanpassing, het resultaat van de inspectie moet worden toegepast op het product in ontwikkeling. Het gaat hierbij niet alleen om het verhelpen van bevindingen, maar ook over het ontwikkelproces. Veranderen is dus nodig om het product te verbeteren en de snelheid van het beschikbaar krijgen ervan te optimaliseren
  • Transparantie, het ontwikkelteam moet altijd de voortgang van de ontwikkeling kunnen presenteren aan de stakeholders. Hierdoor worden verwachtingen uitgewisseld, verrassingen voorkomen en oplossingen voor leerpunten zichtbaar gemaakt

Het beantwoorden van de vraag waarom stoornissen een bedreiging zijn voor een succesvolle toepassing van agile gedachtengoed doe ik middels de introductie van de “Agile stoornis matrix”.


Tabel 1: Bedreigingen van stoornissen op de pijlers van Agile werken en denken

Het doel van de bovenstaande tabel is om inspiratie te geven voor herkenning van gedrag en gebeurtenissen in het veld en het gevolg daarvan op agile werken en denken. Ongetwijfeld zijn er meer voorbeelden te bedenken. Graag verneem ik de reacties hierop. Ook sta ik open voor constructieve feedback over dit onderwerp en de inhoud van dit artikel.

Bron: The Great Scrum Master by Zuzana Sochova
Bron: The 5 dysfunctions of a team by Patrick Lencioni

Auteur: Arjen Kraak, Bergler Competence Center © 2019

berglerStoornissen van teams, impact op de kernwaarden van het Agile gedachtengoed
Lees meer

Omgaan met & begeleiden van tegenstellingen in Scrum- en culturele waarden

Omgaan met & begeleiden van tegenstellingen in Scrum- en culturele waarden

Agile werkprocessen, in het bijzonder Scrum is tegenwoordig de standaard voor softwareontwikkelteams. Deze aanpak benadrukt menselijke samenwerking en zelfsturing. Zodra de samenstelling van het team bestaat uit leden afkomstig uit verschillende continenten, ontstaat op deze thema’s een tegenstelling van normen en waarden. Dit artikel beschrijft mijn ervaringen over hoe ik hiermee ben omgegaan.

Dit artikel gebruikt de officiële Scrum waarden als leidraad. De ervaringen komen voort uit situaties waarin ik als Scrum Master te maken heb gehad. Het gaat hier vooral om teams met teamleden uit Europa en Azië. De tegenstellingen en hoe hiermee om te gaan richten zich op de culturen van continenten. Als samenvatting van elke waarde geef ik een samenvatting in de vorm van een “goody-bag” statement.

Scrum.Org beschrijft kernwaarden in haar documentatie van het raamwerk. Deze kernwaarden zijn niet alleen van toepassing op Scrum, maar eigenlijk in elke team. Met andere woorden; om teams optimaal te laten presteren zijn deze kernwaarden essentieel.

“Openness”
In gewoon Nederlands, transparantie. Vooral de Scrum Master heeft hier een grote rol. De Scrum Master faciliteert de continue actualiteit van het overzicht van de voortgang en de belemmeringen. Voor teamleden uit het Aziatische werelddeel is dit een uitdaging omdat men niet gewend is openheid van knelpunten te geven. Men voelt dat als een falen in prestatie en verlies van arbeidsethos / eer. Met name het bang zijn te falen komt voort uit een historische “afrekencultuur”. De belangrijke taak van de Scrum Master is om deze cultuur binnen de context van het ontwikkelteam te elimineren. Belemmeringen, ook bugs/fouten, zijn een integraal onderdeel van het programmeren; tijdens de retrospective of andere evaluatie momenten, moet de Scrum Master niet de vraag stellen van “wie heeft….”, maar “wat is de oorzaak?”, “hoe gaan we het oplossen?” en “hoe borgen we de oplossing?” De nadruk op we is met opzet. Het team heeft de kans om te leren van de belemmering.

“Goody-bag item”: stel de vraag “Wat” en “Hoe”. “Wie” is niet interessant

“Respect”
Bij elke menselijke samenwerking, is dit onmisbaar. Komt zeer in de buurt van het verkrijgen van onderling vertrouwen. Europese en vooral Nederlandse cultuur is om recht door zee en direct te zijn. In samenwerking met Aziatische collega’s wordt deze benadering respectloos gevonden. Het is vooral de facilitering van de Scrum Master om deze directe bejegening zeker in aanvang, te voorkomen. Het is beter om 1 op 1 met elkaar van gedachten te wisselen en te appelleren op de kennis en kunde van de collega overzees. Door deze persoonlijke interactie wordt vertrouwen gekweekt die verder uitgebouwd kan worden zodra weer in team verband wordt gewerkt. Het vertrouwen geeft een bijkomstig effect van het hebben van een veilige omgeving om transparant te communiceren in het team. Tijdens plenaire overleggen moeten de West-Europese teamleden zich bewust zijn van het feit dat grappen niet altijd als zodanig worden ervaren. Humor heeft in Azië een wezenlijk andere beleving dan in Europa.

“Goody-bag item”: begin persoonlijke interactie, wissel ervaringen uit. Appeleer aan kennis & kunde

“Courage”
In gewoon Nederlands, moed. Men zou dit in de context van software ontwikkelteams ook kunnen interpreteren als proactief. Zodra “respect” en “openness” zich ontwikkelen, komt deze waarde langzaam tot ontwikkeling. De Aziatische teamleden zullen initiatief nemen om product backlog items op te pakken en voorstellen te doen voor verbeteringen in Retrospectives. Om dit voor elkaar te krijgen moet de Scrum Master de organisatie rondom het team transformeren meer zelf organiserend te worden. Vooral in Aziatische culturen is het gemeengoed, dat de “baas” vertelt wie op welk moment welke taak krijgt toegedicht. Op het moment dat het team de Scrum Master vertelt wat hij moet doen, dan is de Scrum Master succesvol. Dit kan hij doen door vraag te stellen: “welke product backlog items kan je volgende periode oppakken, rekening houdend met de prioriteit?” Ook de vragen als “wat heb je nodig?”, “wat zijn de afhankelijkheden?” zijn van belang. De Scrum Master mag vooral niet in de valkuil trappen van het delegeren van werk. Ook moet hij erop toezien dat de Product Owner niet hierop aanstuurt of beïnvloedt.

“Goody-bag item”: stel faciliterende vragen i.p.v. controlerende vragen. Daag het team uit om naar de Scrum Master te delegeren

“Commitment”
De drang om werk op tijd gereed te krijgen wordt versterkt door de verantwoordelijkheid bij het team te leggen, niet bij het individu. De Scrum Master moet dit faciliteren vooral tijdens de Sprint Planning meeting door het team te bevragen over wat er nodig is om de backlog items tot een goed einde te brengen. De Scrum Master ziet erop toe dat iedereen voldoende bijdraagt in de discussie over inschattingen. Het is van belang dat de van nature terughoudende Aziatische teamleden voldoende aan het woord komen. Het doel is immers dat het discussiëren over een inschatting belangrijker is dan het verkrijgen van de schatting zelf. Tijdens het plannen is het van belang dat de Scrum Master het team stuurt naar verantwoording nemen als team en niet een individu te identificeren die het werk uitvoert.

“Goody-bag item”: delegeer niet het werk. Laat het team het werk verdelen. Inschattingen van het team zijn niet onderhandelbaar. Teamleden moeten hun inschatting toelichten.

“Focus”
Context switchen is een belangrijke oorzaak van verlies van productiviteit en kwaliteit van de opleveringen van de softwareontwikkelaar. Dit heeft dus ook effect op het ontwikkelteam. Het effect van context switchen ontstaat bijvoorbeeld wanneer een teamlid moet wisselen tussen operationele werkzaamheden en vernieuwing. Ook zijn er organisaties waar “alle projecten prioriteit 1 zijn”. Wetenschappelijk bewezen is dat na elke context switch een persoon tijd nodig heeft weer de snelheid en kwaliteit op te pakken die hij had voor de switch. Het onderstaande overzicht geeft het effect weer.

Duidelijk is dat het idee van “alles is belangrijk en moet meteen” niet resulteert in een snellere oplevering. Daarnaast is er een verborgen “waste” van verlies aan kwaliteit. Dit zijn dus bugs die worden geïntroduceerd die herstelwerkzaamheden vergen die als een boemerang later terugkomen.

Context switchen heeft nog een ander ernstig neveneffect. Veel ontwikkelaars vinden dit in het begin van hun carrière interessant en uitdagend. Het geeft hen een gevoel van onmisbaar te zijn. Echter, eerst onbewust, maar sluipend bewust kost context switchen zeer veel energie wat niet zelden leidt tot een burn-out. De Scrum Master moet het proces faciliteren van “stop starting, start finishing”. Dit kan hij doen door bijvoorbeeld te zorgen dat antwoorden worden gegeven op redenen van blokkades. Tijdens 1 op 1 gesprekken, kunnen de Aziatische teamleden worden geholpen bij het formuleren van hun belemmeringen zodat de Scrum Master deze kan adresseren. Tijdens de persoonlijke gesprekken zijn zij over het algemeen opener mits de Scrum Master zich faciliterend en niet controlerend opstelt.

“Goody-bag item”: Stel de vraag “waarom kan dit nu niet worden afgemaakt?”, “waar wacht je op?”. “Waarmee kan ik je helpen”. De Scrum Master moet niet het werk overnemen van het teamlid.

Auteur: Arjen Kraak, Bergler Competence Center © 2019

berglerOmgaan met & begeleiden van tegenstellingen in Scrum- en culturele waarden
Lees meer