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

Je IT kost altijd te veel

 

Computable Expert

Henri Koppen
Directeur, THINGKS. Expert van Computable voor de topics Digital Transformation en Cloud Computing.

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.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4900675). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Henri,
Grappig om mijn woorden en opmerkingen over jou terug te zien :-)

Er zijn een aantal onderwerpen in dit artikel waar ik het mee en ook niet mee eens ben. Vanwege tijdgebrek kan ik helaas niet op alles ingaan.
Voor nu, ja, ict kost geld en dat komt naar mijn mening doordat veel businessmodellen, primaire en ondersteunende bedrijfsprocessen verouderd zijn. Je moet elke 3-5 jaar de conditie van je bedrijfsprocessen herzien. Doe je dat niet dan ziet je met enorme kosten van legacy en inefficentie. Ik heb hier eerder een artikel over geschreven:
http://www.computable.nl/artikel/opinie/management/4704821/2379250/ictinnovatie-redt-de-business-niet.html

Dat je geen infrastructuur nodig zou hebben spreek ik niet echt tegen. Dat is iets wat zich over 10 jaar gaat voordoen. Bedrijven hebben zeker 10 jaar nodig voor tranformatie van de huidige ict-vorm naar de nieuwe vorm, lees cloud. Cloud heeft ook deze tijd nodig om verder ontwikkeld en volwassen te worden. Deze twee wegen zullen de komende jaren naar elkaar toe groeien en na circa 10 jaar bij elkaar komen.

En we hebben tegen die tijd een nieuwe legacy: Cloud!

Henri,
Als eerste moet je een verschil maken tussen wat dichtbij de gebruiker staat en verstopt ligt in het datacenter. Dat e-mail, office en nog een heel rijtje andere kantoorautomatisering goedkoper kan is correct. Je kunt hier al flink besparen door bijvoorbeeld niet voor Exchange maar Zimbra te kiezen om wat te noemen. Heel wat lastiger wordt het met maatwerk waarin de business logica ligt opgesloten. Je hebt gelijk dat het meer een organisatorische kwestie is dan techniek maar hoeveel organisaties hebben hun 'koppelvlakken' in beeld?

Je wandelt me echter iets te makkelijk over de problemen die zitten in mid-office welke probeert alle 'ICT-terpen' met elkaar te verbinden, de legacy die vaak organisch gegroeid is door de eisen vanuit de business maar waar deze afnemers niet meer de kosten van willen dragen omdat er iets sexiers is gekomen. Dat nog veel legacy operationeel wordt gehouden zit niet ook niet zo zeer in de techniek maar in de afhankelijkheid van de service die voor de automatisering gebruik maakt van een verouderd systeem. Service Release Management is namelijk nogal uitdagend door de 'disconnected' processen die er in het beheer zijn.

Ik ben het maar deels eens met je conclusie, de beheersbaarheid van de kosten ligt dan wel in de organisatie maar zo simpel is dat nog niet op te lossen. Niet in de basis waar data, applicaties en systemen langer mee gaan dan de ontwikkelingen op de desktop. Het is dus niet even de bits van EBCDIC één positie naar links verplaatsen om zo te profiteren van de ASCII commodity. Migratiekosten zijn soms hoger dan te behalen besparingen waardoor het economisch gewoon voordeliger is om door te gaan met legacy. En uiteindelijk wordt elke nieuwe technologie zelf ook weer achterhaald door de snelheid van ontwikkelingen.

Wat fijn om twee goede reacties te krijgen van mijn grootste fans!

Reza, waar je mee om gaat wordt je mee besmet, dat je dingen van jou in mijn verhaal terug ziet komen zal ik niet ontkennen.

Ewout, als het simpel was kon iedereen het! En ik besef dat ik uiteraard kort door de bocht ga en dat een (grote) bedrijfsvoering gewoon complex is. Want naast techniek heb je cultuur, machtsverhoudingen, competenties, processen en is een verandering per definitie pittig en risicovol.

