-

Har du hørt om nettskyen før? Kanskje i det minste du har hørt om Cloud Computing? Det er få innenfor IT-industrien som ikke har hørt om nettskyen til nå, det er liten tvil at nettskyen blir hypet, men det betyr selvsagt ikke slik at nettskyen i seg selv er en hype, selv om enkelte liker å lovprise litt for mye.

Petter Gottschalk er en av dem som varsler om å være litt nøktern til nettskyen, noe han har rett i. Vi er en bransje som er glad i alt nytt, ofte også med dramatiske konsekvenser, positive og negative. Tjenesteorientert-arkitektur (SOA) er en annen viktig utvikling som skjedde i vår bransje, en utvikling som har har brakt mye glede og motgang. Tjenesteorientert-arkitektur er komplisert, mye mer komplisert enn hva mange ble fortalt og overbevist om. Det er smart og strategisk å bygge løsninger basert på SOA, men det koster penger. Integrasjoner og interopabilitet med kunder og samarbeidspartnere er noe av det mest kompliserte vi gjør idag.

Fra et teknologisk ståpunkt er det veldig lett å komme igang med tjenesteorientert-arkitektur, vi har plattformer som gjør det mulig å lage tjenester fort og enkelt. Det vi undervurderte var kompleksiteten som oppstår når man begynner med integrasjoner og gjenbruk av tjenester. For mange undervurderte også behovet for planlegging av vedlikehold, versjonering, sanering og så mye annet som man må ha kontroll på når man bygger en infrastruktur på SOA. SOA har vist seg å være for komplisert og for dyrt for mange, gevinstene har ikke alltid vært der for å veie opp for investeringer som er gjort.

Hvorfor har man ikke klart å hente gevinstene fra SOA-satsninger?

Det er mye en organisasjon må gjøre for å omstille sine prosesser og systemer for å oppnå en velfungerende infrastruktur for SOA. Disse investeringer har hver enkelt vært nødt til å gjennomføre, hver for seg. Det sier seg selv at det fort blir kostbart, spesielt med tanke på at mange SOA-løsninger gjerne kun er for interne IT-systemer og integrasjoner med begrenset antall samarbeidspartnere. Desto større en organisasjon er, desto større verdi vil man kunne få ut av sine SOA-investeringer.

Nettskyen handler på flere måter om outsourcing av SOA…

Tjenesteorientering i nettskyen

Norge er et lite land tatt i betraktning hele verden, vi har et veldig begrenset marked av lokale kunder innenfor våre egne grenser. Dette er noe som alltid må være med i en vurdering om hvordan og når man skal ta i bruk både SOA og nettskyen. Dette er også noe av det som gjør nettskyen spesielt spennende for det norske markedet.

Fremfor at hver enkelt skal etablere sin egen tjenesteorienterte arkitektur, kan vi ved hjelp av nettskyen leie de delene av en infrastruktur og arkitektur vi har behov for. Det som er styrke i nettskyen er ikke bare muligheten til å skalere, men bredden av muligheter som finnes.

Konseptene i nettskyen

Begrepet nettskyen beskrives gjerne med tre underliggende konsepter: Software as-a Service, Platform as-a Service og Infrastructure as-a Service.

SaaS er programvare i nettskyen

- Det øverste nivået av nettskyen handler om å leie programvare, ferdige løsninger som ofte leveres rett i nettleseren. Kundebehandlingsløsninger (CRM), planleggingsverktøy, analyseverktøy og så utrolig mye annet finnes som man raskt og enkelt kan leie etter behov.

PaaS er kjøremiljø nettskyen

- Videre derfra har vi ulike plattformer hvor man kan bygge skreddersømsløsning og integrasjoner etter egne behov. Kan kjøre egne programmer og systemer i nettskyen, og samtidig utnytte godt av de infrastrukturtjenestene som eksisterer der ute for å dekke behov som autentifisering av brukere, sikker og kryptert kommunikasjon, tjenester-hubber (Internet Service Bus), globale caching løsninger, m.m..

IaaS er infrastruktur i nettskyen

- I nettskyen kan man leie de maskinressursene man har behov for, dette kan være database servere, brannmurer, webservere, m.m..

