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

Benefits of a Reusable Application Framework

Aaron Mulder, Chariot Solutions

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


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


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

Introduction to Frameworks


What’s in a Framework?

• Knowledge baseProduct reviews, configuration information, lessons learned

• Document templatesRequirements, Use Cases, Design Specs, Test Plans, etc.

• Design patterns, standardsCoding & naming standards, proven design strategies, etc.

• Code librariesBase classes, format utilities, tag libraries, etc.

• Code templates and generatorsAutomated generation of starting code, based on templates


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

Application Design Issues


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.


20 Elements, Part I

• Persistence• Key Generation• Database Access• Resource Access• Inter-tier

communication

• Concurrency• Logging• Auditing• Transactions• Error Handling


20 Elements, Part II

• User Messages• Formatting Rules• Data Validation• Security• User Management

• Scheduling & Workflow

• Reporting• System Setup• Application

Integration• Static Data

Development Infrastructure


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?


Testing

• Unit testing• Automated testing (load, regression, etc.)• Testing Issues:

– Login– Data prep & cleanup– Test dependencies– Testing server components


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)

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


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


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


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


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


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


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


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


App Development Profile

0%

20%

40%

60%

80%

100%

0 1 2 3 4 5 6

Application Development

0%

20%

40%

60%

80%

100%

0 1 2 3 4 5 6

Application Development

Infrastructure Development Infrastructure Dev.

Starting from scratch Using a framework

MONTHS MONTHS

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 100s of customers = no organized testing


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


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

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?


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?


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

Questions?

Download Slides:

http://www.chariotsolutions.com/presentations.html

Presentation Feedback:

http://www.chariotsolutions.com/feedback.html

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

Documents