Software ist dafür da, Arbeit zu unterstützen – nicht Arbeit zu machen. An sich ein einfacher und nachvollziehbarer Ansatz, der in der Praxis jedoch viel zu oft unterlaufen wird. Das fluide Prinzip dagegen stellt Anwender und Anwendergruppen in den Mittelpunkt – und passt sich deren Aufgaben, Prozessen und Vorlieben an. [...]
Produktive Software muss einen schwierigen Spagat beherrschen. Denn dafür sind zwei scheinbar konkurrierende Imperative unter einen Hut zu bringen: Funktionsfülle und Bedienkomfort. Je mehr Funktionalität in die Software gepackt wird, desto schwieriger ist es, sie für die Anwendern auf der Bedienoberfläche übersichtlich und intuitiv nutzbar zu machen. Wir alle kennen solche kryptischen „All-in-One“-Funktionsmonster, die zwar (fast) alles können, aber das was gerade gebraucht wird, in gut getarnten Untermenüs verstecken. Das konträre Pendant dazu sind „Best-of-breed“-Ansätze, die die vermeintlich besten Teillösungen zusammenpacken. Sich in dieser Silo-Architektur zurechtzufinden, ist für die Anwender mindestens genauso schwierig.
Keep it simple: Reduktion auf das Wesentliche
Als ideale Lösung könnte man sich die Kombination aus Funktionsfülle im Backend bei gleichzeitiger gezielter Reduktion auf das Wesentliche am Frontend vorstellen. Diese Idee klingt plausibel und bestechend simpel. Aber wie so oft liegt die Tücke in der praktischen Umsetzung. Aufgaben, Anforderungen und Vorlieben ändern sich. Es müsste also auch Raum für Flexibilität und Anpassungsfähigkeit am Frontend geben. Erschwerend kommt als weiterer Aspekt noch dazu, dass das Frontend nicht nur Raum für persönliche Individualisierung lassen sollte.
Wäre es angesichts von Mobilität, Homeoffice und anderen New Work-Konzepten nicht produktivitäts- und motivationsfördernd, wenn gemeinsame Team- oder Unit-spezifische Workplaces entstehen könnten, die ohne großen Aufwand auf die jeweils benötigte Applikations-Unterstützung zugeschnitten sind? Warum sollte beispielsweise eine Abteilung, für die Videokonferenzen kein Thema, Ticket-Systeme böhmische Dörfer oder Chat-Funktionen überflüssig sind, ihre Workplaces damit zupflastern? Intuitive, reduzierte Oberflächen sind eine der wichtigsten Voraussetzungen für produktive digitale Arbeitsplätze. Davon sind die üblichen Software-Stacks weit entfernt. Es braucht neue Ansätze.
Fluide Software: vom Modul zum Dashlet
Der bekannteste Vorstoß in diese Richtung sind modulare Software-Stacks. Im Gegensatz zu den nur bedingt anpassbaren All-in-one-Lösungen und Best-of-Breed-Ansätzen gestatten sie das gezielte Ein-, beziehungsweise Ausblenden von Funktionsmodulen. Wer ständig chattet, aber nie in Videokonferenzen unterwegs ist, hat halt das Messaging-Modul aber kein Talk-Modul auf seinem Workplace. Die logische Fortsetzung des Modul-Gedankens ist ein noch feingranularer Ansatz, der einzelnen Mitarbeitern, Teams oder Abteilungen die Freiheit lässt, ausschließlich die Funktionen oder Funktionspakete zu nutzen, die sie tatsächlich für ihre Arbeit benötigen. Alles andere steht sozusagen auf Abruf im (unsichtbaren) Hintergrund bereit, falls Änderungen gewünscht sind oder notwendig werden. Das ist, kurz gesagt, das Prinzip fluider Software.
Das Funktionsäquivalent dafür sind die sogenannten Dashlets. Im Gegensatz zu Modulen sind sie keine spezialisierten Funktionspakete, sondern singuläre, miteinander kombinierbare Funktionen. Während ein Modul beispielsweise ein komplettes Ticket- oder Videoconferencing-System abbildet, erledigt ein Dashlet nur den File-Transfer oder Social-Media-Chats. Sowohl die Dashlets, als auch die Module, als auch die Bedienelemente können alle miteinander auf der Oberfläche frei angeordnet, gruppiert und zugeordnet werden.
Ein-Blick in den Maschinenraum
So einfach das im Prinzip klingt – und für die Anwender am Frontend auch sein soll – so anspruchsvoll ist die technische Umsetzung auf der Entwicklungsseite. Wer sich auf diese Technologie einlässt, sollte über ausgeprägte Erfahrungen mit modularen Software-Architekturen und Open Source verfügen, inklusive der entsprechenden Entwicklungs-Tools und Programmier-Schnittstellen. Dies ergibt sich unter anderem aus der bereits erwähnten Trennung von Backend und Frontend, die ja irgendwie kommunizieren müssen. In der Regel erfolgt das über RESTful-APIs (Representational State Transfer). Dadurch ist es sogar möglich, Legacy-Systeme in eine fluide Architektur einzubinden. Viele Banken, Versicherungen und Behörden haben solche „Oldies“ noch im Einsatz, die sie gar nicht, oder nur mit hohem Aufwand ersetzen können.
Für einen fluiden Software-Stack müssen zwei elementare Voraussetzungen gegeben sein: Erstens eine einheitliche Software-Architektur und zweitens eine gemeinsame Datenbasis über alle Module und Dashlets hinweg. Modulare wie fluide Software ist in Schichten, sogenannten Layern aufgebaut. Das Backend ist dabei das Reich der Anwendungen, Funktionsmodule und der zentralen Datenbank. Letztere sorgt dafür, dass alle Daten in einem gemeinsamen Daten-Pool gespeichert und verwaltet werden. Nur dann ist es möglich, mit allen verfügbaren Daten in sämtlichen Modulen zu arbeiten, und sie mit allen anderen Modulen austauschen zu können. Eine Ebene darüber, in der sogenannten Middleware, werden unter anderem ein Directory-Service und eine Enterprise-Search-Engine benötigt. Der Directory-Service sorgt als Schaltzentrale unter anderem für die Interoperabilität zwischen den verschiedenen Anwendungen und verwaltet die Zugriffsrechte. Die Suchmaschine ist eine Erweiterung der Datenbank, indiziert und kategorisiert deren Daten und beschleunigt so deren Bereitstellung, wenn sie innerhalb eines Moduls oder Dashlets gebraucht werden.
Flexible Dashboards zur freien Gestaltung
Damit sind wir an der Oberfläche angekommen, den Dashboards als Schnittstelle zu den Anwendern. Hier wird das fluide Prinzip in seinen Möglichkeiten zur Individualisierung ganz praktisch sichtbar. Einzelne Mitarbeiter, ganze Teams oder komplette Abteilungen können sich ihre auf die eigenen Prozesse und Workflows zugeschnittene Arbeitsumgebung frei gestalten – und jederzeit verändern, falls gewünscht oder notwendig. Wer will kann bei entsprechenden Whitelabeling-Optionen sogar das Look-and-Feel an das Corporate Design des Teams, des Unternehmens oder des Providers, respektive Dienstleisters anpassen.
Für die Anwender wie für die Entwickler ist dabei die Betriebssystem-Agnostik des fluiden Software-Stacks wichtig. Er soll ja auf unterschiedlichsten stationären und mobilen Endgeräten mit verschiedensten Betriebssystemen wie Windows, MacOS, iOS, Android, Linux oder Solaris gleichermaßen und mit unveränderter Qualität nutzbar sein. Möglich wird dies durch den Hybrid-Source-Ansatz, bei dem die Code-Basis betriebssystemunabhängig entwickelt, und quasi erst im letzten Moment an das gewünschte Betriebssystem adaptiert wird.
Ohne Open Source, dessen weltweite Entwicklergemeinde und den Pool an verfügbaren Tools ist ein solches Konzept praktisch nicht umsetzbar. Dafür sprechen allein schon die riesigen Entwicklungskapazitäten der Open-Source-Community, sowohl was die Entwicklung, die Pflege als auch die Weiterentwicklung der Software betrifft. Offene Standards werden zudem für die so wichtige Interoperabilität und unabhängige Auditierbarkeit benötigt. Fluide Software ist daher auch das programmgewordene Bekenntnis zu mehr Transparenz und Zusammenarbeit. Im Darwin´schen Prinzip des „Survival of the Fittest“ bedeutet „fit“ nicht, wie fälschlicherweise oft kolportiert wird, die größere Durchsetzungschance des Stärksten, sondern des Anpassungsfähigsten. Auch so gesehen ist fluide Software ein Schritt in die richtige Richtung.
*Die Autorin Andrea Wörrlein ist Geschäftsführerin von VNC in Berlin und Verwaltungsrätin der VNC AG in Zug.
Be the first to comment