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

Risico en gevaar van achterhaalde technologie

 

Computable Expert

Angelo Dijkstra
Management consultant, Invigors LLP. Expert van Computable voor de topics Cloud Computing en Datacenters.

Veel organisaties vertrouwen nog steeds op een oud model server dat sinds jaar en dag trouw ergens in een kelder staat te snorren en vaak al drie keer is afgeschreven. Veelal draaien daar nog belangrijke applicaties en een oud besturingssysteem op, want if it ain’t broke... don’t fix it!

Ik vergelijk zulke situaties vaak met je eigen, oude auto. Je weet dat ie niet perfect is en dat hij wel wat reparatie kan gebruiken, maar hij brengt je nog steeds van A naar B. Maar onder de motorkap van die auto, en dus ook van die oude server, zitten allerlei gevaren en risico’s die kunnen resulteren in serieuze problemen. En die komen altijd op een moment waarop het niet uitkomt.

Serieuze kwetsbaarheden

De belangrijkste gevaren van het gebruik van verouderde technologie zijn wat mij betreft veiligheidsrisico’s. Hoe ouder je besturingssysteem of applicatie is, hoe langer de bad guys de tijd hebben om een kwetsbaarheid te vinden. Dit is al helemaal het geval wanneer de producent niet langer actieve support levert voor de bewuste software. Een recent onderzoek van securitybedrijf Cenzic, laat zien dat de applicatielaag nog steeds een aantrekkelijk doelwit is voor cyberaanvallen. 69 procent van alle applicaties die in 2013 zijn getest, bevatten één of meerdere serieuze kwetsbaarheden.

Het gemiddelde aantal kwetsbaarheden per app is gestegen van dertien vorig jaar naar veertien nu. En die gevaren bevinden zich over het gehele, vaak verouderde applicatieplatform. Oudere versies van SQL Server lopen gevaar. Misschien draait er nog ergens een oude ftp-server zonder dat iemand dat in de gaten heeft. Of er is nog wat verouderde netwerkapparatuur of appliances in gebruik. Het komt er eigenlijk op neer dat alles wat op of aan het netwerk hangt, een potentieel gevaar is voor jouw server en dus voor de business. En wanneer je de software en/of firmware op die server niet up-to-date hebt gehouden is het risico op een serieus security-incident dubbel zo groot.

Raid-arrays

Harde schijven zijn over het algemeen de zwakste schakel bij oudere hardware. Simpelweg omdat ze bewegende delen bevatten. Een probleem met een harde schijf resulteert meestal in het verlies van data en als een data recovery-actie niet correct wordt uitgevoerd, ben je nog verder van huis. Het gebruik van solid state drives (ssd) lost dit probleem voor een deel op en zorgt ook voor betere prestaties. Raid-arrays zijn uitgevonden om je te beschermen tegen uitvallende disks.

Hoewel dit al een veel betere situatie is dan helemaal niets doen, is het geen garantie dat alles weer als vanouds wordt wanneer je een kapotte disk vervangt. Zo kunnen er fouten zijn op andere disks die aan het licht komen tijdens het opnieuw opbouwen. Het probleem is alleen dat je er pas achter komt wanneer je je array echt goed checkt op fouten, wat niet veel mensen doen, of wanneer je dus een array opnieuw gaat opbouwen. In dat geval zit je dus met een kapotte array én dataverlies. Niet echt wenselijk.

Rottende bits

Er bestaat zoiets als rottende bits. Dat is het geval wanneer bits in het geheugen of op een disk staan in verval raken. Wikipedia beschrijft het als volgt: ‘Dankzij steeds maar groeiende capaciteit van disks, grotere bestanden en toenemende groei in data die op disks worden opgeslagen, is het steeds waarschijnlijker dat bit-rot of een andere vorm van incorrecte en onvindbare data zal voorkomen.’ Terwijl de nieuwste enterpise grade hardware steeds stabieler en betrouwbaarder wordt, is de kans dat dit voorkomt wanneer je daar steeds grotere hoeveelheden data op opslaat en mee verwerkt steeds groter. Het vervangen van disks helpt, maar wat ook helpt is het verplaatsen van kritische data naar meer geavanceerde storagesystemen, zoals die van EMC of NetApp.

