J2EE applications almost always require some common "plumbing," often referred to as application infrastructure. A J2EE application development framework provides reusable code to solve many of these common Web application infrastructure issues, letting the development team focus on the business logic. The purpose of this article is to demonstrate the value such a framework offers and how to calculate a return on investment (ROI) on your framework investment. I'll provide the pros and cons of buying a framework, building your own framework, and using an open source framework. I'll also outline a framework development and management process that can improve your ROI.

What is a framework?
The following are two commonly used definitions of a framework:

• "A framework is a partially complete software system that is intended to be instantiated. It defines the architecture for a family of systems and provides the basic building blocks to create them. It also defines the places were adaptations for specific functionality should be made." (Buschmann 1996)
• "A framework is a set of classes that embodies an abstract design for solutions to a family of related problems." (Johnson and Foote 1988)

• Shorter development schedule/shorter time to market: Development projects no longer have to solve the many problems related to Web applications. They simply reuse the code provided by the framework. Project developers don't have to design, develop, or test these framework services; they take them for granted.
• Reduced development risk: With a complex programming model like J2EE, the risk of project failure is high to begin with. An application development framework can significantly reduce the risk by serving as a reliable proven base.
• Consistent application architectures: Using a framework results in all applications having similar application architectures, which makes them easier to learn, support, and maintain.

Table 1: Different approaches -- The pros and cons of buying a framework, building it, or adopting an open source framework.
	Pros	Cons
Buy	1. Good documentation available 2. Hardened 3. High quality 4. Good support available 5. You save time	1. It's rare to find a framework that meets all your framework requirements 2. Many commercially available frameworks are too heavy and are overkill for many situations 3. Steep learning curve 4. Require vendor resources to mentor developers 5. Depend on vendor for upgrades/new features 6. Expensive 7. Upgrades typically costly, increasing total cost of ownership (TCO)
Build	1. Build to your exact requirements -- i.e. you get exactly what you need	1. More time and high skill resources required to design, develop, test, support, and maintain 2. Requires repeated use to harden and fine-tune 3. Requires significant testing and quality assurance activities 4. Documentation usually first to suffer if schedule slips
Open source	1. Cheap 2. Low TCO 3. Typically reliable and stable because of large contributor and user base	1. Typically lightweight framework 2. High learning curve 3. Requires you to evaluate quality before selecting a particular open source software component 4. Depending on release, may not be hardened

1. Initial development: This is your upfront development effort to get to the first release of your framework.
2. First use: The first application you build with the framework.
3. Harvesting framework candidates: When you build an application, there will be elements you expect to be part of the framework that aren't there; you'll end up building these. It makes sense to move these into the framework so applications that follow can benefit. At the end of every application development effort, you should undertake a formal process to harvest framework candidates. You'll have to make sure the component candidate isn't business-specific; these generally aren't reusable.
4. Second use: The next application you build will use the framework plus any components harvested from the previous application.
5. Harvesting framework candidates: Again, a formal process for harvesting framework component candidates keeps the framework in a good position to meet the needs of future application development efforts.
6. Next use: And so on ...

Figure 1: The framework development process -- This includes the harvesting of framework candidates after each use.

• S: Savings per year.
• N: The number of framework-based application development projects anticipated per year.
• C1: Estimated average cost to design, develop, and test custom framework-like plumbing per application (i.e., code you expect a framework to provide).
• C2: Yearly cost to support and maintain custom framework-like plumbing per application.
• F2: Yearly cost to support and maintain a framework per application that uses it.