Dette er de mest etablerte prinsippene for nettskyen, men det er også flere andre prinsipper og beskrivelser og dette vil sannsynligvis utvikles i tiden fremover.

Spar på investeringer, kom fortere igang

Ett av de mest brukte budskapene om nettskyen er nemlig det jeg akkurat har forklart: Man slipper dyre investeringer i maskinvare, programvare og tjeneste for å komme igang. Man kan leie det man trenger, av maskinvare og programvare.

Styrken til nettskyen ligger nemlig i det at vi alle går sammen om å investere på infrastrukturen, for deretter å dele på ressursene. Har du noen gang hørt noen selge deg SOA og fortalt at dette er raskt og enkelt å komme igang med? Ble du fortalt at SOA var billig?

Teknologiene vi utviklet under SOA-hypen har vært instrumental for realisering a nettskyen slik den fremstilles idag. Nå har verden blitt moden og vi har fått en infrastruktur vi alle kan nyte godt av. På samme måte som vi alle i dag nyter godt av felles infrastruktur i den moderne samfunnet, som vann og strøm, kan vi nå nyte godt av datakraft og tjenester i nettskyen.

Fagruppe for Cloud Computing

I høst har Den Norske Dataforeningen startet en ny faggruppe for Cloud Computing, hvor Peter Flem fra Capgemini er leder og jeg er en av nestlederene. Ett av våre mål er å hjelpe norske bedrifter til å se mulighetene og verdiene av nettskyen, samt redusere noe av tåken som har oppstått med hypen. Vi arrangerer fagmøter gjevnlig og ønsker å invitere alle som ønsker å lære mer om nettskyen.

Neste møte er 20. oktober, hvor jeg skal fortelle om integrasjoner i nettskyen.

Steria og nettskyen

Hos Steria har vi gjennomført flere SOA-prosjekter med suksess og vi er allerede godt igang med satsning på nettskyen, både med infrastruktur og utvikling. SOA-investeringer hos våre kunder har gjort dem mer forberedt for nettskyen og forenkler fremtidige integrasjoner i nettskyen.

Det siste halve året eller så har jeg gått å gledet og gruet meg over dette tilbudet. Og det har slått meg: Å skrive et tilbud er som å forelske seg.

Først blir man litt kjent med kunden og kundens problem. Noen fanger interessen, og man får lyst til å vite alt om problemet. Man spør og graver. Om man ikke får snakke med kunden (og det får man ofte ikke i denne fasen), så snakker man med kolleger og venner som naturligvis ikke har noe svar: “Tror du at det er sånn? Tror du at dette er forklaringen på hvorfor det som de ba om var litt pussig? Tror du at de vil være interessert i dette forslaget?”

Til slutt bestemmer man seg for å satse alt. Søvnløse netter går mens man forsøker å fremstille seg attraktiv for den andre parten. Man forsøker å finne hva den andre parten har lyst til. Og noen ganger må man våge å si noe de ikke vil, men egentlig trenger å høre. Så leverer man et tilbud. Man må tørre å legge alle følelsene sine i tilbudet, fullt vitende om at man kan bli avvist. Den som intet våger, intet vinner.

Så kommer forhandlingene. Den andre parten føler seg attråverdig. De har mange beilere. Man snakker om en mulig fremtid sammen, men den andre parten vil ikke forplikte seg. Man tenker i sitt stille sinn “men jeg liker deg, liker ikke du meg, da?” Men man våger naturligvis ikke å si det.

Og til slutt sier de “ja”. Man er klar til å knytte knuten.

Og nå starter deg egentlig jobben. Jeg gleder meg.

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)

Dette er definitivt en navnestandard som mange synes å mene noe om. La oss derfor krympe dette inn til å omhandle navnestandard for servere.  Satt på spissen finnes det i hovedsak to strategier. Dette er den enkle og kompliserte strategien.

Den enkle strategien går ut på å navngi serverne sine med et løpenummer for eksempel server001, server002 osv. En annen variant i kategorien enkel, kan være å velge ut et tema fra noe man har kjært. Eksempelvis karakterer i Andeby, for deretter å kalle serverne sine for Donald, Pluto og lignende. Denne varianten bør velges med varsomhet i miljø som eksponerer tjenestenavn direkte mot forretning og kunder som ikke nødvendigvis er like begeistret for temaet.