Legacy-systemen kunnen ook slachtoffer worden van ‘software-rot’. Dit is het rottingsproces dat bestaat uit het alsmaar langzamer worden van de softwareprestaties of het feit dat de software langzamer reageert en uiteindelijke fouten maakt en onbruikbaar wordt. Dan is de term legacy echt van toepassing en zal er snel vervanging moeten komen.

Strategische issues

Wanneer bovenstaande zaken actueel zijn, kan zich op elk moment een probleem voordoen. De consequenties kunnen verlies van productiviteit zijn, of erger, verlies van kritische data dat zorgt voor negatieve impact op de bedrijfsvoering. Maar er zijn nog meer gevaren die op de loer liggen en waar je wellicht nooit aan hebt gedacht. Het blijven vertrouwen op oudere technologie en infrastructuur zorgt ervoor dat je organisatie achterblijft op enkele strategische punten.

Je concurrenten zijn je liever kwijt dan rijk. Ze willen jouw klanten en waarschijnlijk maken zij gebruik van technologie om concurrentievoordeel te behalen. Dit kun je niet doen door gebruik te maken van oude technologie. Door de inzet van moderne applicaties op een moderne infrastructuur kunnen je concurrenten beter communiceren, sneller reageren, meer deals sluiten en relaties verstevigen.

Oudere technologie kan simpelweg minder dan een moderne infrastructuur. Dit zorgt voor minder flexibiliteit op allerlei gebieden, zoals het kunnen analyseren van data voor het nemen van beter onderbouwde beslissingen, communicatie en samenwerking of het ontwikkelen van nieuwe applicaties.

Ben je in staat om snel en eenvoudig nieuwe applicaties uit te rollen en nieuwe medewerkers in te werken? En kun je op nieuwe initiatieven binnen enkele uren reageren in plaats van enkele dagen, weken of zelfs maanden? Misschien besteed je al je tijd wel aan het beheren van de infrastructuur en ‘het licht aanhouden’ in plaats van te focussen op nieuwe initiatieven. Oude it staat het tijdig kunnen voorzien in de juiste it-oplossing serieus in de weg.

Samenvattend zijn de (verborgen) risico’s van het gebruik van oude technologie als volgt:

  1. Een toename in beveiligingsbedreigingen en kwetsbaarheden
  2. Het falen van harde schijven die kunnen leiden tot catastrofaal dataverlies
  3. Bit-rot dat kan leiden tot het onbruikbaar worden van data
  4. Software-rot dat kan leiden tot instabiliteit, meer downtime en het verlies van productiviteit
  5. Je bent minder concurrerend
  6. It is minder flexibel
  7. De organisatie kan minder snel reageren

Problemen voorkomen en verhelpen

Organisaties doen er dus goed aan om werk te maken van het upgraden en onderhouden van hun systemen. Wat draait er? Is de software up-to-date? En is het echt nodig dat die bepaalde software draait op die bepaalde hardware en wat zijn de alternatieven?

Er zijn legio mogelijkheden om deze problemen te voorkomen of te verhelpen. Het vervangen van alle soft- en hardware is er één van, maar denk ook eens aan het uitbesteden van (delen van) je infrastructuur, serverpark en het hosten van applicaties in een (hybride) cloudmodel bij een betrouwbare hostingpartner.

Maar het begint bij het besef dat ‘goed’ niet perse de beste optie is.

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

7,1


Lees meer over


 

Reacties

Er is nog een belangrijk punt vergeten. Oude bestandsformaten zijn vaak niet meer of alleen met veel moeite leesbaar, wanneer je dan naar nieuwe hardware/software wil draait het oude pakket niet meer en het extraheren van je data wordt een hindernisloop om nog een oud programma te vinden dat je data er uit kan halen.
Dat kost tijd en geld.
De besparing van langdurig gebruik kan zich zo in lucht oplossen.

Nogal doorzichtig artikel. Inspelen op de angsten van de mensen en hiermee een oplossing aandragen die het symptoom niet aanpakt maar hoogstens verplaatst.

Dataverlies en uitval is prima op te vangen met diverse architectuur keuzes met elk hun prijskaartje.
Afhankelijkheden met legacy kan worden aangepakt door het zoveel mogelijk vermijden van vendor lock-ins en gebruik te maken van open standaarden.

Of je dit zelf doet of uitbesteed maakt in deze niet gek veel uit behalve dan dat je de expertise zelf hebt of over laat aan een professional.

