Composite Project System

Projektsoftware ist ein Themenbereich, der mir seit Längerem am Herzen liegt. Tools gibt es wie Sand am Meer und in sehr unterschiedlichen Ausprägungen. Ein entscheidendes Merkmal habe ich jedoch bisher noch bei keinem gefunden – die Ausrichtung als Plattform.

Ich halte es für unwahrscheinlich, dass ein einzelnes Produkt so umfassende Features beinhaltet, dass es für unterschiedliche Zwecke und Branchen geeignet ist. Gleichzeitig ist jedoch eine zentrale Informationsbasis in Projekten enorm wichtig, die es eben mittels Speziallösungen nicht oder nur mittels aufwändiger Point-to-Point Integration gibt.

Der Ausdruck “zentrale Informationsbasis” ist etwas schwammig. Damit meine ich einerseits “generische” Informationen wie klassische Dokumente und E-Mails, andererseits spezifische Objekte wie einen Testlauf in einem Softwareprojekt oder eine Lead-Chance im Vertrieb.

Composite Project System

Das Composite Project System ist eine Blaupause für ein System, welches dies ermöglicht. Es enthält ein zentrales Repository (Workspaces), einige Standardwerkzeuge für Kontaktverwaltung, Dokumentenmanagement, E-Mail Archivierung und evtl. Aufgabenverwaltung, aber vor allem die Möglichkeit der Erweiterbarkeit um z.B. branchenspezifische Anwendungen.

Composite Project System Map

Workspaces

Workspaces sind vom Grundprinzip her dem Windows Explorer nicht unähnlich:

Composite Project System

Der Explorer enthält “lediglich” eine hierarchische Ansicht von Content-Elementen. Die Content-Typen sind jedoch nicht fest in der Anwendung verdrahtet, sondern können durch – nennen wir es Plugins oder Apps – beliebig hinzugefügt werden. Diese Typen sind jedoch “echte Entitäten”, die in einer relationalen Datenbank auf Tabellen abgebildet werden. Die UIs sind von Plugin-Entwicklern individuell gestaltet und nicht von einem Power-User zusammengeklickt.

So ein Workspace kann ein wertvolles Asset in einem Projekt sein, so können zu einem sehr engen Kontext Dokumente, E-Mails und eben beliebiger anderer Content miteinander verknüpft werden. Natürlich legt nicht jede Organisation auf eine solche Strukturierung wert, v.a. wo sie mit Mehraufwand verbunden ist. Daher wäre es ein wichtiges Usability-Ziel den Mehraufwand gegenüber isolierten Lösungen nahe Null zu halten. Aber wer auf eine solche Strukturierung wert legt, kann diese mittels dieser Workspaces auf ein ganz neues Level heben.

Als Gesamt-UI könnte ich mir so etwas vorstellen:

Explorer2

Man kann mehrere Tabs von Workspaces öffnen. Darin enthalten ist ein Explorer, sowie beliebig viele Tabs von geöffneten Content-Elementen.

Die Projektstruktur ist natürlich nicht fest, ich habe hier als Beispiel nur aus Gewohnheit eine für ein Softwareprojekt relevante Struktur gewählt.

Standard-Anwendungen

Eigentlich wäre mit den Workspaces schon der gesamte Funktionsumfang der Kernanwendung beschrieben. Aber ein Betriebssystem wird auch nicht ohne jede Anwendung ausgeliefert, daher sollte es einige Standardanwendungen geben.

Dokumentenmanagement

Eine der wichtigsten Aufgaben eines Workspaces ist sicherlich die Ablage von Dokumenten. Als Standardanwendung soll es ein einfaches Dokumentenmanagement geben, in dem Dokumente hochgeladen werden können. Weitere Features wird es nicht geben, so wie Notepad ja auch keine wirkliche Textverarbeitung ist.

E-Mail Archivierung

E-Mails sind und bleiben wichtiger Informationsträger. E-Mailprogramme sind aber so ausgereift, dass es nicht einmal im Ansatz Sinn macht, diese zu ersetzen. Stattdessen sollten E-Mails importiert werden. Hier ist es wichtig den Aufwand für den Import gering zu halten. Als ersten Schritt würde ich IMAP unterstützen, weil dadurch viele Mailserver abgedeckt werden.

