Management maakt IT kapot !

oktober 31, 2013 under IT & Samenleving

Door onkunde, gebrek aan een lange termijn visie en een ambivalente houding jegens automatisering, staat Management een optimale inzet van IT in de weg. Dit wordt niet erkend; een stuk eigenaarschap en verantwoordelijkheid wordt afgeschoven op de IT organisatie of op een leverancier. Wanneer wordt IT nu eens eindelijk beschouwd als een onderdeel van de core business in plaats van een lastige kostenpost.

In elk denkbare bedrijfstak, kan de vervaardiging van goederen of diensten niet zonder een solide parallelle informatievoorziening. Dit is nogal een open deur. Echter nog steeds wordt er een kunstmatig, geforceerd, onjuist en hierarchisch onderscheid gemaakt tussen de core-business (“waar het geld verdiend wordt”) en de IT infrastructuur (“..die alleen maar geld kost”). Terwijl informatie en het strategisch inzetten daarvan een essentieel onderdeel vormt van de core-business.

Korte termijn visie

Op alle terreinen in de samenleving wordt de scope van beleid korter. Bonuscultuur, aandeelhoudersvalue en de voorkeur aan zichtbare resultaten zijn hiervan de oorzaak. De organisatie is daarom voortdurend onderhevig aan ingrijpende beslissingen. Fusies, afstoten van bedrijsonderdelen, outsourcing, off-shoring, etc… Voor een IT infrastructuur betekent dit een voortdurende aanpassing van het basisontwerp en een voortdurende stroom van verstorende wijzigingen en projecten. Een infrastructuur, de kennis ervan en de processen er omheen kennen echter een andere, veel tragere dynamiek. Er is sprake van een natuurlijke inertie. Een solide IT infrastructuur heeft misschien wel 5 tot 7 jaar jaar nodig, om goed en doordacht ontworpen te worden, te worden gebouwd en geïmplementeerd, te integreren in de organisatie, om de kennis ervan te borgen en, niet op de laatste plaats, om ervan te genieten en ervan te profiteren gedurende de periode na voltooiing. Waarom wordt een fabriekshal wel gebouwd met een scope van 10 jaar en een IT infrastructuur niet ? Het adagium van de steeds sneller veranderende samenleving en de behoefte van ultieme flexibiliteit is naar mijn mening doorgeschoten. De balans is zoek tussen stabiliteit en betrouwbaarheid enerzijds en flexibiliteit en aanpasbaarheid anderzijds.


Het gevolg is dat de IT infrastructuur een onsamenhangende lappendeken wordt. Oude, nog niet eens voltooide omgevingen, blijven voortbestaan in een sub-optimale status. Nieuwe segmenten worden gebouwd en om het oude toch met het nieuwe te verbinden worden “tijdelijke” specials bedacht. Oude apparatuur wordt niet weggehaald: “het werkt toch?”; “we weten eigenlijk niet wat we onderuit halen..”; “geen tijd voor Life Cycle Mgt.; doen we wel als het wat rustiger is..”. Delen van de infrastructuur worden uitbesteed aan verschillende externe partijen en mensen worden herplaatst naar ander plekken in de organisatie, de externe partijen nemen mensen over, of mensen worden ontslagen. Actuele kennis en kennis over historie van het IT landschap, wordt zo verspreid of verdwijnt zelfs. Niemand heeft meer inzicht en overzicht en niemand voelt zich meer eigenaar en verantwoordelijk voor de uiteindelijke IT dienstverlening. Nieuwe implementaties van projecten en ketens kosten onnodig veel tijd omdat informatie bij vele verschillende afdelingen moet worden gehaald. Wijzigingen worden zeer riskant en hebben veel tijd nodig om te worden beoordeeld door diverse Change Advisory Board’s omdat niemand echt kan overzien welke diensten er allemaal geraakt worden. Storingen duren onnodig lang om te worden opgelost omdat op allerlei plekken in de organisatie maar ook daarbuiten er dingen moeten worden onderzocht en op knoppen moet worden gedrukt. Nadat enkele specialisten van de oude garde er na ettelijke nachtelijke uren in slagen om de storing op te lossen, begint op de middle management laag het “zwarte pieten spel” en worden de techneuten lastig gevallen met vragen van “de planning” waarom ze afgelopen maand zoveel overuren hebben geschreven op een projectcode. Dit moet anders; we gaan de processen verbeteren..Er komen service-managers en proces-coordinatoren bij..Nog meer Chiefs en de laatste Indians (techneuten) raken zwaar gefrustreerd…

