Developing a Common Corporate Framework for your Java Applications

In today's market, application development teams are often asked to complete applications in time frames shorter than ever before, with fewer resources, and at lower cost. This high pressure, fast-paced environment can open a door to poorly designed and implemented applications that are difficult to support and maintain. When a project has a tight schedule, one of the first practices to be jettisoned is the notion of code reuse. It is a common view that making code reusable, while important strategically, will slow down development on the current project. If this practice becomes standard throughout a company, what you end up with is a family of corporate applications that have no common infrastructure, no common design elements, multiple styles of coding and design, and hundreds of instances of solving the same set of problems repeatedly.

In any large corporation, it's very common for developers to move across development organizations and teams throughout their career with that corporation. It is often the case that each of these moves necessitates learning a new development model and framework. In most large companies, different development groups tend to have their own development styles and preferred components and frameworks.

Within Java enterprise applications, a large percentage of the code written is common across applications. Nearly every enterprise application requires common services such as security, persistence, logging, a presentation framework and configuration support. These common services can be written once and combined into an application framework which can be reused by all your projects. When there is not a common framework being used, thousands of hours of work and countless dollars are being spent in rewriting common functionality from scratch for each application. In addition to providing the common services for your applications, frameworks can drive your applications to use more object oriented principles and design patterns.

Within a corporation with a large development team, you have a captive audience and an excellent environment for achieving reuse at many levels including source code, design, and architectural reuse. One of the quickest and most strategic ways to move towards an environment of code reuse and increased collaboration is to support and enforce a common corporate framework for all of an organization's applications. A common framework can provide increased developer productivity, consistent quality across applications, rapid adaptability, and a shorter developer learning curve.


The Framework: Build or Buy?
So once you've decided that a corporate framework sounds like a pretty good idea, the next decision you'll have to make is, is this something I can just buy, or will this require a development team to create? Let's consider both options, followed by a recommendation.

There are certainly plenty of frameworks available off-the-shelf. These include both commercial and open-source products. One problem I see with just pulling one of these frameworks and declaring it your corporate framework is that each company has unique constraints, infrastructure, and policies which can not be completely accounted for in any given off-the-shelf framework.

Going to the other end of the spectrum, it doesn't make much sense to build your framework from the ground-up either. This ignores too many good solutions which are very reusable. After all, reusability is what we are trying to achieve, so let's start with the framework. Do not reinvent quality open source frameworks. Some larger companies may have an aversion to open source software, but in the area of frameworks, you need to get past that. There is simply too much high quality code available for use in commercial applications to ignore. Java is somewhat unique in that it has a very vibrant open-source community that has created many high-quality components and frameworks. This is a fantastic thing for Java developers and companies that do Java development. Many large companies fail to take advantage of this resource. These companies suffer from the "we must create it in-house or pay for it" syndrome. Interestingly enough, when they realize that almost everyone else is using a particular open source component, i.e. Struts, then suddenly the large company says "I guess it must be okay for me to use that too."

The development of a corporate framework is one area where I would specifically recommend against using a commercial product, especially one for which you do not have access to the source code. What goes into your framework will hopefully become the basis for all of your other enterprise applications. Do you really want to trust this to a commercial vendor for which you don't even have source code? Often you'll find that after you've used the framework on several projects, you'll want to extend or perhaps modify the framework. If you chose a commercial framework, your options for extending and/or changing the framework are very limited. Clearly, framework development is an area where the use of open source components makes more sense.

So what am I recommending? I've said not to buy, but should you simply use open source frameworks, or should you build your own? My answer to that question is to use open source frameworks and components to solve generic problems, thinks like logging, auditing, security, persistence, etc. Layer these with your own code to solve company specific problems.  There are some great open source frameworks out there, such as Spring and Hibernate, to name a couple, and its silly to ignore this high quality content to build from scratch.

Another word of caution here, a common mistake that I've seen large companies do is to implement a framework based on the current vendor technologies that are being used. While I agree with tailoring a corporate framework to a company's environment and usage patterns, I believe that tying it to current vendor specific technologies is going too far. For example, if Oracle is your current vendor of choice for database, don't create your framework assuming Oracle to always be there.

Ultimately, you'll be asked by a manager to justify the time and money spent on creating a common application framework. Determining the ROI for a common application framework is out-of-scope for this article, so I'll only mention it briefly. When calculating ROI, you need to think about the time saved in developing all this common functionality in each of your applications, the reduced testing time, as well as savings in training, and maintenance. When you take all these things into account, the value of a common application framework should not be a difficult argument to make.


Creating the Framework
When you think of Java frameworks available today, do you think of one or two commercial vendors? Or do the open source frameworks come to mind first? I'm certain the great majority of readers will say the latter. This is because framework development today is heavily dominated by the open source community. There are several reasons why framework development has been so successful in the open source community.

In a May, 2004, report from Forrester Research, Liz Barnett states "Corporate Development Can Learn from Open Source Development." She goes on to say state that while less than a third of corporate projects finish on time, on budget and within scope, open source development projects are winning worldwide renown for their development models. Certainly corporate development groups should be taking a hard look at what is going on in the open source community and understanding how they are being so successful.

