Modernisering er et arkitekturvalg. Ikke et 2-års prosjekt.

I mange bokprosjekter ser vi det samme mønsteret.

Et stort moderniseringsløft.
Lang planleggingsfase.
Big-bang lansering.

Så stillstand.

Ikke fordi ambisjonen forsvinner.
Ikke fordi markedet slutter å endre seg.

Men fordi arkitekturen gjør neste steg vanskelig.

Det som ofte presenteres som et teknologiprosjekt, er i realiteten et arkitekturvalg. Og når arkitekturvalget låser organisasjonen til en monolittisk struktur, blir modernisering noe man gjør sjelden – og helst så lite som mulig.

Det som faktisk gjør vondt

Vår erfaring fra komplekse plattformer er at det som gjør vondt, sjelden er frontend.

Det som skaper friksjon over tid er:

• Uklar ansvarsdeling mellom systemer
• Kjernelogikk spredt på flere plattformer
• Manglende sporbarhet i hvordan data behandles
• Infrastruktur som ikke kan reproduseres raskt og kontrollert
• Avhengigheter som gjør små endringer risikable

Når slike strukturer får utvikle seg, øker risikoen for hver justering. Innovasjon må planlegges i store bolker. Endringer krever koordinering på tvers av flere miljøer. Organisasjonen blir naturlig mer forsiktig.

Det er slik 2-års prosjektene oppstår.

Bokbransjen trenger ikke enda et system

Bokbransjen trenger ikke enda en tungt system.
Den trenger ikke enda et hyllevarersystem.
Den trenger ikke enda en frontend-oppgradering.

Den trenger en arkitektur som tåler kontinuerlig endring.

Det betyr:

En robust digital tjenesteplattform som fungerer som et stabilt datalag mellom ERP, OMS, CRM og brukerflater.
Tydelige domenetjenester for metadata, katalogkvalitet, prisstyring, tilgjengelighet, og ordre.
Deterministisk produktbehandling som kan etterprøves.
Sporbar historikk i hvordan data behandles og eksponeres.
Infrastruktur som kode, slik at miljøer kan etableres og testes uten risiko.
Komponenter som kan byttes ut uten at hele arkitekturen må berøres.

Når dette fundamentet er på plass, endres dynamikken.

Modernisering blir ikke et prosjekt.
Den blir en egenskap ved plattformen.

Kontinuerlig utvikling fremfor episodisk transformasjon

I en slik arkitektur kan nye initiativer etableres trinnvis.

Et nytt søkegrensesnitt kan testes uten å endre kjernesystemet.
En AI-basert bokassistent kan kobles på via definerte API-er.
En kampanjemodul kan erstattes uten fult release-løp.

"Ephemeral components" - løsninger som prøves, justeres og eventuelt forkastes – blir mulig fordi kjernen er stabil.

Da reduseres risikoen.
Da kan innovasjon testes i mindre skala.
Da slipper man 2-års løft hver gang noe skal forbedres.

Forskjellen mellom prosjekt og plattform

Forskjellen er enkel:

Et prosjekt leveres.
En plattform utvikles.

Et prosjekt har en start og en slutt.
En plattform er designet for kontinuerlig videreutvikling.

For beslutningstagere i bokbransjen er derfor det avgjørende spørsmålet ikke:

“Når skal vi starte neste moderniseringsprosjekt?”

Men:

“Har vi en arkitektur som gjør at vi slipper å tenke modernisering som et prosjekt i det hele tatt?”

Det er her skillet går.

Mellom å implementere systemer.
Og å bygge plattformer.