Werkvloer als sluitpost

De eersten in de rij maken het grootste deel van de koek op…Een voorbeeld uit de praktijk. Er moeten datacenters worden uitgefaseerd. Alles moet worden gemigreerd naar andere, bestaande datacenters. Hiervoor moet een infrastructuur ontworpen worden die als tussenstap fungeert om de applicaties om te vormen om ze te kunnen laten landen in hun nieuwe omgeving. Het loopt tegen het einde van een boekjaar en nog voordat er ook maar een schets is, wordt er al een partij hardware besteld om nog gebruik te kunnen maken van het budget in dit lopende jaar. In de eerste maanden van het nieuwe jaar wordt er op allerlei niveaus vergaderd en overlegd tussen architecten, de businessmanagers van de vragende partij en de projectleiders van de leverende partij. Na 4 maanden is er een zeer globaal document, in de vorm van een high level design (HLD). Ondertussen is de planning niet aangepast en zijn de oorspronkelijke deadlines gewoon blijven staan. De technisch specialisten die de infrastructuur moeten gaan bouwen krijgen enerzijds een draft versie van het HLD en anderzijds een setje pakbonnen met het verzoek om uit te zoeken wat er voor hardware is geleverd en waar het eigenlijk staat. Er is al veel tijd verstreken en de druk om concrete resultaten te kunnen laten zien wordt alsmaar groter. Naar alle eer en geweten puzzelen de techneuten een detailontwerp bij elkaar met behulp van het summiere HLD en de beschikbare ‘lego-blokjes’ aan hardware. Maanden zijn er opgegaan aan politiek getouwtrek en discussies over architecturele keuzes; het echte bouwen en realiseren is een sluitpost geworden in de tijdsplanning. Om nog maar te zwijgen over kennisborging in de vorm van documentatie en overdracht, dat al helemaal in de verdrukking komt op het einde van een project.

Wel de lusten niet de lasten

Als er één gebied is waarin Management een, op zijn zachtst gezegd, een ambivalente houding laat zien is dat wel (IT)security. Natuurlijk wordt er wel geïnvesteerd in technologie en processen. Er moet immers voldaan worden aan diverse normen (ISO, PCI, etc..) om sowieso ‘in business’ te blijven. Ook is men huiverig voor (externe) audits en is men gevoelig voor eventuele imagoschade als een security incident breed in de publieke belangstelling komt te staan.
Maar ik betwijfel of men intrinsiek is begaan met IT-security; “Om te kunnen voldoen aan de norm moeten we het minimale doen, rijden we een partij firewalls en IDS/IPS systemen binnen en gaan we iets doen met toegangscontrole en authorisatie en authenticatie. Maar eigenlijk hebben we er alleen maar last van. Security doet vaak moeilijk en het kost weken om een firewall poort geopend te krijgen. Onze klant wil connecteren op een bepaalde poort dus ze moeten gewoon die firewall openzetten..Het duurt veel te lang zo..”.
Dus, na een intern escalatie traject staat er aan het bureau van de argeloze firewall beheerder een “stropdas” die een verkeersstroom er doorheen duwt. Dat daarmee de veiligheidsstandaarden worden geschonden is op dat moment even niet belangrijk.
En als het dan mis gaat, bij een incident of na een audit dan, wordt er van hogerhand gezegd: “Dat moeten ‘we’ (lees: jullie techneuten) beter doen in het vervolg..”.