Herkenbaar verhaal. In mijn praktijk heb ik een aantal van dergelijke situaties meegemaakt. Totdat de boel echt crashend. Dan is er een groot probleem. Maar wat erger is, je bent dan overgeleverd aan de helpende hand van je leverancier. Voor menig MKB bedrijf een horror scenario.
Maar de andere kant van het verhaal: menig opdrachtgever ziet er tegen op om een dergelijk traject te starten. Waar begin je en hoe pak je het aan. Welke stappen moet ik doorlopen. Maar ook hier weer een horror scenario: hoe bepaal ik de adviezen van mijn (potentiële) leveranciers? Onwetendheid over de aanpak van een dergelijk traject is vaak de reden dat vervanging wordt uitgesteld. Je kop in het zand steken.
Terwijl de aanpak op zich niet zo moeilijk is. Natuurlijk heb je de leveranciers nodig, maar belangrijk is dat je zelf de regie in handen houdt.

De genoemde verborgen risico's zijn op zich correct, maar het verhaal laat maar één kant van de medaille zien.

Nieuw hoeft niet per sé beter te zijn, ook nieuwe producten hebben hun kinderziektes. Je hebt dan misschien geen bit- of software-rot, maar sommige combinaties van de nieuwste hard- +softsoftware kunnen ook tot de nodige ellende en dataverlies lijden.

Als je systeem na 3 jaar financieel is afgeschreven, maar nog steeds voldoet, kan het lonend zijn nog een jaar of 2 door te draaien en in plaats van in nieuwe systemen te investeren te investeren in borging van je data integriteit en backup. Hiermee kun je aanzienlijk besparen.

Vergelijk het met de eerder genoemde auto: wat is het risico van de oude auto? Als je alleen maar 1 keer in de week boodschappen doet en 1 keer in de maand naar je schoonmoeder gaat, is het een minder groot probleem als de auto kapot is dan als je koerier bent en iedere week 2500km moet rijden.

Vervanging van technologie moet mijns inziens een kosten-baten-risico afweging zijn, en niet "vervangen om het vervangen" omdat er weer nieuwere technologiën en versies van je omgeving zijn.
(ik vergelijk het wel eens met MSWord; het kan veel meer dan 10 jaar geleden, maar ik gebruik bar weinig van alles wat in die tijd is toegevoegd)

@Pa Va Ke
Je hebt gelijk als je over priodes van vijf jaar kijkt. Mijn opmerking komt uit een situatie waar software uit de periode voor 2000 nooit een update had gekregen en de gehanteerde database-engine eigenlijk niet meer bestaat.
Wie zijn updates regelmatig laadt kan software gebruiken die zo 10 jaar meegaat afhankelijk van de business.
Ook hardware kan vaak verrassend lang mee, met behoorlijke back-ups is dat nauwelijks een probleem zolang je je bewust bent van het risico.

Dat je met oudere software 'minder concurerend' zou zijn, waag ik te betwijfelen.

Zeven praktische punten van waar je ook aan moet denken. Hoewel ik wel het gevoel heb dat elk punt het gevolg is van die daarboven. Bovenaan, puntje 0, zou dan kunnen staan beheer en onderhoud van systemen. En dan zou je al klaar zijn. Maar dat zeg je eigenlijk onderaan, onder het laatste kopje.

De suggestie dat dit niet of minder nodig is, als het maar nieuw is, lijkt me iets te kort door de bocht. Maar dat was vast de bedoeling.

Angelo,

Op zich praktische punten die wel herkenbaar zijn.

Alleen sluit ik mij wel enigzins aan bij Pa Va Ke en Johan Duinkerken.

Bit-rot is niet altijd onlosmakelijk verbonden met legacy en oud. Bit-rot wordt in mijn optiek erg vaak door menselijke fouten ( slecht beheer/programmering/kennis gebrek etc. ) of verkeerde architectuurkeuzes verspreid.

@Anna
Uiteraard heb je gelijk, maar beheer en onderhoud is niet sexy en innovatief. Daarmee scoor je niet als ict-auteur of cio en wordt je getypecast als oubollig en out-of-touch.

Kleine toevoeging nog.

Alles staat en valt met een goede back-up.

