Soa en de agile beweging staan soms op gespannen voet, maar dat zou niet zo moeten zijn. De agile principes kunnen best in een soa-project worden gehanteerd. Maar zoals dat gaat met principes, gaat het meer om een manier van denken dan om het extreem hanteren van principes. Laten we wel kritisch blijven.
Het is alweer ruim tien jaar geleden dat het agile manifesto voor software ontwikkeling werd opgesteld. Ik ben altijd een grote aanhanger geweest van de agile aanpak, of dit nu XP, agile UP, DSDM of Scrum is, de uitgangspunten zijn voor mij eigenlijk altijd niet meer dan logisch geweest. Een van de beste projecten waar ik ooit onderdeel van ben geweest was een volledig en strikt DSDM-project bij een grote bank. Het project is succesvol verlopen dankzij de grote betrokkenheid van de business ('ambassador user') en de goede en gelijkwaardige samenwerking met de techneuten. Feitelijk was het een project waarin de eindgebruiker op basis van prototypen prima de richting kon aangeven en nieuwe wensen kon formuleren. Net als het agile manifesto zal het ongeveer tien jaar geleden zijn geweest, en dat was voor de opkomst van de grote soa-trajecten zoals ik die later tegen ben gekomen.
Bij soa denk ik meer aan bedrijfsbrede architectuur en daarin is volgens mij een eindgebruiker niet goed in staat om in zijn eentje de richting te bepalen. Veelal zie ik dat projectleden de eindgebruiker elke beslissing willen laten nemen. Soms gaat het niet om een specifieke eindgebruiker maar noemt men het 'de business', waarin dus ook analisten zitten. Maar wat weet de business nu van een compleet it-landschap?
Recentelijk ben ik betrokken geweest bij een groot soa-traject (zonder dat overigens de term soa expliciet werd gebruikt). Bij aanvang van dit verandertraject was het motto: Business in the lead. Wellicht goed bedoeld, maar voor een techneut als ik een kwetsende uitspraak. De business en de it moeten gezamenlijk en op gelijkwaardige basis tot producten en services komen. Het zou niet moeten gaan om de business als afdeling (ten opzichte van it), maar om de business value.
Het extreem en kortzichtig focussen op directe business value kent het risico van onderbelichting van andere stakeholders. Ik ben bijvoorbeeld een groot voorstander van zaken als 'Less is More' of YAGNI (You ain't gonna need it), maar evenals het overdreven benadrukken van 'de gebruiker', moeten we ook hier kritisch blijven. Als de business zegt 'You ain't gonna need it' dan wil dat nog niet zeggen dat een andere stakeholder zoals technisch beheer het niet nodig heeft. Bovendien is er geen enkele innovatie mogelijk als je teveel vast houdt aan het YAGNI-principe.
Als voorbeeld kun je denken aan bekende websites als Flickr, Facebook of Google. Al deze moderne websites hebben niet-grafische interfaces in de vorm van developers api's. Ik denk dat dit behoorlijk technisch gedreven is. Als je wacht totdat de 'gebruiker' tegen de ontwikkelaars zegt dat er een developers api moet komen, dan kun je lang wachten. Bij een presentatie van Facebook werd zelfs beweerd dat elke ontwikkelaar nu en dan extra functionaliteit op eigen houtje toevoegt, wat uiteindelijk ook business value kan creëren.
Een gezonde dosis technology push kan ook bij gewone it-projecten (bedrijfsapplicaties) geen kwaad. Natuurlijk moeten we oppassen voor het Bob de Bouwer anti-pattern, maar we hoeven ook niet slaafs te doen wat gebruikers (denken te) willen. Een goede business-it alignment vereist een gezonde balans tussen push en pull en samenwerking op gelijkwaardig niveau en niet it als doeners en business als denkers.
Vaak wordt het “verservicen” van applicaties en functionaliteiten op de traditionele waterval manier aangepakt omdat het opzetten van een applicatie architectuur en het inrichten van bijvoorbeeld een ESB niet echt heel erg geschikt is voor een agile aanpak. Zodra een bibliotheek van bouwblokken (gedeeltelijk / per generiek proces) is opgebouwd, kan dit gebruikt worden om samen met “de business” op een agile manier functionaliteiten aan elkaar te gaan klikken. Deze combinatie van waterval en agile werkt best goed samen, blijkt in de praktijk.