Hoe kan de kloof tussen “business” en IT worden overbrugd. Ik heb daar eigenlijk geen pasklaar antwoord op. Wel denk ik dat het moet beginnen bij besef en inzicht bij de beslissers, dat IT veel meer is dan de simplificatie van “water uit de kraan” en dat het veel dichter tegen “de business” aan staat dan wordt gedacht. Een optimale inzet van IT is toch vaak maatwerk en is niet zonder ingrijpende gevolgen inwisselbaar of uitbesteedbaar. Daarbij moet een IT infrastructuur de kans krijgen om zich over een langere uit te kunnen kristalliseren. Hierdoor is het rendement van investering hoog en houdt je als bedrijf goede technisch specialisten binnenshuis en daarmee hun kennis en ervaring van en met het IT landschap.

Bart van den Berg, oktober 2013

(dit artikel verscheen tevens op de opinie-pagina van de Computable)

comments: Closed tags: , , , ,

Cloud & Vertrouwen

augustus 15, 2013 under IT & Samenleving

Er is een onstuitbare ontwikkeling dat IT functionaliteiten en data-opslag in de ‘cloud’ worden belegd. Ik kan in het algemeen een eind meegaan in de voordelen van een cloud-oplossing. Echter, ik bespeur bij mijzelf een grote aarzeling om mijn (privé) data naar de cloud te brengen. Dit is niet eens in eerste instantie ingegeven door beveiligingsoverwegingen, maar meer door mijn groot gebrek aan vertrouwen in de grote bedrijven en instanties als zodanig.

Ik moet vooraf wel kwijt dat ik redelijk ouderwets ben en sterk hecht aan oude vertrouwde en beproefde oplossingen en werkwijzen. Maar als je die factor uitschakelt dan blijven er een aantal van mijn bezwaren naar mijn mening nog steeds overeind. Mijn grootste bezwaren zijn dat ik er geen vertrouwen in heb dat een cloud-dienst over 10 jaar of meer überhaupt nog bestaat of dat ik transparant toegang blijf houden tot mijn data.

Stabiliteit

Leveranciers kunnen worden overgenomen of kunnen failliet gaan. De bankencrisis heeft ons geleerd dat ook de instanties en bedrijven waarvan eens werd gedacht dat ze onaantastbaar waren, toch ook konden omvallen. Als dit al geldt voor banken dan geldt het helemaal voor IT dienstverleners.  Op een lager niveau kennen we de verhalen van bijvoorbeeld de keuken die je nu aanschaft waarbij je na 10 jaar je aankoopbedrag ‘gegarandeerd’ terugkrijgt. In de tussentijd is de keukenboer failliet gegaan en blijkt dat de stichting die de betalingsverplichting had overgenomen geen juridische relatie meer heeft met de gedupeerde eindklant. Op micro niveau is er het voorbeeld van het opslaan van (deep)links naar websites of subpagina’s. Na verloop van tijd zullen de subpagina’s of verwijderd zijn of naar een andere locatie zijn gegaan of de content is veranderd. Op het moment dat je een link een keer echt nodig hebt dan is de pagina niet meer beschikbaar.De gemeenschappelijke deler van dit al is het gegeven dat de scope en horizon van aanbieders steeds korter lijkt te worden. Verandering, vernieuwing en wijziging als enige constante. Als eindgebruiker, die op zoek is naar continuïteit, ben je overgeleverd aan een dynamiek die je niet kent, die je niet wil en waar je geen invloed op hebt. En als je dan een ‘helpdesk’ belt kom je er na een paar weken achter dat de dienst is aangepast en gewijzigd om nog beter aan ‘de wensen van onze klanten’ te voldoen. Maar jou wens voor continuïteit en stabiliteit is niet meegenomen (“mij is nooit wat gevraagd”). Er bestaat doorgaans geen keuze-optie: “Alles laten zoals het is”.

Toegankelijkheid

Wat betreft de toegang tot je (remote) data, dien je vaak gebruik te maken van een portal, een ‘agent’ of een bepaalde minimale versie van een webbrowser…Ook allemaal vereisten die worden afgedwongen door de leverancier. Het zou nog acceptabel zijn als die vereisten enigszins gelijk blijven in de loop van de tijd. Echter in deze ‘vendor lockin’ moet je eerder dan je lief is mee in het update- en upgrade proces van een ander.

