Benefits of a Reusable Application Framework

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