Denne artikel stammer fra det trykte Computerworlds arkiv. Artiklen blev publiceret den Computerworld d. 12. november 2004.
Flere vedholdende myter om it viser sig i denne analyse, begået af amerikanske
InfoWorld, at være mere til grin end til gavn. Men som alle andre fagfolk risikerer også den it-ansvarlige at hoppe på fejlagtige overleveringer.
INTERNATIONALT
De store server-leverandører praler gerne af, hvor enkle, hurtige og billige deres respektive server-produkter er at opgradere for kunden selv. Men det er en myte, at gud og hvermand ligger og roder "under kølerhjelmene", medmindre der ligefrem er tale om udskiftning af en defekt del.
Er en server under et år gammel, er den sandsynligvis leveret med de dele, der er nødvendige, og er den over et år, begynder ingen ved deres fulde fem at skille chassiset ad for at skrue på nogle gigahertz.
For at be- eller afkræfte myten tog InfoWorld kontakt med en række vigtige server-leverandører. Ingen af dem udviste større samarbejdsvilje, da de blev bedt om statistik over opgradering af deres servere - hverken i form af salgstal på løsdele eller i form af antal kundebesøg, gennemført af deres servicefolk. Flere hævdede, at oplysningerne ikke fandtes, andre, at det var fortrolig information. Alle var dog enige om at være overraskede over spørgsmålet og så frem til resultatet.
Heldigvis kom en enkelt (unavngiven) leverandør til at videresende en uformel kommentar fra en marketingchef, hvis synspunkt afspejlede en mistanke: "Hovedparten af kunderne køber fra første færd en server forsynet med ram og processorer til fremtidig vækst".
Ikke at forglemme er der også en indgroet skræk for at komme til at lave rod i maskineriet ved at opgradere - både på hardware-siden og med styresystem, drivere og applikationer. Alt andet lige er der jo ikke nogen enorm ydelsesgevinst at hente ved at gå fra for eksempel 2,0 gigahertz til 2,6 gigahertz, hvis resten af serveren forbliver uberørt.
Overordnet kan man sige, at jo mindre server, desto større sandsynlighed for, at dens hardware vil forblive urørt tiden ud. Hvis en low-end-server ikke kan klare arbejdsbyrden, er løsningen at skifte den ud med en større eller at udbygge med flere servere i et load-balance-cluster. Der er ingen ROI at hente på at kaste gode penge efter dårlige.
Siden de kom på markedet i 1950'erne, har mainframe-computere hersket som urokkelige vogtere af forretningsverdenens mest centrale data.
IBM fik tilnavnet Big Blue efter farven på sine første mainframes og opbyggede gennem årtier et solidt greb om markedet - frem til 1970'erne og 80'erne, hvor de første mini- og mikrocomputere gjorde deres indtog. Fra da kunne man købe sig til distribuering af centrale data ud til de brugere, som sad med det praktiske arbejde, og dermed efterhånden frigøre sig fra afhængigheden af mainframen.
Ikke desto mindre overlevede den antagelse, at mindst 80 procent af alle koncern-data fandtes på mainframes, til langt op i 1990'erne - flere år efter pc-revolutionens start.
Men internettet og flodbølgen af ustrukturerede data, såsom e-mails, hjemmesider og Word-dokumenter - og et tilhørende væld af teknologier til at styre og lagre disse data - må give en formodning om, at mainframen er ved at slippe sit stålsatte tag.
Analytikeren Dana Gardner fra Yankee Group har noteret sig, at stadig større mængder, virksomhedscentrale, økonomiske data i vore dage skabes, deles og håndteres langt uden for mainframens rækkevidde.
- Flere store virksomhedskunder bruger i dag Spreadmarts - store og flade filer i regneark, beregnet til at håndtere en lang række forretningsprocesser efter et meget decentraliseret mønster, siger hun.
Desuden har leverandørerne i de senere år kørt massiv markedsføring af snesevis af integrations-strategier, som hen ad vejen vil bryde de teknologiske grænser mellem mainframes og distribuerede platforme, og dermed bliver spørgsmålet om, hvor data befinder sig, stadigt mere underordnet.
SAN og NAS er også miljøer, som truer mainframens dominans. Selv om flere af dem har linier forbundet til mainframe-baserede data, er tendensen klar hos et stigende antal brugere: De placerer deres data på SAN- og NAS-udstyr.
Eksperter er enige om, at det ikke er en myte, når man hævder, at mindre firmaer foretrækker homogene mijøer, mens større selskaber uundgåeligt bevæger sig mod de heterogene gennem fusioner og opkøb.
Forskningschef i Forrester Research, Mike Gilpin, peger på desuden på friheden i det heterogene miljø:
- Det er altid smart at have en alternativ leverandør, man kan true lidt med, siger han.
Gilpin får opbakning fra kunde-/partnerchef i IBM's Autonomic Computing Group, David Bartlett:
Før i tiden var forholdet mellem homogene og heterogene miljøer sådan cirka 80 til 20, men det er nu nærmest vendt på hovedet. Virksomheder vil både være globale og kunne fungere i ubrudt døgndrift ugen igennem, og her har selvfølgelig banet vejen til det mere heterogene.
Begge miljøer har imidlertid deres fordele og ulemper. Enkeltleverandør- (såkaldt lukkede, eller proprietære) løsninger dæmmer op for bøvlet med at få systemer til at fungere sammen, som ikke er indrettet til det. Men de lukkede løsninger binder samtidig brugeren til en enkelt, eller nogle ganske få, leverandørers forgodtbefindende med deraf følgende begrænsede valgmuligheder.
Med såkaldt åbne løsninger får brugeren mange teknologiske valgmuligheder, hvilket teoretisk sænker priserne, fordi flere leverandører byder med.
Men hvad er egentlig et åbent system? Termen "åben" bruges som regel om software eller hardware, der bygger på standarder, eller som indeholder standard-komponenter, og uanset hvilken leverandør man spørger, vil han formentlig svare, at hans system er åbent - og at samtlige konkurrenters er lukkede.
For 20 år siden var CIO'ens vigtigste opgave at sikre, at virksomhedens forretningsmål blev tilstrækkeligt understøttet af den teknologi, it-afdelingen valgte. Der skulle bygges bro mellem to meget forskellige kulturer. Men i takt med at teknologien siden er blevet stadigt mere sammenvævet med organisationens nøglestrategier, er de øverste it-ansvarlige blevet tvunget til at bruge langt mere krudt på forretningssiden.
Samtidig er antallet af teknologi-projekter vokset, hvorved mange CIO'er og CTO'er har måttet skubbe beslutningsansvaret for teknologi-indkøb og -implementering længere ned i organisationen. Alt for ofte har de, der træffer produkt-beslutninger, fokuseret for ensidigt på teknologien og har derved truffet taktiske beslutninger uden skelen til, hvordan de ville påvirke de overordnede virksomhedsmål.
En vigtigt grund til, at de it-ansvarlige har måttet interesserere sig mere for forretning end for teknologi, skal findes i dotcom-boblens brist. Efter nyttesløse investeringer i sidste halvdel af 1990'erne kræver mange topchefer i dag kortsigtet - for ikke at sige omgående - ROI på alle it-investeringer af en vis størrelse.
Men når CIO'en eller CTO'en skal arbejde så koncentreret på kortsigtede gevinster, tvinges de uvægerligt til at udsætte visionen om de stabile, langsigtede implementeringer til bedre tider. Dermed risikerer de at stille deres virksomheder i en ringere konkurrence-situation end dem, der finder en mere rimelig balance mellem deres ROI og it-investeringer.
- Den organisation, som virkelig forstår it-teknologi, og hvordan man bruger teknologien til at opnå et konkurrencemæssigt forspring, står lige nu i den bedste position, siger Will Zachmann, direktør for analysefirmaerne Canopus Research og Agylity.
Eksistensen af gigantiske konsulentforetagender som IBM Global Services, Capgemini og Sapient kunne give mistanke om, at det ude i virksomhederne vrimler med dårlige erfaringer med it-projekter.
Men begrebet "fiasko" er relativt, mener nogle, herunder forskningschef i AMR Research, Jim Shepherd. Ganske vist præges mange projekter af mindre systemfejl eller budgetter, der er løbet løbsk, men det gør dem ikke nødvendigvis til fiaskoer med fatale konsekvenser for brugeres forretning.
- Trods problemer undervejs i et projektforløb lykkes de fleste implementeringer faktisk i sidste ende, siger Jim Shepherd.
The Standish Group, som udelukkende giver sig af med at registrere it-succeser og -fiaskoer, arbejder med en meget skarp definition af succes. Firmaet undersøgte sidste år 13.522 projekter og fandt, at andelen af projekter under "succes-grænsen" var nede på 34 procent. Helstøbte fiaskoer, defineret som projekter, der blev stoppet halvvejs, var 15 procent. Mellem de to kategorier var så de gennemførte, men "udfordrede" projekter, som repræsenterede 51 procent af alle it-projekter og var kendetegnet ved overskredne budgetter, tidsrammer - samt projekter, som ikke levede op til den lovede funktionalitet.
Ifølge rapporten er succes-kriteriet for et projekt helt afhængigt af graden af bruger-involvering, støtten fra topledelsen og af projektlederens erfaring - i nævnte rækkefølge.
- Måske er den dårligste nyhed for it-projekter som sådan ikke antallet af dem, der blev skrottet, men dem som blev gennemført - dog uden de oprindeligt specificerede funktioner, mener direktør i Standish Group, Karen Larkowski.
- Indholds-mangler på over 50 procent kunne meget vel betegnes som en fiasko, tilføjer hun.
Her har AMR's Jim Shepherd dog et andet synspunkt, som han selv kalder mere realistisk:
- En fiasko er en situation, hvor man ikke længere kan tage imod ordrer, afslutte regnskaber, eller hvor hele projektet simpelthen skrinlægges. Og det er meget sjældent!
På et eller andet tidspunkt, og af en eller anden grund, har alle former for informationsteknologi svigtet, når det gælder skalering. Hvad vil det så overordnet sige? Ikke ret meget - for "skalérbarhed" er et frygteligt vidt begreb.
Applikationer skal ideelt set kunne skaleres op til kæmpemæssige server-farme eller ned til de mindste håndholdte. Men ikke nok med det, så udgør størrelsen kun en af akserne i skalérbarhed - andre udgøres for eksempel af hastighed, transaktions-intensitet, udbud af tjenester, forespørgsels-håndtering og en række menneskelige faktorer.
Der findes ikke et enkelt kunstgreb, som kan tackle hele spektret under et, men det afholder os ikke fra at forsøge.
En historie fra det virkelige liv er det mundhuggeri, som opstod, da Friendster, der driver et såkaldt "socialt netværk" online, skiftede fra J2EE til PHP og forbedrede sine svartider markant. Det var vand på PHP-tilhængernes mølle, som i årevis havde måttet høre på, at "scriptsprog ikke kan skaleres". De kunne nu med stor fornøjelse give igen med et "Java kan ikke skaleres".
Ikke blot gik dønningerne højt, men de kastede også nyt lys på det, PHP's opfinder, danskeren Rasmus Lerdorf, kalder PHP's "shared nothing"-arkitektur. Fordi PHP er "statsløs", bliver potentielle flaskehalse skubbet ud af web-laget og ind i database-laget, forklarer Lerdorf.
- Hvis man for eksempel bruger Oracle, vil skalérbarheden være ligefrem proportional med, hvor stor en check du udskriver til Oracle. Hvis man bruger MySQL, eller PostgreSQL, gælder det om at have korrekt konfigureret replikering samt om at have et arkitektonisk perfekt struktur af database-maskiner.
Man Java kan bruges på en tilsvarende måde. Da eBay under stor bevågenhed gik over til J2EE, fik den nye arkitekturs statsløshed størstedelen af æren for succesen.
- Statsløsheden er netop et kendetegn ved EJB (Enterprise JavaBeans, red.), siger Sun-ingeniøren John Crupi, som deltog i eBays re-design. Den reviderede arkitektur brugte statsløse Session Beans, slap for klynger, men baserede sig på et sæt forretnings-objekter, som blev undersøttet af eBays unikt skræddersyede database-lag.
Kort og godt er skalérbarhed ikke en medfødt del af et programmeringssprog, en applikationsserver eller en database. Den opstår derimod af en kunsterisk kombination af ingredienser til en effektiv løsning.
Det kunne være fristende at påstå, at den decentraliserede, løst koblede web-arkitektur af natur er skalérbar. Men det er ikke tilfældet. Også her er der tale om ingredienser, som skal blandes i det rette mål.
For alle former for teknologi gælder det, at "X kan ikke skaleres" er en myte. Realiteten er, at der altid vil findes måder at skalere X på - og masser af måder, hvorpå man kan kikse med det. At få øje på mulighederne og undgå faldgruberne kræver erfaring, som (endnu) ikke kan købes indpakket.
Billedtekst:
IBM havde gennem årtier et solidt greb om markedet for mainframes indtil 1970'erne og 80'erne, hvor de første mini- og mikrocomputere
kom på markedet.
Boks:
Sammendrag: I it-verdenen huserer adskillige myter. Nogle af dem viser sig ved en nærmere analyse ikke at holde, mens andre er rigtige.
Boks:
Myte 1: Serveropgradering gør en forskel.
Virkelighed: Betal aldrig ekstra for opgradérbarhed. Du får ikke brug for det.
Boks:
Myte 2: 80 procent af alle virksomhedsdata ligger på mainframes.
Virkelighed: Snarere 50 procent - og måske mindre end det.
Boks:
Myte 3: Alle store installationer afvikles på blandede platforme.
Virkelighed: En "myte" i forholdsvis pagt med virkeligheden.
Boks:
Myte 4: CIO'er og CTO'er skal i dag have bedre forretningsforståelse end teknologisk forståelse.
Virkelighed: Teknologisk ekspertise er vigtigere end nogensinde.
Boks:
Myte 5: De fleste it-projekter mislykkes.
Virkelighed: Det kommer helt an på definitionen af at "mislykkes".
Boks:
Myte 6: It kan ikke skaleres.
Virkelighed: Stort set al it kan skaleres, forudsat at man bruger de rigtige ingredienser og implementerer dem korrekt.
