1 / 35

Benefits of a Reusable Application Framework

Benefits of a Reusable Application Framework. Aaron Mulder, Chariot Solutions. Today, we’ll discuss…. What we mean by framework Elements of a strong application framework Including project infrastructure in the framework Benefits of a framework Creating and maintaining a framework.

spam
Download Presentation

Benefits of a Reusable Application Framework

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Benefits of a Reusable Application Framework Aaron Mulder, Chariot Solutions

  2. Today, we’ll discuss… • What we mean by framework • Elements of a strong application framework • Including project infrastructure in the framework • Benefits of a framework • Creating and maintaining a framework

  3. About Aaron Mulder • Chief Technical Officer of Chariot Solutions • Published author (Professional EJB, BEA WebLogic 7.0 Application Server Deployment and Administration Handbook) • Presented at JavaOne 2001-2003, and the Philadelphia Java & BEA Users Groups • Member of the JSR-88 Expert Group (J2EE Application Deployment) • Contributed to open-source projects such as Geronimo, JBoss, OpenEJB, and PostgreSQL

  4. About Chariot Solutions • Information Technology provider focused on automating business processes • Team of leading Java architects on staff • Technical expertise in software architecture and development, and systems integration • Proven track record with companies such as ExxonMobil, Midas, Rosenbluth International, UGI Utilities, and the State of New Jersey

  5. Introduction to Frameworks

  6. What’s in a Framework? • Knowledge base Product reviews, configuration information, lessons learned • Document templates Requirements, Use Cases, Design Specs, Test Plans, etc. • Design patterns, standards Coding & naming standards, proven design strategies, etc. • Code libraries Base classes, format utilities, tag libraries, etc. • Code templates and generators Automated generation of starting code, based on templates

  7. Can I Buy a Framework? • Every framework should be different • It must meet your top needs first • Individual features must offer implementation options that your applications require • Your project teams must be on board with it • You will need to maintain it • Often too much is worse than none at all • That said… every element need not be developed in-house

  8. Application Design Issues

  9. Application Framework Elements • Common to many applications • Reusable across most projects • Solvable in more than one way The 20 application design issues which follow were chosen because they are: There are more questions than answers. Every team's needs are different, and every framework will be different.

  10. Persistence Key Generation Database Access Resource Access Inter-tier communication Concurrency Logging Auditing Transactions Error Handling 20 Elements, Part I

  11. User Messages Formatting Rules Data Validation Security User Management Scheduling & Workflow Reporting System Setup Application Integration Static Data 20 Elements, Part II

  12. Development Infrastructure

  13. Tools • IDE (many support a plugin architecture) • Build scripts, directory structure • Code generators • Source code control • Bug tracking • Time tracking • How much integration is appropriate?

  14. Testing • Unit testing • Automated testing (load, regression, etc.) • Testing Issues: • Login • Data prep & cleanup • Test dependencies • Testing server components

  15. Documentation • Team web site • Code standards & templates • Configuration information (tools, server, ...) • Use cases, models & specs • Test plans • Will documents be under source code control? (HTML, DocBook vs. MS Word)

  16. Benefits of a Framework

  17. High-Level Benefits • Don’t write the same code twice • Don’t do the same thing slightly differently in every application • Don’t test the same code twice • Take advantage of advanced features “for free” • Partition different layers of the infrastructure • Cut down on redundant data entry • Integrate separate applications

  18. Pitfalls: Duplicating Code • Code is “cut & paste” into a different application, then customized • Bugs are introduced when adjustments are missed • May waste time “carving out” the code • Now have 2 copies to maintain, neither of which have “the big picture” • Best fit for app #1 may not be such a good fit for app #2, because portability wasn’t a goal

  19. Pitfalls: Different Implementations • Everything looks the same, but works slightly differently (introducing bugs, etc.) • Usage & techniques from one app cause problems in another • What was easy in one app may not be easy in another, wasting time on bad designs • Changes to business/regulatory requirements must be handled in every application • Tests don’t transfer easily

  20. Pitfalls: No Reusable Tests • Tests are time-consuming to prepare, particularly for validated applications • It often takes time (as problems are uncovered) for a test to reach full coverage • Some features may be dropped from scope due to difficulty in testing them • Tests and documentation often drift out of sync with the application code

  21. Pitfalls: Few Advanced Features • Every project must find budget for every feature • Compromises are made based on time and budget constraints • More features are “hard-wired” to the application • When new business or regulatory requirements come along, custom code must be upgraded manually

  22. Pitfalls: Tightly-Coupled Infrastructure • Let’s say you have a massive Documentum system… • …and you have 30 applications, each with a custom Documentum interface • Now you need to upgrade Documentum, and you budget for the upgrade and data conversion • But out of the blue, 30 applications now fail unless they’re also upgraded

  23. Pitfalls: Redundant Data Entry • Often similar information is stored in several applications • It’s not that users are lazy… they’re often focused on a task and don’t see the big picture • Now different applications hold different data, and it may not be easy to tell “which is right” • Ultimately, problems crop up later, perhaps in unexpected places

  24. Pitfalls: No Application Integration • Every time integration is needed, it’s solved with a new one-off solution • To save time, one-off solutions may try to build on other one-off solutions (square peg / round hole syndrome) • No standard security, request priorities, management, transport, etc. • Some apps may not even know what’s “integrating” with them

  25. App Development Profile Starting from scratch Using a framework Application Development Application Development Infrastructure Development Infrastructure Dev. MONTHS MONTHS

  26. Case Study

  27. Case Study: Before • Company had 3 mission-critical applications, all developed separately by separate departments • Each application had similar “technology layers” from different development eras • Customers called for integration and/or new & different features, got one-off solutions • 3 apps x 5 versions x 100s of customers = no organized testing

  28. Case Study: The Framework • Created a single loosely-coupled integration platform for all application, customer, partner, & vendor contacts • Included an application framework supporting configuration instead of extension • (Gradually) implemented a single “enterprise data store” to replace the siloed applications • (Gradually) modernized the entire application codebase

  29. Case Study: After • Testing processes improved dramatically (improved coverage, more types of testing, possible to full test every deployment) • Customer responsiveness improved across the board (setup, call center, integration requests) • New business opportunities appeared (customers who wouldn’t buy “the big upgrade” would buy a menu of configurable features) • Next step: a unified portal

  30. Creating a Framework

  31. Building a Framework • Use a pilot project • Develop with framework in mind • Extract framework at end of project • Build collaboratively across projects • How do we synchronize framework(s)? • Use a dedicated framework team • What order are issues addressed in? • What happens to trial & error?

  32. Maintaining a Framework • Do we use separate source code control for the framework? • Does every project get a source-level copy? • How are changes propagated back? • Should a project expect updates? (Will the framework commit to backward compatibility?) • Can we compartmentalize the framework? • What is the process for incompatible changes? • When is vendor dependence OK?

  33. Distributing a Framework • Need to get buy-in from developers who are supposed to use the framework • Best to involve all groups in the planning • Implement some key time-saving features to make the benefits obvious • Document, document, document • Overview of features, code documentation, tutorials, sample code, before & after, etc. • Define interfaces for everything • Eliminate dependencies where possible

  34. Questions?

  35. Download Slides: http://www.chariotsolutions.com/presentations.html Presentation Feedback: http://www.chariotsolutions.com/feedback.html

More Related