Agile SOA reduceert complexiteit
De meest voorkomende redenen voor bedrijven om van een SOA-implementatie af te zien, zijn onzekerheid over waar men precies moet beginnen en het onvermogen om te voldoen aan de investerings- en implementatievereisten.Hoewel de meeste bedrijven flexibiliteit en aanpassingsvermogen nastreven, omvat de overstap naar SOA een complex proces dat afhankelijk is van de introductie van additionele ondersteunende technologieën en methodieken binnen een architectuur die al uitpuilt van de toepassingslagen, databases en technologieën. Deze onderling verbonden lagen van complexiteit dragen bij aan wat al een starre en moeilijk aanpasbare architectuur is, en zijn in veel gevallen bepalend voor de manier waarop SOA wordt geïmplementeerd. Dit is er de oorzaak van dat veel SOA-projecten lang duren, veel geld kosten, zich niet aan kunnen passen aan een veranderende werkelijkheid en dus een hoge kans van falen hebben. Een agile-aanpak van de SOA-implementatie kan bedrijven helpen de complexiteit, doorlooptijd en risico’s te reduceren.De meeste SOA-projecten die op dit moment in uitvoering zijn, worden gerealiseerd met de ‘alles-in-een’-aanpak. Een langlopend project wordt opgetuigd – als een traditioneel watervalproject – dat ergens tussen de negen en twaalf maanden kan duren.Dit proces heeft een aantal nadelen. Doordat er veel tijd zit tussen de definitie en oplevering, kunnen de requirements veranderen met het verstrijken van de tijd. Een ‘alles-in-een’-aanpak kan hier niet goed mee omgaan aangezien de methode ervan uitgaat dat de analyse vooraf gebeurt en niet meer verandert. Dit maakt het aansluiten op de wensen van de business moeilijk te sturen in zo’n project. De interactie met de business vindt vooraf plaats op een moment dat de business zich vaak nog niet voor kan stellen wat SOA is en hoe zij kan helpen. Wat resulteert is een project dat voor een groot deel gedreven wordt door de IT-organisatie en niet door de business. Dit maakt het moeilijk het project door de business gefinancierd te krijgen.Een ander probleem kan zijn dat er te weinig nadruk komt te liggen op het aanpasbaar houden van de SOA-architectuur tijdens een ‘alles-in-een’-aanpak. Dit vormt een risico voor de onderhoudbaarheid en flexibiliteit van het opgeleverde product.Toch zijn er verschillende redenen waarom bedrijven nog geen agile-methoden gebruiken voor hun projecten. De eerste reden is de onbekendheid met de agile-methode. Hoewel agile-methodieken al langer bestaan, worden ze nog niet breed gebruikt in Nederland. De toepassing ervan voor het ontwikkelen van SOA-architecturen lijkt in eerste instantie tegenstrijdig, maar is dit in wezen niet.Vaak wordt er in deze context gedacht dat agile betekent dat het proces rondom een agile-project niet geformaliseerd is. Dit idee ligt ten grondslag aan een van de grootste risico’s in een agile-project, namelijk het meegaan van de ontwikkelaars in niet goed doordachte requirements. Wanneer dit gebeurt, kan een agile-project veel onnodige functionaliteit gaan bevatten en uiteindelijk mislukken. Het argument dat vaak wordt gebruikt is dat agile-methoden goed werken in omgevingen waar de requirements niet van tevoren duidelijk zijn, zoals innovatieve systemen of systemen met een korte levensduur. In omgevingen waar meer formele processen een rol spelen, zouden traditionele methoden beter werken. Als vervolgens applicaties die volgens een agile-methode opgeleverd zijn geïncorporeerd moeten worden in de kernsystemen, dan zouden traditionele technieken gebruikt kunnen worden.Uiteraard is agile een goede oplossing voor projecten waarvan de scope nog niet helemaal duidelijk is. Maar dat betekent niet dat het bij andere projecten niet zou werken. Een agile-methodiek kan juist helpen in het prioriteren van de functionaliteit, ook als al duidelijk is wat nodig is. Vaak worden in agile-projecten specifieke methoden toegepast om juist die functionaliteiten te kunnen implementeren die belangrijk zijn voor de business. Een agile-methodiek is net zo formeel als een traditionele waterval, kent oplevering in fasen met de juiste documenten en besteedt juist veel aandacht aan het niet opleveren van nutteloze functionaliteit.Het tweede argument om af te zien van agile SOA is dat een SOA-project meer een technisch project is. Zo’n project zou veel meer gaan over het analyseren van de huidige en toekomstige bedrijfsprocessen en dus weinig gebruikersinteractie vragen. Het is daarom niet logisch een agile-aanpak te kiezen. Hoe kun je immers gebruikers betrekken bij eisen en wensen rond services die niet te zien zijn? Het uitgangspunt van deze redenering is incorrect. Het ontwikkelen van een SOA-implementatie kan nooit een technisch project zijn maar moet altijd ten dienste staan van concrete oplossingen voor gebruikers. Wanneer dit niet het geval is, ontstaan er problemen rondom financiering (zie kader). Alles wat in de IT gebeurt, moet in relatie worden gezien met de gebruikers, omdat dit de enige manier is om de bedrijfswaarde van een oplossing vast te stellen.Het derde argument om niet voor agile te kiezen, is het ‘fixed functionality’-dilemma. In een project is er een driehoek van tijd, budget en functionaliteit. Klanten vragen het liefst om projecten waarin alle drie deze componenten gefixeerd zijn. Dit creëert de illusie voor de klant dat hij minder risico loopt. Een agile-project kan deze belofte nooit nakomen, omdat per definitie de functionaliteit (scope) nooit gefixeerd wordt. Klanten die vragen om een ‘fixed’ project zullen dus aarzelen in een agile-project te stappen. In werkelijkheid zien we echter dat het onmogelijk is om alle drie de variabelen onveranderd te houden in een project, zonder concessies te doen aan de kwaliteit. Vooral het vastleggen van functionaliteit is in de praktijk een illusie. Er zijn altijd verschillen van opvatting, misverstanden waardoor een scope aangepast moet worden. Bij een agile-project kom je daar snel achter zonder veel tijd te verliezen. In een traditioneel project kom je hier over het algemeen pas achter bij de eerste gebruikerstesten. Dan is het vaak te laat om nog grote wijzigingen door te voeren.Het laatste veelgehoorde argument om geen agile SOA-aanpak te gebruiken, heeft te maken met de gebruikte tools voor implementatie van een dergelijk project. De huidige generatie programmeerhulpmiddelen eist van een organisatie die een agile-project uit wil voeren extreem ervaren ontwikkelaars. Het probleem is hier dat in een hoog tempo (tweewekelijkse opleveringen) werkende code opgeleverd moet worden. Deze code moet niet alleen werken maar ook nog eens van hoge kwaliteit zijn, en zo zijn geschreven dat aanpassingen erop eenvoudig door te voeren zijn. Na een dergelijke oplevering moet de input van de gebruikers geïncorporeerd worden terwijl er over twee weken weer een nieuwe oplevering klaar moet zijn. Als dit niet wordt uitgevoerd door ervaren mensen, vertraagt het project, doordat de opleveringen niet gehaald worden. Het vinden van ervaren mensen is moeilijk en duur. Daarom moeten organisaties die agile willen gaan werken naar technologieën zoeken die het mogelijk maken dit proces in te gaan met minder ervaren mensen.Concluderend kan men zeggen dat er genoeg redenen zijn om goed na te denken voordat een organisatie overgaat tot het uitvoeren van een agile SOA-project. Maar met de juiste strategie en hulpmiddelen kan agile SOA bepalend zijn voor het succes van een investering in SOA.Tony van Büüren van Heijst is als senior presales consultant werkzaam bij Outsystems (tony.vanheijst@outsystems.com)