Strategien som undertegnede definerer som komplisert, baserer seg på en modell som søker å gi tilleggsinformasjon ut i fra serverens navn. Dette kan fungere godt. Et eksempel kan være navnet oslapp001 som indikerer at dette er applikasjonsserver 001 plassert i Oslo.

Det kompliserte elementet i denne strategien er ikke å forklare lokasjon og funksjon, men snarere å finne en balanse i hva som skal forklares. Det er her mange går i fellen. Ofte som et resultat av at det finnes en eller flere ildsjeler som med de beste intensjoner ønsker å forklare mest mulig.

Det er også en risiko for at en komplisert navnestandard mister sin hensikt. Dette kan skje når det ikke tas høyde for miljøendringer. Et eksempel på dette kan være at to datasenter slås sammen og man har benyttet variabler for disse i servernavn.

Det finnes ingen fasit eller mal for en god eller dårlig standard. En ting som passer bra for i en organisasjon kan fort bli en fadese i en annen virksomhet. På generelt grunnlag holder undertegnede en knapp på den enkle varianten med server001. Dette fordi den virker i alle miljø og vil aldri bli utdatert. Øvrig informasjon om selve tjenesten kan lagres separat i en et dokument, katalogtjeneste eller lignende. Noen vil også argumentere for at denne strategien er best i forhold til sikkerhet. Dette fordi man eksponerer ingen opplysninger om serveren ut i fra navn.

Som en oppsummering på konferansen presenterer Kuppinger Cole de fem viktigste trendene innenfor IAm, GRC og Cloud computing. Nytt av året er at årets konferanse er slått sammen med Cloud Computing som virkelig er en het potet i Europa nå om dagen. Alle innlegg fram til nå har kommet inn på temaet, og det er stor spenning relatert til dette temaet som er upløyd mark. De viktigste trendene slik de blir formidlet er bl.a. en økende grad av justering mellom virksomhet og IT og evolusjonen mot et hybrid IT miljø bestående av et godt administrert miljø med en blanding av både interne og eksterne IT tjenester. Her er de heteste trendene , oversatt etter beste evne i tilfeller av manglende norske uttrykk, oppsummert fra konferansebrosjyren:

Identity and Access Management (IAM)

1. Mer fleksibilitet i arkitektur
   IAM-arkitektur er i endring. Den klassiske monolittiske tilnærmingen med provisioning som kjerne er kun en av flere arkitekturer som vurderes av integratører og kunder. Økende fleksibilitet i arkitekturer, samt integrasjon mot IT tjenester og virksomhetsportaler med sstøte for flere forsyningsverktøy blir mer og mer en realitet. Det hjelper også kunder med å implementere IAM raskere, biligere og mer spisset enn tidligere.
2. Tilgangsstyring og forsyning blir mer integrert
   Tilgangsstyring, også kalt IAM-GRC, er blitt en standard i flere arkitekturer og implementeringer, og er plassert på toppen av brukerforsyningen. Det er en økende grad av integrerte tilnærminger, samt en utvidelse av foryningsverktøy i form av tilgangsstyringsverktøy med mer støtte for integrasjon mot flere forsyningsverktøy i tillegg til adaptere for direkte tilkobling til mål- og fagsystemer. KuppingerCole forventer at denne trenden vil fortsette, og da med flere opsjoner for kundene og at tettere integrasjon mellom ulike teknologier vil bli mer standard.
3. Allsidige autentiseringsmekanismer blir mer modent
   Allsidige autentiseringsmekanismer, da i betydningen muligheter for å fleksibelt bruke ulike autentiseringsmekanismer basert på vanlig mellomvare blir mer modent og implementeres av flere leverandører. Dette muliggjør gjenbruk av sterk autentiseringsteknologi, samt mulighet for å velge den mest hensiktsemssige teknologien for ulike grupper av brukere (f.eks. interne og eksterne brukere) og brukstilfeller. Kostnaden med sterkere autentisering vil bli redusert.
