“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