Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
"Vi har for mange systemer" sier du. Er du sikker?
- 1. “Vi har altfor mange systemer” Er du sikker? @ChristinGorman
- 4. “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations" — M. Conway[3]
- 7. • Akvakulturregisteret • Ektepaktregisteret • Eco-Management and Audit Scheme (EMAS) • Enhetsregisteret • Foretaksregisteret • Frivillighetsregisteret • Gebyrsentralen • Gjeldsordningsregisteret • Jegerregisteret • Konkursregisteret • Lotteriregisteret • Løsøreregisteret • Oppgaveregisteret • Partiregisteret • Registeret for utøvere av alternativ behandling • Regnskapsregisteret • Reservasjonsregisteret
- 9. “Nå skal landbruksdepartementet overta ansvar for jegerregisteret”
- 11. public void mottaNySøknad(Søknadsskjema søknad) { if (søknadFinnesAllerede(søknad.getHovedperson())) { throw new SøknadFinnesAlleredeException(); } if (!folkeregistrertSammen(søknad.getAllePersoner())) { throw new IkkeBosattSammenException(); } arkiver(søknad); sendBekreftelsesEpost(søknad.getHovedperson()); }
- 12. public void mottaDokument(Dokument dokument) { regelmotor.valider(dokument); arkiver(dokument); sendBekreftelse(dokument); }
- 13. Bruker Teknologi Gjenbruk “entitet” “dokument” “vedlegg” “søker” “søknadsskjema” “legeerklæringer”
- 14. Å skrive en fortelling
- 17. The Ripped Banana A Short Story by qristin Helen Platt looked at the ripped banana in her hands and felt happy. She walked over to the window and reflected on her cold surroundings. She had always loved magical Philadelphia with its mammoth, mighty mountains. It was a place that encouraged her tendency to feel happy. Then she saw something in the distance, or rather someone. It was the figure of Doris Wishmonger. Doris was a stupid lover with ample eyes and greasy feet. Helen gulped. She glanced at her own reflection. She was an intelligent, stupid, cocoa drinker with pretty eyes and skinny feet. Her friends saw her as a giant, gorgeous god. Once, she had even saved a steep deaf person that was stuck in a drain. But not even an intelligent person who had once saved a steep deaf person that was stuck in a drain, was prepared for what Doris had in store today. The hail pounded like talking ostriches, making Helen fuzzy. As Helen stepped outside and Doris came closer, she could see the united glint in her eye. Doris glared with all the wrath of 9354 hopeful hurt humming birds. She said, in hushed tones, "I hate you and I want justice." Helen looked back, even more fuzzy and still fingering the ripped banana. "Doris, I am your father," she replied. They looked at each other with concerned feelings, like two dirty, decomposing donkeys cooking at a very optimistic holiday, which had flute music playing in the background and two admirable uncles thinking to the beat. Suddenly, Doris lunged forward and tried to punch Helen in the face. Quickly, Helen grabbed the ripped banana and brought it down on Doris's skull. Doris's ample eyes trembled and her greasy feet wobbled. She looked ambivalent, her emotions raw like a knowing, kindhearted knife. Then she let out an agonising groan and collapsed onto the ground. Moments later Doris Wishmonger was dead. Helen Platt went back inside and made herself a nice mug of cocoa. THE END
- 18. Samme hovedpersoner (gjenbruk av data) ✓
- 19. Samme bokhandel (felles innlogging til en “appstore”) ✓
Editor's Notes
- Dette er noe jeg hører stadig vekk. Fra politiet, til Nav, Statens Vegvesen og nå sist fra Brønnøysundregisteret. Alle klager over et mylder av forskjellige systemer som er vanskelig å forvalte effektivt. Jeg tenker å bruke Brønnøysund som eksempel ikke fordi de er verst i klassen på noensomhelst måte, men fordi de funger som et veldig godt eksempel, samt at ettersom de ikke har fått midler for å gjennomføre planen sin ennå, så er det kanskje håp om å komme med konstruktive innspill.
- Her er tegnigen de presenterte i Digi i sommer. Litt karikert, men er et godt bilde på hvordan man opplever en stor IT-portefølje som har vokst ukontrollert over tid. Brønnøysund forvalter 18 forskjellige registre, og systemene de bruker er koblet sammen litt hist og her og oversiktsbildet er forvirrende og vanskelig.
- De ønsker å komme seg hit og man kan godt forstå hvorfor. Her har de fortsatt alle 18 registre, men de er organisert på samme måte, og bruker alle samme platform. Denne arkitekturen er det lett å forstå og resonnere rundt for ledelsen.
- Designet til Brønnøysund, som så mange andre i deres situasjon plasserer organisasjonen i sentrum. Det blir veldig tydelig fra deres ønskede målbilde. EN sentral saksbehandlingsplatform som implementerer logikk for alle 18 registrene. Men det er jo ikke “Organisasjonen i sentrum” som er slagordet når vi snakker om digitalisering i offentlig sektor. Det er “Brukeren i sentrum”. Det er det lett å glemme. Det er jo ikke brukeren som designer systemene. Brukeren har ikke budsjettansvar. Det er ledelsen i f.eks. Brønnøysund som lager designene, og da er det lett å designe et system som er tilrettelagt dem selv. Man må jobbe aktivt for å unngå denne veldig naturlige tendensen.
- La oss se på nåsituasjonen med nye øyne. Fra brukerens perspektiv. Hvem er egentlig brukeren? Når vi ser på alle de forskjellige registrene det er snakk om blir det raskt klart at det er fryktelig lite overlapp mellom de forskjellige brukerene. De som bruker akvakulturregisteret har sjelden bruk for partiregisteret. Det er ganske vanskelig å finne overlappende brukscase her.
- Når vi ser på situasjonen fra brukerens perspektiv, så er plutselig ikke dagens løsning så ille like vel? For alt jeg vet kan det være den er det, men poenget mitt er at det er dette perspektivet vi må ha for å lage en god løsning. Ikke bare for brukeren.
- Hvis arkitekturen er basert på organisasjonen blir software til hindring for organisasjonsendringer. Vi kan ikke lenger flytte ansvar for et av registrene. Alt er koblet tett sammen. En ganske tilfeldig sammensetning av registre blir plutselig nå låst fast i Brønnøysund. Dette er uheldig.
- Men viktigere er hva denne typen arkitektur gjør med selve brukeropplevelsene. Dette er tatt fra en av Brønnøysund sine kravspesifiseringsdokumenter og viser hva de ser for seg å lage. Typisk 3-lags-arkitektur. Gui på topp, som har skjermbilder for alt. Så har vi business-logikk i midten. En regelmotor som har regler for alle registrene, saksbehandlingskode som tar for seg saksbehandling av alle typer henvendelser og kommunikasjon, som tar for seg eposter, brev, altinn-meldinger og slikt og til slutt selve dataene lagret i bånn. Denne arkitekturen gjør det lett for arkitekter og ledere på topp å forstå hva som skjer, men nå er det brukerreisen som blir en spagetti. En enkelt brukeropplevelse vil involere absolutt HELE stacken. En hver endring - legge til et nytt felt i jegerregisteret, vil involvere endringer i ALLE deler av hele systemet. Utrulling av ny funksjonalitet blir plutselig 18 ganger mer risikofylt - ettersom den oppdaterte komponenten blir brukt av alle 18 systemer.
- Som programmerer er det som frustrere meg mest, hvor vanskelig det blir for meg å legge til rette for gode tilpassede brukeropplevelser. Hvis jeg får lov til å skrive kode som er tilrettelagt en spesifik brukeropplevelse kan jeg skrive noe som det her. Dette er helt oppditktet kode som er klart farget av at jeg en gang har jobbet med Bostøtte. Her mottar vi en ny søknad om bostøtte. Så kan vi validere søknaden. Har hovedpersonen en eksisterende søknad i systemet? Ikke lov! Er ikke alle personenen på søknaden bosatt sammen? Ikke lov! osv. Så kan vi arkivere og sende bekreftelseseposter. Her har vi hele flyten brukeren opplever representert sammen. Men skal vi lage en saksbehandlingsløsning som støtter allverdens saker, så kan vi ikke skrive noe sånt.
- Da må vi over til noe som dette. Mye penere kan man si, men også mye mer vagt. Det heter ikke Søknadsskjema, men dokument. Vi kan ikke ha reglene for bostøtte, vi må kalle en regelmotor og la den finne hva det nå enn er av regler som finnes for akkurat denne typen dokument. Bekreftelsen vet vi heller ikke helt hvor går, noen vil få meldinger i altinn, noen får epost, noen får brev, dette må håndteres via konfigurering.
- Jo mer brukersentrert arkitekturen er, jo mer minner koden om det brukeren faktisk opplever. Jo mer gjenbrukbar arkitekturen skal være, jo mindre minner koden om de problemene den faktisk løser. Utvikleren har liten mulighet til å sette seg inn i hva det egentlig er brukeren opplever. Og enda vanskeligere blir det å lage gode tilpasninger til hvert brukscase. Når alt skal funke for alt, blir det minste felles multiplum som gjelder.
- Jeg tror de fleste utviklere vil kjenne seg igjen i det jeg sier, men for dere som ikke skriver kode, prøv å se for dere å skrive en fortelling. Du har blitt ansatt fordi du er glad i, og flink til å skrive gode historier.
- Det er mange “regler” rundt hva som utgjør en god historie. Man har en hovedperson/helt, som har et mål, også er det bad guys eller onde krefter de må sloss mot for å nå det målet. Masse regler om hvordan best få til en god historie. Disse bør man helt klart beherske som forfatter eller skribent. Men selv om man helst bør følge best practice, så er det grenser for hvor langt man bør gå i standardisering.
- Det finnes software som autogenerer alt mulig rart av tekst. Her for eksempel er en som lager historier. Man bare fyller ut litt info om hovedperson og kontekst, så vipps
- Så har man en historie. I veldig begrensede kontekster så kan dette fungere veldig bra. Jeg kjenner en som har laget fotball-journalist-software. Som tar resultatene av en fotballkamp, sammen med historikk fra alle tidligere kamper og generere meningsfylte tekster om kampen. Men det sier seg nesten selv, at jo mer forskjellige tekstene må være, jo vanskeligere blir det å lage meningsfylt innhold. Hvis man vil endre en del, så kan man ikke bare gå inn og endre den genererte teksten, man må inn i malen og endre der, på en måte som ikke affekterer noen av de andre typen tekster som skal genereres. Det blir fort til at man begrenser mulighetene for gode tekster, til fordel for “enhetlighet”. “Kan vi ikke bare endre denne delen her til å si X istedenfor?” “Nei, det kan vi ikke, for da ødelegger vi for Y”. Det er ikke sånn at gjenbruk nødvendigvis er ondskap selvsagt. Det er flere gode måter å gjenbruke innen IT.
- Akkurat som i historier er det bare fint å gjenbruke data - hovedpersonene. Harry potter bøkene handler om de samme folkene i hver bok. Helt greit. Akkurat som at min adresse kan gjenbrukes overalt.
- Vi kan også kjøpe alle Harry potter bøkene, og en hel haug andre bøker fra samme bokhandel. Det er også fint. Felles innlogging til en slags appstore der man får tilgang til alle de forskjellige appene man har lyst på hadde også vært strålende.
- Men å ha gjenbruk på business-regler, på kode, det er vanskelig å få til på en god måte. Her bør man dele inn applikasjonene (og kanskje organisasjonen også) etter de konkrete brukerbehovene.