Oft steht man als Entscheider vor der Wahl: welche Software soll man einsetzen? Eine spezielle Lösung ohne viele Eingriffsmöglichkeiten oder eher etwas sehr allgemeines, was man selner steuern kann? Die Antwort ist – wie immer – kompliziert, aber nicht unrreichbar…
Spezialsoftware ist meist als eine Blackbox-Lösung. Es gibt nur einen Zweck, auf den hin alles ausgerichtet ist. Gut abgestimmt, meist einfach aufgebaut, steuerbar über einige Parameter. Ein Arbeitspferd ohne viel Tamtam.
Damit wäre eigentlich alles schon gsagt… Aber die Realität ist meist nicht so einfach gestrickt. Chefs, die Sonderwünsche (manchmal ohne einen tiferen Sinn) unbedingt umgesetzt sehen wollen. Kunden, die Sonderkonditionen durchsetzen wollen. Die Vorstellung der Vorgänger: „Das ist doch fast dasselbe, man müsste nur hier und da was ändern“ – nur eben vor langer langer Zeit, als man noch HIMEM.SYS per Hand eingtragen hat… Man kann durchaus Software, die für den Einsatzbereich X geschrieben worden ist so anpassen, dass es für den ähnlichen Bereich Y nützlich wäre. Aber niemand wird bereit sein, zu garantieren, dass es mit einer neuen Version genauso gehen wird. In diesem Fall verschiebt man mehr oder weniger das Problem auf der Zeitachse, statt eine passende Lösung gleich zu suchen. (Und wenn es mit der Folgeversion funktioniert… Viel Spaß mit Updates! Jede kleine Änderung muss noch einmal gemacht werden. Bei einem Update-Intervall von über einem Jahr kann das bei größerer Fluktuation zum Problem werden.)
Wie wäre es denn mit der beliebten Lösung „Excel für alles“? Es gibt kaum ein Unternehmen, welches nicht dieses Programm (oder eher derartige Software – der Name wird als Kategoriebezeichnung mißbraucht) in mehreren unteschiedlichen Bereichen einsetzen würde: Buhhaltung (was nur zu verständliche wäre), in Lagerverwaltung, Stapelverarbeitung von Daten (Import oder Export, alphabetische Sortierung großer Datenmengen) oder als Urlaubsplaner. Alles das geht mit Tabellenberechnungssoftware. Doch sind auch hier irgendwann die Grenzen des Machbaren oder des Hinnehmbaren erreicht: eine Aneinanderreihung von Workarrounds ist keine Lösung. Jedenfalls keine, die effizient und zukunftsfähig wäre.
Wenn also weder die Spezialsoftware, noch die eierlegenden Wollmichsäue Flexiblität und Zweckmäßigkeit gleichermaßen bedienen, was wäre dann die richtige Wahl?
Die Kompromislösung heißt „Frameworks“. Es ist keine fertige Software. Vielmehr eine solide Basis für einen Bau nach eigenem Wunsch. Frameworks haben bestimmte Stärken (Aufgaben, die sie besonders gut erledigen) und schwächen (Lösungen, die man nur über kleinere oder größere Umwege erreichen kann). Sie zielen oft auf bestimmte Einsatzgebiete ab. So gibt es z.B. Frameworks für die Aufbereitung der Daten zu Diagramen. Diese können nicht besonders gut mit diesen Zahlen rechnen. Sie können auch nur in den wenigsten Fällen Bilder zuschneiden oder drehen. Doch was sie tun, erledigen sie recht gut… Und sie können mit den meisten anderen Programmen kooperieren. Für die Anbindung der einen an die nderen muss man selber sorgen. Es ist keine Blackbox aber es ermöglicht eine flexible Lösung. Bei Updates ist auch hier Vorsicht geboten: einige Funktionen ändern sich, abere kommen hinzu. Je größer der Versionssprung, desto wahrscheinlicher ist eine Inkompatibilität der eigenen Entwicklung zum Framework. Andererseits ändert sich an der Ausrichtung und Funktionsumfang dieser Software selten etwas. Im Bild eines Hausbaus gesprichen bleibt es ein Fundament, welches die Frage nach der Bodenbeschaffenheit obsolet macht. Es garantiert eine relativ hohe Unabhängigkeit von anderer Software wie Datenbanken, Präsentationsformate etc.
Natürlich kann es Frameworks geben, die nicht genau das macht, was man sich wünscht. Es gibt auch Frameworks, die sehr hohe Abhängigkeiten von bestmmter Software aufweisen. Aber wenn auch dies zutreffen würde, sollte man im Blick behalten, dass der Einsatz von Frameworks (in fast allen Fällen) zeitspareder, sicherer und flexibler ist, als wenn man alles selber entwickeln würde.
Es gibt auch andere Probleme mit Frameworks. Viele davon betreffen aber die (nicht unwesentlichen) Hintergründe der Entwicklung. So setzen viele Frameworks auf sog. objektrelationale Mapper, die zwischen der relationalen Struktur der Datenbank und dem objektorientierten Datenmodel des Programms vermitteln. An sich richtig und sinnvoll… wären da nicht die sehr komplexen Beziehungen, die man mit JOINs abbilden kann, die Datenbank aber unnötig stresst. Ein handgeschriebenes SQL Statement ist oft schneller und hilfreicher. Dies sind aber Hintergründe, die man bei der Entwicklung berücksichtigen muss. Hat man die Wahl zwischen Standardsoftware („von der Stange“), die noch teuer angepasst werden muss, und einer Eigenentwicklung, so muss dieses Detail ebenfalls berücksichtigt werden.
Deshalb mißtraue ich Softwareherstellern, die behaupten, ihre Software würde alle Facetten eines Einsatzgebietes abdecken. Das geht oft nur mittelmäßig und auf Kosten einer kaum zu überblickenden Konfiguration. Einen Programmierer tauscht man dann gegen einen viel teureren Berater…