Veel mensen interesseert it geen klap, alleen met die houding kom je er niet aangezien it praktisch een core feature is van iedere organisatie. Het zal dus voorlopig uitdagend blijven en hier zijn geen pasklare oplossingen voor als in : Doe dit, doe dat en dan komt het goed.

Ik snap de teneur van het stuk en ik kan er een heel eind in meegaan. Maar zoals Ewout al aangeeft wordt wel heel erg snel over het feit heengestapt dat legacy systemen heel veel bedrijfsspecifieke logica bevatten en niet bestaat uit 100% generieke logica. Natuurlijk ieder bedrijf kan SAP/BPCS/JDEdward/NameYourFavouriteOrRelevantApplication aanschaffen en daarmee kan veel ontwikkeltijd worden bespaard, maar wat meer wel dan niet ontbreekt in die pakketten is de logica die specifiek van toepassing is in het bedrijf; en meestal is die logica juist /het/ hart van het bedrijf, de raison d'être, het onderscheidende kenmerk waaraan het bedrijf haar bestaan ontleent. En dat moet echt ingebouwd, en als het even tegenzit moet het weer opnieuw als er weer een nieuwe versie van dat pakket uitkomt.

Wat het bedrijf heeft gekocht is tijd: de ontwikkelafdeling heeft in een keer een blank canvas gekocht waarop deze de bedrijfsspecifieke kenmerken kan aanbrengen. Als alles helemaal van de grond af aan had moeten worden ontwikkeld was het waarschijnlijk veel meer geld en tijd kwijt. Je mag aannemen dat de meeste kinderziekten eruit zijn gehaald en dat nog te ontdekken pubertijdsproblemen er op een later moment worden gepatched.

Dat aanbrengen van de nieuwe functionaliteit kost geld (want tijd), en je kunt het natuurlijk uitbesteden aan de leverancier, maar die doet het ook niet voor niets.

Maar de eerste vraag die moet worden gesteld is: "welk probleem wil men eigenlijk oplossen met het vervangen van de legacy applicatie?". Daaruit kan een kosten/baten analyse komen waar dan alternatieven kunnen worden afgewogen.... maar ook dat kost geld. Ooit wel eens een manager aan je bureau gehad die zei dat management teveel kost?

In principe is het leven heel simpel. Alles kan goedkoper. Als je er maar aandacht aan besteedt. Die tijd wordt een probleem in de regel niet gegund. Dus: ze hieven het glas, deden een plas en alles bleef zoals het was.
Je gaat het pas zien, als je er op gaat letten, dat is dus met it kosten ook zo.

Ik snap dit soort artikelen nooit, ga eens terug naar de typemachine en goed nadenken hoe het toen was, voordat er IT was ging alles met de hand en in kelders met archieven. onzinnig onderwerp mijns inszien.

Laat ik nou zo'n ITer zijn die zichzelf graag weg automatiseert. Want als het werk wat ik doe zo makkelijk te automatiseren is valt de uitdaging ook weg.

Moet de stelling niet zijn: “de uitvoering van de processen die leiden tot de realisatie van de dienst of het product (de kern van het bestaan van de organisatie) kost altijd te veel”?
Om de een of andere reden is de primaire organisatie in staat om de schuld van haar eigen disfunctioneren af te schuiven op IT. En daarmee is IT altijd te duur. Hoe is ze dat gelukt?
1. IT is lekker vaag. We hebben geen idee hoe het werkt, het heeft nog steeds een hoog nerd imago en alles wat IT ons niet uit kan leggen kunnen we aanwijzen als de oorzaak van het niet goed functioneren van onze processen in plaats van dat die processen zelf de oorzaak zijn.
2. IT is per definitie duur, omdat het functioneren van functionaliteit verbeterd kan worden met duurdere spullen. Legacy werkt nog steeds prima, zolang het draait op de zwaarste processors en het soepelste geheugen. Het niet doorzien van deze vicieuze cirkel en/of het niet willen of kunnen doorbreken daarvan leidt alleen maar tot steeds hoger wordende IT kosten. In relatie met 1 is de schuldige snel aangewezen.
3. Terecht wordt de risicofactor aangehaald. Infrastructuur is commodity, maar bijvoorbeeld het beveiligen van je data niet. Wie onvoldoende acht slaat op de risico’s is per definitie duurder uit. En omdat 1 en 2 van toepassing zijn komt ook hier de beslisser in de ‘business’ er vaak mee weg te wijzen naar inefficiënte en dus te dure IT.

