Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

SaaS en Scrum zijn vrienden voor het leven

 

Computable Expert

Gijs in ‘t Veld
CTO bij Motion10, Motion10. Expert van Computable voor de topics Digital Transformation, Cloud Computing en Infrastructuur.

De wereld van de it verandert de laatste tijd snel. Heel erg snel. Zo snel dat we het niet allemaal meer bij kunnen houden soms. Dit geldt voor zowel it’ers als eindgebruikers. Eén ding staat als een paal boven water: cloud computing gaat niet alleen over uitbesteding van computers, software en beheer. Het is een paradigma verandering die alles verandert in onze wereld.

Cloud computing is natuurlijk een gemakkelijke, maar tevens verwarrende paraplu benaming voor een aantal zaken die te pas en te onpas door elkaar worden genoemd. Nog even in het kort:

- IaaS (infrastructure-as-a-service) is leuk, maar weinig vernieuwend en spannend; virtual machines kunnen we ook gewoon bij onze aloude hosting provider draaien.
- PaaS (platform-as-a-service) is al een stuk interessanter, met name om je maatwerkoplossingen te laten landen en gebruik te maken van out-of-the-box platform mogelijkheden op het gebied van databases en middleware om zodoende sneller oplossingen te kunnen ontwikkelen.
- SaaS (software-as-a-service), natuurlijk veruit het belangrijkste deelgebied in cloud computing; multi-tenant software, voor je gehost en beheerd in de cloud en waarmee je zeer snel oplossingen kunt configureren en in productie nemen.

Oervormen van SaaS, zoals outlook.com of dropbox.com waren en zijn ook nog steeds bruikbaar, maar eigenlijk ieder een one-trick-pony. SaaS is pas echt interessant als het gaat om applicaties die uitgebreid geconfigureerd kunnen worden om zich aan te passen aan je eigen business wensen en eisen, zodat echte bedrijfsprocessen ondersteund of zelfs uitgevoerd kunnen worden. Denk hierbij aan crm-, erp-, bpm- en ecm-systemen. Combinaties van deze SaaS-oplossingen zijn door middel van integratie ook mogelijk en bieden daarmee nóg meer mogelijkheden.

Rond het inzetten van deze vormen van SaaS, waarbij echte (delen van) primaire of secundaire bedrijfsprocessen kunnen worden geautomatiseerd en geoptimaliseerd nemen we in de praktijk op dit moment drie belangrijke dingen waar. Er is een duidelijk trend richting 'standaard-tenzij' oplossingen aan het ontstaan. Ook is de business véél directer betrokken bij het inzetten van deze oplossingen. Tot slot is goed genoeg beter dan perfect (denk aan de 80/20 regel).

Automatisering wordt steeds minder een it-feestje. SaaS is voor de business. Tegelijkertijd zien we in een trend om weg te bewegen van de traditionele waterval aanpak voor het uitvoeren van ontwikkel- en implementatieprojecten. Meer en meer worden deze projecten agile uitgevoerd en met name Scrum is hierbij een populaire vorm. Niet alleen bij softwareontwikkeltrajecten, maar zelfs op it-support- en -beheerafdelingen zien we dit de laatste tijd ook ontstaan. Het aanpakken van allerlei kleine of grote projecten door middel van een goed op elkaar ingespeeld team dat in een aantal korte of langere sprints werkt naar een 'prima' oplossing voor een business probleem, in nauwe samenwerking met die zelfde business.

