![[Forrige artikkel]](../../gifs/prev.gif)
![[CW hjemmeside]](../../gifs/cw.gif)
![[Neste artikkel]](../../gifs/next.gif)
Strategisk valg av et verktøy kan ofte føre galt av sted
Som gammel systemutviklingsmann, er jeg skeptisk når jeg hører om organisasjoner som foretar strategisk valg av ett utviklingsverktøy -- et valg som skal følges for enhver pris, skriver Stein Arne Nistad.
Noen kilometer etter konstaterte en betjent på en bensinstasjon (dette var jo i riktig gamle dager, så slike fantes fortsatt) langt fremskredent vannpumpehavari med fare for bråstopp og fullstendig skjæring. På en hasardiøs måte kom vi oss hjem til Lørenskog, min studentfrue og jeg. Det var fortsatt en stund til jul, og økonomien bar preg av et nytt studielånfinansiert stereoanlegg i stua. Her måtte det gjør-det-selv reparasjon til.
En sen høstdag for snart 20 år siden streiket min gamle Ford Taunus 17M. Det begynte på Sollihøgda da varmeapparatet sviktet og hvite røykskyer virvlet opp fra panseret.
Vannpumpa ble innkjøpt noen dager etter, og etterlot et tilnærmet svart hull i bankkontoen.
Så satte jeg igang i optimistisk stil. Med skiftenøkkel gjøv jeg løs, ute i en iskald garasje, mens regnet ble til sludd og senere til snø utenfor. Vannpumpa var en kinkig affære.
To av boltene gikk greit, mens den tredje satt nesten umulig til. Skiftenøkkelen måtte smettes inn i en spalte, med noen centimeters klaring. Bolten måtte så lirkes ut med korte små tak med skiftenøkkelen. Etter en halvtime var jobben gjort. Så var det den omvendte prosessen. Ny pumpe på plass. De to enkle boltene gikk greit, men den siste -- som jeg slet. Svette, eder og galle! Kjølevæske og olje i øynene! Iskald på ryggen!
Omsider - etter et par tre timer var bolten på plass. Som kronen på verket, skulle jeg bare dra den skikkelig til, og da -- bolten knakk! Jeg ga opp. I protest fylte jeg radiatoren med frostvæske og kjørte i vei, til nærmeste bensinstasjon.
Som det lakk. Heldigvis var det den innerste bolten som var røket, slik at vannpumpa ble klemt mot blokken av viftereima. En flaske radiatortetting gjorde susen, og etter noen minutter var pumpa tett. Ikke en spesielt god eller vedlikeholdbar løsning med det fungerte. Og under over alle under; 17M-en gikk i flere år med vannpumpe hengende i to bolter.
Det er forskjell på undervisning og læring. Undervisning gir deg teorien, læring oppstår når teori knyttes til erfaring og blir til kunnskap. Jeg lærte en lekse i kulden under min gamle 17M. Et enkelt budskap: Det kreves kompetanse for å utføre bestemte typer oppgaver (en bilmekaniker ville neppe dratt bolten så hardt til at den brakk) -- og har du nødvendig kompetanse til å løse en oppgave, så løses den best ved bruk av egnet verktøy. Et skrallesett, med leddet stang ville gjort susen. Vannpumpeskiftet ville gått som en lek, uten frustrasjon og nesten-katastrofer . Moralen er, med andre ord - velg redskap som passer til jobben som skal gjøres.
Jeg støter stadig på prosjekter for strategisk valg av komponenter i en IT-løsning; Prosessens mål er å standardisere komponentene; dvs maskiner, operativsystem, regneark, tekstbehandler osv. Komponenter velges fra markedets velfylte hyller, i den hensikt i å unngå kaos i organisasjonen. Uten tvil et edelt mål -- og i de fleste tilfeller også både nødvendig og ønskelig. For det er intuitivt fornuftig å standardisere bruken av program og maskinvare innenfor en organisasjon. Et slikt standardiseringsarbeid er forhåpentligvis med på å redusere effekten av Finks lov som ubønnhørlig konstaterer at: "Et systems kompleksitet øker med kvadratet av antall komponenter som inngår!" (Effekten av loven burde indikere at de fleste større organisasjoner opplever kaos på IT-siden, hvilket i og for seg heller ikke er langt fra sannheten!)
Strategiske valg er derfor bra -- dog innefor fornuftige rammer. For en ting er å standardisere teknologiplattform og bruk av desktop produkter. En helt annen sak er det å standardisere bruken av utviklingsverktøy.
Som gammel systemutviklingsmann, er jeg skeptisk når jeg hører om organisasjoner som foretar strategisk valg av ett utviklingsverktøy -- et valg som skal følges for enhver pris. For erfaringsmessig er et utviklingsverktøy som er godt egnet til utvikling av skjermbilder nødvendigvis ikke like godt egnet til rapportering. Et verktøy som er godt egnet til utvikling av skjermorienterte systemer er ikke automatisk godt egnet til produksjon av behandlingsintensive systemer.
Og jeg snakker av erfaring: For noen år siden ledet jeg et prosjekt hvor det var valgt et utviklingsverktøy. Applikasjonen skulle realiseres innenfor rammene av verktøyet -- koste hva det koste ville -- og det var det det gjorde. I prosjektet gikk det med tusenvis av timer for å generere rapporter i et verktøy som var uegnet for oppgaven. Misforstå meg rett; Verktøyet var bra til det det i utgangspunktet var laget for -- utvikling av funksjonsorienterte skjermbilder i et on-line system. Verktøyet var aldri ment for utvikling av komplekse dataintensive rapporter og skulle heller aldri vært brukt til det.
Så tilbake til mitt historiske og traumatiske vannpumpeskifte. En viktig del ved alle praktiske arbeidsoppgaver er å finne rette verktøy. Det være seg reparasjon av biler eller oppussing av hjemmet. Godt og riktig verktøy er gjerne mer enn halve jobben. Så også når det gjelder systemutvikling. Det er gjerne en sammenheng mellom et utviklingsprosjekts vellykkethet og verktøyenes egnethet i forhold til de oppgavene som skal løses. Og det å velge et generelt strategisk verktøy -- et slags systemutviklingens brekkjern, skiftenøkkel, skrutrekker, drill, avbiter og huggjern bygget sammen til et slags "ultimate development tool" kan føre svært galt av sted.
Slike generelle verktøy med "magiske" egenskaper finnes enkelt og greit ikke. Imidlertid er det i markedet tilgjengelig en lang rekke glimrende verktøy, dog med forskjellige egenskaper og karakteristika. Noen rene metode verktøy, noen kombinerte utviklingsverktøy med sterk metodestøtte, andre mer typiske utviklingsverktøy, eller 3GL generatorer. Spekteret spenner fra CASE til maskinære utviklingsverktøy, fra komplekse rapporterings- og statistikkverktøy til verktøy som kan benyttes av sluttbrukere. Det finnes verktøy med sterke bindinger til bestemte plattformer som f.eks Windows og andre mer konseptuelle som støtter flere ulike plattormer.
Kanskje kan det defineres enkelte objektive kriterier som kan avdekke om et gitt verktøy er godt egnet for en organisasjon. Personlig er jeg imidlertid av den oppfatning at et verktøys egnethet i utgangspunktet kun kan måles i forhold til den konkrete arbeidsoppgaven som skal løses. I praksis betyr dette at valg av verktøy må vurderes i en taktisk sammenheng. Og da blir spørsmålet hvilke verktøy er nødvendig for å løse de konkrete oppgavene?
Svaret er ikke nødvendigvis et verktøy, kanskje må flere benyttes for å realisere prosjektet på en effektiv og vedlikeholdsmessig god måte. Og dette er en interessant observasjon i seg selv. Min påstand er: Jo mindre effektivt utviklingsmiljøet er -- jo mindre vedlikeholdbart blir systemet som utvikles. Og årsaken er ganske enkel: Effektivitet betyr produktivitet. Med andre ord: Dårlig produktivitet betyr som oftest at det er lite samsvar mellom oppgavens karakteristika og verktøyets egenskaper. Det vil med andre ord si at utvikleren må "fikse" og "trikse" for å få løst oppgaven. Resultatet blir da vanligvis ikke i spesielt gode, effektive eller vedlikeholdbare systemer. Kostnadene blir høye, og det vil oppstå et skjæringspunkt, hvor det er billigere å opprette og vedlikeholde kompetanse på et nytt egnet verktøy, enn det er å utvikle og vedlikeholde programmoduler i et mindre egnet verktøy.
Hva så med Finks lov? Et sammensatt utviklingsmiljø hvor verktøy velges fra oppgave til oppgave er isolert sett neppe med på å redusere kompleksiteten i drifts- og utviklingsmiljøet. Imidlertid tror jeg at strategiske valg også her kan redusere effekten. Jeg tror det handler om å komponere en verktøykasse som henger sammen; En verktøykasse som dekker utviklingsprosessen fra det metodiske til realisering. Målet må være at verktøykassen inneholder et så begrenset antall verktøy som mulig, dog må den være dekkende i forhold til de oppgavene som skal løses. Og ikke minst, må det være mulig å inkludere nye verktøy når nye behov som det kvalitativt er vanskelig å dekke ved bruk av de eksisterende verktøy melder seg. Utfordringen er å velge verktøy som kan benyttes innefor rammene av en felles metodisk overbygning og som kan integreres med hverandre. For det er viktig at moduler utviklet i de forskjellige verktøy kan snakke sammen og at de kan inngå i en felles systemløsning.
Å komponere en slik verktøykasse er i seg selv en stor faglig utfordring. Det kreves oversikt, erfaring og bred kompetanse. Oppgaven løses kanskje best gjennom et dedikert prosjekt. I prosessen kan det bli nødvendig å knytte til seg ekstern kompetanse eller å støtte seg på informasjon fra eksperter på området. ButlerBloor, Gartner Group, Meta Group osv. kan være interessante informasjonskilder i denne sammenheng. Strategisk valg av et verktøy tror jeg som sagt ofte kan føre galt av sted; For det finnes neppe en verkstedeier med fornuften i behold, som ville beslaglegge samtlige pluggnøkkler og annet spesialverktøy på sitt bilverksted med begrunnelsen: "Her på verkstedet har vi valgt skiftenøkkel som strategisk verktøy for vedlikehold av biler!"
![[Image map not available]](../../gifs/artmap.gif)