Als het gaat om het zuivere begrip “te dure IT” dan praten we niet zozeer over spullen of slecht ondersteunende functionaliteit, maar vooral over de organisatie en uitvoering van de IT serviceprocessen. Mensenwerk dus.
Te dure IT vanuit businessperspectief ligt maar al te vaak aan de business zelf. Maar volgens mij laat Henri tussen de regels die boodschap ook al doorkomen.

Ik ben het oneens met de stelling dat IT _altijd_ te duur is. Als dat zo zou zijn, dan was de beste bedrijfsvoering het uitfaseren van IT en alles met de hand administreren.

IT wordt alleen te duur als je er niet voor waakt dat je dure oplossingen gaat maken voor situaties die niet vaak voor komen. Je moet goed in de gaten houden wat de kosten zijn voor een systeemaanpassing ten opzichte van de business value.

Overigens is het IT vakgebied zich daar ook steeds meer van bewust en maakt allerlei bewegingen richting het meedenken met de portemonnee van de klant. Dat is immers beter voor de langetermijnrelatie.

IT kost past te veel als je geen goed risico en TCO-overzicht kunt maken.
Roepen dat iets goedkoper kan is makkelijk, het tegendeel wordt meestal pas duidelijk als het te laat is.

Als het IT park goed draait, waarom zou je dan 3 man nodig hebben voor beheer, dat kan toch ook met 1?
Klinkt als een eenvoudige bezuiniging, totdat die ene systeembeheerder op vakantie in Zuid Afrika zijn been breekt, en ineens 6 weken wegblijft. Uiteraard valt dit samen met een stroomstoring op kantoor, waardoor een cruciale server niet meer opkomt, en de router die het netwerkverkeer naar buiten verzorgd sneuvelt......



Overigens was mijn eerste gedachte na de eerste zin: en hoe vaak roept een manager dat hij overbodig is .... maar dat terzijde

Als er een IT'er aan je bureau komt om te zeggen dat "het" (onterecht) meer gaat kosten heb je "het" verkeerd georganiseerd. De verantwoordelijkheid voor projecten en kleine veranderingen moet je bij de gebruiker leggen die dan middels inmiddels eeuwenoude projectmanagement-technieken de zaak kan gaan besturen. Als een IT'er onbegrijpelijke taal uitslaat moet je hem dwingen om "het" in gewoon Nederlands uit te leggen. Wedden dat dan blijkt dat ie "het" zelf ook niet snapt. IT is al lang niet meer voor de IT'er maar kan met groot gemak door de niet-IT'er gedaan worden.

Dank voor de reacties!

PaVaKe, DE it bestaat niet :-), ik denk dat je TCO en risico moet opdelen in functie. Kantoor Automatisering / Productie / R&D et cetera. Zo zal niet alles nog commodity zijn, maar wat ik nu zie is dat niets commodity is.

Als een onderdeel standaard is ingezet, is systeem beheer daarover ook standaard geworden en zijn mensen dus vervangbaar.

Cruciale server klinkt als niet commodity en/of legacy, dus dat valt hierbuiten.

Je opmerking over manager en overbodig... dat klopt en ligt precies in het verlengde van mijn boodschap, want wat voor it geld, kun je doortrekken naar veel meer in de organisatie. Je maakt je organisatie slanker, want als je standaardiseert, standaard software gebruikt kun je meer met minder en hoeft het niveau van een deel van de medewerkers ook minder hoog te zijn. Het lijkt een beetje op Lean & six sigma.

Johan, elke IT-er zou deze instelling moeten hebben en dat kan ook, er blijft genoeg leuks over. Ook zijn er nog genoeg vlakken waar van alles gebeurt en het is geenszins mijn bedoeling om als it simpel af te schilderen. Ieder bedrijf heeft processen, veel applicaties, integratie vraagstukken, et cetera, maar laten we de werkzaamheden op het juiste niveau plaatsvinden. Alles onder de integratie en presentatielaag moet in mijn ogen zo standaard mogelijk zijn. Alles daarboven raakt al snel de it en de business.

