Ein Framework besteht aus einer Menge vorgefertigter Bausteine. Es unterstuetzt nicht nur die Wiederverwendung von Code, sondern vor allem auch die Wiederverwendung des Designs. Die Klassen, aus denen ein Framework besteht, wurden bereits von den Entwicklern miteinander "verdrahtet". Das fachspezifische Wissen ueber Zusammenhaenge und Ablaeufe der Klassen wurde also bereits im Framework hinterlegt und braucht nur noch aufgerufen zu werden.

Anders als in prozeduralen oder objektorientierten Klassenbibliotheken ruft das Framework die Methoden des Entwicklers auf und nicht umgekehrt. Die Kontrolle ueber den Ablauf der Anwendung obliegt in der Framework-basierten Entwicklung nicht mehr dem Programmierer, sondern dem Framework. Verschiedene Frameworks bauen aufeinander auf und stehen in Beziehung zueinander.

Aus wirtschaftlicher Sicht lohnt sich der Einsatz von Frameworks aus vielerlei Gruenden: Zum einen laesst sich der einmal entwickelte Framework auf dem Markt angebieten. Will man dies nicht, so kann der Framework intern eingesetzt werden, um einen Wettbewerbsvorsprung zu erlangen. Umgekehrt lassen sich Frameworks am Markt erstehen, so dass auf deren Basis Applikationen schneller entwickelt werden koennen. Der Schwerpunkt der Inhouse-Entwicklung laesst sich also durch den Zukauf der im Framework vorliegenden Infrastruktur auf die eigentlichen Anwendungsprobleme verlegen.

Entwickler koennen die Frameworks unangetastet nutzen, sie aber auch an ihre spezifischen Beduerfnisse anpassen. Hierfuer sind die Frameworks mit zwei unterschiedlichen Arten von Anwendungsprogrammier-Schnittstellen (APIs) ausgestattet. Das Client-API sieht nach aussen wie eine Sammlung von Klassen einer Klassenbibliothek aus. Es steht dem Entwickler zur Verfuegung, wenn er den Framework so nutzen will, wie dieser ausgeliefert wird. Das Framework API stellt die Schicht dar, die die Anpassung des Frameworks ermoeglicht.