The existence of the framework, particularly the existence of the standard interfaces, allows you to mix, match, and add reusable components at will. Using such a development philosophy, adapting to unique application requirements may simply be a matter of adding yet another flavor of a particular type of item to your inventory of possible choices.

Keep it simple
One of the best ways to make such an environment easily extensible is to be sure to always keep things simple. There was a time when such code widgets were referred to as "atomic" elements, based on the idea that the atom was the lowest level of a complex structure currently known. Atomic elements generally do one thing, and their interface specification usually only involves a single method. Some developers look at that and wonder why even bother with such an obviously simplistic piece of code, but it is the simple nature of such easily identifiable and understandable components that makes things work so well in a shared environment.

For example, in the area of authorization, there are a number of strategies floating around for authorization methodologies. Some are based on specific user IDs, some are based on user groups, and the current trend is to base authorization on a user's role, or job function. If you look at code examples, you can see method names like isUserInRole(roleName) or isMemberOfGroup(groupName). These are interesting approaches, but if you really get down to the fundamental question, it isn't really about a user's job function or group affiliation.

The question that you really want to know is simply this: is this user authorized for this item? By creating a simple interface with a sole method such as isAuthorized(resourceName), the implementing classes can utilize whatever the current fad happens to be in regards to authorization methodologies, and the applications are insulated from these choices. Our navigation filter, from the previous example, simply needs to call the isAuthorized()method for every menu option delivered by the retriever, keeping those that are authorized and discarding those that are not. The underlying implementation that made the authorization determination is really of no concern to the filter; the filter merely utilizes whatever authorizer has been configured for the current implementation.

Start small; grow fast
Once you make the decision to create an extensible application framework, there is a certain amount of work involved in getting all of the pieces to play nice together for the first time. But once you overcome those initial obstacles and have one or two systems under your belt, things really start to take off. Every time you take on an application development project, you have the opportunity to either reuse an existing component or add another reusable component to your library. Either one of these options will increase your productivity; with an increase in productivity comes additional opportunity to further increase your productivity. The process just starts to build upon itself. The words of Sun Tzu, recorded over 2500 years ago in his Art of War, definitely apply to developing software based on a common framework: "Opportunities multiply as they are seized."

Jeff Chilton is Vice President of Fulfillment at Echo Technology Group, Inc., an IT consulting firm that specializes in enterprise-focused best practices. Visit http://www.teametg.com for more information or email him at jchilton@teametg.com.