4. Føderasjon finnes der ute
   Føderasjon, et tema som er gjenstand for mye diskusjon, er blitt en realitet. Tilsutningsraten er økende og vil fortsette å øke. I stedet for at man diskuterer potensialet blir nå føderasjon implementert i prosjekter med virkelige tilfeller.
5. Økende tilslutning av IAM i mellomstore bedrifter.
   IAM har fram til nå kun vært interessant for store selskaper og organisasjoner, og spesielt organisasjoner med compliance krav, men blir nå i økende grad relevant for mellomstore organisasjoner som middel mot å beskytte seg mot data- og informasjonslekkasjer og etterlevelse av krav angående personvern. Leverandører med standardimplementeringer og lettvekter produkter vil helt klart tjene på dette.

GRC – Governance, Risk Management, Compliance

1. Fra punktløsninger til GRC arkitektur
   Det er i dag for mange GRC initiativ i organisasjonene. Det spås at dette vil endre seg mot at flere virksomheter tenker mer på en helhetlig GRC arkitektur før man investerer i egne punktløsninger. Dette vil hjelpe virksomhetene til å optimalisere de investeringene som gjøres.
2. Tilgangsstyring som et startpunkt
   Tilgangsstyring er en av de mest økende områdene innenfor IT. Det betraktes som et logisk startpunkt for GRC initativ. Selv om det kun dekker en liten del av It-kontroller, er disse viktige, nemlig de som omhandler tilganger, informasjonslekkasjer, lovverkt angående personvern, og opphavsrett og/eller åndsverk. Det forventes at flere selskaper vil fokusere på tilgangsstyring når de skal investere i IT-GRC.
3. Lukke sløyfen for tilgangsstyring
   Et aspekt ved utviklingen er at det i økende grad blir mer integrasjon med automatiseringsteknologi for avstemming, som lukker sløyfen for endringer i målsystemer for attestering og sertifiseringer som har hatt fokus fram til nå. Disse tilnærmingene av lukking av sløyfene som støtter ikke bare reaktive men også prevantive kontroller blir mer og mer standard i markedet for tilgangsstyring (Access Governance).
4. Virksomhets-GRC åpner opp for IT-GRC
   I dag er mange av de såkalte virksomhets-GRC verktøy (bedre definert som virksomhetsorientert GRC ) hovedsaklig fokusert på forretningssidens syn på risiko, f.eks. drifts og noen ganger strategisk risiko. Men, forretning er basert på IT-systemer. Derfor er ITrisiko og driftsrisiko tett relatert, og de automatiserte kontrollene for driftsrisiko er basert på på informasjon i IT-systemene. Av den grunn må desse to verdenene konvergere, som helt klart er en stor trend i dag. Kuppinger Cole forventer at muligheten for å støtte integrasjon mellom virksomhetsstyring og IT-styring vil bli en nøkkedifferensiator mellom leverandører.
   
5. Risikokonsepter blir innført
   Risiko er i økende grad forstått som et nøkkelkonsept for IT-ledelse. Risikokonsepter blir i økende grad støttet av verktøy og implementert i organisasjonen. Men, det er typisk i dag et syn på organisatorisk og strategisk risiko som er splittet fra synet på IT-risiko. Analyseselskapet forventer at dette sakte men sikkert vil endres.

Cloud computing

1. Fra taktikk til strategi
   Cloud computing flytter seg nå fra taktikk til strategi – fra opportunistisk bruk av eksterne tjenester mot en strategisk tilnærming for anskaffelse av tjenester som dekker både interne og eksterne tjenester på en konsistent måte. Utviklingen er obligatorisk for muligheten til en fleksible anskaffelse av tjenester samt for å minimere risiko ved å ta i bruk standardiserte tilnærminger for valg av tjenestetilbyder(e).
2. Hybride IT-miljøer blir standard
   Virksomhetenes miljøer for cloud computing vil i økende grad være hhybride, med en blanding av eksterne og interne tjenestetilbydere. For de aller fleste organisasjoner vil dette bli en langsiktig realitet, og det er faktisk en realitet i dag når vi ser på eksterne tjenestetilbydere som blir benyttet på mange områder som bl.a. webkonferanse, webhotell, samt SaaS applikasjoner.