Hans, beveiligen van je data is in mijn ogen juist net iets wat bij uitstek wel commodity is vanuit technisch perspectief. Het grootste gevaar van data zit niet in de it maar in het organisatie stukje van mensen en governance (processen) en dus de conclusie uit je laatste paragraaf is in mijn ogen dus juist!

Marcel, er zit een enorme hefboom in IT, alleen doe je die deels teniet door niet te standaardiseren. Pak de hefboom zonder de kosten op te laten lopen. Goede IT leidt in mijn ogen tot besparingen. Sterker nog we automatiseren nog te weinig! Ik pleit dus voor meer IT :-)

Andre: Eens. Aandacht ofwel Vitamine A lost zeer veel zaken op.

cpt: In de basis helemaal mee eens. Inrichting is voor veel software een groot deel van het gebruik en er zitten altijd losse eindjes aan processen en hoe dit kan worden geautomatiseerd. We maken ook allemaal fouten en door de tijd heen worden fouten duurder (technical debt). Dit blijft ook mensenwerk en dit is niet zo maar weg te automatiseren. Legacy is in die zin goed omdat het in de basis processen automatiseert. Maar legacy betekent ook veroudering en er vanaf stappen is een groot risico en kost ook (veel) geld. Dit zijn gewoon feiten in mijn ogen. Punt is dat er veel mogelijkheden zijn bijgekomen en dat het nu mogelijk is bepaalde zaken eenvoudiger te maken zodat de uitdagingen vooral spelen waar ze het meeste opleveren, maar de transitie is niet makkelijk en als voorbereiding daarop moet je bereid zijn verlies te nemen door te rationaliseren en te standaardiseren.

Zoals reza zegt is cloud de legacy van morgen. Ofwel, wat we nu als "state of the art" beschouwen zal vroeg of laat verouderd zijn. Maar hoe beter je de zaken gescheiden houdt hoe beter je onderdelen kunt rationaliseren en vervangen waardoor je de legacy niet zo hoog op laat lopen als nu het geval is in primaire bankprocessen.

Maar gooi die benen eens op het bureau en kijk wat er zich afspeelt. Als je beseft wat er allemaal aan elkaar hangt wil je er bijna niet aan denken om dit "op te lossen". Toch zal iemand die pil een keer moeten nemen :-)

Meestal staat de kantoor automatisering redelijk los van de rest, dus is dat misschien een goed vertrekpunt.

Nog een nabrandertje in reactie op Ewout.

Hell yeah! Reken maar dat het niet eenvoudig is op te lossen. En zeker het risico en de kosten om van legacy naar een nieuwe it te komen is soms onmogelijk hoog, maar doorgaan zal zeker ook tot het einde van je life cyclus als organisatie leiden, tenzij je de bank bent of de overheid.

Ik heb ook zeker niet de wijsheid in pacht om even te vertellen hoe het moet. Er is veel leiderschap, moed en visie nodig voor dit proces. Heel veel mensen hebben niet de juiste competenties en het is zo complex dat het ook niet aanlokkelijk is om eraan te beginnen. Als het makkelijk was had iedereen het allang gedaan.

De enige handvatten die ik geef is rationaliseren, het gescheiden houden van zaken in een modulaire opbouw. Je moet dus altijd als een chirurg iets kunnen verwijderen en vervangen. Dit kan nooit als alles aan alles hangt. Vandaar dat rationaliseren nodig is en governance om ervoor te zorgen dat het alles aan alles hangen nooit meer gedaan wordt.

En als laatste wederom: Laat het fundament commodity zijn, en wellicht dat dit veel weerstand oproept omdat commodity ook nadelen heeft.

