Software2010-Modernisering v0.2

Больше похоже на это

LEGEMIDDELHÅNDTERING

от Yusra Ali Mudei Mudei

det moderne norge

от Juan Marcus Batistuta Samnøen Samnøen

Hægland taksering

от Erlend Askildsen Hægland Hægland

Sparing

от andylopez94 a

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

Realisme, et arkitekturmålbilde som kan nåes

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

Evaluering av Cloud som et fremtidig målbilde, når kan det være relevant?

Software as a Service

Platform as a Service

Software Infrastructure as a Service

Hardware as a Service

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

Konkurransesituasjon

Hvor skal vi?

Zachman/TOGAF

Domain adoption, tilpasses egenskaper som kjennetegner industrien, f.eks. financial services

Definere Målbilde

Gode begrunnelser for arkitekturvalg