Hvordan havner man i slike situasjoner? Kan de unngås?

Er det arkitekten sin skyld?

Det er lett å skylde på arkitekten og kalle ham (eller henne) for en idiot og et stabeist, men er dette rettferdig? Både ja og nei. Stabeist er kanskje korrekt, men idiot er vedkomne neppe. Intelligens er evnen til å finne gode generiske modeller som kan brukes til å finne løsninger i en kaotisk hverdag. Idioter pugger tallene i boka og ser ikke sammenhenger. Intelligente mennesker lærer seg reglene for å regne seg frem til alle mulige tall – ikke bare de i boka. En god og intelligent arkitekt er en som kan finne enkle overordnede strategier som gjør applikasjonen som helhet ryddig og pen. Fra et kaos av brukerhistorier og kundekrav skal han eller hun finne enkle og elegante strategier som kan brukes til å løse alt. Hvis alle programmerere kunne gjøre akkurat som de ville for hver brukerhistorie, hadde koden endt opp i kaos. Alle hadde funnet opp sine egne hjul, og noen av dem hadde nok vært ganske kantete og skjeve. I vedlikeholdbarhetens navn om ikke annet er det klart at arkitekten ønsker seg felles løsninger og forutsigbare implementasjoner. Men finnes det alltid én løsning som passer overalt? «Gjør alt så enkelt som mulig, men ikke enklere» sa Einstein. IQ-tester måler evnen til å finne enklere løsninger, men de måler ikke nødvendigvis evnen til å se når nok er nok.

Maks antall personer = 150

Når utviklernes hoved-utfordring er å få løsningen til å passe inn i arkitekturen er det klart at noe har gått galt. Min teori er at disse situasjonene er et tegn på at prosjektet har blitt for stort. Akkurat som at store firmaer gjerne er mye tregere enn mindre firmaer, blir store prosjekter tregere enn små. Tregere både når det gjelder utførelse av eksisterende oppgaver, og enda mer når det gjelder innføring av nye prosesser. Antropologen Robin Dunbar har oppdaget at 150 mennesker det meste folk klarer å holde styr på. Det militære og flere firmaer har tatt dette med i betraktning og passer på at organisasjons-enheter aldri inneholder mer enn 150 mennesker. Selv om man ikke kjenner alle, så vet man hvem de er og hvor de jobber. Hvis man trenger noe gjort, kan man bare gå bort til den man vet man bør snakke med, og få det gjort der og da. Når organisasjonen vokser over 150 mennesker vet man ikke lenger hvem det er man må kontakte for å løse problemene sine. Man må da henvende seg til sjefen sin, eller en helpdesk på andre siden av kloden eller noe slikt, og håpe på at de igjen klarer å finne frem til den som kan hjelpe. Jo større og bedre organisert bedriften er, jo mindre effektiv blir kommunikasjonen. Når IT-support sitter i Jakarta, lønningskontoret er i Stavanger og markedsføringen foregår i Dubai, så blir det dårligere kommunikasjon enn om alle var i samme bygg. Mange mener at slik må det bare være når firmaet vokser, for man kan da ikke ha lønnskontor, IT-support og markedsføring i hvert eneste kontor når man har hundrevis av kontorer verden over. Jeg er ikke enig. I smidige prosjekter utvikler man ikke database-koden, business-logikken og GUI-koden hver for seg. Man utvikler brukerhistorier hver for seg. GUI, business-logikk og database-greier samtidig. Jeg tror noen store firmaer kunne lære mye her. Istedenfor å samle alle IT-avdelinger under ett tak, tror jeg det lønner seg å heller samle alle som har med samme produkt under ett tak. Design, produksjon, markedsføring, IT-support og alt som hører med til et produkt. Hver business-enhet bør være istand til å tjene penger. Slik organisering koster kanskje mer, men den vil også produsere og tjene mer.

Maks antall klasser i et prosjekt = ?

Mye av det samme skjer i store software-prosjekter. Når prosjektet vokser og vokser ender man fort med å gruppere koden etter «software tier» og ikke etter bruksområde. Man lager regler som at «slik snakker vi med databasen» og «slik skriver vi rapporter». Og reglene gjelder for alle uansett. Jeg tror man med fordel heller burde dele prosjektet inn i separate produkter. Produktene vil bestå av en samling av brukerhistoriene som passer sammen på et vis. Disse produktene trenger ikke ha samme regler for bruk av database eller noe som helst. Arkitekten og utviklerne står fritt til å finne løsninger som passer best for akkurat dette produktet. Jeg tror ikke denne typen tankegang kommer naturlig for folk med høy IQ. IQ driver folk til å se mønster og finne fellestrekk og dermed gruppere alt som likner. Her var det oppkobling mot database, der var det oppkobling mot database – da slår vi dem sammen! Her var det et lønnskontor, der var det et lønnskontor – da slår vi dem sammen! Det føles godt og opp til et visst nivå er det selvsagt det rette å gjøre. Men et sted går grensen. Hvor da? Når bør man begynne å tenke på splitting? I business-verden er 150 et tall å huske på. Har vi tilsvarende tall for software-utvikling? Hvor mange klasser kan et prosjekt ha? Er det antall klasser vi burde telle? Siden det er så fristende å finne fellestrekk og lage felles løsninger, tror jeg det hadde vært greit å ha noen konkrete tall og grenser å forholde seg til. Når man disse grensene kan man begynne å tenke seg om: Har prosjektet blitt for stort? Kan jeg dele det inn i mindre enheter? Kanskje svarene er nei, men det er viktig å stille seg spørsmålene like vel.

“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