Artikel

SOAgile - Deel 7: Vakmanschap, eenvoud en discipline zijn essentieel

Ik heb in de vorige delen van deze artikelenreeks telkens gesteld dat Agile en SOA veel met elkaar gemeen hebben. Daarvoor heb ik de 12 Agile principes vergeleken met de SOA principes. Dit om na te gaan waar ze goed bij elkaar passen en waar ze verschillen. In dit één na laatste deel van de serie neem ik het 9e en 10e Agile principe ter hand, namelijk: “Continuous attention to technical excellence and good design enhances agility” en “Simplicity - the art of maximizing the amount of work not done - is essential”.

In tegenstelling tot de Agile principes [1], is er niet slechts één bron voor SOA principes, dus gebruik ik steeds een bron die vaak wordt gebruikt door architecten, namelijk de uitgangspunten die Thomas Erl [2] heeft gepubliceerd.

Continuous attention to technical excellence and good design enhances agility

Mijn vertaling van het Agile principe "Continuous attention to technical excellence and good design enhances agility" in het Nederlands is:

Continue aandacht voor technische kunst en kunde en een goed ontwerp verbetert wendbaarheid / flexibiliteit.

Agile teams zorgen ervoor dat de gebruikte technologie voldoet aan de verwachtingen van de business en werkende software oplevert; overal en altijd. Een service georiënteerde architectuur vereist een hoog niveau van technische expertise en een goed ontwerp. Het vraagt namelijk om ‘losse’ koppelingen, herbruikbaarheid en abstractie. Deze principes verlangen extra aandacht en vaardigheid om te leren.

Vakmanschap

Agile ontwikkelaars moeten niet alleen ‘classes’ en ‘methods’ ontwerpen, maar zullen betrokken moeten zijn bij het ontwerpen van het hele systeem. Dit door zowel architecten als de business te begrijpen en te helpen om gezamenlijk het hele systeem te realiseren. Dit is een uitdagend doel voor een Agile ontwikkelteam; om verder te kijken dan een enkel project.

Sommige ontwikkelaars blijven herhalen dat een hoge mate van standaardisering (en architectuur ook wat dat betreft) een onnodige beperking is, die dodelijk is voor hun creativiteit.

Om maar weer eens een analogie te gebruiken; als u een pakketje zo snel mogelijk afgeleverd wilt hebben, zou het beter zijn als er geen maximum snelheid op de Nederlandse wegen gold. Voor die ene levering is het veel sneller om gewoon alle regels te negeren.

Voor de klant die het pakket heeft besteld zijn er echter meer waardevolle zaken dan de levering van dit pakket alleen. De klant wil namelijk ook dat het veilig is voor zijn en uw kinderen om veilig naar school te lopen of te fietsen. Dus terwijl de koeriersdienst hoge leversnelheid kan bereiken met een auto vol technische hoogstandjes en een fraai gestroomlijnd ontwerp dat ongekende snelheden kan bereiken, zal er rekening gehouden moeten worden met de omgeving als geheel.

Dit is nu precies waar SOA zeer nuttig kan zijn. Vanwege de notie van kleine eenheden en het bestaan van slechts een paar richtlijnen / principes waar elk project aan moet voldoen. Natuurlijk moeten deze richtsnoeren regelmatig geëvalueerd en verbeterd worden. Standaarden zijn ervoor om veranderingen te ondersteunen en niet om omwille van zichzelf gehandhaafd te worden.

Standaarden

De euro is, hoewel deze tegenwoordig behoorlijk onder vuur ligt, een voorbeeld van een standaard die het betalingsverkeer heeft vergemakkelijkt. Of wat te denken van de gestandaardiseerde trekhaken op auto’s. Je kunt daardoor elke aanhangwagen of sleurhut achter je auto hangen, vrijwel van elke plek van de wereld waar een aanhanger vandaan komt. En de koppeling op vrachtwagens waar elke oplegger op past; dat komt de overdraagbaarheid bijzonder ten goede. Ik zit zelf met smart te wachten op die ene gestandaardiseerde oplaadstekker die past op de vele verschillende merken telefoons. De standaard-mobiele-telefoon-oplaadstekker komt eraan heb ik begrepen. En misschien wordt er zelfs wel iets voor hergebruikt, een USB. Ha fijn, weg met die snoerenrommel!

Discipline

Hieruit volgt dat het voor zowel SOA en Agile zeer belangrijk is om de beste praktijken en principes consequent en gedisciplineerd toe te passen. Voor interoperabiliteit [3]  en verandervaardigheid.

Dat we standaardregels soms ook moeten veranderen blijkt uit het voorbeeld dat Zweden overschakelde van links naar rechts rijden. In 1955 stemde nog ruim 80% van de bevolking tegen, hoewel in alle omringende Scandinavische landen al rechts gereden werd. Vooral in de grensgebieden gaf dit veel ongelukken. In de nacht van 3 september 1967 werd het verkeer tussen 01.00 uur en 06.00 uur verboden om te rijden. Om 06.00 uur moest al het verkeer stil staan en zich van links naar rechts verplaatsen. Dus we kunnen ook zoiets - beslist niet triviaals - veranderen als we vinden dat dit het juiste is om te doen.

