To sider av samme sak

To sider av samme sak

I mange organisasjoner har man organisert seg slik at applikasjonsutvikling gjøres av en gruppe, mens applikasjonsdrift gjøres av en annen. Dette er en gal måte å fordele arbeidet på.
Jeg ønsker å bruke denne artikkelen til å påpeke både uheldige konsekvenser og en mer fremtidsrettet arbeidsmåte.

Noen begreper først: En applikasjon i denne sammenheng er et system som ikke er hyllevare. Applikasjonsdrift er den driften som ikke har med drift av hyllevare å gjøre, men er knyttet til applikasjonen som sådan. Altså vil det å drifte en server med hensyn på nettverk, diskplass, minne, operativsystem osv. kunne være drift som ikke nødvendigvis er direkte knyttet til applikasjonen, mens derimot det å tolke (og eventuelt korrigere) en applikasjons oppførsel gjennom logger, skjermbilder, responstider og lignende, er det.

For å ikke gjøre artikkelen unødvendig lang, postulerer jeg uten videre at de best egnede til å drifte applikasjonen er de samme som har utviklet applikasjonen. Dersom dette ikke er tilfellet, kan kvaliteten kun bli like god dersom all den kunnskap som utvikleren sitter med, overføres til den som drifter. Jeg tror vi alle kan være enige om at dette er en helt urealistisk tanke. Dersom denne drift og utvikling likevel deles i to separate grupper, så vil følgende uheldige konsekvenser oppstå:

Applikasjonen får et dårligere tilsyn, fungere mindre stabilt og med dårligere ytelse. Og utvikleren lærer ikke av sine feil, og fortsetter å programmere systemer som gjør det mer komplisert å utføre drift.

I tillegg vet vi at etter at en applikasjon først er produksjonssatt, skal den fortsatt utvikles videre. Denne videreutviklingen kan enten skje ved hjelp av de som lagde v.1.0 (bra), men kan også skje ved hjelp av nye utviklere uten noe knytning til den gamle gruppen (dårlig). I det siste tilfellet så vil applikasjon høyst sannsynlig forringes ytterligere.

Dette scenarioet er ikke et tenkt tilfelle, men snarere den mest utbredte situasjonen i dag, og den blir sannsynligvis enda mer utbredt i fremtiden. Hvorfor?

Jeg tror noe av grunnen er at de som tar beslutningene om outsourcing og konsulentbruk ikke har disse sammenhengene klart for seg. Her har vi som jobber med it et klart ansvar for å kommunisere på en bedre måte, og vi må nok påta oss et stort ansvar fordi vi så ukritisk har lagd to båser, nemlig drift og utvikling.

Hvor mange har ikke hørt frasen om at "vi skal drive med den spennende delen, nemlig utvikling, så kan vi sette bort driften til noen andre"? En rekke utviklere vil applaudere dette, men ser ikke selv at de mister en unik mulighet til å utvikle seg selv og applikasjonen videre.

Det er i dag mye snakk om refaktorering som en teknikk for å forbedre applikasjonen. Men hvor skal drivkraften til refaktoreringen komme fra? Jeg vil påstå at nettopp drift og den daglige interaksjonen med applikasjonen vil være en nyttig drivkraft til å påpeke hvor skoen trykker mest. Dersom man fikk gjennomført en mentalitetsendring blant it-folk, slik at det ble mer naturlig at utviklere også driftet sine applikasjoner, tror jeg det ville medføre en heving i kvalitetsnivået som ikke minst ville komme brukerne til gode.

Jeg kan ikke her møte alle motforestillinger som måtte komme, men jeg kan tenke meg et par: 1) Hvordan skal man få tid til å både drifte og utvikle samtidig? Her kommer vi straks innpå dette med de "gode" drivkrefter. Din applikasjon/system bør nemlig koste lite å drifte, og jo bedre applikasjonen lages, jo mindre vil driften koste. Dette vil lede utviklingen inn i en oppadgående spiral. 2) Skal alle som driver med utviklingen av en applikasjon også utføre drift? Nei, det er ingen grunn til å ta dette "helt ut". Prinsippet om å overføre kunnskap til drift som i sin tur flyter tilbake til utviklingsprosessen står imidlertid fast.

Jeg håper jeg med dette innlegget kan anspore til en fruktbar debatt om hvordan vi kan forbedre oss selv som utviklere og arkitekter, og gi våre kunder mer igjen, spesielt nå når situasjonen ser ut til å gå i en retning av enda mer konsulentbruk, utskillelse av it-enheter og oursourcing av alle former for drift. En utvikling som i endel sammenhenger er uheldig

Innlegget står for min egen regning.

Morten Simonsen
arkitekt, utvikler og drifter i Storebrand