turning spaghetti into lasagne : applying the principles of application frameworks to packaged...

Turning spaghetti into lasagneApplying the principles of application frameworks to packaged applications

James CouzensSolution Architect, SuncorpJAOO Conference, 2009

What I will be talking about today

About our experience

Checklist onhow to

create aframework

Overview

Frameworks – common understanding

The problem space – organisational, package

Our solution – architecture and framework

Challenges – what to watch out for

Conclusions – why consider it

What is meant by “application framework”

4

Implement standard structure of an application using abstraction

Provide adaptations for specific functionality at defined places

Application framework characteristics

5

Modular Reusable

Extensible

Inversion of control

White box vs. Black

box

Framework pros & cons

6

Pros

Cons

Leverage

Rely on

Improve

Learning Efficiency

Vendor application characteristics

7

XML web page definitions

<?xml version="1.0"?><PCF xmlns:xsi="http://www.w3.org/2001/ XMLSchema-instance" xsi:noNamespaceSchemaLocation= "../../../schema/pcf.xsd"> <DetailViewPanel id="LossDetailsDV" mode="Pr">

<PanelRef def="ClaimSummaryMattersLV(Claim.Matters, Claim)" visible="perm.Matter.view(Claim) and perm.System.viewmatters"> <TitleBar title="displaykey.Web.ClaimSummary.MattersLV.Title"/> <Toolbar/> </PanelRef>

... ...

Vendor application characteristics

8

Rule engine with pre-defined rule sets

Vendor application characteristics

9

Pre-defined events

- ClaimAdded

- ClaimChanged

- ClaimRemoved

User-defined

events- Add events (add,

change, remove) to

user defined entities

Vendor application characteristics

10

XML persistence layer

<!-- Extension to claim table --> <extension entityName="Claim"> <column desc="True anyone living in the property" name="SC_PermanentOccupancy" nullok="true" type="bit"/> <column desc="number of days Property Vacant" name="SC_DaysPropertyVacant" nullok="true" type="integer"/> <column desc="number of damaged units" name="SC_NoDamagedUnits" nullok="true" type="integer"/> ... ...

+ inbound web services+ integration plug-ins+ OO configuration language

Vendor application characteristics

11

XML web page definitions<?xml version="1.0"?><PCF xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="../../../schema/pcf.xsd"> <DetailViewPanel id="LossDetailsDV" mode="Pr">

Pre-defined and user-defined events- ClaimAdded- ClaimChanged- ClaimRemoved

Rule engine withpre-defined rule

sets

XML persistencelayer

<extension entityName="User"> <column name="OffsetStatsUpdateTime" type="datetime"/> <column name="NewlyAssignedActivities" type="integer"/> <column

+ inbound web services+ integration plug-ins+ OO configuration language

With all this why do I still

run into problems

Business structure – growth by merger

12

Companies

Vendor application has limitedmulti-company capability

Business structure – joint ventures

13

Limited multi-company capability

Business structure - brands

14

No concept of brand

Business structure – products, versions, systems

15

+ over 100 products

+ multiple versions per product

+ multiple legacy systems … and so on

Implications of variability

16

UI

Rules:if (brand=="amp" or brand=="gio" or brand=="suncorp") { ... } else if (this.isRACQIBrand()) { ... } return false }

Data model

The result is code spaghetti

17

Code lacks modularity

Prolific dispatch code

Inconsistent logging, error handling

Problems with merging

Oh no! What are we going

to do?

Goals and principles

18

• Standardise business process

• Prefer OOB over customised

• Maintain upgrade path

• Ease of maintenance

• Minimise duplication

• Maximise reuse

• Entity awareness

• … … …

Architectural model

19

Framework to support the model

20

Initially focussing on UI variations and rules

Application framework – the use interface controller

<<abstract>>UIController

+createUIObject()+applyRule()

<<abstract>>UIInput

+visible()+editable()+validation()+ ...

*

PageController

Subclass this level if no claim context

FieldInput<<abstract>>

UIControllerClaim

+initUIInputs()

<<abstract>>UIInputClaim

Subclass this level if have claim context

PageController FieldInput

*

21

Application framework – UI example

22

LossDetailsDV.Pr.pcf

<TypeKeyInput

editable="Claim.isEditable_IDRStatus()"

... />

CORE_ClaimUIExt.gs

function isEditable_IDRStatus():boolean {

...

if (brand==“brand1")

{ do something for this brand }

else if (brand==“brand2”

{ do something for brand2 }

else if (brand==“brand3" )

{ do something for brand3 }

else return a default value

}

Application framework – UI example

23

Page configuration

file (PCF)

Add a UI controller variable to the page:<variable name = “UI”initialValue=shared.base.UIController.createUIObject(“PCFName”)>

Controller creates UI input classes for that page:Input classes implement context specific logic , i.e.

function isEditable ():boolean { return something for context}

1

2

3

<Input id=”IDRStatus”...Editable=UI.applyRule(“IDRStatus”).isEditable>

4

Application framework – run time context

user locale

claim

Product

Motor

Motor

Shared

24

Suncorp

PageCtlr

Base

PageCtlr

PageCtlr

PageCtlr

Application framework – rules and rule sets

<<abstract>>RuleSet

+execute()

<<abstract>>Rule

+name+condition()+action()

ConcreteRuleSet

*

All rules run in the context of a claim so no need for claim level abstract class

ConcreteRule

*

25

• Triggered by the same events as OOB rules.• OOB hierarchy traversed until framework rule set found.• Framework instantiates rule set based on claim context• Rule set uses context to find correct rules• Rules will fall back to a default rule if none in specific

context

Key Points:

The challenges of this type of approach

26

6. Framework ownership

5. Framework champions

4. Making sure training is sufficient

3. Ensuring the right underlying skills

2. Getting vendor buy-in

1. Politics and personality

James’ top

ten list of

challenges

when

implementing

a framework

on top of a

packaged

application

7. Building a framework Agile

10. Understanding the business variability

8. Assessing impact on upgrades

9. Understanding the vendor’s framework

Concluding remarks

27

Moves away from vendor product

May require up-skilling

Business domain variability

Unable to standardise

Not supported well by application

Credit where credit’s due

• The following people were instrumental in developing the architecture approach and frameworks described in this presentation and pushing for its adoption

• Paul Donohue

• Paul Reedman

• Steven Shaw

• Reese Williams

Pick me, pick me