Application Lifecycles: 2 case studies Joris Van Looveren joris.van.looveren@volvo.com
Background info... (1) Joris Van Looveren Volvo IT - Gent (Oostakker) joris.van.looveren@volvo.com Background Computer science @ VUB (some time ago...) Now: (web) application development at Volvo IT
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
Contents Application lifecycle? Case studies @ Volvo IT 2 applications: Infoshop: simple ANDON: complex Observations Questions
Application Lifecycle (1): Wikipedia definition
Application Lifecycle (1): Wikipedia definition JIRA CVS Subversion JUnit JABD
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?
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?
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 -...
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 -...
Case study 1: Infoshop 2 extremes of the complexity spectrum
Infoshop: original structure Report Bursting Engine Oracle database Infoshop Network share
Infoshop: constraints Java expertise available in-house Oracle used for Business Intelligence systems Reports too large and numerous for DB external storage required
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)
Infoshop: current structure Report Bursting Engine Oracle database Infoshop Network share
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
Case study 2: ANDON
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
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
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
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)
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
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
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
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
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
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
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
Any questions?