Als de komst van de cloud ons iets heeft gebracht, dan is het wel dat het organisaties onder hoogspanning heeft gezet om continu mee te blijven gaan in de laatste technologische ontwikkelingen. Dankzij de cloud kunnen bedrijven sneller gebruikmaken van nieuwe functionaliteit en kunnen zij, dankzij de toepassing van het abonnementsmodel, sneller wisselen van leverancier. Met andere woorden, de snelheid van innovatie is hiermee ook flink gegroeid.
Een snellere zakenwereld en meer behoefte aan wendbaarheid, dat zijn in navolging van de cloud dé ingrediënten geweest voor de opkomst van Agile. Als de markt en klanten vragen om het kunnen opleveren van producten en diensten in een tijdsbestek van maanden, of zelfs weken in plaats van jaren, dan past daar een Agile methodiek bij. Maar waarom blijf ik dan toch zoveel mislukte, miljarden verslindende it-projecten zien die een eindresultaat leveren waarvan je als buitenstaander al lang en breed kon aanvoelen dat deze tegen het einde van de rit niet meer courant zouden zijn?
Dit heeft alles te maken met het ontbreken van deugdelijk lifecycle management voor productontwikkeling. Elk bedrijf merkt de toegenomen snelheid van innovatie, maar door alleen Agile te gaan ontwikkelen los je het probleem niet op. Als je wel je ontwikkelprocessen aanpast, maar goed lifecycle management vergeet en ‘fire and forget’ blijft toepassen – waarmee je dus alleen actuele issues aankaart en de rest laat zitten – dan zul je als bedrijf altijd achter blijven lopen. Sterker nog, (kleinere) organisaties die niet geplaagd worden door verouderde it en bijbehorende processen, zullen jouw bedrijf nog een tandje harder voorbij gaan rennen.
DevOps…
Agile in het kader van een optimale applicatie lifecycle gaat verder dan alleen het ontwikkelen. Het vraagt om de adoptie van DevOps en het kiezen voor een platform dat maakt dat je lifecycle management als een competitief wapen kunt gaan inzetten. Om met DevOps te beginnen: steeds vaker bestaan applicaties uit vele kleine componenten die worden samengevoegd in een geïntegreerde verzameling, die wordt afgeleverd als enkele deliverable. Als je daarvoor gaat ontwikkelen, moet constante verandering in componenten worden ondersteund en moet je aan continue integratie denken.
Dit vraagt om een samenhangende aanpak wat betreft development (Dev) en operations (Ops) in alle lifecycle fasen van een applicatie om wendbaarheid te kunnen demonstreren. Daarbij is het essentieel om te beseffen dat applicatie evolutie altijd plaats hoort te vinden, en dat het dus niet iets is wat je even inplant.
…én een geschikt platform
Wil je DevOps kunnen ondersteunen, dan vereist dit een platform dat niet alleen voorziet in het ontwikkelen, aanbieden, beheren en verspreiden van applicaties, maar ook in het ondersteunen van continue ontwikkeling en integratie door alle betrokken partijen in de it-keten. In lijn met wat ik eerder vertelde over Agile als opvolgende trend op cloud, kom ik hier ook weer terug bij de cloud: alleen een cloud-gebaseerde dienst voor lifecycle management kan werkelijk DevOps optimaal vormgeven.
Betrouwbaar, snel en efficiënt opleveren
Als organisaties zich niet meer in de vingers willen snijden met trage it-projecten die uiteindelijk kostbaar worden door inconsistente implementaties, complexe integratie van diensten, afhankelijkheid van een oude (prijzige) infrastructuur en een hoog risico en weinig expertise bij de uitrol van eindproducten, dan is er meer nodig dan alleen Agile gaan werken. Een cloud-gebaseerde dienst voor lifecycle management versnelt en simplificeert het ontwerp, deployment en het beheer van applicaties. Vergeet niet dat niet alleen Agile de definitie van wendbaarheid kent. De cloud demonstreert al jaren hetzelfde en draait om véél meer dan alleen kosten besparen.
Sneller en wendbaar,
maar waar naartoe?
Dev en ops,
samen maar hoe?
Cloud en Agile,
zij lossen het op.
Simplificeren,
helemaal top.
Als je maar commercieel hijgerig blijft hypen en op dergelijke manier je onder druk laat zetten, kan ik me er wel iets bij voorstellen. Als je dat dan tenslotte overkomt dan moet je wel een hele dikke portemonnee bezitten aangezien je dan als afnemer altijd de grote rekening vroeg of laat gepresenteerd krijgt.
Laat een materie als IT, automatiseren, daar nu juist helemaal niet voor zijn bedoeld. IT is een middel dat besparingen moet opleveren en als zodanig moet je daar dan ook naar blijven kijken. Een andere universele wetmatigheid stelt terecht, de kracht zit hem altijd in de eenvoud, en de eenvoud der dingen vind je vrijwel altijd als je rustig naar de dingen kijkt en daar de tijd voor neemt.
Een derde wetmatigheid in en met IT, m.i. is altijd ervoor te zorgen dat je nooit gebruikt maakt als eerste van nieuwigheden. Wil een leverancier jou ergens van overtuigen wat in ontwikkeling is, prima, in afzondering en laat de leverancier daar dan maar een zak geld naast zetten. Immers, je levert waarde op voor die leverancier, laat je daar dan ook maar meteen voor belonen.
Anders, gewoon gebruik maken van proven concepts en je bereikt precies wat je met IT ICT uiteindelijk wil bereiken; Besparingen.
René; “…en je bereikt precies wat je met IT ICT uiteindelijk wil bereiken; Besparingen.”
Je hebt zo’n beperkte kijk op automatisering, ik kan er niet bij en heb niet eens de zin om daar uitleg aan te gaan geven.
Zolang je niet bij het begin begint, weet je niet waar het einde is!
Dit geldt voor veel, maar zeker voor het lifecycle management (ontwikkelen en onderhouden) van Informatiesystemen.
Zoals geacht wordt bekend te zijn (!!!!)) is een Informatiesysteem: een samenhangend geheel van 1) gegevensverzamelingen, en de daarbij behorende 2) personen, 3) procedures, 4) processen en 5)programmatuur alsmede 6) de voor het informatiesysteem getroffen voorzieningen voor opslag, verwerking en communicatie (de infrastructuur).
Dus als je bij het begin wilt beginnen moeten al deze aspecten, in onderlinge samenhang, op elkaar worden afgestemd en afgestemd blijven.
Als de wil daartoe aanwezig is, dan kan gebruik worden gemaakt van diverse instrumenten. Ook die van Agile e.d.
De naamgeving is anders, maar de doelstelling is daarbij steeds hetzelfde: het definiëren van het vertrekpunt, het zoeken naar en vinden van mogelijke risico’s (de beren op de weg), het op een rij krijgen wat de impact is op mensen, middelen en processen, het zoeken naar de oplossing richtingen (de alternatieven) en wat het kost en de opbrengst.
Enkele methodieken en benamingen: Business case, IST-SOLL, FIT-anayse, GAP-analyse, Definitiestudie, impactanalyse…
Dus een impactanalyse. Maar dan wel binnen de context! Een samenhangend geheel.
Een goede start positie, met voortdurend zicht op het einde!
N.B. Daar waar projecten stranden en mislukken is nagenoeg altijd het zogenaamde voortraject overgeslagen en is er geen vorm van impactanalyse geweest.
Het is zo simpel.
Eerst denken dan doen.
@Henri
In essentie heeft René wel degelijk een punt. Automatiseren an sich is geen doel als het niets bespaart. Dat hoeft dan nog niet eens alleen maar in financiële zin te zijn. Agile an sich is een techniek en zoals met alles gaat het om de toepassing in de context.
Johan, alsjeblieft.
Besparen als doel van automatiseren is in mijn ogen zo achterhaald.
We automatiseren omdat bepaalde dingen niet zonder automatisering kunnen
We automatiseren omdat het foutkansen verkleind en productie verhoogd (productie verhogen != besparen)
We automatiseren omdat het flexibiliteit kan verbeteren.
We automatiseren omdat het veiliger is
Besparen is allang niet meer de drijfveer.
Cloud computing = automatiseren (Dank Weolcan)
Agile doe je ook niet om te besparen, maar om eerdere in het proces het juiste te doen.
“het is zo simpel” vs scrum being “difficult to master”
“eerst denken dan doen” vs zo snel mogelijk prototype in mekaar flansen.
Is Agile een techniek, methode, methodiek of filosofie ?
Heeft elke requirement niet ook een inpliciete besparingscomponent ?
Moeten we onthaasten of versnellen ?
Automatisering als Kronenburg Park.
Vraag niet naar de weg, want iedereen is de weg kwijt.
Ga die wereld uit.
@Henri
Goh, dat je dat uit mijn reacties kunt opmaken, knap. Ik heb overigens in menig traject zowel scrum als agile vs de ‘beperkte conventionele methoden’ nog steeds niet hetzelfde zien opbrengen. Wel meer rekeningen, dat dan weer wel. Echt sneller werd het dan ook niet opgeleverd. Zou het aan de IT professionals liggen, aan de scrum masters of toch misschien aan ….
René,
Je schrijft
“. IT is een middel dat besparingen moet opleveren en als zodanig moet je daar dan ook naar blijven kijken. ”
Dat is een hele beperkte kijk op automatisering uit de jaren negentig. Automatisering voegt heel veel aan de organisatie toe (mits goed uitgevoerd).
Levert de website van Bol.Com besparingen op (voor Bol.Com)?
Bol.Com zou er niet geweest zijn zonder website en die website is niet gemaakt voor besparingen, nee, die website is er gemaakt als business model. Alleen al dit voorbeeld maakt je uitspraak dus niet goed. En daarmee valideer ik dus mijn uitspraak.
@Norman van Es
In je aanhef van je reactie stel je juist de angel aan de kaak. Commercie is er niet bij gebaat dat de klant weet wat het eind resultaat is. Immers, je kan dan namelijk niet uit je project lopen waardoor je niet meer kan binnen harken dan je contractueel overeenkomt. Henri wil er nog steeds niet aan dat IT gewoon 100% voorspelbare materie is ergo, een IT professional moet gewoon kunnen becijferen hoe lang een project zal gaan duren en wat het kost. Dat dit in de praktijk toch zo heel vaak anders verloopt proves my point.
@Johan
Goh, dat je IT als commerciële commodity wil zien en daar grof aan verdienen, zoals Henri het wil doen geloven…. de essentie van automatiseren, of je dit digitaal doet of mechanisch, is gewoon mens en/of proces overbodig maken, productie/proces versnellen. Er is namelijk geen enkele andere reden te bedenken om te automatiseren. Of je dit nu technisch doet, virtueel (is ook digitaal Henri) of dat je nu een android/windows mobile daarvoor gebruikt om nog meer bereikbaar te zijn, is mij natuurlijk om het even.
Ik ken geen enkel winst gerichte onderneming die er anders tegen aankijkt. Natuurlijk geld dit niet voor de leveranciers want die willen er natuurlijk aan blijven verdienen. Dat commerciële ondernemingen om het hardst roepen dat bedrijven mee moeten met de nieuwste ontwikkelingen, lees zaken zoals byod, dat vele malen meer kost dan je lief is, lees Het Nieuwe Werken wat allerminst nieuw is, lees dat je met zijn allen de cloud in moet, u moet snel zijn want straks kun je niet anders meer, oh je pas aangeschafte apparatuur? Tja, vervroegd afschrijven dan maar? Dat je met zijn allen als idioten aan de app en zo dalijk in één streep door IoT in zonder na te denken, commercieel lekkurrrrrrr, maar als we het hebben over een duidelijke strategie en kosten baten analyse dan hebben we plots een hele lange discussie.
Blijft mij onveranderd vreemd omdat ook die elementen, je leest het goed Henri, aan dezelfde bandbreedte en wetmatigheden onderhevig zijn als elke stap in en met IT/ICT. Gewoon beginnend bij het begin. I/O en bij geen fatsoenlijke I heb je gewoon geen O. Zo eenvoudig is het.
Overigens Henri, like it or not, ook voor cloud computing gelden zakelijk gewoon dezelfde wensen en regels en wetmatigheden als die bij de aangekochte eigen server intern. Heel eenvoudig, wat levert mij die investering op wat is de afschrijftermijn, en ben ik bereid dat te betalen daarvoor. Commercieel gezien zou ik ook roepen dat besparen allang niet meer de drijfveer is. Mijn klant vraagt mij nu net ….. ehhh wat dan wel? I kidd you not, tis een KPN’er.
Henri,
Zucht, je l#lt. Haal die automatisering weg en wat krijg je dan? Twee pakhuizen ipv één vol rennende weinig kosten kaboutertjes, Polen of Roemenen, die af en toe van een trapje kunnen vallen, vingertje klem, jankend in een hoekje gaan liggen, vervangen moeten worden maar wel weer doorbetaald want tja, van Brussel moet dat ook tegenwoordig.
Kijk even wat de kosten zijn en de doorlooptijd per bestelling voordat die uiteindelijk in de vrachtwagen van tante Pos ligt en het gaat gewoon om de centen en de omzet. De systemen van Bol zijn helemaal niet zo anders als die van het Centraal Boekenhuis anno 1995 alleen zijn ze, hoe kan het ook anders, stukken sneller geworden. Niet zo verwonderlijk. Want wat levert dat dan per saldo op mijn beste Henri? Gewoon een vergrote omzet, zekerheid van doorgang van proces, versneld proces en aan het einde Henri?
Hard cold cash. Niets anders dan dat. Dacht jij dat Bol.com daar anders in staat over denkt? Ik kan je verzekeren dat zij alleen maar naar IT kijkt in de zin van toevoegende waarde, continuïteit die zich uiteindelijk voor de board en aandeelhouder, vertaald in money. Business model zal ze werkelijk worst zijn. Als het maar oplevert. De rest Henri, is helaas niet aan jou of mij of hoe jij of ik er tegen aankijken. That’s it!