Here is just a partial list of the kinds of things that are fundamental to most application systems:

• Authentication;
• Authorization;
• Navigation;
• Configuration;
• Logging;
• Event management;
• User profile maintenance;
• User/security administration;
• Notification;
• Self registration;
• Password management (restoration, reset, expiration, etc.);
• Help and tutorial facilities.

This list is virtually unlimited, and as an organization begins to think in terms of a common applications architecture, the things that are automatically provided as a portion of the base application software begin to grow and transform. One of the reasons for that phenomenon is the dramatic effect that code sharing has on the cost justification calculations. When code is specific to a single application, the cost to add a particular feature is often more than the potential value that feature has to offer, so the decision is usually made not to include it. If, however, you are talking about modifying code that is common to tens or hundreds of application systems, suddenly the cumulative effect of the potential benefits across all of those systems far exceeds the cost of the modification and it is well worth the effort to proceed. You end up with better, more robust, and feature rich software because it is worth it to invest the time in making it so.

What about the exceptions?
Although there are not nearly as many exceptions as certain parties would have you believe, there are certainly those circumstances in which someone needs something that just doesn't quite fit with the universal approach that an organization has chosen. That having been said, this is certainly no reason to abandon the idea of a universal framework. The beauty of inheritance is that you can either accept the ancestral code as is, or you can override it. The trick is to set things up in such a way that things will work, either way you go.

Take for example the feature of navigation. Virtually all application systems have some form of navigation--some kind of menu or option list that allows system users to move around the system and get where they need to go. At its most fundamental level, presenting a user with navigation options involves three distinct processes:

• Retrieval;
• Filtering;
• Formatting.

The retrieval process is simply getting all of the various choices from somewhere. At this point, it doesn't matter where you get them; it just matters that you need to get them. That's the first step. Once you have them, the next step is to remove from the list all of those items to which the current authenticated user does not have access. This is to comply with the generally accepted system design principle that states that a user should not be presented with a navigation option that leads to something for which he or she does not have authorization. This is commonly referred to as filtering. Once you have the filtered list of options, the final step is formatting the options to be displayed on the page. The formatting process makes no judgments as to which options should or should not be displayed, because the retrieval and filtering process has already taken care of that aspect of the process. The formatter simply wraps some form of presentation code around the options so that they can be presented as an integral element of the fully rendered page.