@Henri De cloud ontwikkelingen betekenen misschien dat infrastructuur als commodity beschouwd kan worden: een heel netwerk en machinepark in een hand om draai beschikbaar. Ik denk dat het verder geen enkel verschil zal betekenen voor het onderhoud wat nu ook al gebeurt. Je netwerk moet onderhouden worden, machines en applicaties moeten beheerd worden. Ook dan. Misschien zorgt deze ontwikkeling wel voor meer verwarring en is het medicijn erger dan de kwaal. Ik voorzie nog een woud van virtuele machines en systemen waar we straks geen eind meer aan weten. Een bestaande situatie in de overtreffende trap.

Ook over de kantoorautomatisering als commodity heb ik mijn twijfels. Ik denk dat het nooit op zichzelf staande onderdelen zijn en er altijd verwevendheid is met de rest van de organisatie en het bedrijf. Met die specifieke eigenschappen en die ander bedrijfsspecifieke applicaties waar ongetwijfeld links mee zullen bestaan. De organisatie dan maar aanpassen aan de software daar geloof ik niet in, het lijkt me een karwei wat lastiger is dan je denkt. Niet alleen de organisatie maar ook de bestaande software zal onder loep genomen moet worden. Als je zo een actie begint moet je volgens mij ten einde raad zijn.

Ik ben dan ook extreem conservatief, werkt het en voldoet het dan is er eigenlijk geen enkele redenen om de zaken volledig op zijn kop te zetten. Dan heb je genoeg aan je upgrades en aanpassing. Ben het ook volkomenm eens met @cpt met de opmerking: welk probleem wil je oplossen met het vervangen van de legacy? Dat is de eerste vraag die je moet stellen. Ik heb inmiddels al zoveel onzin over legacy gelezen. Gaat het fout? Legacy. Nogmaals legacy kan ook staan voor bewezen, uitontwikkeld, betrouwbaar. En dan nog kan ik me voorstellen dat je tot de conclusie komt dat er wat moet gebeuren. Functionerende legacy geeft je iig tijd om goed na te denken. Haastige spoed is zelden goed, zeker in de ICT.

Waar ik denk dat wel goed bezuinigd kan worden dat zijn de ontwikkelingstrajecten. Dat kan met veel minder mensen. Als je alle proces (scrum, lean, lean six sigma, kanban etc etc) gebeleiders en ander it bureaucraten en tussenlagen weghaalt schiet het al een stuk op. Een andere goed tip voor bezuiniging voor een organisatie is om te investeren in eigen onafhankelijke ict kennis. En je niet uitleveren aan een externe partij.

IT met losse handen, nee ik geloof er niet in.

Louis, je bent inderdaad de IT-er zoals ik ze heel veel tegenkom. Er zullen ook meer it-ers het met jou eens zijn, dan dat mijn mening omarmt wordt.

Wat betreft "Welk probleem wil je oplossen met het vervangen van je legacy?"

- Oplopende kosten die steeds minder in verhouding staan met de opbrengsten
- Een enorme rem op innovatie. Het houdt allerlei andere zaken tegen
- 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.

Want ja, legacy is een functionerend systeem, maar zoals gezegd; verouderd. Niet alle werkende systemen van jaren oud zijn legacy.

Je opmerking dat commodity infrastructuur ook onderhouden moet worden. Sure, maar tegen een fractie van de kosten! Het staat totaal niet in verhouding met de huidige manier van infrastructuur onderhouden en dat is mijn kritiek naar jou en laat me een voorbeeld geven. Ik geef zeer regelmatig workshops, lezingen, seminars en kennis sessies. Vaak aan IT-ers. Na praktisch elke sessie zijn de aanwezigen toch wel onder de indruk van wat er mogelijk is en dat betekent dus dat het nieuw voor ze is wat ik ze laat zien. Dus neem nu eens echt de tijd om te onderzoeken hoe deze diensten werken, hoe meer je te weten komt, hoe meer je onder de indruk zult zijn, al zal ik niet ontkennen dat er nog genoeg zwakke kanten aan zitten. Alleen gaan de verbeteringen zo snel dat er met gezwinde spoed de nadelen steeds minder worden.

