Locked in?
Es dürfte dem einen oder anderen nicht verborgen geblieben sein, daß ich das Gros meiner Tage damit verbringe, Software in einer In-House – Umgebung gleichermaßen zu betreiben, zu entwickeln und auch, irgendwie, in ihrer langfristigen Ausrichtung und Entwicklung zu planen. Ich bin seit ehedem Anhänger der Idee “Freier Software” (mit großem “F”, wie in “Freie Rede”, nicht wie in “Freibier”…) oder, wenn pragmatischer, technischer, zumindest des Ansatzes von Open-Source-Software-Entwicklung, im Wesentlichen aus denselben Gründen (offener Umgang mit “gemeinschaftlichem” Wissen, Respektieren der Rechte und Interessen aller Beteiligten, Lösen von einem starren und meist falschen “Produzent”/”Konsument”-Verhältnis und so weiter und so fort). Im Alltag indes zeigt sich, bisweilen, daß diese Frage zwar interessant und relevant ist, aber letztlich nicht weit genug springt, um gewisse Probleme zu lösen, und auch nicht in jedem Fall allein geeignet ist, um “Lock-In”-Effekte, die übermäßige und faktisch nur extrem schwer lösbare Bindung an bestimmte Produkte oder Hersteller, von vornherein zu minimieren.
Das Problem…
… kennen vermutlich viele: Logik im Unternehmen ist “in die Jahre” gekommen. Pflege der Fachanwendungskomponenten (seien es nun Excel-Makros, seien es komplexe Unternehmensplattformen oder “Standardanwendungen” mit hinreichend viel unternehmensspezifischen Anpassungen) kostet umso mehr Kraft, je älter sie werden. Irgendwann merkt man, daß man umfassendere Änderungen nicht mehr vornehmen kann, weil eigentlich niemand mehr die Lösung vollständig überblickt, bzw. derjenige, der das noch tut, so viel zu tun hat, daß er auf absehbare Zeit keine Chance hat, auch nur annähernd “alles” an Aufgaben zu lösen. Irgendwann merkt man, daß Änderungen an einer Stelle Konsequenzen an anderer Stelle nach sich ziehen, die einem erst sehr spät im Zusammenhang auffallen, weil die (einstmals offensichtliche) semantische Verbindung zwischen den zwei Punkten längst nicht mehr klar ist. Irgendwann merkt man, daß die “Pflege” der Plattform Schritte erfordert, die weh tun (sei es nun die Konvertierung und der Test einer umfangreichen Sammlung von Makros auf eine neuere Version einer verwendeten Office-Plattform oder die Migration einer Fachanwendung auf eine neue Umgebung).
Und… irgendwann merkt man, auf dem Weg dorthin, daß die Frage ‘”open-source”/”frei” oder nicht’ in diesem Problemkreis nur bedingt hilft. Sicher, eine proprietäre, geschlossene Plattform erschwert das Leben an dieser Stelle noch zusätzlich, wenn der Hersteller nicht mehr willens bzw. in der Lage ist, Support für “sein” Produkt in dem erforderlichen Umfang zu leisten. Aber letztlich ist, in den Fällen, in denen mit Schmerzen zu rechnen ist, wichtig: Diese Plattform ist nur die Basis. Sie ist in fortgeschrittenen Fällen die Basis für Weiterentwicklungen, für unternehmensspezifische Fach- und Geschäftslogik. Sie ist in einfachen Fällen, eigentlich in jedem Fall, Basis für die Haltung von Unternehmensdaten und -informationen, mithin jenes Wissens, ohne dessen Existenz das Unternehmen keine sinnvolle Geschäftstätigkeit mehr ausüben könnte, ohne dessen Existenz die Basis-Software nurmehr ein “nutzloser Haufen von Nullen und Einsen” wäre.
Daten
Womit sich ein interessanterer Fokus ergibt als die Software selbst: Daten. Nutzdaten. Dort liegt der Wert, den das Unternehmen greifbar in die Software gepackt hat. Dort liegen all die Myriaden von Dokumenten, Adressen, Metadatensätzen, Verknüpfungen zwischen Datenelementen, deren Gesamtheit in den Geschäftsprozessen des Unternehmens jeden Tag existenziell ist. Letztlich wird, in fast allen Fällen, Verfügbarkeit und Integrität dieser Daten irgendeinem Stück Verwaltungssoftware anvertraut, davon ausgehend (darauf hoffend?), daß dies wie erwartet funktioniert. Und dort ist ein erstes Problem greifbar, welches weit garstiger ist als die Frage, ob eine Basisplattform nun “offen” ist oder nicht: Was passiert, wenn die verwalteten Daten derart streng an die “Verwaltungssoftware” gebunden werden, daß sie ohne diese faktisch nicht mehr verwendbar sind? Einfach: Man wird von der Verwaltungssoftware abhängig, weil es im schlimmsten Fall unbeherrschbarer Aufwand ist, alle Fachdaten samt aller Zusammenhänge dort wieder zu extrahieren und in ein anderes System zu überführen. Im schlimmsten Fall ist dies vollständig manueller Aufwand, weil automatische Übersetzungen entweder nicht oder nur teilweise zuverlässig möglich sind. Dieser Umstand ist nicht schlimm, so lange die gegebene Softwareplattform den Anforderungen genügt. Sollte diese Grenze indes erreicht werden, kann man davon ausgehen, daß hieraus schmerzhafter Aufwand im Sinne von Zeit und Geld resultiert. Quelloffene oder freie Sofware hilft hier indes nur bedingt, da die Bindung zwischen “Datenformat” und “Anwendung” nicht notwendigerweise das Instrument zur Bindung von Nutzern an ein proprietäres System und damit von Kunden an einen Hersteller sein muß, sondern auch einfach eine Folge von Unwissenheit oder technischen Entscheidungen (“Optimierung” durch eigenes Binärformat) sein kann. Und auch bei quelloffener oder freier Software kann hier eine Grenze erreicht werden, an der die Erweiterbarkeit, Anpaßbarkeit des Systemes nicht mehr wirtschaftlich vertretbar, eine Migrationserwägung unvermeidlich ist.
An dieser Stelle gilt es also den Fokus auf die Daten im System zu legen. Offensichtliche Abhilfe schafft die Verwendung offener Formate (auch: hier (englisch)) für Ablage und Austausch von Daten. OpenDocument, das Dokumentenformat von LibreOffice, als ISO-Standard ist hier ein gutes Beispiel, XML als generelle Möglichkeit zum Ablegen von strukturierten Daten vermutlich ein anderes. Ob die Anwendung ihre Daten immer in genau diesen offenen Formaten vorhalten und ablegen muß, ist sicherlich diskussionsbedürftig, aber auf jeden Fall sollte sie imstande sein, notfalls ihren gesamten Datenbestand verifizierbar und verlustfrei in ein solches Format exportieren (bzw. auch aus einem solchen Format importieren) zu können. Womit sich der zweite Punkt aufdrängt…
Schnittstellen
… in der simplen Frage: Existiert für die Anwendung von vornherein eine “Außenwelt”, oder ist die Anwendung als ein “Silo” zu betrachten, in dem Daten und Funktionalität weitestgehend abgeschlossen und unerreichbar verstaut sind? Im Kern ist festzuhalten: Datensilos will man nicht. Spätestens in einer Zeit, in der Begriffe wie SOA oder Anwendungsintegration gleichermaßen Schlagworte der Software- und Beraterbranche wie auch (bittere?) Notwendigkeit in vielen Unternehmen sind, darf man die Nachteile von Silos als bekannt annehmen: Daten und Funktionalität werden, dort einmal eingebracht, nur in sehr eingeschränkter Art und Weise (etwa: über eine Benutzerschnittstelle für Endanwender) erreichbar, kaum sinnvoll in automatisierte Prozesse anbindbar, kaum über die Grenzen des “im Silo Möglichen” hinaus erweiterbar. Nicht zuletzt ist auch der oben schon umrissene Bedarf einer Migration zwischen Anwendungsplattformen gern die Konsequenz des Umstandes, daß man in einer Anwendung diese Silo-Grenzen erreicht hat, daß man benötigte Funktionalität, die Unterstützung neuer Technologien (etwa mit Oberflächen für mobile Endgeräte) oder die Ein- bzw. Anbindung relevanter neuer Anwendungen nur noch mit unverhältnismäßigem Aufwand, oder schlimmstenfalls gar nicht mehr möglich sind.
An solchen Punkten ist Schmerz vorhersehbar. Und, indes: Auch diese Probleme lassen sich nicht mit einem Wechsel von “proprietär” nach quelloffen oder Frei lösen. Fehlt dem Entwickler eines Freien Produktes das Verständnis für, die Einsicht in die Notwendigkeit von sauberen, öffentlichen Schnittstellen zur Außenwelt, werden die Dinge kompliziert. Sicher ist es in einem “offenen” Umfeld weit eher möglich, Schnittstellentechnologien nachzurüsten, aber was im Proprietären unter Umständen vom (Un-)Willen des Herstellers abhängt, steht in der quelloffenen/freien Welt vor dem Problem, die Komplexität eines Programmsystemes zu verstehen und so zu beherrschen, daß die richtigen Modifikationen an der richtigen Stelle vorgenommen werden können. Ob dies, in Sonderheit für den Fall einer vollständigen (bidirektionalen) Schnittstelle “durch die Silo-Wand” hindurch, im Aufwand zurückbleibt hinter einer Migration, die ein derartiges Schnittstellenkonzept von Anfang an unterstützt, bleibt wohl zu diskutieren. Für die Plattformwahl insgesamt zu berücksichtigen damit: Schnittstellen-Technologien in der “Features”-Liste. Begriffe wie SOAP, REST, CORBA oder dergleichen sind dabei nicht völlig falsch, wobei im konkreten Fall immer abzuklären ist, in welchem Umfang und welchem Feature-Set die jeweilige Technologie unterstützt wird. Trotz allem, ganz gleich, ob quelloffen, frei oder proprietär: Kein Geld in die Silos!
Fachlogik
Bleibt der letzte Punkt, vermutlich der diffizilste in dieser Liste: Was tun mit Logik, die in einem Makro, einem Anwendungssystem, … untergebracht ist? Auf den ersten Blick bedarf die Frage keiner allzu großen Überlegungen – das Fachwissen steckt schließlich im Unternehmen, und da die Menschen im Unternehmen tagtäglich mit den gängigen Geschäftsprozessen beschäftigt sind, sind auch Abläufe, Akteure, Constraints, … zweifelsohne bekannt.
Wirklich?
Zum einen bleibt, stets, die durchaus begründete Frage im Raum stehen, ob das Wissen zu den in Logik gegossenen Prozessen detailliert genug vorhanden ist, um den Code in all seinen Aspekten noch zu durchblicken und zu verstehen. Das skaliert vom Anwendungssystem bis zum Makro, wenn es Jahre später nachzuvollziehen gilt, warum bei jenem Stück VB-Script, das eine komplexe Tabelle befüllt wird, um alles in der Welt diese oder jene Zelle fett vor rotem Hintergrund formatiert werden wird. Aber das Problem ist noch deutlich interessanter: Wo verläuft in der Struktur des Systemes die Grenze zwischen Code, der tatsächlich Fachlogik abbildet, und solchem, der den Erfordernissen der Umgebung, der Infrastruktur, … gerecht wird? Ist, für den “simplen Fall” des tabellenfüllenden Makros, die Funktionalität, in denen Logik zur Berechnung von Inhalten steckt, irgendwo plausibel isoliert bzw. gekapselt, oder ist Berechnungslogik kreuz und quer vermengt mit Anweisungen zum Befüllen von Zellen, zum Setzen von Formatierungen, …? Ist, im “großen Kontext”, die Logik, die Fachaktionen mit Fachobjekten ausführt, an definierter Stelle greifbar, dokumentierbar, übergebbar, isolierbar hinterlegt, oder ist sie quasi-monolitisch vermengt, vermischt mit Persistenz-Code, (De-)Serialisierungs-Logik für irgendwelche Übertragungswege, Code und Funktionalitäten zur Anzeige in einer sehr speziellen Oberfläche usw. usf. etc. pp.?
Ähnlich wie Schnittstellen oder Datenformate, nur noch deutlich gravierender und schmerzhafter, verhindert dieses Problem wahlweise die Weiterentwicklung eines Systemes über gewisse Grenzen hinaus gleichermaßen wie auch die Migration auf eine neue Plattform. Begründung: Die relevante Funktionalität, die Abbildung von Abläufen, Geschäftsprozessen und deren organisatorischen, fachlichen, technischen Randbedingungen liegt im Code. Durch das Vermengen dieses fachlichen Codes mit jenen Code-Fragmenten, die aus der Plattform heraus erwachsen, wird es enorm erschwert, auch nur zu isolieren, wo genau die Grenze zwischen Fachlogik und Framework-Infrastruktur verläuft, welche Funktionalität isoliert, erweitert, ggfs. migriert werden muß, und welche man bisher und wohl auch in einer neuen / erweiterten Umgebung als gegeben voraussetzen kann und will. Das Leben des Entwicklers wird auf diese Weise sehr viel anstrengender und härter.
Löst sich diese Schwierigkeit mit einem Wechsel auf freie oder quelloffene Software? Nein, ganz und gar nicht. Die Notwendigkeit, eigenen Code in einen bestimmten Kontext, ein bestimmtes Programmiermodell oder -paradigma einzuordnen, wird immer bestehen bleiben, ganz gleich, ob es sich um ein Office-Makro innerhalb eines speziellen Office-Systems oder Code in einem Application-Server handelt. Das Herbeiführen einer möglichst strikten Trennung zwischen “eigenen” Fachfunktionen und “fremdem” Infrastruktur-Code ist in jedem Fall wohl das absolute Minimum an Anforderung, mit dem man an diesen Umstand herantreten kann. Darüber hinaus bleiben hier die ganzen Aspekte der Softwaretechnologie, insbesondere der frühen Phasen nahezu aller Software-Entwicklungsprozesse, in Gültigkeit bestehen: Erfassung, Dokumentation, Protokollierung von Anforderungen und Änderungen… Entwurf von System- und Architekturmodellen, und sei es minimal in der Definition und Abbildung des Zusammenhanges zwischen Code, Fachfunktionen und Anforderungen, entlang der Dokumentation der Berührungspunkte zwischen Fachlogik und Code der Infrastruktur. Das ist bei einer Freien Plattform keine schlechtere Empfehlung als bei einer proprietären, ebenso wie es sinnvoll und nützlich ist, sich an gängigen Best Practises und Konzepten zu orientieren, die sich unter Umständen plattformübergreifend zur Modellierung der Systemarchitektur verwenden lassen, etwa Entwurfsmuster, etablierten Software-Architekturen, Integrationsmustern und dergleichen mehr. Nahezu trivial die Erkenntnis, daß Code umso leichter zwischen verschiedenen Plattformen zu portieren ist, je portabler das zugrundeliegende Design, die Architektur des Ganzen ist. Ob Frei, quelloffen oder proprietär, das spielt an diesem Punkt fachlich nahezu keine Rolle mehr: Wenn die Zielplattform den Anforderungen genügt, die zur Abbildung der modellierten Funktionalität erforderlich ist – gut. Wenn nicht, dann ist die Wahl, proprietär oder Frei, in jedem Fall die falsche – rein fachlich, pragmatisch, wohlgemerkt – was nicht bedeutet, daß man bei gleicher fachlicher Eignung nicht eventuell die Freie Alternative bevorzugen sollte. 😉
Abschließende Gedanken
Nein, ich weiche nicht ab von meiner Begeisterung für Software Libre oder Open-Source-Software. Nach verschiedenen mehr oder weniger massiven Kontakten auch mit proprietären Anwendungen und Lizenzmodellen habe ich oft den Eindruck, daß Software, die zumindest Open-Source ist, im Hinblick auf die umrissenen Punkte out-of-the-box mehr Funktionalität mitbringt als vergleichbare proprietäre Alternativen, und im Hinblick auf Lizenzbedingungen und damit verbundenen Kosten ist quelloffene oder Freie Software sowieso argumentativ gut aufgestellt. Es ist eben einfach nur zu berücksichtigen, daß “Frei” und “offen” in diesem Kontext, in dem Kontext der Abbildung unternehmens- und fachspezifischer Logik in Software, nicht allein problemlösend oder entscheidend sind, daß auch im Falle von offenen (im Sinne der Lizenz) Systemen mittel- bis langfristig ärgerliche Effekte auftreten können, wenn die Auswahl auf Freiheit und Offenheit begrenzt wird und bestimmte andere Randbedingungen Ignoranz erfahren. Andererseits… ist dies auch beim Kauf proprietärer Lösungen zu berücksichtigen, und vielleicht bewegt zunehmende hartnäckige Nachfrage von Kunden ja doch auch entsprechende proprietäre Lieferanten zum Handeln…