Simplicity - the art of maximizing the amount of work not done - is essential

Mijn vertaling van het Agile principe "Simplicity - the art of maximizing the amount of work not done - is essential" in het Nederlands is:

Eenvoud - de kunst van het maximaliseren van de hoeveelheid afgeronde taken - is essentieel.

SOA definieert services als de belangrijkste levering. Een service is wat mij betreft een realisatie van eenvoud, met kleinere bouwstenen die voldoen aan bepaalde principes (losse koppeling, autonomie, samenstelbaarheid etc.).

Deze Agile aanpak helpt ook om te bepalen wanneer en welk type software daadwerkelijk nodig is. Als u slechts software laat bouwen die de - al wel benodigde, maar nog niet gerealiseerde- service ondersteunt, kunt u de hoeveelheid werk dat niet gedaan hoeft te worden / de afgeronde taken maximaliseren.

In Nederland zeggen we wel eens: “Jij gaat geen nieuw systeem bouwen als je de info kunt bijhouden op de achterkant van een sigarendoosje" of misschien is het beter om te zeggen ‘niet het wiel opnieuw uitvinden”.We passen dit uiteraard ook toe op onze SOA -werkwijze. In deel 6 van deze serie heb het voorbeeld van de wiki als - tijdelijk - serviceregister gebruikt. Simpel en afdoende als je nog maar weinig (herbruikbare) services hebt.

Simpel, gecompliceerd of complex

Overigens is het nog niet zo gemakkelijk om iets simpel te houden of te krijgen. Vooral in de ICT branche. Nog onlangs had ik hierover een twitter conversatie met de CTO van één van de grote systeemhuizen. We kwamen al gauw tot de overeenstemming dat het behoorlijk gecompliceerd kan zijn om iets simpel te maken, dat gecompliceerd en complex [4] niet hetzelfde is en het vrij simpel is om iets complex te maken. Volgens mij heeft de vaardigheid om iets simpel te houden en krijgen veel te maken met vakmanschap, eenvoud, discipline en persoonlijk leiderschap, dat samen uitmondt in de kwaliteit die wij met z’n allen zo enorm essentieel zeggen te vinden.

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
Ad Gerrits op donderdag 3 februari 2011 21:13

Vind het een geweldige serie!
Zou alleen "Simplicity - the art of maximizing the amount of work not done - is essential" niet met
"Eenvoud - de kunst van het maximaliseren van de hoeveelheid afgeronde taken" vertalen, maar met
"Eenvoud - de kunst van het maximaliseren van werk dat niet gedaan hoeft te worden".

Marco Coopmans op vrijdag 4 februari 2011 9:15

Ik zit me nu al een tijdje te verbijten bij het lezen van deze artikelreeks en ben nu toch op het punt aangekomen dat ik moet reageren.

Wat zit me dwars? Het uitgangspunt van het op 1 lijn zetten van SOA en agile is wat mij betreft helemaal verkeerd. Het lijkt namelijk wel alsof SOA de heilige graal is, de oplossing voor al uw problemen. En dat is het helemaal niet. Het is niet voor niks dat je nog nauwelijks voorbeelden kunt vinden waarbij SOA ten volle wordt doorgevoerd. Hoe komt dat? SOA is namelijk ontzettend complex! Hoezo dus simplicity? Theoretisch gezien is het natuurlijk een prima concept, maar in de technische uitvoering is het nog steeds een enorme zoektocht ondanks het feit dat onze technische platforms steeds beter worden in het ondersteunen hiervan.

De vergelijking van het bezorgen van het pakketje gaat hier ook niet op. Het zal de gebruiker namelijk niks interesseren hoe je zijn functionaliteit realiseert (het pakketje bezorgd) als het maar niet idioot lang duurt en duur is. Het zijn andere stakeholders (met name IV) die zich druk maken om hergebruik, beveiliging, etc. Tuurlijk zou dit ook een issue moeten zijn voor de business, maar dat is het niet. Verder kan ik tal van situaties bedenken waar SOA (hergebruik) helemaal geen toegevoegde waarde heeft, sterker nog alleen maar een onnodige complicerende factor is.

Hieruit komt ook het tegensputteren van ontwikkelaars over onnodige beperkingen en het inperken van creativieit. Het heeft niets te maken met onwil. Het heeft te maken met het geen nut hebben van deze standaards in bepaalde situaties en dat het verzinsels zijn vanuit het theoretisch model (vaak van architecten) , zonder zelf enige ervaring te hebben met het bouwen van een dergelijk systeem. Typisch de mensen die geen onderdeel zijn van het team en zich ook niet hoeven te committen. Agile ontwikkelaars zijn over het algemeen erg skilled en weten welke best-practices ze moeten hanteren om een systeem goed onderhoudbaar en van hoge kwaliteit te maken - dit heeft niets met SOA te maken.