3. Fokus på tjenester og ikke på at de er eksterne
   Med utviklingen fra en taktisk tilnærmingen mot standardisering vil tjenester bli kjernen i cloud computing – alle typer av tjenester og ikke bare eksterne tjenester. Evnen til å vellykket administrere IT er veldig avhengig av en konsistent tilnærming for anskaffelse og administrasjon av tjenester, uavhengig av hvor de kjøres. Dette vil i større grad bli forstått med resulterende endring av fokus fra få store og populære tilbydere av cloud computing mot endring av IT-strategi og ledelse.
4. Det blir mer fokus på sikkerhet enn tidligere
   På nåværende tidspunkt blir sikkerhet sett på som et tema innenfor og for skyen, i hvert fall delvis. Kuppinger Cole forventer en økende grad av kunnskap om virkelige sikkerhets- og styringsspørsmål, som helt klart er forskjellig fra dagens tåkete sikkerhetsbekymringer. Utviklingen vil gi organisasjoner bedre muligheter til å håndtere cloud risiko og bygge gyldige sikkerhetsstrategier for bruk av eksterne tjenester i skyen.
5. Mange nyetableringer, sammenslåinger og oppkjøp av selskaper
   På lik linje som i andre nye markeder innenfor IT er det mange nyetableringer i markedet for cloud computing, og flere vil komme. Gitt at det er mange nye trusler er det nok av plass for oppstarter. På den andre siden vil det bli flere oppkjøp av større leverandører som vil utvide og styrke sitt eget cloud computing tilbud.

Verden ser altså ut til å ble mer hybrid enn hva vi ser er vanlig i dag. Interne og eksterne brukere, interne og eksterne applikasjoner og tjenester må administreres og styres. GRC skal dekke dette. IAM må virke med alt sammen. Bevegelse mot en tilnærminger som må støtte denne hybride IT-verden, samtidig med sterk justering mot forretningsnærhet, blir kjernepunkter ITsjefen må forholde seg til. Dette er også i samsvar med hva spesialistene og leverandørene mener og tror også. Min egen vurdering og oppfatning av denne overfloden av informasjon og inntrykk er at Norge på mange områder ligger langt bak mange av landene her i Europa. Men jeg tror også at på mange av disse områdene kommer vi etter etterhvert som kundemarkedet modnes. We are all individuals… really? Det viser seg at vi ikke er så veldig spesielle med spesielle behov likevel hjemme på berget. Vi er derimot på mange områder hengende etter og har mer taktisk enn strategisk fokus.

Min erfaring er at det er ved produksjonssetting de virkelige utfordringene begynner, og da din prosjektgruppe trenger fokus. Nettopp da må styringsgruppen og involverte beslutnignstagere forstå at prosjektet trenger arbeidsro og gode rutiner, ikke nedleggelse, nye rapporteringsforpliktelser, bli gjenstand for budsjettkutt eller lignende. Utsagnet et system som ikke endres er et dødt system er virkelig sant i denne perioden. Husk det når du budsjetterer prosjektet og når du setter dine forventninger.

Det er alltid forbundet med risiko å ta en beslutning om konvertering og produksjonssetting, ofte resulterer det, i at man ikke klarer å skru av det gamle systemet likevel, eller at svært mange interessenter blir misfornøyde og skaper mye støy for prosjektet – den gamle løsningen fungerte jo bedre. Man kan teste så mye man orker før produksjonssetting, men Murphy’s lov slår til og ting går galt. Brukeren kan det ikke – da fungerer det ikke. Noe av det testteamet trodde var i orden viser seg kanskje også å skape en nedtur i begynnelsen. Opplevelsen trenger altså ikke bare være basert på reell mangel på funksjonalitet, men opplevd funksjonalitet. Fenomenet kan illustreres med en blodbadkurve, der man opplever at det nye systemet fungerer vesentlig dårligere enn det gamle systemet i en periode etter produksjonssetting.

Ved å gjøre de rette grepene kan imidlertid blodbad-perioden reduseres og gjøres minst mulig smertefull. Her er fire tips.

