Smidig-bibel med farlig forenkling

Smidig-bevegelsens bibel, the Agile Manifesto slår fast som sitt første prinsipp: "Vår høyeste prioritet er å tilfredsstille kunden gjennom tidlige og kontinuerlige leveranser av verdifull programvare." Greit nok, men hvem er kunden?

Kunden er en annen enn kundene. I smidige prosjekter er kunden alltid den forretningsenheten som har bestilt utviklingsprosjektet. Denne kunden skal målbære behovene til kundene. Folk fra forretningsenheten skal samarbeide tett, helst daglig, med utviklerne. Ansikt-til-ansikt er det aller beste. De skal sitte sammen, i samme rom. Det går an å bruke smidige metoder på avstand, til dømes mellom Norge og India, men det svekker effekten.

Prosjektet oppfatter lederen for enheten, eller en annen utpekt person fra enheten, som produkteieren, det vil si den som skal ha ansvar for resultatet av prosjektet. Det hviler et stort ansvar på produkteierens skuldre. Hun bør vernes.

Er det noe galt i dette? Det er i hvert fall en farlig forenkling. Produkteieren er opptatt av å dekke de behov hun oppfatter som viktige på best mulig måte. Det er dét som er hennes rolle. At prosjektets resultat skal ha et langt liv og være en integrert del av bedriftens applikasjonsportefølje er ikke hennes sak. Derfor oppstår det ofte applikasjoner vi kaller "silo", som ikke er konsistente med resten av porteføljen og inneholder "redundante" (dupliserte) datamengder.

Tilføyelse

Vi kan ikke gå ut fra at produkteieren, i hele applikasjonens levetid, er bevisst på endringer i forretningsstrategien og it-arkitekturen. Et oppdatert prinsipp må derfor lyde slik: "Vår høyeste prioritet er å tilfredsstille kunden gjennom tidlige og kontinuerlige leveranser av verdifull programvare i henhold til gjeldende virksomhetsstrategi". Er dette opplagt? Jeg tviler.

Hva betyr denne tilføyelsen? At gruppene som har ansvaret for virksomhetsarkitekturen (EA), prosjektporteføljen (PMO) og driften blir aktivt involvert. De skal støtte produkteieren. Noen smidige apostler vil oppfatte dette som byråkratisering, men det er ikke til å unngå. Den typiske applikasjon lever lenge, ti år eller mer, og må holdes i ship shape.

Gartners undersøkelser har vist at bare åtte prosent av livstidskostnadene for en applikasjon blir investert i utviklingsfasen, resten kommer etterpå som kostnader til vedlikehold, videreutvikling og drift. Det er ikke nok å være rask og supereffektiv med de første åtte prosentene, det er de resterende 92 prosentene som virkelig teller. Programvare som endres til stadighet blir "sprøere" med tiden, går lettere i stykker. Hver gang en feil blir rettet, blir det skapt to nye, pleier vi å si. Til slutt tør ingen å røre applikasjonen, og da blir den ikke et aktivum, men en belastning. Smidig praksis som periodisk refaktoring (et annet ord for restrukturering) kan forsinke denne foreldelsesprosessen.

Arkitektur bør gjøre prosjektene bedre, ikke være til hinder. For eksempel å gjenbruke mønstre, komponenter, skjemaer, tjenester og ikke minst data bør skape muligheter og redusere risiki.

No big betyr ikke null

Det er vanlig å snakke om at utviklingsprosjekter enten er smidige eller fossefall. Gartner foreslår at vi tenker tredelt. For frittstående applikasjoner virker smidige og raske metoder som Scrum utmerket. Produktutvikling er et godt eksempel. For komplekse applikasjoner som skal henge sammen med mye som finnes fra før (eller vil komme senere) kan det forhåndsplanlagte fossefallet fortsatt være det rette. Midt imellom må det finnes plass for en ny modell som Gartner har døpt EAD, Enterprise-class Agile Development. Den tar utgangspunkt i velprøvd smidig metodikk, men utvider den i både bredde og lengde.

Jeg må ikke legge igjen inntrykket av at smidige prosjektgrupper ikke tenker arkitektur. Det gjør de – men det de tenker på er applikasjonens arkitektur, ikke virksomhetens, som er vesentlig mer mangslungent. Virksomhetsarkitektur skal legge stor vekt på helhetstenkning og de langsiktige sammenhenger. Jeg har stor sympati for prinsippet No Big Design Upfront, men det betyr ikke null design upfront.