BBS moderniseringprogram STAY i 2006: Erfaringer med arkitektur og gjennomføring Johannes Brodwall Lead Software Architect.

Presentasjon om: "BBS moderniseringprogram STAY i 2006: Erfaringer med arkitektur og gjennomføring Johannes Brodwall Lead Software Architect."— Utskrift av presentasjonen:

1 BBS moderniseringprogram STAY i 2006: Erfaringer med arkitektur og gjennomføring Johannes Brodwall Lead Software Architect

2 Hva er STAY?

3 Moderniseringprogram

4 Mainframe ut – UNIX inn

5 COBOL ut – Java inn

6 Hvem er jeg?

7 Johannes Brodwall

8 Lead software architect

9 Bakgrunn fra Java programmering og arkitektur

10 Foredraget

11 En tidslinje + erfaringer

12 Fokus på utvikling

13 Still spørsmål!

14 (Jeg kan kaste slidene)

15 2003 2/5

16 Marked i nedgang

17 Respons: Konsolidering

18 Mål: Kvitte oss med mainframe

19 Mål: Time to marked

20 2004 5/28

21 Kravfangst: Use cases

22 Informasjonstjenester

23 Regningsbetaling

24 Sommerferie

25 Pilotprosjekt...

26 ... avbrytes

27 (Råd: Kjør pilot)

28 Høst 2004

29 Kravfangst fortsetter

30 Arkitektur

31 Forretningsarkitektur

32 Teknisk arkitektur

33 DCRI DCRI = Data Center Reference Implementation

34 Applikasjonsarkitektur

35 Implementasjonsarkitektur

36 (Skrives av meg)

37 Domain Driven Design

38 ”Domain-Driven Design var vår ledestjerne fra dag 1. Det har påvirket oss mye og hjulpet oss såpass mye at ”forretningslogikk er vanskelig” ikke står på listen over erfaringer. Tvert imot føler jeg at ”forretningslogikk er ikke så vanskelig!” -- Eirik Torske, utvikler

39 Spring, Hibernate, JMS

40 Anti-SOA (?): Gjenbruk via tradisjonell gjenbruk, integrasjon via databaser (og meldingskø)

41 Utviklingsarkitektur

42 Test driven design

43 (eller i det minste enhetstester)

44 Continuous Integration

45 Smalt nåløye ved rekruttering

46 Tilbakeblikk på arkitektur:

47 ”Arkitekturbildene er i dag en selvfølge. Det er først når vi tenker på det at vi innser at vi har en arkitektur” -- NN

48 2005

49 Kravfangst fortsetter

50 Analysis paralysis?

51 Blankett: 160 use cases Regningsbetaling: 300 use cases NICS: 100 use cases

52 Sentral aktør: ”Klokka”...

53 ... Hmmm.

54 Tilbakeblikk:

55 Use cases er vanskelig

56 (For mye og for lite detalj på en gang)

57 Implementasjonsprosjekter

58 Direkte remittering

59 NICS NICS = Norwegian Interbank Clearing System

60 ATI ATI = Applikasjonsteknisk infrastruktur

61 Oppskalering: 10  50 utviklere

62 Scrum binder prosjektene sammen

63 Arkitekturkjernen utkrystaliserer seg

64 Referanseapplikasjon

65 Sommer 2005

66 ”Jeg ser du skal i samme R1”

67 WebSphere 6.0

68 (Bleeding edge...?)

69 Forsinkelser forplanter seg

70 Sikkerhet og web

71 Høst: Use case utfordringer

72 Stabilisering av utviklingsarkitektur

73 Byggsystem

74 (men kunne brukt mer tid på selve systemet)

75 "Continuous integration har en oppdragende effekt på utviklere som gjør at man tester bedre.” – Hans Petter Vadseth

76 Refactoring av 300 klasser

77 Vi blir for smarte...

78 ... overdesign

79 ... spekulative anskaffelser

80 Kravtester

81 JavaZone 2005: FitNesse

82 JavaZone 2005: Anti-SOA

83 Integrasjon mot mainframe og NonStop

84 Involverer mange personer

85 Vanskelig å teste

86 Tidkrevende

87 ”WAS-ifisering” WAS = WebSphere Application Server

88 Urovekkende tidkrevende

89 (Men vi tester utenfor server)

90 Release 2

91 DB2 -> Oracle

92 Besparelse realisert

93 Ikke helt smertefri leveranse

94 (Liten tue velter stort lass)

95 ”Half-full”: Problemløsning

96 Prosjekt blir program

97 Forsinkelser

98 Folk starter å fokusere på oppsplitting

99 Erfaring: Store leveranser: Bordet fanger

100 Andre prosjekter starter å få fokus

101 BBS: Endring fra konsolidering -> Fokusert vekst -> Ekspansiv vekst

102 Jul 2005

103 Omorganisering av IT og prosjekt

104 Mindre fokus på ”det ene store prosjektet”

105 ATI forsvinner

106 Arkitektur i organisasjonen

107 2006

108 Leveranse R3

109 Ingen overraskelser

110 Rutinifisering av utviklingsarkitektur

111 (Etter vinterferien har jeg har lite å gjøre)

112 Arkitekten som veps

113 Testkvalitet

114 Hastighet

115 Brittle tests

116 Testene våre er gode, men kan alltid bli bedre!

117 Continuous Integration rutiner

118 "Byggsystemet kan være vanskelig å forstå og bruke riktig dersom man ikke vet hvordan dette virker. Dette er spesielt vanskelig for de som ikke har benytter junit eller maven før.” – Hans Petter Vadseth

119 ”Vær varsom” flagg

120 ”De problemene som oppstår med continuous integration er problemer som vi bare hadde oppdaget senere” – Bjørn Bjerkeli

121 Infrastrukturprosesser

122 Infrastrukturarkitekt

123 Teknisk validering av arkitekturelementer

124 Litt sent, da!

125 Sommer 2006

126 Leveranser på STAY arkitektur

127 eFaktura B2B

128 Elektronisk avtale

129 Direkte remittering

130 Sommer 2006

131 Erfaringer og optimisme

132 JavaZone: 6 STAY relaterte CfP

133 ”Java i BBS 2007”

134 Gjenstående risikoer

135 Software som ferskvare

136 Kompleksitet på infrastruktur

137 Og arkitekter?

138 Nå kan vi bare lukke øynene og håper vi har pekt i riktig retning og at de er flinke nok til å komme i mål

139 Erfaringer

140 Arkitektur

141 Unngå krystallkulearkitektur

142 Kompleksitet er din største fiende

143 Arkitekturen bør forvinne

144 Referanseapplikasjon

145 Infrastrukturteam: Må fokusere på teknisk test

146 Prosjektplanlegging

147 Vi blir ikke ærlige før vi skal produksjonssette

148 Pilotprosjekt kunne hjulpet

149 Krav er ferskvare

150 Kravfangst med krystallkule

151 Prosjektgjennomføring

152 Omstillingsprosjekter kan ikke leve i isolasjon

153 Unngå overspesialisering

154 Enhetstesting: Enormt effektivt

155 Continuous integration

156 Scrum, scrum, scrum!

157 Hva har jeg lært?

158 ”Når vi forsøkte å tenke for mye framover tenkte vi ofte feil....

159 ... Når gjorde det mulig å endre kurs, fikk vi stor gevinst!”

160 Takk for meg