1. Styr forventningene i forkant – Blodbad-perioden er ofte den samme tidsperioden der styringsgruppen forventer at gevinstene skal realiseres, gjerne nokså umiddelbart. Dette er en umulighet hvis man ser på kurven over. Prosjektet er travelt opptatt med å prioritere feil, lære seg å drifte det nye systemet, lære brukerne å bruke det nye systemet og løse de mest kritiske tingene som mangler i systemet, ofte ved hjelp av tidkrevende workarounds inntil gode nok løsninger er på plass.

2. Gi prosjektet økonomisk handlingsrom – Det sikreste man kan gjøre for å sikre absolutt fiakso er å legge ned prosjektet i denne fasen. Likevel er ofte “pengene brukt opp”, man hadde jo ikke regnet med at man måtte jobbe når man hadde levert til produksjon og nedleggelse blir realiteten. Det å ikke ha penger til endringer og videreutvikling i denne perioden er den sikreste måten å redusere levetiden på det nye systemet dramatisk. Det kan også tenkes at de som har fått det nye systemet trenger litt tid på å lære det, så regn med noen vikarer.

3. Vær flink til å prioritere og operer med åpne prioriteringslister – Styringsgruppen ønsker rask realisering av visjonen og at prosjektet skal makte å følge den stiplede grønne utviklingsbanen. Svaret er ja, det skal dere få, men først må prosjektet få hodet over vannet i form av å løse de mest kritiske feilene. Deretter kan man prioritere forbedringer og nyutvikling. Et sikkert tegn på at man har med en umoden styringsgruppe å gjøre er dersom de i denne perioden forventer at prosjektet skal prioritere nye forretningskrav som plutselig har kommet opp når de ser det nye systemet. Prosjektgruppen bør prioritere utestående områder slik at det som er mest kritisk (eller lønnsomt) kommer først.

4. Avklar ansvar og organisasjonsmodell for vedlikehold tidlig – Etter produksjonssetting kan det være uklare ansvarsforhold knyttet til vedlikehold. Innse det med en gang – et system uten endring er et dødt system. Da må man vite hvordan endringene skal gjennomføres, testes og produksjonssettes også etter oppstart. Ofte “fryses” kanskje systemet for å unngå store endringer rett før oppstart, med den konsekvens at utviklerne som kunne løst feil raskt forsvinner over til andre oppgaver eller mister fokus. Realiteten er at det er i produksjonssettingsfasen at endringstakten, eller i hvert fall feilrettingstakten, bør være desidert størst. I hvert fall dersom man mener alvor med å snu blodbadet og realisere visjonen for prosjektet.

Legg merke til at jeg ikke foreslår å utsette produksjonssettingen. Dette er åpenbart eneste alternativ dersom man ser at selv de mest basale behov systemet er tenkt å løse ikke fungerer, men i så tilfelle har prosjektet et større problem og burde ha lært seg metoder som Scrum og EVO for lenge siden.

Legg også merke til at prosjektet endrer karakter den dagen man produksjonssetter. Det er ikke lenger et erstatningsprosjekt. Det er et smidig forbedringsprosjekt og må behandles som det!

Les mer på sterkbladning.no:

• Johannes om erstatningsprosjekter
• Ole-Vidar om driftsrammeverk (ITIL) vs utviklingsrammeverk (Scrum)

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.

“If A System Is Working, Leave It Alone. Don’t Change Anything!”
- John Gall, Systemantics (1975)

Planen

Det gamle systemet hadde blitt uholdbart. Leverandøren ga ikke lenger support på maskinvare eller programvare, det var umulig å oppdrive kompetanse for å videreutvikle og det var ikke lenger vedlikeholdbart siden det var så kompleks.

Vi skulle derfor erstatte systemet med et nytt et. Bygget fra bunnen med moderne teknologi. Det burde bli enkelt, siden dagens system kan fungere som kravspesifikasjon. Vi hadde estimert arbeidet til 83 511 timeverk.

Vi ville naturligvis ikke investere store mengder arbeid i det gamle, døende systemet. Og dessuten var det umulig å integrere med. Så vi måtte bygge det nye systemet med all funksjonalitet, og så, en spennende helg om noen år, sette det i produksjon.

Slik høres introduksjonen til mange erstatningsprosjekter ut. I disse prosjektene har man et eksisterende system som typisk er kritisk for virksomheten. Av gode eller dårlige grunner har man valgt å gjennomføre et prosjekt som skal erstatte hele den gamle systemet med et nytt system som oppfyller samme målsetning.