Deze back-up dient geregeld getest te worden. En er dient geborgd te worden dat de data ook over een x aantal jaar nog in te lezen is. Want alleen data veiligstellen is leuk, maar je moet het ook nog terug kunnen halen. Hier voor zijn de keuze qua hardware en programmatuur van cruciaal belang. Zijn deze eenmaal gemaakt dan is overstappen lastig en tijdrovend.

Tevens dient er ook op operationeel vlak wel wat veranderd worden. Voor het patchen, aanpassen of installeren van een nieuwe release dient er een correcte back-up/copie gemaakt te worden. Mocht er 'bit-rot' onstaan dan kan je altijd nog terug. En 'bit-rot' is soms pas heel laat te ontdekken.

Als een server die een werkend systeem oplevert een risico is als deze omvalt dan zit het probleem niet in de server, maar in je organisatie.

En dit geldt eigenlijk voor de rest van het artikel. Er wordt angst aangepraat, maar die angst zou zich niet moeten richten op de techniek, maar op de organisatie.

Naast de genoemde punten is er ook nog een kostenaspect. En dan bedoel ik niet eens de herstelkosten die gemaakt moeten worden bij een verstoring. Gewoon de kosten van beheer en aanpassingen die noodzakelijkerwijs zijn. Zijn er nog wel mensen beschikbaar die de juiste kennis nog hebben en bereid zijn om hieraan te werken.
Daarnaast zijn nieuwe servers goedkoper in stroomgebruik.

@Henri


De techniek de schuld geven is makkelijk: kun je vervangen, en "de techniek" zegt niets terug.
Dat gaat bij de organisatie net iets lastiger zeg maar ;)

Henri/Pavake,

Helemaal mee eens. Vaak is juist de menselijke factor (lees organisatie, kennis ) de beperkende factor.

Geheel eens met Henri. Veel FUD aangepraat met weinig goede onderbouwing. SSDs lossen harde schijf problemen niet altijd op. SSDs hebben ook een beperkte houdbaarheid, ze zijn ontegenzeggelijk sneller, dat is waar. Het gevaar van bitrot is bij SSDs echter niet kleiner.

Er wordt geen onderscheid gemaakt tussen de hardware server en de software server. Als men een server op de juiste momenten voorziet van patches is er geen probleem met beveiligingslekken (zeker bij Linux distributies worden security patches nog jarenlang ondersteund, dit in tegenstelling tot sommige betaalde operating systeem varianten).

Er wordt snel aangenomen dat nieuwe systemen makkelijk(er) aan te leren zijn door de werknemers terwijl oude systemen heel moeilijk aan te leren zouden zijn. Waar is de onderbouwing?

En de 7 punten die worden aangedragen als nadeel van oude technologie zijn net zo geldig bij nieuwe technologie. Ook uitval van SSDs kan catastrofale gevolgen hebben. Nieuwe applicaties kunnen last hebben van (zero day) security problemen. Het zelfde geldt voor bitrot, software rot, etc..

Waar de auteur de plank een beetje misslaat is de uitspraak dat je minder concurrerend zou zijn met een oud systeem of dat je IT minder flexibel zou zijn. Hiervan wil ik de onderbouwing wel eens willen zien. Volgens mij ben je concurrerend met een product, niet met een server; en flexibiliteit hangt niet alleen af van de server (maar ook van het personeel en management).

Kortom: geen goed stuk, ook al is het een opinie.

Ik ben het eens met PaVaKe en ik ontken de benoemde gevaren en punten in dit artikel niet.
Maar ja, de investering die je nodig hebt om je dienst op je eigen DC veilig te stellen heb je ook nodig als je van een cloud-leverancier gebruik wilt maken. Ik heb het over cloud escrow. Bovendien je hebt misschien in een cloudmodel een aantal risico`s niet die je in je traditionele model hebt maar je hebt wel in een cloudmodel een aantal nieuwe risico`s die je omgekeerd niet in je traditionele omgeving hebt.

