Hvorfor gjør vi IT-investeringer? Det handler om å redusere komplekse problemer til meningsfylte oppgaver som mennesker kan fullføre.

Jeg ønsker å fokusere på utvikling av programvare (løsninger, pakkeprodukter, osv) og hvilken verdi programvare har for våre brukere. Å bygge programvare er en av flere viktige funksjoner som vi gjør hos Steria, og det er tusenvis av andre som også bygger programvare for å løse utfordringer.

Undersøkelser har vist at vi ikke har hatt særlig forbedring i suksessraten i utviklingsprosjekter. Bransjen har ca. 30% suksess i prosjekter som starter opp, og slik har det vært siden 1996 i følge Standard Group (CHAOS Report). Hvorvidt dette er representativt for det norske markedet er ukjent, men egne erfaringer fra Norge tilsier at det er en betraktelig høyere andel prosjekter med suksess her i landet, mye takket være smidige teknikker og prosesser.

Programvarens lov

I henhold til David S. Platts 3 lover om programvare, har programvaren vi bygger i seg selv ingen verdi. Det har liten betydning hvor teknisk bra kildekoden til et program er, det er kun vår egen mor som bryr seg om slikt.

Platts 3 lover sier:

1. Programvare har ingen verdi i seg selv. Den eneste verdien programvare har er gleden den gir til brukeren.
2. Programvaren kan øke brukerens glede på en av to måter. Den kan hjelpe brukeren å fullføre en ønsket oppgave, eller den kan gi en god opplevelse. Eksempelvis hjelper Outlook med å lese og skrive epost, mens HALO på Xbox 360 gir deg en god opplevelse som er underholdende.
3. Brukeren skal ikke tenke på programvaren. Det viktigste er innholdet og oppgaven, ikke programvaren i seg selv.

Målet med programvare bør alltid være å redusere komplekse problemer til enkle oppgaver. Enkle oppgaver som mennesker kan utføre, uten at det krever mye tankearbeid. Desto mindre en bruker må tenke, desto mer glad og produktiv vil han bli.

Tenke enkelt

Når vi har et komplekst problem vi ønsker å løse, hvilke mekanismer pleier vi å benytte for å løse dem? Når vi ser på programvaren som har blitt utviklet opp igjennom årene, er det ganske klart at vi ikke tenker på å gjøre ting enkelt.

Vår forståelse av komplekse problemer øker desto mer vi jobber med dem. Men vi har problemer med å komme opp med enkle løsninger. Altfor ofte lager vi kompliserte løsninger for komplekse problemer. Dette må vi forsøke å unngå, for det er hovedårsaken til at utviklingsprosjekter feiler.

Vi må sammen begynne å tenke enklere. Vi må sammen utforske hvordan vi kan redusere komplekse detaljer i et løsningsdesign, helt til vi sitter igjen med et design som er så enkelt som overhodet mulig og fortsatt gir verdi til brukerne.

Vårt mål bør være: Lage en enklest mulig arkitektur.

Det er selvsagt mange årsaker hvorfor noe som starter enkelt, fort blir komplisert. En viktig faktor er mengden av funksjonalitet i en løsning. Robert L. Glass  skriver i boka “Facts and Fallacies of Software Engineering” at 25% økt funksjonalitet øker kompleksiteten med 100%.

Neste gang du står ovenfor et problem som noen ønsker løst ved hjelp av programvare, start med å tenke over brukerne og hvordan du kan øke deres glede. Deretter reduserer kompleksiteten i løsningsdesignet til du oppnår det enkleste designet som er mulig som fortsatt oppnår målet: Gjøre brukerne glade!

(Se mitt innlegg om løsningsarkitektur på MSDN Live for mer detaljer om dette emnet)

