Benefits of a Reusable Application Framework Aaron Mulder

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 August 2003 Copyright © 2003 - Chariot Solutions 2

About Aaron Mulder • Chief Technical Officer of Chariot Solutions • Published author (Professional EJB, BEA Web. Logic 7. 0 Application Server Deployment and Administration Handbook) • Presented at Java. One 2001 -2003, and the Philadelphia Java & BEA Users Groups • Member of the JSR-88 Expert Group (J 2 EE Application Deployment) • Contributed to open-source projects such as Geronimo, JBoss, Open. EJB, and Postgre. SQL August 2003 Copyright © 2003 - Chariot Solutions 3

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 Exxon. Mobil, Midas, Rosenbluth International, UGI Utilities, and the State of New Jersey August 2003 Copyright © 2003 - Chariot Solutions 4

Introduction to Frameworks

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 August 2003 Copyright © 2003 - Chariot Solutions 6

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 August 2003 Copyright © 2003 - Chariot Solutions 7

Application Design Issues

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

20 Elements, Part I • • • August 2003 Persistence Key Generation Database Access Resource Access Inter-tier communication • • • Concurrency Logging Auditing Transactions Error Handling Copyright © 2003 - Chariot Solutions 10

20 Elements, Part II • • • August 2003 User Messages Formatting Rules Data Validation Security User Management • Scheduling & Workflow • Reporting • System Setup • Application Integration • Static Data Copyright © 2003 - Chariot Solutions 11

Development Infrastructure

Tools • • August 2003 IDE (many support a plugin architecture) Build scripts, directory structure Code generators Source code control Bug tracking Time tracking How much integration is appropriate? Copyright © 2003 - Chariot Solutions 13

Testing • Unit testing • Automated testing (load, regression, etc. ) • Testing Issues: – Login – Data prep & cleanup – Test dependencies – Testing server components August 2003 Copyright © 2003 - Chariot Solutions 14

Documentation • • • August 2003 Team web site Code standards & templates Configuration information (tools, server, . . . ) Use cases, models & specs Test plans Will documents be under source code control? (HTML, Doc. Book vs. MS Word) Copyright © 2003 - Chariot Solutions 15

Benefits of a Framework

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 August 2003 Copyright © 2003 - Chariot Solutions 17

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 August 2003 Copyright © 2003 - Chariot Solutions 18

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 August 2003 Copyright © 2003 - Chariot Solutions 19

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 August 2003 Copyright © 2003 - Chariot Solutions 20

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 August 2003 Copyright © 2003 - Chariot Solutions 21

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 of the blue, 30 applications now fail unless they’re also upgraded August 2003 Copyright © 2003 - Chariot Solutions 22

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 August 2003 Copyright © 2003 - Chariot Solutions 23

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 August 2003 Copyright © 2003 - Chariot Solutions 24

App Development Profile Starting from scratch Using a framework Application Development Infrastructure Development Application Development Infrastructure Dev. MONTHS August 2003 MONTHS Copyright © 2003 - Chariot Solutions 25

Case Study

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 100 s of customers = no organized testing August 2003 Copyright © 2003 - Chariot Solutions 27

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 August 2003 Copyright © 2003 - Chariot Solutions 28

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 August 2003 Copyright © 2003 - Chariot Solutions 29

Creating a Framework

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? August 2003 Copyright © 2003 - Chariot Solutions 31

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? August 2003 Copyright © 2003 - Chariot Solutions 32

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 – Overview of features, code documentation, tutorials, sample code, before & after, etc. • Define interfaces for everything • Eliminate dependencies where possible August 2003 Copyright © 2003 - Chariot Solutions 33

Questions?

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