Communication is one of the things which make open source projects successful. This is also where I've seen companies fail when trying to development internal frameworks. The company will create a central team of developers to go off and work on a framework with little communication with the customer (the other development teams) at all. No matter how experienced and smart the developers you choose to create this framework are, if they do not have a clear two-way communication channel with the rest of the corporate development teams, they are bound to fail. Taking this a step further, you should consider allowing members of other development groups to participate in the framework development. Developers who are interested in contributing could apply for committer status on the project, enabling them to make changes and contribute development tasks to the framework project. Consider hosting a collaboration server for the framework using something like gForge (www.gforge.org). This will give you a front-end to the project very similar to what you see with SourceForge hosted projects.

Don't make your development process a closed, tight-lipped project, be sure to schedule open peer reviews inviting developers who have a future stake in using your framework. Don’t wait until you have a complete framework developed before making releases. "Release software early and often," is a tenant of both the agile development community and the open source community.

Properly architected frameworks should provide extensibility both above and below the framework. Here is what I mean by this, the framework should expose public APIs, which you can use to extend the framework and build out the logic of your application. Also, the framework should use Interfaces at its lowest level that can be implemented to provide plugability underneath the framework. These points of extensibility will provide maximum adaptability to your particular environment and projects. In the end, your goal is to create an extensible, vendor-independent framework that you can use across your Java development projects. The framework will increase quality, and productivity while lowering cost and shortening time-to-market for all of your projects.

A problem with many of today's frameworks is that they have grown very bloated. This makes the framework more complex and greatly increases the learning curve for it. If you want your framework to implement functionality in lots of areas, do it in such a way that you maintain separate modules which can be used independently, so that the user's do not have to use your framework in an all-or-nothing fashion. Developers are daunted by a huge framework which they must take all of, or none of. An applicable saying here is "Don't make them swallow the whole elephant." This is why it's important to understand the concept of components when you're designing a framework for corporate use. A framework consisting of many components will be much more useful than one large framework that is not easily divisible.

The best frameworks are born out of necessity. A development group might look across several applications they have developed and realize that a sizable portion of the functionality can be abstracted and generalized into an independent application framework. The opposite path to framework development, conceiving the framework independent of concrete application needs and requirements, is much less likely to result in a successful framework that solves your company's problems.


Deploying the Framework
Don't develop a framework, throw it up on a website, and expect your development teams to swarm to it, and instantly be happy for creating this great framework for them. Think of your internal development teams as your customers, and thus market your framework to them using appropriate strategies. Just as with a commercial product, marketing, education, and communication about your framework will be key to its success.

Frameworks do not gain acceptance through a push model. This is the model where a centralized team is developing the framework and trying to push it down on the other development groups while saying, "Here, use this, it will solve all your problems and assure that you develop company approved applications." The only successful way in which frameworks will truly be adopted is if you allow it to happen through a pull model. You should create enough interest and excitement in the framework so that development teams are requesting the framework themselves.

Always include a sample application with your framework. For example, many of the open source frameworks include a modified version of the Java Pet Store application that showcases the framework's use. The Java Pet Store application was originally developed by Sun to showcase general J2EE coding practices and styles. This can be a critical component as to whether your framework is successful or ultimately fails.


Growing the Framework
The development of a framework should not be a typical project with a defined end date where once deployed, the development team moves on to other projects. The framework should be thought of as an ongoing project that requires support, and development staff.

Create a process whereby development teams can propose additions to the framework. When reviewing the proposed additions, make sure they are not things that would be specific to only a small number of applications. To qualify for inclusion in the framework, the addition has to have broad applicability across the company's projects.

Going a step further, a common framework can be part of a larger effort of providing a center for Java excellence. Sun has a program in which they assist large companies in establishing a Java Center of Excellence (JCOE). The JCOE establishes a centralized knowledge base for Java technology within your company. The JCOE should support all software development groups in your company through training, mentoring, architectural review, best practices, framework development, and establishing company-wide development patterns. The JCOE can also establish a knowledge base of project artifacts which can be reviewed by other project teams.


Wrapup
I firmly believe that the greatest area for process improvement within large organizations is in the area of collaboration and enhanced communication. Establishing a common corporate framework for your applications is a step towards a more collaborative development environment within your organization. As a summary, I've created the table below to highlight some of the benefits of a common corporate framework.



Benefits of Using a Common Application Framework

Shorter development cycles	Many common tasks will already be implemented and tested within the framework, saving you effort on all other projects. Sun reports an average of 40% faster development cycle through reuse.
Consistent higher quality	By assuring the quality of your single framework codebase, you ensure consistent higher quality across your enterprise applications
Shorter project learning curve	Since each of your projects will share a common framework, developers moving from project to project will have an easier time learning each new project.
Consistent application architecture	Using a common framework will result in all of your applications having a similar architecture, making them easier to learn, support, and maintain.
Reduced risk	Core technologies will be reused, thus eliminating significant risk of having to develop these from scratch.