Het creëren van geautomatiseerde oplossingen voor bedrijfsprocessen op basis van SaaS-platformen en in de vorm van Scrum-trajecten blijkt in de praktijk erg goed te werken. SaaS leent zich bij uitstek voor het snel leveren van 'prima' resultaten.  Scrum is hierbij de ideale aanpak. Voor het grootste gedeelte ontstaan oplossingen door middel van configuratie. Er wordt zo veel mogelijk gebruik gemaakt van de out-of-the-box mogelijkheden. Men integreert verschillende SaaS-producten waar opportuun. No code. Tenzij het écht niet anders kan. Maar telkens moet de business de afweging maken of het het echt waard is om precies dat stukje functionaliteit te creëren waardoor het traject en ook de oplossing zelf mogelijk een stuk complexer wordt en upgrade naar een nieuwere release moeilijker wordt. De consequenties moeten telkens helder zijn. Bijsturing kan snel. Hiervoor bieden SaaS en Scrum de perfecte combinatie. SaaS en Scrum zijn vrienden voor het leven!
Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4900421). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Veel is herkenbaar, maar ik zie ook een tegenstrijdigheid: SaaS op Scrum-wijze ontwikkelen versus de tendens naar standaard tenzij. Want standaarden daar heb je meer partijen voor nodig, lees: veel klanten.
SaaS met Scrum lijkt op een maatwerk-feestje.
Kortom: de conclusie dat SaaS en Scrum vrienden voor het leven zijn, is een contradictio in terminis

Weer een leuk en vurig artikel.

Toch heb ik één ding niet helemaal goed begrepen. SaaS is iets vanuit een eindgebruikers perspectief. Je neemt een dienst af. Dat heeft toch *niets* te maken met het ontwikkelen van software?

Vanuit de ontwikkelaar gezien heeft scrum geen enkele relatie tot SaaS, maar gewoon tot software ontwikkeling. Of ik nu een web applicatie op maat maak voor één klant die ook nog eens de eigenaar is, of een web applicatie die mijn bedrijf exploiteerd als SaaS zit toch vanuit een scrum oogpunt geen enkel verschil?

Okee, ik heb nog een keer gelezen en het kwartje valt (mijn zoon van zeven zal niet weten wat een kwartje is). Wat je eigenlijk zegt is dat je software implementeert met scrum.

Dus ook voor het inzetten van een software product kun je scrum gebruiken en dat blijkt zelfs heel goed te werken.

Dat inzicht had ik nog niet en klinkt als iets wat heel goed uit te proberen is... Leuk!

Scrum als software implementatie methode.


@Henri: zelfs bij nalezen haal ik jou conclusie er niet uit, maar het is er ook niet geheel strijdig mee.
We wachten de reactie van Gijs maar even af...

@Henri inderdaad, je samenvatting na twee keer lezen is de juiste!

Artikel begint met : "De wereld van de it"
De wereld, de it ? Er is maar 1 DE en dat is de PaVaKe stelling.

Er zijn nog zat bedrijven die software maken als hun core business. Nu zal ik vast te horen krijgen dat distributed Scrum eigenlijk al een beetje Scrum in de Cloud is. Maar is een goed op elkaar ingespeeld distributed team scrummasteren niet een contradictie op zich ? Iets als een facebook vriend voor het leven.. samen met Saas en Scrum.
En wat te denken van de scheiding tussen programmeren (als het echt niet anders kan, kennelijk) en bestaande programma interfaces bestuderen om te kijken of het systeem kan functioneren door ze te bundelen ? Volgens mij zoeken programmeurs toch ook de helft van de tijd naar programma libs en gaan dan pas evt zelf iets maken.

Business die gaat technische teams gaat aansturen en zich met technische interfaces bezig houdt ? We weten allemaal wat daarvan komt..

Al 20 jaar geleden werd het einde van 3e generatie programmeertalen al voorspeld. Vooralsnog zie ik nog overal ICT-feestjes.

Gijs,
Het komt niet vaak voor maar bij het lezen van dit artikel had ik exact de bevindingen zoals die van Henri.
Verwarrend, moet ik dit artikel lezen door de bril van een afnemer of een dienstverlener?
Ik kan zoals Leen de conclusie van Henri hieruit halen.

Verder nog, ik vraag me af tot hoeverre een SaaS oplossing de benodigde flexibiliteit kan aanbieden die een Scrum-aanpak vereist? Afhankelijk van je project, de kans is groot dat je snel behoefte krijgt aan een maatwerk-oplossing dan je initiele SaaS-oplossing.

