Artikel

SOAgile - Deel 4: Met elke kleine stap dichter bij je doel komen

Dit is alweer het vierde artikel waarin ik verkondig dat Agile en SOA veel met elkaar gemeen hebben en waarin ik de verschillen en overeenkomsten tussen Agile principes en de SOA principes onderzoek. Ik herhaal nog maar eens dat het doel van mijn pennenvruchten is om de compatibiliteit tussen SOA en Agile softwareontwikkeling aan te tonen.

Vele organisaties in Nederland zijn namelijk bezig een service georiënteerde architectuur in te voeren, terwijl de IT afdeling vaker het Agile denkraam lijkt te omarmen. Ik hecht veel waarde aan beide concepten en probeer een intermediair te zijn tussen de nog steeds sterk gescheiden werelden van architecten en ontwikkelaars.

Om mijn doel en uitgangspunt te toetsen vergelijk ik telkens een (of meerdere) van de 12 Agile principes [1]  met de SOA principes. Zo probeer ik aan te tonen waar de concepten overeenstemmen, elkaar aanvullen en verschillen. Als bron voor de SOA principes gebruik ik telkens de publicaties van Thomas Erl [2].

In dit deel van de serie behandel ik de verschillen en overeenkomsten tussen het Agile principe ”deliver working software frequently, from a couple of weeks to a couple of month, with a preference to the shorter timescale” en de SOA principes.

Mijn vertaling van dit principe is:

Lever regelmatig werkende software af, binnen tijdseenheden van enkele weken tot enkele maanden. De lengte van de termijn dient bij voorkeur steeds korter te worden.

Om zoveel mogelijk momentum te krijgen en te houden en te bewijzen dat je services werkend kunt krijgen, is de beste aanpak om regelmatig werkende software af te leveren. Dit telkens vieren van het afleveren van een werkend product geeft energie en motiveert mensen. Dit bereik je door iteratief en incrementeel te werken.

Verkrijg sponsoring voor de top-down identificatie van het ene na het andere waardevolle business proces en vertaal deze naar, onder andere, herbruikbare technische transformaties en dataservices. Begin klein en bouw uw SOA per service en per proces, per keer.

In een Agile software project worden meestal kleine (elementaire) services opgeleverd. Standish Group noemt deze ‘stepping stones’. Het vraagt om de naleving van enkele strakke principes om ervoor te zorgen dat deze stapjes er daadwerkelijk toe leiden dat je de goede richting op blijft gaan.

De beoogde architectuur en richtlijnen voor de services [3] kunnen voor dat doel gebruikt worden. Dit betekent dat de producteigenaar rekening houdt met de architectuur en dit als een eis op de product backlog zet of dat de vertaling van die eis in de zogenaamde ’definition of done‘ staat.

Vanwege de vereiste losse koppeling [4] in SOA, kan die technologie worden gekozen die past op het moment dat zich een concreet probleem voordoet; de architectuur blijft echter een leidraad voor iedereen.

Door het regelmatig en frequent opleveren van deze ‘stepping stones’ in het Agile project, bouw je uiteindelijk een SOA. Vooral in een grotere organisatie kan een service georiënteerde architectuur niet in één keer worden gebouwd. Om maar eens een beroemde analogie te gebruiken: de manier om een olifant op te eten, is telkens een klein hapje te nemen. Dus “think big; take small steps”.

Agile ontwikkeling staat er pal voor om te zorgen dat alles wat je in je werk doet onmiddellijk leidt tot waarde voor de klant. Als we dit toepassen op SOA, bouwen we in het kader van een project alleen die services die nodig zijn voor het bedrijf.

Services kunnen, hetzij top-down of bottom-up geïdentificeerd worden. In ieder geval worden ze altijd gebouwd in de context van een project met end-to-end eisen en wensen. Dit zorgt ervoor dat het risico van een bijna religieus SOA streven services gaat opleveren die nooit en te nimmer zullen worden gebruikt sterk wordt beperkt.

De uitdaging voor zowel Agile als SOA is om de iteratieve planning te integreren met het programma - en portfoliomanagement. Het is ook een uitdaging om releases af te stemmen met de operatie, de gebruikers en beheer. Wat dat laatste betreft zijn de DevOps [5] initiatieven heel bemoedigend. Juist het programma- en portfoliomanagement, operatie, gebruikers en beheer moeten zich aanpassen aan een ander tempo van opleveringen en de kleinere brokken functionaliteit (service) die geleverd worden.

Agile en SOA houden elkaar hier dus in balans, houden elkaar gezond. Net als in een goed huwelijk eigenlijk, waar beide partners elkaar complementeren en zij aan zij op weg gaan.

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

 
Reacties
Huub van Burken op maandag 27 december 2010 10:06

Hoi,

Van welke organisaties met een vestiging in Nederland kun je nu zeggen dat ze echt goed Service Oriëntatie/"SOA" geïmplementeerd hebben? De theorie vind ik hele interessant, maar ik zou eigenlijk ook graag voorbeelden van dichtbij huis willen horen/zien.

Ik zou dit succes bij voorkeur afgemeten willen zien naar het behalen van doelen (federation, interoperabiliteit, vendor neutraliteit, alignment tussen business & IT) om de visie van een wendbare organisatie met hoge ROI en lage operationele IT kosten te realiseren.

Ik zie uit naar reacties van collega's in het !

Mary op maandag 27 december 2010 15:33

Hoi Huub,

Bij overheden worden services gerealiseerd, ook al die in de keten van belang zijn. Een volledig service georiënteerde organisatie kom je daar echter niet tegen. Dat is nu juist ook het punt. Stukje bij beetje, dat is hier het adagium. Als je teveel en ineens wilt dan is dat gedoemd te mislukken. Hopelijk neemt het mij niet kwalijk als ik zeg dat dit een van de redenen is waarom het WIA project is mislukt en andere zeer ambitieuze overheidsprojecten.... (zie evt. het rapport van de algemene rekenkamer)

Van Arval, een leasemaatschappij, weet ik in ieder geval zeker dat ze met SOA vergevorderd zijn en een aantal van de doelen hebben bereikt die je noemt.

Verder zijn Nederlandse vestigingen / bedrijven zoals De Goudse verzekeringen, Quion hypotheek maatschappij, het Centraal Boekenhuis, DAS Rechtsbijstand en OAD reizen volgens eigen zeggen een heel eind op weg maar ik ken verder de ins en outs niet. Wel weet ik dat ze verschillende talen gebruiken, verschillende (of géén) platform leveranciers hebben en andere 'technieken' en hulp middelen gebruiken.

Bol.com is een voorbeeld van SOA & Agile (in dit geval met scrum)

In de business verslagen zul je geen begrippen als SOA of Agile aantreffen als reden voor het bereiken van doelen. Daarin staat inderdaad een andere taal.

Misschien kunnen de 'officiële' onderzoeksbureaus je daarover iets meer vertellen? Of software ontwikkel bedrijven die beide concepten (tegelijkertijd) implementeren en organisaties hebben geholpen de business doelen te bereiken? In verband met mijn wens om ook 'leveranciers' neutraal te blijven zal ik de namen van die bureaus en bedrijven hier niet noemen.

Mary

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.