Hva er problemet?

eller hvorfor er det så vanskelig å snakke om Marcus?

Fordi vi ikke vet det samme?

Vi er kjent med datamodellering med RDF

Videreutvikles ikke!

Brukere må ha desktop-app!

Ikke validering

Full av bugs

UX kan ikke enkelt tilpasses

Umulig gjøre til et avansert arbeidverktøy

Bruker sparql

Videreutvikles ikke!

Laget av én chilener

Bruker en forferdelig template-engine

Bygger ikke på moderne web-app-prinsipp

Ineffektiviteter overalt

Dårlig skalering

Kjapt søk

Tungvidt utviklingsprosess

Har ikke fått til hierarkiske data eller relasjoner

Driftes av UB

Frontend ikke basert på et solid rammeverk

Sparql

Ikke langt unna IIIF

Egenutviklet modell

Ikke IIIF

Ikke API

Ikke fulltekstsøk

MAM

Noen penger inn

Hjemmesnekret PHP-serversideskript foretar validering og epost

Integrerer med Redmine Plugin ingen andre ved UiB bruker

Manuelt arbeid

Utvalg(?) av dokumenter i Oria

Hvor mye er det brukt?

Hvordan skal vi videreutvikle integrasjonen?

Lite er testbart

Forsøk på å lage et utviklingsmiljø med frontend og backend inkluderer ikke alle komponentene og har ikke vært enkelt å jobbe med

— Folk liker det

Fint, og vi skal ta det som er bra med oss, men arkitekturen har ikke livets rett

Men, dette kan være et moment vi kan utnytte...

UB må ha en plan

Prinsipp

Pragmatikk over evangelisme
UX/brukeropplevelse over (elegant) datamodel
Konsum av tjenester før drift av tjenester
Svak integrasjon over sterk integrasjon

UB må unngå...

...langvarig driftsansvar
...fokus på det som gir mest verdi, "Fail fast, fail often"
...prosjekt uten faglig, teknisk ansvarlig på bestillersiden
...prosjekt uten klare tidsrammer og leveranser
...infrastrukturutvikling
...enkeltutviklere som er ansvarlig for enkeltfunksjoner eller for valget av de
...uoversiktlige kostnader, dvs. det bør være en billing manager

UB må || bør...

Skal vi jobbe med HF og forskerne der...
- Levere raskt på forskeres behov
- Vi kan ikke forvente at forskere følger vår "tidsregning"
- Hva som helst kan komme inn fra siden
Levere forskningsstøtte, ikke drift av sentrale UiB system
Hjelpe brukere med rammeverk, ikke nødvendigvis lage eller tilby ferdige løsninger

Hva skal lages?

UB må vurdere hvor man skal sette inn innsatsen på HF-infrastruktur. Hva skal UB som produsent lage? Hva skal man eie?

Drift av løsninger (OSS eller egen utvikling) forplikter UB i mange år. Man må ta en seriøs utredning på hva UB eller HF trenger og hvordan man kommer dit raskest.

Dette bør gjøres før man rekrutterer nye ansatt.

Frontend

CMS

Hvilke komponenter?

En HF-infrastruktur vil trenger flere tunge komponenter og utstrakt støtte.

MAM
Konstant frontend-utvikling
CMS, som må kunne tilpasses raskt
Visualisering av forskningsresultat
...

Frontend

CMS

Viz

MAM

Hvordan?

Alt skal i skyen. Skyen er vanskelig. Vi kan betale andre til å gjøre det enklere for oss.

Vi kan gå rett på Now, Netlify.

Eller bestille tilsvarende løsning fra ITA på AWS (kan de levere?). For UB må løsningen være så smertefri å bruke som mulig.

Det betyr at produkt som UB lager må ha eget budsjett. Man må kunne betale for effektive løsninger.

Frontend

CMS

SaaS

Viz

Analyse

MAM

For hvem?

Vi har lovet gull og grønne skoger bare man følger vår "Linked data"-sti

Hver gang vi reklamerer, frister Marcus's overflate nye ofre.

Spørsmålet blir da, hvem skal vi lage dette for?

For UB? HF? Små museum? Alle? Ingen?

Frontend

CMS

SaaS

Viz

Analyse

MAM

Kan UB levere?

I min mening, absolutt ikke uten partnere.

Vi trenger partnere eller nasjonale aktører som leverer de tyngste komponentene. UB og UiB har ikke kapasitet til dette.

Det man har kapasitet til er å bygge tilpassede løsninger på toppen av en nasjonal eller kommersiell
infrastruktur. En infrastruktur som ikke krever "koordinering"

Frontend

CMS

SaaS

Viz

Analyse

MAM

ITA

UB/HF

Kontekst

eller hvor er hypen nå?

Fra turn-key til `${x}aaS`

{X}aaS-ness

Open source

Frameworkness

redhat-y-ness

Frontend

Backend

viktighet

ub.du.replace('evangelister', 'pragmatikere')

Styring

Litt historikk

Digitale fulltekstarkiv

Da prosjekt var det mest spenstige vi kunne gjøre
God prosjektledelse
Ved prosjektslutt ble dette ikke videreført
Marcus som beta fra en arbeidspakke ble satt i produksjon
Adhoc utviklet av tre utviklere, uklar rollefordeling
DU-gruppeleder var en slags sjefsutvikler, men med liten mulighet til å prioritere arbeidsoppgaver
Seksjonen UFS spredte seksjonsleder på for mange oppgaver til å kunne bidra konstruktivt
Kort sagt, Marcus har ikke styring

Organisasjon 2018-2020

UFS

DU

US

FS

"saksfiltre"

Få faglige overlap?

"eksterne" partnere

Språksamlingen og Avhandlingsportalen ved DU IKKE med!

Organisasjon 2020-????

UFS

DU

US

FS

Styringgruppe

Arbeidsteam

Styringgruppe

Start på overordnet kravspesifikasjon...

Eller, her slenger jeg inn hva som helst...

Kompleksitet bevares

Den må bare flyttes nedover!

Helst vekk fra DU!

La oss si, vi SKAL lage Marcus v6

(og den skal ikke lages med turn-key software)

Vi har en plan
- Godkjent av eksterne konsulenter blant flere alternative løsninger
Vi har en styringsgruppe, alle avklaringer på plass
Hvordan kan det tenkes at vi løser dette innenfor de rammene jeg mener vi har?

Rekruttering

Må rekrutteres etter en helhetlig utviklingsplan
IKKE adhoc
IKKE før utviklingsplanen foreligger
Bedre å fortsette letingen enn å ansette feil person
- Vi må være 90% sikre på at dette er riktig person