Application Lifecycles: 2 case studies - LORElore.ua.ac.be/Teaching/CapitaMaster/Application...

Application Lifecycles:2 case studies

Joris Van [email protected]

zondag 21 februari 2010

mailto:[email protected]


Background info... (1)

Joris Van LooverenVolvo IT - Gent (Oostakker)[email protected]

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


ContentsApplication lifecycle?

Case studies @ Volvo IT

2 applications:Infoshop: simpleANDON: complex

Observations

Questions


Application Lifecycle (1):Wikipedia definition


Application Lifecycle (1):Wikipedia definition

JIRA

JUnitJABD

CVSSubversion


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 studiesapplications built by Volvo IT

1. ANDONproduction quality follow-up application

2.InfoshopPortal 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 Development

Deploy to production

Changes

Retirement

- user initiated- infrastructure change - ...

- business driver

- change in business process- replacement- ...

Maintenance- bug fixes- “keep it running”


Application Lifecycle

Initial Development

Deploy to production

Changes

Retirement

- user initiated- infrastructure change - ...

- business driver

- change in business process- replacement- ...

Maintenance- bug fixes- “keep it running”

What happenshere?


Case study 1: Infoshop

2 extremes of the complexity spectrum


Oracledatabase

Report Bursting Engine

Infoshop

Infoshop:original structure

Networkshare


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

Oracledatabase

Report Bursting Engine

Infoshop

Networkshare


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


DB2database

uploadbreakdown

ANDONweegbrug

digitaltacho

toolsoft

weegbrug

digitaltacho

toolsoft

VDAHDOC

= VCOM

= file share

= HTTP

weegbrugprinter

ANDON:original structure

PDA


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 inputaggregation 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)


DB2database

uploadbreakdown

ANDONweegbrug

digitaltacho

toolsoft

weegbrug

digitaltacho

toolsoft

VDAHDOC

= VCOM

= file share

= HTTP

weegbrugprinter

ANDON:current structure

= Web service

PDA


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 servicesWAS6→WAS7: webservice technology changed

User complaint:complete rewrite of Weighbridge module

Lots of small changes to individual moduels


Observations (1):technological evolution at Volvo ITTechnological 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 applicationsunless:- 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?


Application Lifecycles: 2 case studies - LORElore.ua.ac.be/Teaching/CapitaMaster/Application...

Documents

Transcript of Application Lifecycles: 2 case studies - LORElore.ua.ac.be/Teaching/CapitaMaster/Application...