Neem niet weg dat ik een voorstander ben van het jaarlijkse review van je ict-conditie zodat je met kleine aanpassingen, tijdig met minder risico`s, minder investering en beheerst met de tijd meegaat. Een ict-omgeving die up-to-date is, legt de bal neer bij de business en geeft de business de mogelijkheden om door het wijzigen van werkprocessen (daar waar nodig) meer efficiëntie en wendbaarheid te behalen.
Dit is overigens mogelijk wanneer ict niet alleen als "kostenpost" beschouwd wordt.

@ Johan Duinkerken
Je slaat de spijker op zijn kop. Het is een artikel dat zijn dienst verkoopt. Vergelijk met de auto is natuurlijk lastig, want gevirtualiseerde auto's in een cloud bestaan niet of iets vergelijkbaars.
Beiden hebben onderhoud nodig en dat iemand (of dat nu een bedrijf of een prive persoon is) dat nalaat, zal altijd leiden tot dit soort zaken.
Als we dan gaan kijken naar de oplossing, vind ik Anna haar opmerking, veel nuttiger. Zorg dat het niet voorkomt.

Het doet me denken aan de manier waarop Amerikanen hun wegennet aanleggen. Zij kijken bij de financiering van snelwegen (en overigens ook brugger) alleen naar aanlegkosten. Iemand die is ingevoerd in aanleg van infrastructurele trajecten weet dat je de prijs x2 moet doen, om ook de komende 50 jaar de weg te kunnen blijven onderhouden.

Dus les 1, zorg dat je een business case maakt met het complete onderhoud erin, qua tastbare producten/diensten (patchmanagement, monitoring, hw servicing, sw/hw onderhoudscontracten) en kies een serieuze afschrijvingsperiode, waarbij je ook een vervangingsinvestering opneemt.

@Angelo
Dat er risico's zijn is een 'fact of life' maar risicomanagement als proces gaat om het mitigeren hiervan op basis van - zoals PaVaKe zegt - de business case waarbij er vanuit twee cases gewerkt kan worden: operationeel en financieel. Je hele verhaal is niet eens meer een 'Wij van WC-eend' verhaal maar gewoon een klok en klepel gevalletje als ik even snel de SLA doorneem en van daaruit concludeer ik dat er alleen maar inspanningsgaranties en zeker geen resultaatgaranties gegeven worden.

Verhaal rond disks is werkelijk compleet onzin, RAID-arrays worden niet ter vervanging van een back-up gebruikt maar om middels redundantie de beschikbaarheid en prestatie te verhogen. Om EMC of NetApp te noemen als oplossing lijkt me een zwak argument, het gaat niet om een product maar de processen van hostingprovider zoals we dus al eens leerden met hostingprovider Exacthost. En bitrot wordt vooral in verband gebracht met het vervallen van de opslagmedia of in het geval van Jan het in onbruik raken van software wat gewoon om lifcecycle management gaat.

Derk Kremer heeft gelijk dat het om de regie gaat maar begint net als NumoQuest wel in herhaling te vallen met zijn studeerkamer wijsheden in boekvorm want als het om service lifecycles gaat dan is de onderliggende technologie irrelevant. Hierbij heb ik het dus niet over het service portfolio van de cloud prutsers maar die van de afnemer welke helaas vaak niet meer weet wat er allemaal onder de motorkap gebeurt.

Betreffende het vervangen van legacy applicatieplatformen is de praktijk weerbarstiger doordat veel hostingproviders met server virtualisatie deze alleen maar 'verclouden' waardoor wel de fysieke footprint verlaagd wordt maar de problemen dus niet opgelost. Wederom verwijs ik graag naar je eigen voorwaarden waaruit blijkt dat elke vorm van maatwerk buiten de service valt en dus gewoon door de afnemer gedaan moet worden.

Terug naar het begin, casus van financieel risico kan inderdaad gemitigeerd worden met hosting maar dat geldt dus meestal niet voor het operationele risico doordat dingen wel op afstand geplaatst worden maar lang niet altijd adequaat opgelost. Grappige is dat bedrijven hier meestal pas achterkomen als de service 'down' is want incident management blijft uiteindelijk altijd reactief, net als dat rekening pas achteraf komt.

De cloud biedt mogelijkheden, geen wonderen...

"Ik vergelijk zulke situaties vaak met je eigen, oude auto."

Als je de vergelijking met een auto begint, en die kan illustratief zijn, moet je hem wel afmaken en nuanceren. Bij auto's is de curve van afnemende kapitaalskosten (rente en afschrijving) tegenover toenemende onderhoudskosten al lang geleden beschreven en is een optimale gebruiksduur vaak berekend. Als die berekening voor servers en de programmatuur die daarop draait niet wordt gemaakt, blijft het in het duister tasten over wanneer je moet gaan vervangen.

Overweging: Huisdeuren (ik noem maar wat, vul alles in wat je wilt) vallen na honderd jaar gebruik ook uit elkaar. Ben ik daarom als huisdeurverkoper geloofwaardig als ik iedereen adviseer zijn deuren na vijf jaar preventief te vervangen?

Als ik als ex-Mapics consultant zie wat er op meerdere plaatsen gebeurde bij het vervangen van Mapics naar zogezegd modernere systemen, zoals Dynamics toestanden, waarbij plots MRP niet behoorlijk functioneren, forecast alleen als productflyer bestaat, zelf input doen van forecast data aanvaard ik niet, een grove leugen, veel hardcoded toestanden moet invoegen, dan stel ik mij vragen als blijkt dat zogezegd nieuwe concepten minder functionaliteit in huis hebben dan dertig jaar oudere concepten, Excel en internet buiten beschouwing gelaten. Waar blijft uw concurrentieel voordeel? Maar dat blijkt niet de bedoeling te zijn vlg. Sommige experts.

Om maar bij het begin meteen me de deur in huis te vallen....

Falend E2E keten policy
Veel organisatie focussen volkomen op zaken zoals #Plum #Scrum #Lean #Mean en #Humtidum of #BunteIllustrierte maar kennen weinig tot niets meer van de meest basale merites zoals een IT keten policy.

Bijzaken worden tot hoofdzaken verheven maar het meest basale meer en meer veronachtzaamd, terwijl die gewoon basic en onveranderd blijven in aandacht en belang. Als je namelijk geen goede policy en procedure hebt om hetgeen EOL is, en geen oog hebt voor een goed geordend CMDB voor je spullenboel, verdien je bijna niet beter.

Je blijft dan als IT professional wel telkens hetzelfde roepen waarbij 'heilige geesten' telkens maar graag commercieel hypen waarom hun model of 'Nieuwe Realiteit' zoveel beter is dan....

Wederom een artikel als deze?

Misschien een aardig signaal gewoon even weer eenvoudig na te gaan denken en te kijken naar simpel, simpeler, simpelst? Wat mij betreft is gecompliceerd niet interessant en nee, ik ga niet domweg mee in die zg 'nieuwe realiteiten' omdat er voor mij nog steeds de universele waarden vooraan staan.

De toevoegende waarde van IT dat je wil implementeren. Niet hijgerig hypen.

Een prima artikel; wel wat opmerkingen.

M.b.t. de hardware. Niet alleen bewegende delen in de klassieke zin, kunnen slijten. Chips en kleine soldeerverbindingen kunnen haarscheurtjes krijgen door het steeds weer uitzetten en krimpen, vooral bij slechte koeling. Daardoor kunnen componenten gaan falen. Testprogramma’s kunnen dit soort kromme bitjesproblemen vaak opsporen.

Chemische processen in elektrolytische condensatoren kunnen deze elco’s compleet ruïneren en ook andere componenten in de buurt. Elco’s kunnen binnen twee jaar rot zijn, of na twintig jaar nog steeds goed. Visuele inspectie kan plotselinge uitval voorkomen. Maar het mag soms niet vanwege de garantie.

Door het herschrijven van HD’s, EPROM’s, kan bit-rot tegengegaan worden. Dat werkt niet bij SSD’s, of DVD’s. Dan moet je (na opschonen) een kopie op een nieuwe schijf maken.

Omdat je niet weet wanneer het probleem optreedt, is niet zinvol om de hardware zonder een directe aanleiding preventief te vervangen; testen dus. Vervangen hoeft overigen niet altijd vernieuwen te betekenen.

M.b.t. de software. Bit-rot is niet altijd weg te werken, zoals in de vorm van slapende code is bij aangeschafte software. Even wat rotte bitjes bij een Windows Server of een MS Suite gaan wipen, is helaas geen optie. Overbodige data en software gaan opschonen kan wel, maar dat gebeurt te weinig.

Naast regulier beheer en onderhoud, is het regelmatig schouwen van hard en software en architectuur belangrijk. Dan kan beoordeeld worden of deze vervangen moet worden vanwege technische, functionele of economische redenen. Elke component of laag kan eerder of later dan gepland afgeschreven moeten worden. Haperende oude meuk kan heel kostbaar zijn. Als er geen nieuwe eisen zijn, dan geldt if it ain’t broke... don’t fix it.
Gebeurt dit schouwen niet, dan is er sprake van organisatierot. Wellicht moet dan je eens wat menselijke componenten gaan vervangen.

Wat een belegen artikel. Praat nog over servers in kelders, de bezemkast was een populaire naam bij de ICT-ers, disks, alsof deze in de server zitten, etc. Nog een paar jaar en dan zijn we van deze verhaaltjes af.
Servers met applicaties draaien virtueel, data staat op een SAN of in de cloud en applicaties zijn niet verouderd omdat het een SAAS is.
Anno 2014 ben ik wel klaar met deze onzin.

Even kijken, "Don't change a winning team". Als ik het verhaal lees lijkt het meer op een verkooppraatje, moeten verbeteren omdat vernieuwing moet. Ontzettende onzin natuurlijk. Waarom zou je persé iets moeten moderniseren als het goed werkt. Nieuwe hardware kan natuurlijk altijd, desnoods in een VM ofzo. Het veiligheidverhaal is natuurlijk sterk overtrokken want je kunt zat mogelijkheden eromheen treffen dat de veiligheid versterkt. En wat virussen betreft, zijn vaak geschreven voor nieuwere systemen.

Daarnaast is oude software vaak geschreven op performance en niet op 'modelling' bullshit wat nu tegenwoordig de trend is. De vraag blijft altijd of vernieuwing daadwerkelijk een verbetering is en of het daardoor efficiënter en sneller wordt. Zo'n systeem is vaak uitontwikkeld en wanneer je weer opnieuw zou beginnen kunnen er nieuwe problemen ontstaan. Dat brengt de continuïteit en stabiliteit van een organisatie in gevaar.

Automatisering wordt nu veel te veel omringt door 'Fashion', het lijkt niet meer om automatiseren te gaan. Eeen nieuwe broek omdat je er anders niet meer bijhoort. Kolder.

Heb het ook gezien bij het UWV, nieuw programma waarbij er veel met de muis moet worden gewerkt. Gevolg: RSI klachten personeel. Inderdaad daarvoor een 'oud' DOS programma maar was gespitst op invoer. Dat bedoel ik dus, vernieuwing hoeft niet altijd een verbetering te zijn.

Tja ook ik zie vooral weer eens een WC-eend verhaal.
Er wordt nogal eens vergeten dat heel wat bedrijven niet gebaat zijn bij een standaard oplossing.
En er zijn heel wat toepassingen die je echt graag op je eigen (al dan niet gedateerde) server wil laten draaien.
Probleem is vooral dat:
- We maar blijven denken dat ICT enkel bestaat uit kantoor automatisering en al dan niet fancy websites
- We maar blijven denken dat enkel een kan en klaar oplossing een goede oplossing is
- We maar blijven denken dat er geen gekwalificeerde mensen te vinden zijn en we het dus moeten doen met het gemiddelde niveau dat de afgelopen vijftien jaar van HBO opleidingen vandaan zijn gekomen
hmmm dat zijn wel de belangrijkste punten van kritiek die ik heb.
De overige zijn in essentie een herhaling ervan.

@ Reza,

Goede toevoeging.

Net zoals bij auto's moet je ook je ICT omgevingen periodiek checken.

En wordt repareren te duur dan is vervangen altijd nog een optie.

Ik heb hier in het verleden al iets over geschreven:

http://www.computable.nl/artikel/opinie/storage/4549928/1277017/apk-voor-de--ictomgeving.html

Beste Angelo,

Goed stuk en zeker een reminder van.... Want het is ook een telkens weer terug kerend hiaat in de E2E IT keten. Ik kan me alleen niet helemaal vinden in je kleine opsommingslijstje, maar dat terzijde. Een goed voorbeeld was twee jaar geleden toen alle wissels in en rond Utrecht plots 'er uit vielen'. Wat bleek, de aansturende PC was een legacy PC waar niemand eigenlijk echt naar om heeft gekeken gedurende verschillende migraties en transities.

Ik vond dit werkelijk een acte van onvermogen voor de IT dienstenleverancier. Je hebt immers, tenminste zo zie ik het, ook tot taak zaken te signaleren en zaken aan te kaarten.

Absoluut een goed artikel. Dank.

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

×
×