Correctie:
Ik kan zoals Leen de conclusie van Henri niet hieruit halen

@Reza, @Mauwerd, @Leen: Denk aan de implementatie van bijvoorbeeld een workflow systeem in de cloud zoals Nintex of een samenwerkings- / ECM omgeving zoals Office 365 of een CRM omgeving zoals SalesForce.com. Als je dit slim implementeert komt hier weinig tot geen code aan te pas. Toch kunnen het grote, agile implementatietrajecten zijn. We hebben het dan over configuratie en niet coderen. Functioneel consultants i.p.v. technische consultants of ontwikkelaars. De business zit hier in de vorm van de product owner in 1 of meerdere Scrum teams bovenop en kan dus snel nieuwe functionaliteiten verwachten en tijdig bijsturen.

Akkoord, implementatieprojecten kun je agile doen. De vraag is wel (maar niet geheel on-topic) of je dit type integraties bij de klant wil doen of liever verbergt als Cloud Broker.

Ja, met computers kunnen we vandaag meer dan vroeger. Maar de eisen van de vragers worden ook steeds groter. Elke keer als ik een proof of concept van een bestaand pakket voorstel, wordt er net zolang door ge-eist tot het maatwerk wordt. Reza herkent dat kennelijk. Toch maar weer programmeren dan.
Je ziet het ook in hardware. Die wordt steeds sneller, kleiner en goedkoper. Toch komen er meteen weer nieuwe trage apps, nog veeleisender voor je platform. De inefficiente apps vragen supersnell hardware. Toch maar weer snellere hardware dan.
Rond de eeuwwisseling was Internet toegang niet genoeg. Het moest ook nog eens gratis.

Een standaard office_applicatie/mail/website pakket zal best wel voldoen, bij het gros van de doelgroep. Daarbuiten wordt het maatwerk, gevraagd door business/consumers, beetje gestuurd door consultants/productowners. Maar uiteindelijk mag iemand het programmeren. Hoe dichter bij de business/consumers, hoe minder zij daar zelf toe in staat zijn. Daarom blijf ik nog ff ZZP-er :-)

Mauwerd, maatwerk heeft in mijn ogen drie oorzaken:

1) Men denkt dat een organisatie verandering moeilijker is dan maatwerk ontwikkelen.
2) Men is te lui / niet kundig genoeg om software als een commodity aan te vliegen
3) Men wil de "Jack of all trades" ( & master of none) zijn, ofwel de software moet alles kunnen.

Als apps traag zijn is de ontwikkelaar een prutser. No exceptions, ter onderbouwing; waarom is Google onmogelijk snel met een database van triljarden items?

En dit is de reden waarom scrum als implementatie methode mij wel aanspreekt, als zijn de termen "loosely coupled".

@Henri wederom mooie conclusie die ik helemaal onderschrijf.

@Henri,

de 3 oorzaken die je noemt liggen allemaal aan de businesskant en die willen jullie (o.a. jij en Gijs) juist meer verantwoording geven. Dat haal ik tenminste uit het artikel en je reacties.

Dat jij en Gijs die verantwoording willen en risicos durven te onderkennen, dat maakt de business nog niet bekwaam in het kiezen van automatiseringsoplossingen.

Ik hoor 3 argumenten tegen business feestjes :-)

App ontwikkelaar met zn bijbehorende time to market met Google imperium vergelijken is overigens ook niet helemaal fair he.

SaaS en Scrum omschrijven als een software implementatie methode levert wel enkele bekende risico's.

Bijvoorbeeld: wat blijft er over van de software specificatie (ofwel: functionele documentatie) en in welke vorm wordt deze gegoten. Software ongedocumenteerd in productie nemen is je informatievoorziening bouwen op drijfzand.

In de tweede plaats de kans op eilandautomatisering, aangezien in het artikel niet wordt gerept over architectuur (SOA).

Tot slot de vraag of complexe bedrijfsfunctionaliteit - vroeger ook wel bedrijfslogica genoemd - uitsluitend tot stand kan worden gebracht op basis van configuratie.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×