Zelf doen

Door dit soort ervaringen heb ik een zeer hardnekkige neiging om data en content gewoon zelf te willen hebben: gedownloade MP3′tjes in plaats van Spotify, gedownloade filmpjes in plaats van een link of playlist in Youtube, kopiëren en plakken van de inhoud van een webpagina in een Word document, de originele Jpegs van foto’s in een mapje in plaats van een online foto-album…Natuurlijk wel opgeslagen op een NAS in een RAID-1 configuratie (tegelijkertijd data schrijven naar 2 discs), en het maken van meerdere periodieke backups waarbij niet wordt vergeten om een harde schijf op een andere locatie te bewaren. Het ‘zelf doen’ vergt immers wel extra werk en discipline. Maar dat heb ik graag over voor het gevoel van controle en vertrouwen dat ik heb dat ik over 10 jaar nog steeds de originele digitale high-resolution versie van de baby-foto’s tot mijn beschikking heb..

“Zelf doen, zelf doen”…zelf je data blijven opslaan en beheren…het past in het rijtje van broodfondsen, zelf sparen voor je pensioen, lokale groentetuintjes, burgerinitiatieven in de wijk, etc…We zijn te vaak teleurgesteld en ‘bedonderd’ door grote bedrijven, overheden en instanties……..en nog elke dag….

comments: Closed tags:

IPv6: “slicing the elephant”

januari 26, 2013 under IT & Samenleving

De overstap naar IPv6 wordt beschouwd als een mega-operatie. Dit zorgt er vaak voor dat een IPv6 project wordt uitgesteld. Dat is jammer omdat er juist nu nog tijd is voor een rustige en gefaseerde implementatie van IPv6. De kunst is eigenlijk om een dergelijk omvangrijk project in kleine behapbare stukjes te hakken

Maak het kleiner

Het invoeren van IPv6 is als het vervangen van de gemeentelijke riolering; het is een enorme klus en we weten dat het een keer moet gebeuren maar het liefst stellen we het nog zo lang mogelijk uit. Een van redenen waarom men hier zo tegenaan hikt, is het gegeven dat een IPv6 implementatie je gehele infrastructuur raakt. Op zich is dat waar. Echter in de hoofden van degene die erover moeten beslissen wordt een dergelijk project heel groot gemaakt. Het is op zich niet verkeerd om de impact van IPv6 niet te licht in te schatten maar door IPv6 als één groot blok te beschouwen, krijgt het een verlammende werking. Een extra vertragende factor daarbij is nog dat het moeilijk is uit te leggen aan de hogere ‘baasjes’ waarom we nu al moeten voorsorteren op IPv6; de business-case is moeilijk rond te krijgen.

De kunst is om die grote olifant, die in zijn geheel niet te behappen valt, in plakjes te snijden (“slicing the elephant”) om zo gefaseerd IPv6 in te voeren. Heel veel werk kan je al doen nog voordat je een eerste IT systeem hoeft aan te raken. Te denken valt aan een inventarisatie of alle hardware en operating systems IPv6 compliant zijn. Verder kan je al beginnen met een aantal medewerkers op cursus te sturen om zo kennisniveau, bewustwording en enthousiasme te verhogen.

IP plan

Het eerste grote deelproject is het maken van het IPv6-nummerplan. Dit majeure onderdeel kan helaas niet verder in kleinere stukjes worden opgedeeld omdat een IP-plan als geheel moet worden ontworpen. Verder moet het belang van een IP-plan niet worden onderschat. De keuzes die hierin worden gemaakt zullen de komende 10 à 20 jaar hun invloed doen gelden. De kans dat je een nieuw IP plan kan opstellen is een unieke die maar een paar keer in een loopbaan langskomt. Nu is het de tijd bij uitstek om iets te doen met de lessen die kunnen worden geleerd van fouten en inconsistenties  in het huidige IPv4 nummerplan. Je kan weer met een schone lei beginnen. (Nog steeds hebben we geen enkel stuk hardware aangeraakt..)

Dual Stack

