Hoe vaak komt er een it'er aan je bureau om te zeggen dat de it teveel kost? Hoe vaak komt een leverancier langs met een zelfde boodschap? Hooguit een nieuwe leverancier die het roept, maar vervolgens ben je weer meer geld kwijt en is het it landschap weer een stukje verder uitgebouwd. Dit komt omdat een it'er zich fundamenteel met it bezig wil houden.
Eckart Wintzen beschreef dit fenomeen haarscherp. Hij gaf aan dat als je iemand aan stelt als fleet manager voor het beheer van de leaseauto’s dat het gevolg dan is dat de wagenparkkosten oplopen. Die gaat namelijk allemaal dingen verzinnen voor de lease-rijder om zijn functie relevant te houden.
Wist je dat er een orgaan bestaat voor het actueel houden van rekenmethoden op basis scholen? Denk je dat de directeur van dit orgaan ooit zal roepen dat we nu wel een optimum bereikt hebben? Nee, en daarom bestaat dit nog steeds; er veranderen regelmatig nog de methoden.
De it-afdeling zal dus niet snel uit zichzelf komen om te zeggen dat het allemaal eenvoudiger moet.
Infrastructuur is een commodity
Hoe hard het ook ontkent wordt, infrastructuur is een commodity geworden en als dit nog niet zo is, zal het niet lang meer duren. Ik heb talloze discussies gevoerd waarbij het argument steeds gebruikt wordt dat ik onvoldoende van infrastructuur begrijp. Ik begrijp infrastructuur prima, namelijk dat het een fundament is waarop je alles bouwt en dat je een fundament niet als een wiel steeds opnieuw uit gaat vinden, maar dat je het fundament gebruikt wat grote partijen voor je gebouwd hebben op grote schaal zodat je het goedkoop af kunt nemen. Ik gebruik hetzelfde fundament als enterprise organisaties en dat voor een fractie van de kosten. Infrastructuur is namelijk niet iets waarmee je je bezig zou moeten houden. Dit is echt niet anders dan de infrastructuur van ons land van wegen, water, elektriciteit en ga zo maar verder. Wie infrastructuur nog niet als handelswaar afneemt betaald teveel. Punt.
Boekdrukkunst
Wat is goedkoper? Afdelingen zelf hun printer laten aanschaffen, of kiezen voor een standaard en deze bedrijfsbreed uitrollen? Uiteraard dat laatste. Het onderhouden van allemaal verschillende printers is lastig in support, maar ook voor het in voorraad houden van toners.
Hoe denk je dat boekdrukkunst vijfhonderd jaar geleden ontvangen werd? Lang niet iedereen zag direct de impact op de schriftgeleerden die alle boeken nog met de hand overschreven. Het zelfde zie je nu als het aan komt op cloud computing. Kantoorautomatisering is een commodity, een standaard handelsartikel wat nu nog als maatwerk verkocht word. Een deel van de bedrijfsprocessen is misschien uniek, maar de basis van kantoorautomatisering is email, agenda en documenten die worden gebruikt door gebruikers met één of meer rollen. Standaardiseer wat standaard is.
De legacy draak
It kan dus simpel en infrastructuur hoeft niet duur te zijn, maar deze constatering staat haaks op de werkelijkheid. Want die is dat er veel geld betaald wordt voor it en de kosten jaarlijks oplopen. Projecten mislukken regelmatig en deadline en budget worden geregeld overschreven. Ook kantoorautomatisering is tot op heden vaak als maatwerk benaderd en alles is aan alles gekoppeld.
Een tijd terug had ik de opdracht om een bi-tool te maken waarin de performance van medewerkers gemeten werd. De aanwezige data was niet fijnmazig genoeg dus werd deze handmatig aangevuld terwijl men eigenlijk organisatorisch wijzigingen hadden moeten uitvoeren om dit probleem bij de wortel aan te pakken. Een it-oplossing wordt echter vaker verkregen om de organisatorische wijziging te vermijden en daarin ligt de crux. It is dus in feite mensenwerk.
Legacy is het huidige werkende systeem dat aan het eind van zijn levenscyclus terecht is gekomen en waarmee de kosten oplopen. Deze legacy draak verslaan is waar veel organisaties tegenop zien, maar het gevaar hierin is dat als je als bedrijf de it-kosten niet omlaag kunt brengen je in feite een gat creëert dat door concurrenten kan worden opgepakt. Je moet uniek zijn of goedkoop. In de middenmoot gaat het vaak mis.
De draak verslaan bestaat uit het inlossen van technische schuld; verworvenheden uit het verleden die nu hun tol eisen. Eén van de belangrijkste activiteiten om deze schuld in te lossen bestaat uit het rationaliseren van het applicatielandschap. Dit betekent afscheid nemen van tools, ontwikkelingen stop zetten, zaken simpeler maken. Dit is een uitdaging die moed en organisatorisch talent behoeven. Het gaat namelijk gepaard met pijn en weerstand.
Leverage
Het beslissen over het inzetten van technologie zou maar op basis van één principe genomen moeten worden, namelijk met de vraag; ‘zit er een hefboom in?’. Levert het veel meer op dan om het niet te doen? Kan er meer werk gedaan worden met minder arbeid? Verlost het ons van een pijn? Kunnen we iets sneller doen zonder dit middel? Automatiseert of versnelt het een bedrijfsproces? Helpt het de mensen om meer werk in minder tijd te doen?
Daarbij geldt ook de vuistregel; als de hefboom klein is zou dit in relatie moeten staan tot het risico.
Conclusie
It kan veel goedkoper en hier zijn drie inzichten van belang. Namelijk dat dit een organisatorische uitdaging is, dat it op basis moet van commodity infrastructuur/kantoorautomatisering en dat it’ers of leveranciers waarschijnlijk niet de beste raadgevers zijn.
Ik zal niet beweren dat it simpel is, maar er moet wel van een simpele basis uitgegaan worden en inzet op basis van hefboomwerking. Zo komt de complexiteit dus te liggen op het juiste niveau en zijn de kosten weer beheersbaar geworden.
Hoe raar het misschien mag klinken – maar Henry en Louis hebben beiden gelijk!
– Oplopende kosten die steeds minder in verhouding staan met de opbrengsten
(1) => WMO: Waaruit blijkt dat? Hoe erg is dat dan? Op welke manier en in welke mate kan een cloud-achtige helpen?
– Een enorme rem op innovatie. Het houdt allerlei andere zaken tegen
(2) => WMO: Ook hier dezelfde vragen als bij het vorige punt.
De vragen bij bovenstaande 2 punten komt volgens mij dicht in de buurt van wat Louis bedoeld.
– Alles hangt aan alles en dit gaat steeds verder waardoor je echt nooit meer kunt schakelen
– Het wordt steeds moeilijker en duurder om mensen te vinden met kennis van je legacy.
=> WMO: Dat geldt ook voor de huidige cloud-achtige omgevingen. Ter illustratie:
Een jaar of 4-5 terug was ik voor een verzekeringsmaatschappij bezig met het onderzoeken en oplossen van de performance problemen met een web applicatie rondom spaardepots.
Ik kwam er toen achter dat op bepaalde momenten iets van 7 of 8 verschillende servers betrokken waren bij de uitvoering van één klik van een gebruiker. Dat waren willekeurige combinaties van Windows, Linux en AS400 servers.
Ook toen riepen de DevOps teams in koor “dat klopt niet!”. Maar er was ook niet iemand die me kon vertellen hoe het dan wel zat.
Tegenwoordig zie ik min of meer hetzelfde verschijnsel. Een recente klantencase bestond uit force.com voor de kern van een CRM applicatie. Met op de “achtergrond” een integratie laag op basis van zelfontwikkelde applicaties bij een PaaS leverancier (vergelijkbaar met Mendix – weet de naam even niet) aangevuld met een aantal generieke servers+storage configuraties die deels draaien bij Amazon en deels bij Microsoft Azur.
Ook hier is er niemand die me kan vertellen onder welke condities nu waar iets gestart wordt. Ook nu weer performance problemen en ook nu weer mag ik via reverse engineering uitzoeken hoe het allemaal aan elkaar hangt.
Dus ja, (1) er is een besparing gerealiseerd op arbeidskosten in vergelijking met meer traditionele IT verschijningsvormen. Daar zijn (deels) platform kosten voor in de plaats gekomen. Deze worden direct gefactureerd naar de betreffende business units of afdelingen.
De servers+storage bij Amazon en Azur zijn het gevolg van het overhevelen van een deel van de legacy business apps naar de “cloud”. Dus ja, (2) hier valt nog wat winst te halen. Alleen is er niemand die daar een inschatting over durft te maken omdat er nauwelijks inzicht is in de onderlinge samenhang en de werking van de business logica die in die applicaties gebouwd is.
Punten (1) en (2) onderbouwen (min of meer) de visie van Henry over het gebruik van cloud computing.
Maar ook: nog steeds geen samenhangend, integraal overzicht van IT en applicatie kosten. Wat zich weer vertaalt naar financiële zorgen rondom allerhande verborgen kosten. Dit wordt bevestigd door een studie van “Research in Motion” eind 2012. Uit deze studie blijkt dat 79% van de organisaties die gebruik maakt van cloud omgevingen zich zorgen maakt om de verborgen kosten.
Ondanks de eerder genoemde zorgen hebben de cloud aanhangers het gelijk aan hun kant – allez – voorlopig dan toch. Uit hetzelfde eerder genoemde onderzoek blijkt namelijk ook dat investeringen in cloud computing 12% bedragen. Terwijl investeringen in zaken als datacenter- en applicatie optimalisaties blijven hangen rond de 5-6% elk.
Ook de plannen voor de langere termijn laten hetzelfde beeld zien – een kleine 25% verwacht over 5 jaar alléén nog maar gebruik te maken van hybride cloud omgevingen.
Kortom – blijkbaar vragen bedrijven zich niet meer af wat beter is. De verwachting is dat cloud computing in ieder geval een aantal zaken zal oplossen – whatever die problemen ook zijn. De tijd zal het leren…
🙂
Zat net nog even na te denken over het Cobol verschijnsel. Volgens mij het toonbeeld van legacy met de levenswil van een kakkerlak omdat deze maar niet dood lijkt te krijgen. Of misschien eerder een haai omdat het simpelweg de beste vorm van (IT) evolutie is van dit moment.
Dus wat dat betreft verdient de term legacy geen negatieve connotatie. Het zal eerder regelmatig tegen het licht gehouden moeten worden om te kijken of het niet overklast wordt door iets anders. Want wat IT innovatie/revolutie betreft zijn we nog maar een paar decennia bezig en zolang we nog niet in de buurt komen van wat we in sci-fi vormen kunnen bedenken is er nog genoeg te doen.
Will, dank voor je uitgebreide reactie.
“Kortom – blijkbaar vragen bedrijven zich niet meer af wat beter is.” – dit is wel een sterk maar ook verontrustend punt. Men kiest voor cloud terwijl men niet eens zeker weet of het goed is, en daarin heeft Louis dus zeker een goed punt.
@Johan, Legacy zie ik ook zeker niet als slecht, het is immers een werkend systeem! Sommige legacy wil je nu nog niet vanaf, maar als het een last wordt moet je een keer wat.
Christiaan, je triggert me met deze opmerking :
“Want waarom bijvoorbeeld voor de cloud kiezen als de IT-er nu volledig in control is over zijn eigen servers.”
Want hieruit spreekt namelijk een beeld wat veel IT-ers van cloud computing hebben, namelijk dat cloud computing gaat over het virtualiseren van servers. Hoewel virtuele servers veel gebruikt worden door cloud computing providers is een zeer groot deel aan het oog ontrokken voor de gebruikers van deze cloud dienst.
Ter illustratie Amazon Webservices : Van de 37 diensten die AWS aanbiedt gaat er maar 1 (!) over het direct virtualiseren van servers en vijf over het indirect virutaliuseren van servers. Een zeer groot deel van de diensten heb je dus niets met virtuele servers te maken (al zullen deze op de achtergrond wel gebruikt worden, jij hebt daar geen invloed op). Denk aan diensten als S3 storage, DynamoDB NoSQL database, Route 53 DNS, et cetera.
Windows Azure bestaat uit veertien diensten en daarvan bestaat er ook maar 1 voor het virtualiseren van servers, en 2 diensten voor het indirect virtualiseren van servers. Voorbeelden waarvan je dus niets met virtuele servers te maken hebt zijn: Service Bus, Active Directory, en SQL Databases.
Hoeveel wake-up calls zijn er nodig voor IT-ers voordat ze zich eens echt gaan verdiepen in cloud computing?
Een kleine anekdote:
Tijdens een overstroming liep het water al flink door de straten. Toen mensen het dorp uit vluchten boden zij hun hulp aan de dominee die weigerde “De heer zal mij redden”. Het water bleef maar stijgen en de dominee klom op het dak. Toen een evacuatie boot langs kwam weigerde de dominee in te stappen; “De heer zal mij redden”. Het water bleef stijgen en nu zat de dominee bovenop de kerktoren. Toen een helicopter langs kwam weigerde hij mee te gaan; “De heer zal mij redden”. Toen de dominee verdronk kwam hij bij de hemelpoort. De dominee vroeg de heer “Waarom heeft u mij niet gered?” waarop het antwoord was “Allez! Ik heb drie keer mensen langs gestuurd….”
Als laatste nog een voorbeeld van hoe niet kiezen voor cloud computing een goede keuze kan zijn. Tweakers.net draait in een datacenter /hosting locatie van iemand anders (Trust). Zij doen dit met nagenoeg *geen* server virtualisatie. Tweakers.net heeft een laad performance die in mijn ogen met nagenoeg geen enkele cloud dienst overtroffen kan worden. Met de generieke services van de “grote jongens” wordt het in ieder geval lastig zo niet onmogelijk. Er zijn dus echt wel cases te bedenken waarin je niet voor cloud computing hoeft te kiezen. Daar is wel erg goed over nagedacht! Zelfs de analytics doen ze naar mijn weten zelf.
@Henri: Dat bedoelde ik dus ook precies te zeggen met die opmerking. Veel IT-ers weten niet wat een cloud-oplossing is en komen met zulk soort argumenten terwijl ze helemaal niet weten waar ze het over hebben. Door out-of-the-box te denken, komen ze er achter dat de cloud helemaal niet is wat zij denken.
@Henri Ik denk dat wij over twee verschillende dingen zaten te praten. Jij denk aan diensten uit de cloud als ik het goed begrijp en ik zit te praten over de cloud als een wijze van je systemen te beheren waarop je de bestaande applicaties ook kan laten draaien. Dat zijn die breiwerken waar @Will het in zijn artikel overheeft. En ja daar denk ik dat zelfs de cloudbenadering van systeem beheer interessant kan zijn. Je moet ergens beginnen. Inderdaad ik kom nog niet veel verder dan de IaaS en PaaS.
@Will Klinkt als mooie cases die je daar beschrijft, veel applicaties en systemen die gebruikt worden en die op een of andere manier aan elkaar gelinkt zijn. Dat is het beeld wat ook in mijn hoofd zit. Niemand die het echt weet en reverse engineering om na te gaan wat je nou eigenlijk hebt en waar de issues zitten. Erg leuk, reverse engineering, een favoriete bezigheid van de it’er. Alle reden om in ieder geval de mensen die systemen maken, beheren en onderhouden in ere te houden. Er wordt veel gesproken over commodity maar om mensen ook als commodity te benaderen is niet verstandig, zeg maar dom. Je kan in ieder geval geld besparen om daar in te investeren en te zorgen voor continuiteit. Goed voor de kennis.
@Johan Ja, leve Cobol! Hou ouder hoe beter.
@Henri Eckart was een visionair (pas z’n notes nog weer ‘ns uit de kast getrokken en met veel plezier gelezen). Alleen je maakt een cruciale vergissing in het vergelijk: Fleet management gaat om een secundair proces. IT management gaat, als het goed is, over optimalisatie van primaire processen. Hierbij is er direct resultaat te zien op de bottom line. Als het over secundaire processen gaat is de leverage zeker een belangrijke KPI.
Gijs, Eckart is een held, je kunt zijn boek tien keer lezen en elke keer toch weer een inzicht op doen. Eckart is eigelijk de uitvinder van cloud computing maar dan op business level: All Things Distributed.
Overigens zou ik mijn verwijzing naar Eckart cruciaal **goed** willen noemen.
Want als je de inleiding leest en daaronder dat infrastructuur commodity is, dan lees je dat veel it-ers part of the problem zijn geworden. Zij houden iets in stand waar je vanaf wilt, en daaraan appelleer ik.
Klinkt dat logisch?
@Henri als je inderdaad alleen op infrastructuur doelt klopt het.