Artikel

SOAgile - Deel 3: Verandervaardigheid als concurrentievoordeel

In de vorige artikelen in deze serie heb ik mijn uitgangspunt, dat Agile en SOA veel met elkaar gemeen hebben, geïntroduceerd en heb ik SOA en Agile vergeleken aan de hand van het eerste Agile principe: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

Om mijn uitgangspunt te toetsen vergelijk ik telkens Agile principes [1] met de SOA principes [2]. Dit om na te gaan waar ze goed bij elkaar passen en waar de potentiële mismatches zijn. Vele organisaties in Nederland zijn drukdoende een service georiënteerd architectuurlandschap te creëren, terwijl de IT afdeling meer en meer het Agile denkraam lijkt te omarmen. Net zoals vele anderen zie ik veel waarde in beide concepten en probeer altijd de nog steeds sterk gescheiden werelden van architecten en ontwikkelaars te overbruggen. Daarom lijkt het mij noodzakelijk om de compatibiliteit tussen SOA en Agile softwareontwikkeling aan te tonen.

In dit nummer (3) van de serie artikelen behandel ik de verschillen en overeenkomsten tussen het Agile principe: “Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.” en de SOA principes.

Mijn vertaling van dit Agile principe in het Nederlands is:

Verwelkom veranderende eisen en wensen, zelfs laat in het ontwikkelproces. Agile processen bevorderen het concurrentievoordeel voor de klant.

Met SOA als een middel om zakelijke waarde te realiseren, creëren we een landschap dat bestaat uit kleinere, traceerbare services die organisaties in staat stellen bedrijfsprocessen samen te stellen [3], te herschikken en telkens opnieuw te componeren zodat deze nog steeds voldoen aan de markt en de behoeften van de klant.

Omdat de code niet strak vastzit aan verschillende processen (losjes gekoppeld [4]) en services autonoom [5] zijn is het hergebruik van services relatief gemakkelijk. Een belangrijke business drijfveer voor SOA is wendbaarheid, c.q. adaptiviteit van het bedrijf. Door het ontkoppelen van de serviceleverancier van de serviceafnemer, wordt het gemakkelijker om implementaties te veranderen. Door standaardisatie wordt het gemakkelijker om te veranderen. Door de scheiding tussen de software en het proces, wordt het gemakkelijker om te veranderen. SOA is verandering ... net zoals Agile softwareontwikkeling.

Altijd!?

Als ik de bovenstaande punten noem wordt mij vaak gevraagd om 'generalisaties' te adresseren, want het lijkt erop dat Agile en SOA over dit onderwerp botsen. Als je de SOA aanpak echt letterlijk neemt, zou de vraag "wanneer generaliseer ik, wanneer maak ik iets generieks?" met "altijd" beantwoord moeten worden. Dit is natuurlijk weinig zinvol. Soms is een probleem erg specifiek voor een bepaalde afdeling of functie, of het is iets heel nieuws. In beide gevallen (wanneer het zeer specifiek is of wanneer het probleem nog niet goed wordt begrepen), heeft het geen zin om een generieke oplossing te maken.

Nooit!?

Agile zal dezelfde vraag beantwoorden met "Nooit". Dit is ook onzin. Immers, soms is een probleem algemeen voor een bedrijf. Neem bijvoorbeeld de noodzaak van het gebruik van klantgegevens. Als u deze gegevens beschikbaar heeft in een open, goed presterende applicatie heeft het geen zin om even zo vele exemplaren van dezelfde klantgegevens in even zo vele toepassingen te hebben. Hetzelfde geldt voor het maken en sturen van facturen of een online betaalservice. Het is dan beter te integreren met de bestaande applicatie en te focussen op de belangrijkere en nieuwe uitdagingen.

De uitersten van Agile en SOA hebben dus beide ook nadelen. De combinatie van de twee zal echter de risico's van beide benaderingen sterk inperken. Hier houden de beide concepten elkaar in feite gezond. Bij een nieuwe uitdaging volstaat een breed kader, leert de architect meer van de ontwikkelaar dan andersom en is architectuur meer emergent (iets dat ontstaat). Bij een bekend probleem leert de ontwikkelaar meer van de architect dan andersom en is ontwikkeling meer ‘broodje software’ te noemen (meer routine).

SOA gaat niet alleen over hergebruik en de generalisaties, het gaat om kleine eenheden (services) die waarde leveren in plaats van het creëren van moeilijk te veranderen silo's. Met ontwikkeling op deze manier is het gemakkelijker te wijzigen en gemakkelijker te hergebruiken. De ontwerpprincipes zijn méér dan vergelijkbaar met de Agile ontwerpprincipes (separation of concerns, avoid waste, eliminate duplication etc.) die vaak worden gebruikt in softwareontwikkeling.

Het beste van beide werelden

Architecten en ontwikkelaars kunnen hier dus veel van elkaar leren: SOA houdt het grote plaatje in beeld, Agile levert de kleine stappen (think big & take small steps; think global & act local).

Dat is dan meteen het bruggetje naar het volgende Agile principe: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale”, dat in mijn volgende artikel behandeld wordt.

Categorie:   
Auteur(s)
afbeelding van marybeijleveld
Mary Beijleveld
ABC-thinkBIG - Business consultant, bedrijfsarchitect en Agile project manager

Mary Beijleveld is afgestudeerd bedrijfskundige (MScBA) aan de Universiteit van Groningen. Het onderwerp van haar afstudeeropdracht was: "Het nut van SOA voor -mijn organisatie- in termen van strategische innovatie".

Ze werkt als senior business consultant, bedrijfsarchitect en Agile project manager. Haar aandachtsgebied is de waarde van architectuur voor de business in het algemeen en SOA & procesoptimalisatie in het bijzonder. Ze werkt het liefst op het snijvlak van business en technologie, waar complexe vraagstukken moeten worden aangepakt en de druk om praktische verbeteringen aan te brengen, hoog is.

Naast haar passie voor Agile project- en ontwikkelmethoden, netwerken, bloggen (www.ABC-thinkBIG.com/weblog/) en schrijven van opiniërend artikelen is zij Certified Scrum Master en Product Owner, heeft jarenlange ervaring in het managen van projecten, issue control en uitgebreide kennis van diverse project management methoden. http://nl.linkedin.com/in/marybeijleveld Twitter: ladybeetle

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.