Denne planen burde med en gang ringe noen varselbjeller. Hva er egentlig poenget med dette prosjektet? Prosjektet ønsker å videreføre dagens tjeneste med et nytt og moderne system. Og det er billigere måter å gjøre det på.

Uortodoks observasjon #1:

Et erstatningsprosjekt er en dyr måte å forlenge livet til vår nåværende forretningsmodell.

Det virker umulig å komme seg forbi hindrene i form av support, kompetanse og vedlikeholdbarhet. Men dersom vi doblet lønna til alle som ville programmere COBOL, så ville vi nok få nok kompetanse. Det er mulig å videreføre systemet. Det er bare veldig dyrt. Men det er også fantastisk dyrt å erstatte et system fra bunnen. Man kan bruke mange dyre teknikker for å holde systemet i gang før der lønner seg å erstatte.

På de fleste systemer er imidlertid support, kompetanse og vedlikeholdbarhet ikke de eneste, og kanskje ikke de egentlige motivene. Det finnes andre motiver, både dårlige (noen vil ha et stort prosjekt på CV eller jobbe med ny teknologi) og gode (vi ser muligheten til å levere verdi).

Først når erstatningsprosjektet tilfører forretningsverdi er det verdt å gjennomføre. Erstatningsprosjekter for å redusere kostnader eller forlenge levetiden på en utdatert forretningsmodell er en dårlig ide.

Virkeligheten

“A Complex System Designed From Scratch Never Works And Cannot Be Made To Work. You Have To Start Over, Beginning With A Working Simple System”
- John Gall, Systemantics

Den forrige arkitekten hadde holdt på med systemet i tre år. Og organisasjonen hadde ingenting å vise til. Det var ikke blitt ferdig, og han hadde insistert på at det var umulig å levere deler av systemet.

Styret er lei av denne unnskyldningen, og om administrerende direktør ikke finner en arkitekt som kan bevise at investeringene har verdi, er det han som må gå.

Et forsinket prosjekt mister politisk goodwill. Det er bare en måte for et prosjekt som har mistet troverdighet å redde seg på: Man må levere noe. Og da må man spise noen kameler.

Uortodoks observasjon #2:

Det nye og det gamle systemet kommer til å leve sammen.

Heldigvis er dette gode nyheter. Med en gang vi vet at det nye og det gamle systemet må leve sammen, åpner det døren for en rekke muligheter til å tenke bedre.

Gradvis erstatning

Først, her er fire patterns for å gradvis erstatte et system:

• Delt database: Dersom det gamle systemer benytter en relasjonsdatabase kan det nye systemet bruke denne direkte. Det gjør det mulig å levere deler av det nye systemet nesten umiddelbart, men det legger føringer for designer av det nye systemet som man kanskje kunne unngått.
• Import/eksport: Før eller siden må vi forholde oss til de dataene som finnes i det gamle systemet. Ta kostnaden tidlig og eksporter data til det nye systemet. Men vær forsiktig: Det er vanskelig å ha to mastere for data. Start med å la det gamle systemet være master.
• Datatjenestelag: Dersom du ønsker å erstatte det gamle systemets datalager, kan du innkapsle dette i en tjeneste. Legg imidlertid merke til at datatjenester har høyt endringsbehov og tjenester som deles i et stort prosjekt er kostbare å endre.
• Parallell produksjon: Dersom det nye systemet utvikler funksjonalitet som finnes i det gamle, se om det er mulig at begge versjonene kan være i produksjon samtidig. Da reduseres konsekvensen dersom den nye versjonen inneholder feil, siden å rulle tilbake en produksjonsetting er enklere. Dette gjør at det kan være mulig å produksjonsette med mindre testing. Det nye systemet kan også starte med et subset av brukerne. Dermed kan man utsette noe av ytelsesoptimaliseringen til man har bedre erfaring fra faktisk bruk.

Men det krever mer enn teknikker for å sette sammen systemene for å lykkes. Man må makte å finne oppgaver som man kan jobbe på og realisere verdi for organisasjonen i løpet av erstatningsprosjektet. Her er fire patterns for å finne områder å erstatte:

