• Like
Turning spaghetti into lasagne : applying the principles of application frameworks to packaged applications
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Turning spaghetti into lasagne : applying the principles of application frameworks to packaged applications

  • 672 views
Published

Presentation at the JAOO 2009 conference about the pros and cons of applying the principles and patterns of application frameworks to packaged applications using illustrations of the why, when and how …

Presentation at the JAOO 2009 conference about the pros and cons of applying the principles and patterns of application frameworks to packaged applications using illustrations of the why, when and how from experiences implementing a java based enterprise claims package at Suncorp.

Published in Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
672
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
24
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • The vendors product is an application framework and accompanying development language that has been focused onto solving problems in the insurance domain.PCF – XML definition of a page layoutPre-defined and user defined events Event driven rules developed using vendors language that fit in a partially defined hierarchyUtility classes developed using vendors languagePersistence layer defined in XML files that auto generates database after changesProvides web service based access through auto generated core entity API classesOutbound “plug-in” architecture provides interface plus default implementation to access required functions expected to be provided by external systemsThis is all very good and flexible so why do we still run into problems?
  • The vendors product is an application framework and accompanying development language that has been focused onto solving problems in the insurance domain.PCF – XML definition of a page layoutPre-defined and user defined events Event driven rules developed using vendors language that fit in a partially defined hierarchyUtility classes developed using vendors languagePersistence layer defined in XML files that auto generates database after changesProvides web service based access through auto generated core entity API classesOutbound “plug-in” architecture provides interface plus default implementation to access required functions expected to be provided by external systemsThis is all very good and flexible so why do we still run into problems?
  • The Suncorp Group is a large multiple entity organisation:Multiple companies & joint venturesMany insurance lines of business (personal vs. commercial, motor, property, professional liability, general liability, workers compensation, CTP) Brand differentiation (how many brands?)Many different insurance productsMultiple versions of those products (commercial alone has over 400 product variants)Operating under different regulatory jurisdictionsMultiple legacy systems providing the same or similar informationAd infinitum … huge variabilityIn the past this was managed by having many software products, multiple code bases for the same product and multiple implementation instances, myriad of point solutions, poorly integratedBut we want to have a single software product using the same code base deployed to a single deployment instance covering all core claims functions
  • The Suncorp Group is a large multiple entity organisation:Multiple companies & joint venturesMany insurance lines of business (personal vs. commercial, motor, property, professional liability, general liability, workers compensation, CTP) Brand differentiation (how many brands?)Many different insurance productsMultiple versions of those products (commercial alone has over 400 product variants)Operating under different regulatory jurisdictionsMultiple legacy systems providing the same or similar informationAd infinitum … huge variabilityIn the past this was managed by having many software products, multiple code bases for the same product and multiple implementation instances, myriad of point solutions, poorly integratedBut we want to have a single software product using the same code base deployed to a single deployment instance covering all core claims functions
  • The Suncorp Group is a large multiple entity organisation:Multiple companies & joint venturesMany insurance lines of business (personal vs. commercial, motor, property, professional liability, general liability, workers compensation, CTP) Brand differentiation (how many brands?)Many different insurance productsMultiple versions of those products (commercial alone has over 400 product variants)Operating under different regulatory jurisdictionsMultiple legacy systems providing the same or similar informationAd infinitum … huge variabilityIn the past this was managed by having many software products, multiple code bases for the same product and multiple implementation instances, myriad of point solutions, poorly integratedBut we want to have a single software product using the same code base deployed to a single deployment instance covering all core claims functions
  • The Suncorp Group is a large multiple entity organisation:Multiple companies & joint venturesMany insurance lines of business (personal vs. commercial, motor, property, professional liability, general liability, workers compensation, CTP) Brand differentiation (how many brands?)Many different insurance productsMultiple versions of those products (commercial alone has over 400 product variants)Operating under different regulatory jurisdictionsMultiple legacy systems providing the same or similar informationAd infinitum … huge variabilityIn the past this was managed by having many software products, multiple code bases for the same product and multiple implementation instances, myriad of point solutions, poorly integratedBut we want to have a single software product using the same code base deployed to a single deployment instance covering all core claims functions
  • Is missing support for some key conceptsLegal entities – limitations on security modelBrands – cannot natively cater for extensions around brandProduct and product versions – single product and version per policy typeVariability in these areas affects:User interface (display and input)Data model (both entities and attributes)Business rulesBut only in slight ways
  • Lack of code modularity (code for multiple … all in together), overuse of class enhancements (e.g claim class Lines of Code – 2,450 lines just for claim enhancements)Prolific dispatch code (17 in one class extension alone)Poor or inconsistent error handling and loggingMerge difficulties
  • What could be done Principles (defining what we are trying to achieve – list them here)Architecture (defining the approach that supports the principles – next slide group)Framework (implementing a mechanism to support the architecture, UI and rules being the first areas supported)Multi pronged approachImproved approach to merging (still working on this, the architecture and supporting frameworks should improve this)Architecture Put a structure and definition to what we were trying to achieveOut of box, Base Suncorp, Base Line of Business, ExtensionsThe layered approach diagramFramework (key elements)UI Controller, UI input controller and the factories that create themRule Set and Rules
  • What could be done Principles (defining what we are trying to achieve – list them here)Architecture (defining the approach that supports the principles – next slide group)Framework (implementing a mechanism to support the architecture, UI and rules being the first areas supported)Multi pronged approachImproved approach to merging (still working on this, the architecture and supporting frameworks should improve this)Architecture Put a structure and definition to what we were trying to achieveOut of box, Base Suncorp, Base Line of Business, ExtensionsThe layered approach diagramFramework (key elements)UI Controller, UI input controller and the factories that create themRule Set and Rules
  • This is – a discussion of Suncorp’s experience when we decided a framework was the solution to a set of issues we facedIt is not – a tutorial on how to roll your own frameworkFrameworks – a quick revision, the principal characteristics, types of frameworks, what they do for you – so you know what I mean when I say “framework”The problem – the nature of the domain, vendor product limitations, how we approached it, how we ended up in a mess, and the way we decided to tackle it (intro UI & rules areas here)A solution – The product approach, behave more like a product vendor, better layering, defined out-of-box, base and extension, but still needed a way to make it happenThe frameworks – UI & rules, factories, strategy, singleton(ish), convention, how they change developmentThe challenges – some of the problems we faced, what we solved, what is still to be resolvedConclusion – when you would do it, when you wouldn’t, why this was the right approach for us (followed by questions)
  • What could be done Principles (defining what we are trying to achieve – list them here)Architecture (defining the approach that supports the principles – next slide group)Framework (implementing a mechanism to support the architecture, UI and rules being the first areas supported)Multi pronged approachImproved approach to merging (still working on this, the architecture and supporting frameworks should improve this)Architecture Put a structure and definition to what we were trying to achieveOut of box, Base Suncorp, Base Line of Business, ExtensionsThe layered approach diagramFramework (key elements)UI Controller, UI input controller and the factories that create themRule Set and Rules
  • UI Controller – Abstract class representing an object that controls application page/page component behaviourhas two versions one for when there is no claim context, the other when a claim existsAll pages that contain extension points must have one createdAlso takes care of logging and error handlingThis needs to be subclassedUI Controller contains UI Input – Abstract class representing a field on a page or page componentTypical input controller operations are determine visibility, editability, validation logic, respond to field eventsThis needs to be subclassedCreation – UI controller has factory method (getUIController) that instantiates new and puts in cache or gets existing from cache if already exists.Class constructor adds its UI Input objects that represent the fieldsOnly need to add if default behaviour changes or new field requiredWhen adding new controllers and Inputs must add controllers for default behaviours higher in the package hierarchy (at shared and loss type levels)Benefitpages changed in consistent fashion, once changed they don’t need changing again for the same fieldCode modular, don’t need to contain code for multiple brands or lines of business, easier to testIncreased reuse – inherit default behaviour of shared components, only change where necessary
  • Uses convention to find the class to instantiateclasses are named after the page they control, package hierarchy consistent, class located in the package tree – goes from most specific to least specific, uses the execution context (claim, locale) to determine
  • Two abstract classesRule Set is a container for rules. Executing the rule set causes all the contained rules to be evaluatedRule contains a condition and an action, executed if condition is trueThe rule set sits with in the vendors rule hierarchyBase classes provide consistent handling of logging and errorsAt run time the vendor hierarchy is followed until a rule set is foundThe rule set that is executed is determined by the same convention used for UI Controller using the runtime claim contextBenefitsKeeps rules modular and specific to the business context (no interspersed code)Reuse applies from shared rules classes
  • Someone needs to own the framework – live and breathe it, it can’t be the part-time responsibility of one developerIt needs to be championed amongst the developersStill looking for a full time owner and championDevelopers must have training in its use – can’t just point them at code examples and say off you goTraining material wasn’t completed, author moved on before completeLasagne dropped when taken out of the ovenDevelopers have to have the fundamentals of OO understood. Frameworks make less sense if you don’t understand OO principlesHas led to a change in hiring practice (OO required)Get the vendors buy in early – work directly with their product team if possible - ideally you want the vendor to your your framework into their productLots of to-ing & fro-ing, grudgingly accepted, local services group dislikes immenselySome parts though similar to vendors product directionDon’t underestimate the impact of politics and personalities:Not invented here syndromeCompeting approaches grass roots versus official effort, reconciling approachesResistance from projects outside of where it was pioneered
  • Why would you do it?Business domain has high variabilityApplication does not easily support this variabilityCan’t get agreement to standardise Why would you avoid? Takes you further away from vendor productfuture upgrade path, vendor understands your code lessSkill set of developers not sufficient and not prepared to invest in upskillingAspects could be improvedHeavy reliance on inheritance, prefer to move to an approach supporting compositionQuasi singleton only – language doesn’t support constructs for thread synchronisation (need to check this, also true singleton can’t be subclassed)
  • This is – a discussion of Suncorp’s experience when we decided a framework was the solution to a set of issues we facedIt is not – a tutorial on how to roll your own frameworkFrameworks – a quick revision, the principal characteristics, types of frameworks, what they do for you – so you know what I mean when I say “framework”The problem – the nature of the domain, vendor product limitations, how we approached it, how we ended up in a mess, and the way we decided to tackle it (intro UI & rules areas here)A solution – The product approach, behave more like a product vendor, better layering, defined out-of-box, base and extension, but still needed a way to make it happenThe frameworks – UI & rules, factories, strategy, singleton(ish), convention, how they change developmentThe challenges – some of the problems we faced, what we solved, what is still to be resolvedConclusion – when you would do it, when you wouldn’t, why this was the right approach for us (followed by questions)
  • Provides mechanism to implement standard structure of an application using abstraction to allow developers to provide adaptations for specific functionality at defined places (wikipedia)Characteristics (Fayad & Schmidt)Modularity (encapsulate volatile implementation detail) – hot spots (PREE)Reusability (through stable interfaces)Extensibility (explicit hooks to extend interfaces) – frozen spots (PREE)Inversion of control (framework determines what to invoke rather than the application) (Maven analogy)Whitebox (favours inheritance) vs. Blackbox (favours composition) (PARSONS)PositivesLeverage developer pattern knowledgeImprove reuse, reduce cost and improve quality (PARSONS)NegativesRely heavily on pattern knowledgeGenerally have steep learning curveGenerally less efficient
  • Provides mechanism to implement standard structure of an application using abstraction to allow developers to provide adaptations for specific functionality at defined places (wikipedia)Characteristics (Fayad & Schmidt)Modularity (encapsulate volatile implementation detail) – hot spots (PREE)Reusability (through stable interfaces)Extensibility (explicit hooks to extend interfaces) – frozen spots (PREE)Inversion of control (framework determines what to invoke rather than the application) (Maven analogy)Whitebox (favours inheritance) vs. Blackbox (favours composition) (PARSONS)PositivesLeverage developer pattern knowledgeImprove reuse, reduce cost and improve quality (PARSONS)NegativesRely heavily on pattern knowledgeGenerally have steep learning curveGenerally less efficient
  • Provides mechanism to implement standard structure of an application using abstraction to allow developers to provide adaptations for specific functionality at defined places (wikipedia)Characteristics (Fayad & Schmidt)Modularity (encapsulate volatile implementation detail) – hot spots (PREE)Reusability (through stable interfaces)Extensibility (explicit hooks to extend interfaces) – frozen spots (PREE)Inversion of control (framework determines what to invoke rather than the application) (Maven analogy)Whitebox (favours inheritance) vs. Blackbox (favours composition) (PARSONS)PositivesLeverage developer pattern knowledgeImprove reuse, reduce cost and improve quality (PARSONS)NegativesRely heavily on pattern knowledgeGenerally have steep learning curveGenerally less efficient
  • The vendors product is an application framework and accompanying development language that has been focused onto solving problems in the insurance domain.PCF – XML definition of a page layoutPre-defined and user defined events Event driven rules developed using vendors language that fit in a partially defined hierarchyUtility classes developed using vendors languagePersistence layer defined in XML files that auto generates database after changesProvides web service based access through auto generated core entity API classesOutbound “plug-in” architecture provides interface plus default implementation to access required functions expected to be provided by external systemsThis is all very good and flexible so why do we still run into problems?
  • The vendors product is an application framework and accompanying development language that has been focused onto solving problems in the insurance domain.PCF – XML definition of a page layoutPre-defined and user defined events Event driven rules developed using vendors language that fit in a partially defined hierarchyUtility classes developed using vendors languagePersistence layer defined in XML files that auto generates database after changesProvides web service based access through auto generated core entity API classesOutbound “plug-in” architecture provides interface plus default implementation to access required functions expected to be provided by external systemsThis is all very good and flexible so why do we still run into problems?
  • The vendors product is an application framework and accompanying development language that has been focused onto solving problems in the insurance domain.PCF – XML definition of a page layoutPre-defined and user defined events Event driven rules developed using vendors language that fit in a partially defined hierarchyUtility classes developed using vendors languagePersistence layer defined in XML files that auto generates database after changesProvides web service based access through auto generated core entity API classesOutbound “plug-in” architecture provides interface plus default implementation to access required functions expected to be provided by external systemsThis is all very good and flexible so why do we still run into problems?

