Software2010-Modernisering

Mer av detta

Budsjett kopi

av Elisabeth Thuv Thuv

Software2010-Modernisering v0.2

av Simen Bergsrud

Den amerikanske revolusjonen

av Kokhob Tewldeberhan Mehari Mehari

MAYP Oppgave arbeid

av Runar Oudmayer

Modernisering

Innledning

Hva skiller systemfornyelse fra nyutvikling?

Å flytte systemer fra en plattform til en annen er en enkel sak?

Mange større virksomheter har i dag sinemest kritiske og verdifulle systemer pådøende plattformer

Innhold

Bakgrunn foredragsholdere

Hvor kommer vi fra og hvorfor mener vi det vi mener

Veien inn i Skyen

Lessons learned

Folk går ikke på tryne...

Det er mye som er enkelt i fugleperspektiv

No f..... suprises

Hvordan forvalter man folk og kjernekompetanse

Dårlig håndtering av (teknologiske)konsekvenser ved å bytte plattform

Svært lav toleranse for feil

Ingen vet alt om det gamle systemet

Forankre

Nye og "gamle" utviklere

Linjeorganisasjon (forvaltning/drift/test)

Eier/Sponsor

Gjennomfore

Testing

Organisjonen er ikke klar for å øke testaktiviteten med 500%

Knappet på kompetanse og systemer

Svært høy kostnad å gjøre skikkelig

Verdikjede testing med produksjonsdata

Arkitektur

Ambisjonsnivå må matchekrav (endringstakt, gjenbruk, kvalitet

Arkiterktur må "matche"drivere/endringer

Må ha flere opsjoner på forskjellige typer arkitektur

Greit med grupper av systemerpå arkitektur

No-big-upfront-architecture

Prinsipper

Du tror du har mye frihet i forhold valg

Replace bør være lik mht. integrajon og testing sånn kjøre produksjonlavere kompetanse

Gir gir en del krav til applikasjonarkitekturslik at man unngår test/kompetanseproblemer

Output first

Planlegge

Planlegge helheten - mer enn arkitektur og krav

Hvordan skal det organiseres

Hva slags utviklingsorganisasjon skal vi ha?

Alle valg angende arkitektur, folk, metode etc. må "sette" / finne en rytme. Opplæringsfase

Hva koster det?

Eksterne ressurser - har kompetanse på teknologi, og ikke system

Interne ressurser - har kompetanse på system, ikke teknologi

Migreringsplan

Replace

IaaS

Renew

SaaS

Fremtidig målbilde

Subtopic

Beviste valg i forhold: Ideelt sett så begynner man hvordan krav blir kjørende kode, men så kommer driverne+økonomi+div og påvirker folk/systemer/metode: Feedback loop - tenke igjennom hele. Ikkelike avhengig av context

Driverne + hva man har gir nytt målbilde

Hvordan skal IT-funksjonen se ut? Her har man faktisk en mulighet til å endre

Systemer

Analysere

Drivere/endringer presser frem

Krav om ikke kan løses

Teknologisk

Lovmessig

Forretningsmessige

Kompetanse

Risiko

Økonomi

Presser frem endringer

Hvor skal vi?

Målbilde

Hva har vi?

Zachman/TOGAF