Kortom SOA staat niet gelijk aan Agile. Agile betekent juist het kiezen van de meest simpele werkbare oplossing voor de functionaliteit die op dat moment gevraagd wordt. Die oplossing wordt gekozen door het team, daarbij in het achterhoofd houdend wat het hele systeem uiteindelijk moet gaan doen en hoe het past in zijn omgeving. SOA kan een oplossing zijn, maar dan (waarschijnlijk) in een omgeving die al deels obv SOA bestaat (want alleen dan kun je de gewenste snelheid behalen), of er kan naarmate het project vordert en hier overduidelijk redenen voor zijn naartoe worden gegroeid. Dan ontstaat de SOA op basis van werkelijke behoeftes en best practices en is het niet een soort van standaard oplossing voor alles omdat dat wel aardig lijkt.

Groet, Marco.

marybeijleveld op zaterdag 5 februari 2011 12:46

Hartelijk dank Marco, dat je aangeeft waar voor jou de kritieke punten in de SOA / Agile vergelijking zitten. Super, zo'n reactie!

In feite herhaal je nog eens waar ook anderen en ikzelf in de praktijk de mismatches aantreffen. En je hebt groot gelijk wat mij betreft; SOA en Agile zijn niet hetzelfde. SOA is geen heilige graal en Agile is er in verschillende gradaties.

Je stipt ook de beelden die IT mensen (van welk vakgebied dan ook) hebben, weer eens aan: de business weet niet wat ze wil of interesseert het geen ruk als het maar snel en goedkoop is, degene die de rekening betaalt is de klant, architecten zijn theoretici die niet gecommitteerd zijn omdat ze geen teamlid zijn, ontwikkelaars weten 't het beter en we laten ons leiden door de platform-technologie pushers en systeemhuizen van deze wereld.

Wat ik - misschien onbeholpen- nu juist probeer te doen, is die enorme dikke muren, die we met zijn allen hebben opgetrokken tussen onze disciplines dunner te maken / als vensters te krijgen waar je doorheen kunt kijken. Als samenwerkende groep een multifunctionele of ja, zelf interdimensionele blik te krijgen ook al kan niemand het geheel overzien. Dat we met zijn allen door krijgen dat we onderdeel zijn van hetzelfde systeem en allemaal een bijdrage kunnen leveren als we dat willen (of het in de soep draaien als dat in ons straatje komt)

En daar gebruik ik de vergelijking tussen SOA en Agile voor. Omdat ik ervan overtuigd ben dat SOA strategisch nut heeft; je een SOA alleen op een Agile manier kunt realiseren en omdat ik denk dat de wens voor een service georiënteerde architectuur een Agile aanpak meer evident maakt. Dit laatste had ik bewaard voor het volgende / laatste artikel, maar goed, dit is dan een 'voorschotje')

Als ik als architect ook maar een split second het idee had dat jij je ermee geholpen voelt dan zou ik samen met jou aan het pair programmen slaan. Om behalve mee te helpen de vorm te ontwerpen, de eisen en wensen te identificeren en de omgeving waar het 'bouwwerk' in moet passen, ook mee te kunnen helpen aan het daadwerkelijk realiseren van de structuur en de implementatie.

Maar ik laat het ook graag aan jouw en een ander zijn expertise over. Daarmee trek ik me er niet van weg en ben nog steeds gecommitteerd aan het doel dat we beide hebben: de missie, visie en de bedrijfsdoelen helpen behalen. Waarbij ik jou vooral laat datgene waar jij gepassioneerd over bent en waar jij verantwoordelijkheid voor kunt nemen. Dan doe ik zelf ook waar ik goed in ben, energie van krijg en met plezier kan uitvoeren en waar ik verantwoordelijkheid voor zal nemen.

groetjes,
Mary

Marco Coopmans op zondag 6 februari 2011 21:53

Mary,

Allereerst wil ik duidelijk maken dat ik een collega architect ben en helemaal geen ontwikkelaar (wat je reactie mogelijk doet vermoeden). Ik ben ook zo'n architect die nauwelijk enige programmeer ervaring heeft, maar wel de meeste prachtige modellen weet te ontwikkelen die de ontwikkelaars dan maar moeten volgen.

Ik ben het helemaal met je eens dat als je een SOA architectuur nastreeft je dit het beste op een agile wijze kunt realiseren. Mijn punt is echter dat je eigenlijk niet vooraf een SOA zou moeten nastreven, maar dat in de praktijk zal blijken op welke onderdelen in je applicatielandschap het zeer wenselijk zal zijn om dit toe te gaan passen. Ik denk dat we ons te zeer ophangen aan SOA terwijl er vele situaties zullen zijn waarin andere oplossingen veel efficienter zullen zijn. Juist als architecten moeten we telkens bezig zijn om buiten kaders te denken en te zoeken naar alle mogelijkheden, juist om ook ontwikkelteams te kunnen prikkelen.

Ben benieuwd naar je volgende artikel.

Gr, Marco.

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.