• Risiko: Enkelte endringer er så viktige at uten dem, vil prosjektet regnes som mislykkes. For prosjekter relatert til pensjonsreformen vil det være katastrofalt om man ikke kan implementere det nye regelverket. Andre systemer har lenge hatt kjente svakheter som man har forpliktet seg til å utbedre. Fiks dette først!
• Kostnad: Organisasjoner som benytter systemer har ofte noe arbeidsoppgaver som er ekstra arbeidskrevende. Kanskje det er å punsje data, eller å overføre data fra et system til et annet. Eller kanskje det er kundene som ringer og spør om hvordan saken deres ligger an. Ved å velge et slikt område kan prosjektet levere gevinst tidlig.
• Isolerte brukere: Mange systemer har brukergrupper som bare benytter en liten del av systemet. Det kan være lurt å starte med en slik brukergruppe, ettersom man kan erstatte hele den delen av systemet de benytter på noen få leveranser.
• Nye brukere: Mange organisasjoner ønsker å lage selvbetjeningsløsninger for publikum. Disse er også gode og vanlige steder å starte et fornyingsprogram.

Arkitektur

“…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”- Conway’s Law

En arkitekt på et stort prosjekt som lar prosjektlederen bestemme hvilke arbeidspakker hvert team skal jobbe med har begrenset mulighet til å påvirke prosjektets suksess.

Som arkitekt er det ofte fristende å jobbe med en målarkitektur. Men for et stort prosjekt blir målarkitekturens største føringer organisasjonen som skal utvikle systemet. Å oppfylle prosjektets behov for at folk kan jobbe uten å konstant ramle i beina på hverandre må prioriteres over andre arkitekturmål.

Jo flere kokker, desto mer søl. Det er din jobb å sørge for at ikke alle må være på samme kjøkken. Eller enda verre: Løpe mellom alle kjøkkenene.

Uortodoks observasjon #3:

I store prosjekter er organiseringen den viktigste faktoren i arkitekturvalg.

Min erfaring er at det finnes noe fundamentale grenser for hvor mange personer som kan samarbeide:

• 4-6 personer kan jobbe med en person som dekker arkitektur, analytiker og teamleder-rollene. Dersom gruppen blir større enn dette, må man typisk ha tre personer for å dekke disse rollene.
• 10-12 personer kan jobbe på den samme koden og med den samme produktkøen uten å komme i beina på hverandre. I alle fall så lenge de kommuniserer daglig
• 30-35 personer kan jobbe med en kodebase som er kontinuerlig integrert. Dersom det er flere, vil tiden man bruker på å rette integrasjonsfeil bli en betydelig kostnad.

Og når prosjektet blir for stort for kontinuerlig integrasjon, må gjenbrukt kode versjonshåndteres. Dette betyr at det vil være dyrt å gjøre endringer. Kode som ikke kan endres blir ofte dårlig kode. Så gjenbruk ut over 30-35 personer er overraskende dyrt.

Til slutt bør team ha som målsetning å produksjonsette hver tredje måned. Dette er veldig vanskelig å gjøre dersom en leveranse inneholder mange deler som ikke er kontinuerlig integrert. Deler som ikke er kontinuerlig integrert bør fortrinnsvis produksjonssettes helt separat fra hverandre.

Konklusjon

Et prosjekt som skal erstatte dagens system uten å endre forretningsprosessene har feil fokus. Modernisering er bra, men ha fokus på verdien til andre enn de som vedlikeholder systemet.

Vi har en rekke antagelser om hvordan erstatningsprosjekter vil fungere. Etter min erfaring er mange av disse antagelsene feil. Du kan godt ha annen erfaring, men her er min:

• Et erstatningsprosjekt er en dyr måte å forlenge livet til en eksisterende forretningsmodell
• Det nye og det gamle systemet vil leve sammen
• I store prosjekter er organiseringen den viktigste faktoren i arkitekturvalg

Vi får til erstatningsprosjekter ved å levere gradvis.

“Galls Law: A Complex System That Works Is Invariably Found To Have Evolved From A Simple System That Worked.”
- John Gall, Systemantics, 1975