Je mehr Systeme ich im beruflichen und privaten Alltag benutze, desto weniger besteht das eigentliche Problem darin, dass Informationen fehlen. Meist ist eher das Gegenteil der Fall: Die Informationen sind vorhanden, liegen aber in verschiedenen Anwendungen, Verwaltungsoberflächen und technischen Systemen verteilt. Um einen Überblick zu bekommen, müsste ich mehrere Webseiten öffnen, unterschiedliche Logins verwenden und jedes Mal wissen, in welchem System sich die gerade benötigte Information befindet.
Genau dieses Problem möchte ich mit Kosmos.Kompass lösen.
Kompass ist das zentrale Dashboard meiner Kosmos-Plattform. Es soll nicht selbst alle Daten erzeugen und auch nicht jedes angeschlossene System ersetzen. Seine Aufgabe besteht vielmehr darin, Informationen und Funktionen aus verschiedenen Kosmos-Anwendungen in einer gemeinsamen Oberfläche zusammenzubringen.
Kosmos als Ganzes besteht deshalb aus mehreren spezialisierten Anwendungen, während Kompass die Sicht darauf liefert, die ich im Alltag tatsächlich brauche.
Ein Dashboard soll mir Arbeit abnehmen und nicht nur hübsch aussehen
Dashboards werden häufig als Ansammlung von Diagrammen verstanden. Ein paar Kennzahlen, einige farbige Kacheln und möglichst viele Werte auf einem Bildschirm vermitteln schnell den Eindruck, alles im Blick zu haben.
Für meinen eigenen Alltag reicht mir das nicht.
Ich möchte nicht möglichst viele Informationen sehen, sondern möglichst schnell erkennen können, ob etwas meine Aufmerksamkeit benötigt. Ein normal laufender Dienst muss mir nicht genauso prominent angezeigt werden wie ein ausgefallener Dienst. Eine abgeschlossene Aufgabe ist weniger interessant als eine Aufgabe, die auf meine Freigabe wartet. Eine technische Umgebung, in der sich nichts verändert hat, braucht weniger Platz als ein neuer Fehler.
Kompass soll deshalb nicht zur Datenwand werden, sondern Informationen priorisieren.
Die eigentliche Qualität eines Dashboards liegt für mich nicht darin, wie viele Daten es anzeigen kann, sondern wie wenig davon ich anschauen muss, um die aktuelle Situation zu verstehen.
Die Daten bleiben in ihren Anwendungen
Ein wichtiger Architekturgedanke ist für mich die Trennung zwischen Darstellung und fachlicher Verantwortung.
Kompass soll beispielsweise nicht selbst technische Geräte inventarisieren. Dafür gibt es Argos. Es soll auch nicht festlegen, in welchem Rack ein Gerät steht. Diese Aufgabe gehört zu Atlas. Aufgaben und Freigaben liegen wiederum bei Agenda, während Puls seine eigenen Informationen rund um Artikel und Veröffentlichungen verwaltet.
Kompass kann diese Informationen anzeigen und passende Aktionen erreichbar machen, muss sie aber nicht selbst besitzen.
Dadurch soll verhindert werden, dass mit der Zeit eine riesige Dashboard-Anwendung entsteht, in der sämtliche Geschäftslogik zusammenläuft. Neue Kosmos-Anwendungen können ihre eigenen Verantwortlichkeiten behalten und trotzdem in der gemeinsamen Oberfläche erscheinen.
Memoria als gemeinsame Datenschicht hilft dabei, Informationen kontrolliert zwischen den Anwendungen verfügbar zu machen.
Unterschiedliche Situationen brauchen unterschiedliche Ansichten
Nicht jede Information ist zu jeder Zeit gleich wichtig. Genau deshalb möchte ich Kompass langfristig nicht auf ein einziges starres Dashboard beschränken.
Wenn ich mich mit meiner Softwareentwicklung beschäftige, interessieren mich andere Dinge als bei der Prüfung meiner technischen Umgebung. Bei Contentarbeit können offene Artikel oder Freigaben im Mittelpunkt stehen, während bei technischen Problemen Zustände aus Argos und Protokolle aus Chronos wichtiger werden.
Auch private Themen sollen ihren Platz bekommen können.
Für mich ist das keine unsaubere Vermischung von Unternehmen und Privatleben, sondern eine praktische Konsequenz daraus, dass ich dieselbe Person bin, die beide Bereiche organisiert. Ein Termin bleibt relevant, unabhängig davon, ob er geschäftlich oder privat ist. Eine IP-Kamera kann Aufmerksamkeit benötigen, während gleichzeitig eine Agenda-Aufgabe auf Freigabe wartet.
Kompass soll deshalb eine technische Plattform für verschiedene Ansichten sein, nicht ein vorgefertigtes Unternehmenscockpit mit einer festgelegten Vorstellung davon, was für jeden Nutzer wichtig sein muss.
Plugins machen das Dashboard erweiterbar
Damit diese Idee langfristig funktioniert, darf Kompass nicht bei jeder neuen Datenquelle grundlegend umgebaut werden müssen.
Neue Funktionen sollen sich deshalb als klar getrennte Erweiterungen beziehungsweise Plugins integrieren lassen. Ein Plugin kann Informationen bereitstellen, eine eigene Darstellung besitzen oder bestimmte Aktionen ermöglichen, ohne dass der Kern von Kompass sämtliche Details des angebundenen Bereichs kennen muss.
Diese Architektur ist für mich besonders wichtig, weil ich heute noch gar nicht wissen kann, welche Informationen ich in einigen Jahren im Dashboard haben möchte.
Ein geschlossenes Dashboard wäre irgendwann fertig und danach zunehmend unpassend.
Ein erweiterbares Dashboard kann dagegen mit meinen Anforderungen wachsen.
Dass ich solche Architekturgrenzen früh festlege, ist inzwischen ein wichtiger Teil meiner KI-gestützten Entwicklung. Codex darf innerhalb dieser Grenzen sehr selbstständig arbeiten, soll aber nicht für jede neue Funktion die grundlegende Struktur neu erfinden.
Kompass soll nicht nur anzeigen, sondern auch steuern
Eine reine Übersicht würde mein eigentliches Ziel ebenfalls nur teilweise erfüllen. Wenn mir das Dashboard zeigt, dass eine Aufgabe auf meine Freigabe wartet, möchte ich nicht anschließend eine andere Anwendung öffnen müssen, nur um diese Freigabe zu erteilen.
Deshalb soll Kompass dort, wo es sinnvoll ist, auch Aktionen ermöglichen.
Bei Agenda kann das beispielsweise eine Freigabe sein. Bei technischen Systemen kann eine Aktion später etwas anderes bedeuten, wobei riskante Eingriffe selbstverständlich stärkere Schutzmechanismen benötigen als harmlose Bedienhandlungen.
Der entscheidende Punkt ist die Trennung zwischen sehen und handeln trotzdem nicht künstlich zu machen.
Wenn das Dashboard bereits den Kontext einer Situation besitzt, ist es sinnvoll, passende nächste Schritte ebenfalls dort erreichbar zu machen.
Das passt zu meinem allgemeinen Ziel, KI-Agenten und automatisierte Systeme gezielt innerhalb klarer Grenzen arbeiten zu lassen, statt jede einzelne technische Aktion manuell ausführen zu müssen.
Mobile Nutzung verändert meine Anforderungen
Kompass soll nicht nur am großen Bildschirm funktionieren. Gerade bei Freigaben, kurzen Statusprüfungen oder privaten Informationen ist das Smartphone häufig die sinnvollere Oberfläche.
Das beeinflusst die Gestaltung stärker, als es zunächst klingt.
Ein Desktopdashboard kann problemlos mehrere Bereiche gleichzeitig anzeigen. Auf einem Smartphone muss wesentlich stärker entschieden werden, welche Information wirklich wichtig ist und welche Aktion mit wenigen Schritten erreichbar sein soll.
Der Gartenstuhl-Test ist auch dafür ein gutes Beispiel. Wenn ich eine vorbereitete Codex-Aufgabe freigeben möchte, sollte dafür kein Notebook notwendig sein. Das Smartphone ist in diesem Moment kein Notbehelf, sondern die passende Bedienoberfläche.
Kompass muss deshalb Informationen nicht nur zentralisieren, sondern sie auch abhängig vom Nutzungskontext sinnvoll reduzieren.
Private Anwendungen gehören bewusst dazu
Kosmos ist aus meinen beruflichen Anforderungen entstanden, soll aber nicht auf Unternehmensdaten beschränkt bleiben.
IP-Kameras sind dafür ein gutes Beispiel. Wenn eine Kamera eine relevante Situation erkennt oder ich einen aktuellen Zustand prüfen möchte, interessiert mich nicht, ob diese Information formal in dieselbe Kategorie wie eine geschäftliche Aufgabe gehört. Sie ist für mich relevant und kann deshalb im selben zentralen System auftauchen.
Dasselbe gilt für Termine oder andere private Informationen.
Wichtig ist dabei nicht, sämtliche Daten miteinander zu vermischen. Die Anwendungen können technisch und fachlich sauber getrennt bleiben. Kompass stellt lediglich unterschiedliche Perspektiven innerhalb derselben Oberfläche bereit.
Das ist für mich ein großer Unterschied.
Ein zentrales Dashboard muss nicht bedeuten, dass alles in derselben Datenstruktur endet.
Aus vielen Anwendungen soll ein System werden
Ohne Kompass könnte ich sämtliche Kosmos-Anwendungen auch einzeln entwickeln. Argos könnte Geräte erkennen, Atlas Standorte verwalten, Agenda Aufgaben koordinieren und Puls Artikel organisieren.
Technisch würde das funktionieren.
Im Alltag hätte ich danach allerdings wieder genau das Problem, das ich ursprünglich lösen wollte: mehrere spezialisierte Anwendungen mit mehreren Oberflächen, zwischen denen ich wechseln muss.
Kompass ist deshalb der Teil, der aus den einzelnen Anwendungen für mich ein Gesamtsystem macht.
Die Spezialisierung bleibt im Hintergrund erhalten, während die Bedienung stärker an meinen tatsächlichen Aufgaben ausgerichtet wird.
Mein Ziel ist eine persönliche Informationszentrale
Ich möchte Kompass nicht als allgemeines Management-Dashboard bauen, das möglichst vielen Unternehmen dieselben Kennzahlen zeigt.
Die spannendere Idee ist für mich eine Plattform, die sich an den eigenen Alltag anpassen lässt.
Bei mir gehören Softwareentwicklung, Unternehmensorganisation, IT-Infrastruktur, Websites und private technische Systeme dazu. Bei jemand anderem könnten völlig andere Anwendungen relevant sein.
Deshalb ist Kompass für mich weniger ein fertiges Dashboard als ein Rahmen, in dem aus unterschiedlichen Kosmos-Anwendungen eine persönliche Informationszentrale entsteht.
Sie soll mir morgens nicht möglichst viel zeigen.
Sie soll mir möglichst schnell sagen, was gerade wichtig ist und wo ich eingreifen muss.