Changes are inevitable in any information system. Even with the best possible requirements analysis, it is extremely hard to anticipate all of the potential changes that may be required in a system over time. The best solution is to try to predict major failure points in order to reduce the chances of such failures to an “acceptable” level.
Used in this sense, “acceptable” is greatly dependent upon the project budget and management tolerance. However, in any efficiently run organization, proposing system modification costs that are comparable to the original system development expenditures could be considered a “fireable offense.” As a result, system architects are doomed to add layers upon layers of patches to allow systems to survive longer without any major modifications to the underlying mechanisms.
Good system architecture means building systems in such a way that the inevitable changes are less likely to make the system collapse under the weight of accumulated quick-fixes. The key principle seems logical. There should be NO quick-fixes at all. In reality, all rules are meant to be broken and this one is not an exception. There will be always some deadlines, project restrictions and other reasons to push developers to the “dark side.” The only solution is to create conditions for making changes correctly. This approach requires some serious thinking by the core system architecture team. This article discusses a number of approaches including real “war-stories.”
You can read the whole article or find it in the ODTUG Journal (need to be an ODTUG member). ODTUG stands for Oracle Development Tools User Group and it is a user group that we highly recommend. They have an annual conference (Kscope) in June and a large number of online resources for members.