Artikel

SOAgile - Deel 1: Introductie

Veel mensen hebben het gevoel dat SOA en Agile softwareontwikkeling onverenigbaar zijn met elkaar; voor Agile ontwikkelaars vertegenwoordigt architectuur 'Big Design Up Front' en 'Death by PowerPoint'. Architecten classificeren Agile ontwikkelaars vaak als een soort piraten die alle regels en voorschriften overtreden. Maar als je voorbij deze vooroordelen kijkt, komen beide concepten sterk overeen.

Vele organisaties in Nederland zijn drukdoende een service georiënteerd architectuurlandschap te creëren, terwijl de IT afdelingen daarbinnen meer en meer het Agile denkraam lijken te omarmen. Net zoals vele anderen zie ik veel waarde in beide concepten en probeer ik altijd de nog steeds sterk gescheiden werelden van architecten en ontwikkelaars te overbruggen. Daarom lijkt het nu een noodzaak om de compatibiliteit tussen SOA en Agile softwareontwikkeling aan te tonen en deel ik graag mijn bevindingen door middel van de komende publicaties.

Voordat we iets zinnig over de compatibiliteit kunnen zeggen, vat ik de twee concepten kort samen:

Service Oriented Architecture is een architectonische stijl / vorm dat een middel is om een zogenaamde wendbare c.q. adaptieve (Agile) business te krijgen met behulp van services die waarde aan de business leveren.

Agile softwareontwikkeling is een software ontwikkelingsmethode dat zich richt op de menselijke mogelijkheden om snel waarde aan de business te leveren.

Agile, SOA en management

Zowel Service Oriented Architecture als Agile software ontwikkelingsprocessen zijn relatief nieuw en volgen niet de traditionele managementparadigma’s, zoals het ‘scientific management‘ of het ideaal van de bureaucratie (Taylor, Weber, Simon). Ik ben er zelfs van overtuigd dat SOA en Agile verder gaan dan de hedendaagse managementtheorieën zoals de contingentietheorie (Vroom) en de systeemtheorie (Checkland). Beide concepten vertegenwoordigen een fundamentele verandering in de manier waarop dingen gedaan worden en de manier waarop mensen kijken naar:

  1. Organisaties; functionele en bureaucratische organisaties versus multifunctionele teams en procesgerichtheid.
  2. Eigenaarschap; dat ligt bij enkele topmanagers versus gemeenschappelijk eigenaarschap.
  3. Verantwoordelijkheid; opgedrongen en onderverdeeld versus opgepakt en gedeeld.
  4. Management; topdown en macht versus elkaar ergens in het midden ontmoeten en faciliterend.

En wat eigenlijk het belangrijkste is; hoe wordt gekeken naar:

  1. Mensen; mensen zien als productiemiddel (arbeid) van de organisatie versus de mensen zien als de organisatie (P. Senge, M. Buelens).

Ik stel dus dat Agile en SOA veel met elkaar gemeen hebben. Om mijn uitgangspunt te toetsen vergelijk ik de 12 Agile principes [1] met de SOA principes. Dit om na te gaan waar ze bij elkaar passen en waar de potentiële verschillen zitten. In tegenstelling tot de Agile principes, is er niet slechts één bron voor SOA principes. Ik kies daarom een bron die vaak wordt gebruikt door architecten, namelijk de uitgangspunten die Thomas Erl [2] heeft gepubliceerd.

De Agile principes

Mijn vertaling van de Agile principes in het Nederlands zijn:

  1. Onze hoogste prioriteit is om de klant tevreden te stellen door snel en continu waardevolle software te leveren.
  2. Verwelkom veranderende eisen en wensen, zelfs laat in het ontwikkelproces. Agile processen bevorderen het concurrentievoordeel voor de klant.
  3. 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.
  4. De mensen van de business en de ontwikkelaars moeten dagelijks samenwerken in het project.
  5. Focus het project rondom gemotiveerde mensen. Faciliteer en steun hen, en vertrouw erop dat zij het voor elkaar krijgen.
  6. De meest efficiënte en effectieve methode om informatie te delen binnen een ontwikkelteam, is een persoonlijk gesprek.
  7. Werkende software is de primaire maat van vooruitgang.
  8. Agile processen bevorderen een duurzame ontwikkeling. De sponsors, ontwikkelaars en gebruikers zouden een constant tempo van ontwikkeling gedurende onbepaalde tijd moeten kunnen handhaven.
  9. Continue aandacht voor technische kunst en kunde en een goed ontwerp verbetert wendbaarheid / flexibiliteit.
  10. Eenvoud - de kunst van het maximaliseren van de hoeveelheid afgeronde taken - is essentieel.
  11. De beste architecturen, eisen / wensen en ontwerpen komen voort uit zelforganiserende teams.
  12. Met regelmatige intervallen, overdenkt het team hoe het efficiënter kan worden, stemt dit af en past het gedrag dienovereenkomstig aan.

De vergelijking tussen de Agile en SOA principes zullen in de komende artikelen van deze serie aan de orde komen. Dit artikel is nog slechts de opmaat daarheen. In het volgende artikel zal principe 1 uit bovenstaande lijst behandeld worden.

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.