Application Lifecycles: 2 case studies. Joris Van Looveren joris.van.looveren@volvo.com

Transcription

1 Application Lifecycles: 2 case studies Joris Van Looveren joris.van.looveren@volvo.com

2 Background info... (1) Joris Van Looveren Volvo IT - Gent (Oostakker) joris.van.looveren@volvo.com Background Computer VUB (some time ago...) Now: (web) application development at Volvo IT

3 Background info... (2) Volvo IT IT services branch of Volvo Group (Volvo Group = most everything motorised... except cars) Service areas: Hardware: - everything network-related - computing environment (= computers & intranet) Software: - licenses for commercial software - custom application development

4 Contents Application lifecycle? Case Volvo IT 2 applications: Infoshop: simple ANDON: complex Observations Questions

5 Application Lifecycle (1): Wikipedia definition

6 Application Lifecycle (1): Wikipedia definition JIRA CVS Subversion JUnit JABD

7 Application Lifecycle (2) Many different aspects Static concepts - focused on how - tools to use to perform tasks However: - not forward-looking doesn t address possible changes - how do we prepare? Ergo: can we find out what changes are likely to happen?

8 Application Lifecycle: Case studies 2 case studies applications built by Volvo IT 1. ANDON production quality follow-up application 2.Infoshop Portal for providing all kinds of reporting to end-users 2 extremes of the complexity spectrum how did they change of their lifetimes?

9 Application Lifecycle Initial - business driver Development Deploy to production Changes Maintenance - user initiated - infrastructure change bug fixes - keep it running Retirement - change in business process - replacement -...

10 Application Lifecycle Initial Development - business driver What happens here? Deploy to production Changes Maintenance - user initiated - infrastructure change bug fixes - keep it running Retirement - change in business process - replacement -...

11 Case study 1: Infoshop 2 extremes of the complexity spectrum

12 Infoshop: original structure Report Bursting Engine Oracle database Infoshop Network share

13 Infoshop: constraints Java expertise available in-house Oracle used for Business Intelligence systems Reports too large and numerous for DB external storage required

14 Infoshop: choices Monolithic J2EE application External file share for document storage - protection against data loss - no storage on application server Spring (dependency injection) Data access through ibatis (= named query manager)

15 Infoshop: current structure Report Bursting Engine Oracle database Infoshop Network share

16 Infoshop: changes Nothing really changed?! Server migrations: WebSphere 5 WebSphere 6 WebSphere 7 reason: end-of-life by IBM no real issues; just drop app onto server! Several smaller changes

17 Case study 2: ANDON

18 ANDON: original structure PDA upload breakdown DB2 database ANDON weeg brug digital tacho tool soft VDA HDOC weeg brug weegbrug printer digital tacho = file share = VCOM tool soft = HTTP

19 ANDON: structure Loosely coupled set of modules technology: individual J2EE projects server: IBM WebSphere on zlinux = linux in VM on z/os (mainframe) interaction mostly through DB most modules process external input aggregation in DB

20 ANDON: constraints Java expertise available in-house DB2 used company-wide in external systems interface with 3rd party systems (weigh bridge, ToolSoft, digital tacho) - driver software by vendor - what can vendor provide? - quality of 3rd party software variable

21 ANDON: choices Loosely coupled set of modules - independent development - independent redeploy possible in many cases Lots of file sharing (!!) - protection against data loss (file remains if server dies while processing) - access arbitration by OS - network transfer by OS Proprietary data access mechanism - EJBs deemed too complex (pre EJB3)

22 ANDON: current structure PDA upload breakdown DB2 database ANDON weeg brug digital tacho tool soft VDA HDOC weeg brug weegbrug printer digital tacho = file share = VCOM tool soft = HTTP = Web service

23 ANDON: changes Server migrations: WebSphere 5 WebSphere 6 WebSphere 7 reason: end-of-life by IBM problems: WAS5 WAS6: file sharing semantics changed introduction of web services WAS6 WAS7: webservice technology changed User complaint: complete rewrite of Weighbridge module Lots of small changes to individual moduels

24 Observations (1): technological evolution at Volvo IT Technological evolution for NEW java web apps: Spring + Hibernate Template application empty application (in-house) that contains the most common components Styles in CSS Ajax components Custom build + deploy cycle

25 Observations (2) Parallel evolutions: New technologies introduced in new apps Per application: - conform to infrastructure changes (in casu: server changes) - change according to user requirements - regular maintenance

26 Observations (3a): application specific External systems WILL outlast your application - 3rd party systems: * vendor out of business * vendor cannot perform changes * vendor charges too much for changes *... - databases * data store harder to change Infrastructure changes more important to support - product end-of-life

27 Observations (3b): application specific Technological (Java) innovations: most likely introduced in new applications (new frameworks, new Java version) most likely not retrofitted in old applications unless: - as part of significant changes - when no expertise left

28 Observations (4): general considerations Budgets! - there s never enough for all necessary changes - driver of all changes Maintenance - keep it running - often no time/budget for structural maintenance (e.g. framework upgrade not visible) - very hard to keep architectural uniformity across applications

29 Any questions?