Als we dan uiteindelijk toe zijn aan de implementatie, dan is er eigenlijk maar één realistische strategie: de dual-stack strategie. Dit houdt in dat je in de huidige IP(v4) structuur een IPv6 nummering erbij configureert. Op een host (server of werkstation) kan eenvoudig IPv6 worden geactiveerd (op dezelfde netwerkkaart) en ook in de configuratie van Layer3 interfaces van netwerkcomponenten kan een IPv6 adres naast/onder een IPv4 adres worden ‘ingeklopt’. Dit heeft verder nauwelijks impact op de huidige IPv4 connectiviteit; kan ongestraft naast elkaar bestaan.

Als eerste komt de DNS aan de beurt om IPv6 ‘enabled’ te maken in een dual-stack configuratie; het is immers een centrale- en essentiële dienst voor je gehele netwerk. In veel gevallen is DNS opgenomen in een totaalpakket van IPAM (IP adres registratie), DNS en DHCP, dus zodra het IPv6 nummerplan gereed is moet het gelijk worden ingevoerd in de IPAM-module. Meteen ook een unieke kans om eindelijk eens af te komen van die eeuwige Excel-lijsten.

Deelsegmenten

Deel de gehele netwerkinfrastructuur vervolgens op in wijzigbare en bijelkaar horende segmenten, zoals: koppelvlak met service-provider, core/backbone segment, koppelvlak core-datacentrum, server-segment en eindgebruikerssegment, dmz & firewalls. Maak van de IPv6 implementatie in deze segmenten, kleine deelprojecten en voer ze stap voor stap uit. Je trekt vanaf het punt waar IPv6 je netwerk binnenkomt, aan de service-provider zijde, langzaam maar zeker IPv6 steeds verder je netwerk in. Rond elk deelproject netjes af en evalueer voordat je het volgende stuk oppakt. Langzaam maar zeker ontstaat er overal end-to-end IPv6 connectiviteit en de kennis, durf en ervaring onder de ICT-medewerkers neemt snel toe. Het zal voorkomen dat je stuit op servers en/of segmenten die niet overweg kunnen met IPv6. Dit worden dan logischerwijs ook deelprojecten. Er zijn voor dit soort situaties echter al beproefde (tussen)oplossingen (NAT64/DNS64, Reverse Proxy, etc..).

Natuurlijk is het zaak om IPv6 configuraties eerst te proberen in een testomgeving, maar uiteindelijk kan je gewoon een begin maken met het aanpakken van de produktiesegmenten. Wel moet goed worden gelet op de performance van routers en firewalls zodra IPv6 op die componenten is geactiveerd.

Met betrekking tot het uiteindelijke “live” gaan van IPv6, zullen diensten aan de Internet-zijde, de voorkant, de hoogste prioriteit krijgen. De reden is dat vanaf Internet de eerste urgente aanvragen voor IPv6 connectiviteit zullen komen, van bijvoorbeeld “IPv6-only clients” uit Azië.

Aandachtspunten

Speciaal vermeld moet worden is het wireless segment in combinatie van BYOD: dit segment zal in de komende jaren een enorme groei doormaken en zal ook een grote variatie van mobiele ‘clients’ kennen. De vele verschillende (versies van) operating systems, zullen ieder op hun eigen manier omgaan met IPv6 en al dan niet een ingebakken voorkeur hebben voor IPv6 of IPv4. Een ander aandachtspunt is de voorgeprogrammeerde voorkeur van bijvoorbeeld Windows-Vista of Windows-7 om te communiceren via IPv6. Zolang het gebruikerssegment nog niet klaar is voor IPv6 zal het wellicht nodig zijn om dit ongecontroleerde en onvoorspelbare IPv6 verkeer op de ‘access-laag’ te filteren.

Al schrijvende over IPv6 begin ik onderhand wel trek te krijgen in een broodje olifant: “Slager..kunt u het in dunne plakjes snijden ? het mag gerust een onsje meer zijn..”

Bart van den Berg, 26 januari 2013

( dit artikel verscheen tevens op de opinie-pagina van de Computable: index )

comments: Closed tags: , ,