For noen år siden hadde jeg et massivt vektproblem. Problemet var ikke så stort at jeg hadde vanskeligheter med å komme meg igjennom dører, men jeg hadde definitivt et helseproblem. Jeg hadde ikke en gang en god medisinsk unnskyldning for min overvekt, som noen legitimt kan ha for sin størrelse. Sannheten var at jeg rett og slett bare elsket mat, og at jeg var for svak til å sette en stopper for denne kjærligheten. Men jeg enten forsto ikke, eller ønsket å innrømme at jeg selv var problemet. Jeg prøvde hver eneste slankekur som kom. Vekten min gikk selvfølgelig opp og ned som en jojo. Den nyeste slankedietten skulle alltid være løsningen. Virket ikke den ene, kastet jeg meg fort over den neste. Jeg ønsket at andres diettplaner skulle fjerne min overvekten. Jeg ønsket ikke å endre egne uvaner eller måten jeg oppførte meg på. “Kuren”, “dietten” skulle løse det for meg. Kjøp av junk food var utrolig lettvint, og nødvendig i en konsulents travle hverdag. Jeg overbeviste i hvert fall med selv om det…

For å gjøre en lang historie kort så vedvarte problemet. Investeringer i nye kostprogrammer løste ikke problemet mitt. Det tok flere år før jeg erkjente at det var jeg selv som var problemet, eller mer nøyaktig: at det var tankeprosessen min som var det egentlige problemet. Slankekurene representerte den reaktive meg. Jeg fokuserte på vektøkningen, i stedet for å fokusere på endring av uvaner og adferd som var årsaken til vektøkningen. Manglende viljestyrke og udugelighet til å erkjenne, eller vilje til å erkjenne, selve problemet… var mitt problem. En dag, med hjelp av personer rundt meg og andre tilfeldigheter, bestemte jeg meg for at min egen relasjonen til mat måtte bli endret. Tankeprosessen måtte endres. Mat skulle være middelet for målet som nemlig var overlevelse og god helse. Maten skulle ikke være målet i seg eller for seg selv. Jeg var nå på min vei mot vektreduksjon. Det var kun etter at jeg erkjente jeg hadde et problem samt endring av min tankeprosess for å adressere problemet, at slankekurer, verktøy og strategier virkelig kunne få effekten av tankeprosessen til å bli en virkelighet.

Nå må jeg først si at denne historien faktisk hverken er selvopplevd eller sann, og jeg har aldri hatt et vektproblem. Men vi kjenner vel til andre med lignende problem. Hva er da så moralen, og hva har IAM med dette å gjøre? Like sikkert som at en slankekur ikke vil løse slankerens problem over tid, vil heller ikke verktøy alene løse organisasjoners utfordringer og problemer med brukeradministrasjon og tilgangskontroll. Det nytter ikke å spise plaster når man har magesår. Det som virker er er en sammenhengende, strategisk, fokusert og godt planlagt innsats som er styrt av et velfungerende team.  Jeg er fristet til å si at dersom virksomheten ikke er forberedt på en IAM-suksess for hele virksomheten, bør virksomheten virkelig re-vurdere et IAM-program i det hele tatt. Jeg kaller det et program fordi det i realiteten er flere prosjekter som må foregå samtidig.

Bare så det er sagt så er teknologi og komplekse integrasjoner nødvendig og en viktig del av et IAM program, men det kommer seinere på den lange reisen. Dessverre er det slik at mange virksomheter først velger å starte med integrasjon eller anskaffelse av skinnende ny teknologi, og ignorere det som virkelig er avgjørende for IAM-programmets suksess, nemlig mennesker, krav og prosesser. Holdningen til disse virksomhetene er at på grunn av politikk- og budsjettutfordringer i et IAM-program, er det mindre risiko å fokusere på et verktøy som, dersom det mot alle odds går bra, avleder organisasjonens og ledelsens oppmerksomhet bort fra de interne problemene som virkelig er årsaken til at IAM feiler eller ikke tar av.

Forberedelser, forståelse,  god planlegging, og en klar forankret strategi er veien å gå for å komme godt igang med et IAM program.