Turning spaghetti into lasagne : applying the principles of application frameworks to packaged...
-
Upload
james-couzens -
Category
Technology
-
view
698 -
download
1
description
Transcript of 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