Er zijn nog genoeg cases voor legacy en ik ben niet tegen *alle* legacy, dat zou onzin zijn. Maar als legacy een probleem is, dan zijn er genoeg middelen om hiermee om te gaan, dit is minder een technische uitdaging en meer een organisatorisch ding waar visie, moed en leiderschap bij komen kijken.

@Henri Ha ha, dat je me een IT'er vind zoals je veel tegenkomt vind ik leuk om te horen.

De ene legacy zal de andere niet zijn, de argumenten die je noemt om iets aan daaraan te doen (oplopende kosten, rem op innovatie, geen mensen) kunnen gerust waar zijn maar ik vind dan dat je het wel hard moet maken en precies aan moet kunnen geven waar dat probleem zit. Ik gaf al aan, ik geloof best dat er redenen kunnen zijn om iet aan de legacy te doen maar niet zomaar. Geen algemeenheden. Vandaar dat ik ook aangaf, zorg als organisatie dat je zelf de kennis hebt om dat te kunnen beoordelen. Het antwoord van een externe partij op die vraag kan ik haast wel bedenken.

Over het onderhoud van je infrastrucuur, ik heb het niet over echte machines en kabels maar over het onderhoud van je virtuele infrastructuur, machines en software. Ik heb zelf het idee dat het geen fractie zal zijn maar misschien zit ik er volledig naast. Denk eerder van dezelfde orde. Ik ben uiteraard heel benieuwd naar de diensten en ontwikkelingen die mij overtuigen van wat er mogelijk is en waar de winst valt te halen.

@Henri: ik ben het niet helemaal met je eens dat een leverancier waarschijnlijk niet de beste raadgever is. Ik denk dat juist de kracht van een leverancier moet zijn om bedrijven te helpen bij het zoeken van een goede vervanging voor hun legacy systemen. Door dan de juiste alternatieven aan te bieden, zoals IaaS of SaaS in combinatie met bijvoorbeeld Open Source, kunnen bedrijven daadwerkelijk kosten besparen.

Christiaan, dank voor je reactie. Okee, als ik mijn stelling omdraai krijg je: De leverancier is waarschijnlijk de beste raadgever... hmm dat klinkt ook niet goed toch? Sommige leveranciers blijken misschien de beste raadgever, maar in de regel is het zo dat een leverancier uiteindelijk altijd met zijn eigen oplossing komt en dat zal niet altijd de beste oplossing zijn. Onafhankelijk adviseurs hoeven overigens ook niet altijd de beste adviezen te geven, maar dat terzijde. Wat ik wel merk is dat veel it-ers niet op de hoogte zijn van veel ontwikkelingen en dat de mogelijkheden nu totaal anders zijn dan vijf jaar geleden en dat is een bruggetje naar Louis.

Helemaal mee eens dat je zaken hard moet maken en ik besef me dat mijn artikel niet specifiek is.

Wat betreft je 2e paragraaf, inderdaad, je zit er volledig naast :-) Nouja, laat me het nuanceren. Als je het opzet zoals het bedoeld wordt, dan zijn de kosten aan onderhoud van je (virtuele) infrastructuur nagenoeg 0, ze zitten voor een zeer groot deel versleuteld in de dienst en gebeuren dus buiten je zicht, en het deel waar jezelf verantwoordelijke bent is volledig geautomatiseerd. Ik laat het je met liefde zien.

@Henri: haha de beste raadgever klinkt ook niet goed inderdaad. Het is inderdaad afhankelijk van de leverancier of de oplossing de beste oplossing voor de klant is. Ik vind het zelf altijd belangrijk om een oplossing te bieden of te ontwikkelen dat helemaal in lijn ligt met de wensen en eisen van de klant. Het gaat ons niet om het advies of product wat het meeste geld voor ons oplevert maar om het advies of product wat het meest geschikt is voor de klant.

Wat betreft IT-ers die niet op de hoogste zijn van ontwikkelingen zit het hrm denk ik ook in het feit dat ze niet out-of-the-box durven en willen denken. Want waarom bijvoorbeeld voor de cloud kiezen als de IT-er nu volledig in control is over zijn eigen servers. Een goede IT-er moet juist out-of-the-box kunnen kijken!

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.

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

×
×