Einem IMAP-Ordner sollte ein Workspace bzw. Content Element zugewiesen werden können. Diese Konfiguration wird je Nutzer durchgeführt. Im Hintergrund läuft ein Import-Job, der die E-Mails aus den konfigurierten Ordnern “abholt” und ins Projektsystem importiert. Somit erfolgt die Zuordnung der einzelnen E-Mails zum Workspace bzw. Content Element im E-Mail Client.

Kontakte

Selbst für so triviale Objekte wie Kontakte & Unternehmen ist eine zentrale Datenbasis wichtig. Hier sind zwar keine Features denkbar, die es nicht schon in tausenden anderen Programmen gibt, aber sie sind aus dem einfachen Grund interessant, dass viele denkbare Content-Elemente sich auf Personen bzw. Unternehmen im Kontext beziehen und eine Historie-Funktion über Personen erstellt werden kann.

Zwar sollte man die Kontakte auch im Composite Project System verwalten können, aber realistischerweise gibt es im Unternehmen mehrere Quellen für die Kontaktdaten. Diese sollte man für einen Import konfigurieren können (idealerweise birektional), um somit doppelte Datenerfassung zu vermeiden.

Aufgaben

Eine einfache Aufgabenverwaltung würde eine Workspace-übergreifende Liste, sowie einen Task-Editor beinhalten. Für die Aufgaben selbst genügen einige einfache Felder wie Erledigungsdatum und Beschreibung. Auch hier gilt wie beim Dokumentenmanagement: Im Standard ist nur eine Notepad-Variante enthalten.

Verwaltung

Natürlich muss es diverse Verwaltungsfeatures geben, wie z.B. die Verwaltung der Workspaces oder der Nutzer.

IT-Anbieter

Ein IT-Anbieter sollte einerseits “Plugins” entwickeln können, die sich in das UI des Haupttools einbinden, andererseits sollte er in eigenständigen Anwendungen ebenso auf die Workspaces und Content-Elemente zugreifen können, um diese z.B. zu verknüpfen oder nur anzuzeigen.

Generell müssen die Kernanwendungen sehr erweiterbar sein, d.h. für jede Aktion wie z.B. “Content Element erstellt” muss man sich per Event “einklinken” können. Die UI muss fast beliebig erweitert werden können.

Letztendlich geht es darum Standard-Tools zu entwickeln, alleine für die Softwarebranche gäbe es da Projektmanagement, Anforderungsmanagement, Test, Releasemanagement oder Support die mir als mögliche Bereiche für Anwendungen einfallen. Andere Branchen haben sicher ähnlichen Bedarf an Speziallösungen.

Im Idealfall bildet sich ein richtiges Ökosystem, bei dem das Composite Project System durch eine Vielzahl an Anwendungen ein großen Wert schafft, weil es diese alle in einem Workspace miteinander verknüpfen kann.

Technischer Ansatz

Ein Kernaspekt des Systems ist die Erweiterbarkeit. Einerseits der Anwendung, aber andererseits auch der Datenbank. Ich möchte die Möglichkeit einer zentralen, aber modularen Datenbank schaffen. Alle anderen Ansätze via Integration erfordern eine komplexe Infrastruktur und erscheinen mir dafür für eine Blaupause für eine Version 1.0 ungeeignet.

Das eigentliche Core Design ist simpel: ContentElement ist eine Basisklasse, die sich von beliebigen Plugin-Anwendungen ableiten lässt:

ContentElements

Relationale Datenbanken erlauben durchaus modulare Designs. Beziehungen können unidirektional sein, d.h. die Plugin-Anwendung kennt die Host-Anwendung, aber nicht umgekehrt. Bei O/R Mappern lichtet sich bei diesen Anforderungen schon das Feld. NHibernate sollte ein solches Design erlauben. Entity Framework würde es wahrscheinlich nicht ermöglichen.

Eine webbasierte Anwendung, welche die Workspaces als Rich Client im Browser umsetzt, ist eine anspruchsvolle und dennoch machbare Variante.

Scope

Ich habe versucht ein Featureset auszuwählen, welches gemäß des Minimum Viable Products funktioniert, im Zweifel muss man die Standardanwendungen noch weiter reduzieren.

Natürlich wären ein umfassendes Rechtemodell oder gar Offline-Fähigkeit oder Intercompany-Integration denkbar, letztendlich muss aber – sollte es einmal ein Go für dieses Tool geben – erst einmal der End-to-End Kernnutzen eines Composite Project System umgesetzt werden.