Transcript

  • 1. Turning spaghetti into lasagne Applying the principles of application frameworks to packaged applications James Couzens Solution Architect, Suncorp JAOO Conference, 2009
  • 2. What I will be talking about today  
  • 3. Overview Frameworks – common understanding The problem space – organisational, package Our solution – architecture and framework Challenges – what to watch out for Conclusions – why consider it
  • 4. What is meant by “application framework” Implement standard structure of an application using abstraction Provide adaptations for specific functionality at defined places 4
  • 5. Application framework characteristics Modular Reusable Inversion of control Extensible White box vs. Black box 5
  • 6. Framework pros & cons Pros Improve Leverage Cons Rely on Learning Efficiency 6
  • 7. Vendor application characteristics XML web page definitions <?xml version=quot;1.0quot;?> <PCF xmlns:xsi=quot;http://www.w3.org/2001/ XMLSchema-instancequot; xsi:noNamespaceSchemaLocation= quot;../../../schema/pcf.xsdquot;> <DetailViewPanel id=quot;LossDetailsDVquot; mode=quot;Prquot;> ... ... <PanelRef def=quot;ClaimSummaryMattersLV(Claim.Matters, Claim)quot; visible=quot;perm.Matter.view(Claim) and perm.System.viewmattersquot;> <TitleBar title=quot;displaykey.Web.ClaimSummary.MattersLV.Titlequot;/> <Toolbar/> </PanelRef> 7
  • 8. Vendor application characteristics Rule engine with pre-defined rule sets 8
  • 9. Vendor application characteristics Pre-defined events - ClaimAdded - ClaimChanged - ClaimRemoved User-defined events - Add events (add, change, remove) to user defined entities 9
  • 10. Vendor application characteristics XML persistence layer <!-- Extension to claim table --> <extension entityName=quot;Claimquot;> <column desc=quot;True anyone living in the propertyquot; name=quot;SC_PermanentOccupancyquot; nullok=quot;truequot; type=quot;bitquot;/> <column desc=quot;number of days Property Vacantquot; name=quot;SC_DaysPropertyVacantquot; nullok=quot;truequot; type=quot;integerquot;/> <column desc=quot;number of damaged unitsquot; + inbound web services name=quot;SC_NoDamagedUnitsquot; + integration plug-ins nullok=quot;truequot; + OO configuration language type=quot;integerquot;/> ... ... 10
  • 11. Vendor application characteristics XML web page definitions <?xml version=quot;1.0quot;?> <PCF xmlns:xsi=quot;http://www.w3.org/2001/XMLSchema-instancequot; xsi:noNamespaceSchemaLocation=quot;../../../schema/pcf.xsdquot;> <DetailViewPanel id=quot;LossDetailsDVquot; mode=quot;Prquot;> With all this why do I still Rule engine with run into pre-defined rule problems sets Pre-defined and user-defined events - ClaimAdded - ClaimChanged - ClaimRemoved XML persistence layer + inbound web services + integration plug-ins <extension entityName=quot;Userquot;> <column + OO configuration language name=quot;OffsetStatsUpdateTimequot; type=quot;datetimequot;/> <column name=quot;NewlyAssignedActivitiesquot; type=quot;integerquot;/> <column 11
  • 12. Business structure – growth by merger Companies Vendor application has limited multi-company capability 12
  • 13. Business structure – joint ventures Limited multi-company capability 13
  • 14. Business structure - brands No concept of brand 14
  • 15. Business structure – products, versions, systems + over 100 products + multiple versions per product + multiple legacy systems … and so on 15
  • 16. Implications of variability Data model UI Rules: if (brand==quot;ampquot; or brand==quot;gioquot; or brand==quot;suncorpquot;) { ... } else if (this.isRACQIBrand()) { ... } return false } 16
  • 17. The result is code spaghetti Code lacks modularity Prolific dispatch code Inconsistent logging, error handling Problems with merging Oh no! What are we going to do? 17
  • 18. Goals and principles Standardise business process • Prefer OOB over customised • Maintain upgrade path • Ease of maintenance • Minimise duplication • Maximise reuse • Entity awareness • ……… • 18
  • 19. Architectural model 19
  • 20. Framework to support the model Initially focussing on UI variations and rules 20
  • 21. Application framework – the use interface controller <<abstract>> <<abstract>> UIController UIInput * +createUIObject() +visible() +applyRule() +editable() +validation() + ... Subclass this level if no claim context <<abstract>> <<abstract>> PageController FieldInput UIControllerClaim UIInputClaim +initUIInputs() PageController FieldInput * Subclass this level if have claim context 21
  • 22. Application framework – UI example LossDetailsDV.Pr.pcf <TypeKeyInput editable=quot;Claim.isEditable_IDRStatus()quot; ... /> CORE_ClaimUIExt.gs function isEditable_IDRStatus():boolean { ... if (brand==“brand1quot;) { do something for this brand } else if (brand==“brand2” { do something for brand2 } else if (brand==“brand3quot; ) { do something for brand3 } else return a default value } 22
  • 23. Application framework – UI example Add a UI controller variable to the page: Page <variable name = “UI” initialValue= configuration 1 shared.base.UIController.createUIObject(“PCFName”)> file (PCF) 2 4 Controller creates UI input classes for that page: 3 Input classes implement context specific logic , i.e. function isEditable ():boolean { return something for context } <Input id=”IDRStatus”... Editable=UI.applyRule(“IDRStatus”). isEditable> 23
  • 24. Application framework – run time context Suncorp Motor user locale PageCtlr PageCtlr Product Motor PageCtlr Shared Base claim PageCtlr 24
  • 25. Application framework – rules and rule sets <<abstract>> <<abstract>> RuleSet Rule * +execute() +name +condition() +action() All rules run in the context of a claim so no need for claim level abstract class ConcreteRuleSet ConcreteRule * Triggered by the same events as OOB rules. Key Points: • 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 • 25
  • 26. The challenges of this type of approach 1. Politics and personality 2. Getting vendor buy-in James’ top ten list of 3. Ensuring the right underlying skills challenges 4. Making sure training is sufficient when 5. Framework champions implementing a framework 6. Framework ownership on top of a 7. Building a framework Agile packaged 8. Assessing impact on upgrades application 9. Understanding the vendor’s framework 10. Understanding the business variability 26
  • 27. Concluding remarks Business domain variability Unable to standardise Not supported well by application Moves away from vendor product May require up-skilling 27
  • 28. 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
  • 29. Pick me, pick me