Es gab eine lange Suche nach dem richtigen Modell für die Projektstruktur. Das CAP Theorem sagt uns ja, dass man immer nur maximal 2 von 3 gewünschten Zielen erreichen kann: Konsistenz, Verfügbarkeit, Partitionstoleranz. In der Suche nach der optimalen Projektstruktur habe ich mich immer wieder im Kreis¹⁾ gedreht, weil mal die Konsistenz der Schwerpunkt der Analyse war, dann die Partitionstoleranz, dann die Verfügbarkeit.

Hier sind die Regeln, die eingehalten werden müssen, und die zur letztendlichen Struktur geführt haben:

• Die Projektstruktur muss immer konsistent sein. Es darf also in der Baumstruktur keine Zirkelbezüge geben, und ein Projekt darf nicht mehrmals im Baum erscheinen. Die zweite Regel betrifft die Domäne, sie kann im Lesemodell aufgelockert werden, solange dadurch kein Schaden entsteht²⁾,
• Die Projektnummern müssen global eindeutig sein, und es muss die Möglichkeit geben, sie fortlaufend und lückenlos zu erzeugen,
• Projekte müssen innerhalb eines Hauptprojektes frei verschiebbar sein, am besten auch zwischen Hauptprojekten³⁾,
• Ein Projektleiter muss Teilprojekte anlegen können und diese komplett an Teilprojektleiter abgeben können,
• Wenn Teilprojektleiter an ihren Projekten arbeiten, soll dieses unabhängig voneinander geschehen, d.h. dass der Projektstrukturplan pro Teilprojekt isoliert von den anderen Projektstrukturplänen verwalten und gestalten werden können muss.

Die Lösung wird im folgenden Bild dargestellt: Was hat das auf sich? Relativ einfach:

• Ein neues Hauptprojekt entspricht einem neuen PSP vom Typ Projekt. Das bedeutet, dass das oberste Objekt im PSP ein Projekt sein muss. Innerhalb des Strukturplans kann man weitere Element anlegen. Der Plan ist dabei für die Struktur zuständig, die Objekte⁴⁾ werden lediglich referenziert,
• Auf einer Ebene dürfen immer nur Elemente desselben Typs liegen. Unter Projekt-ID 1.1 gibt es 3 Teilprojekte. Unter Produkt-ID 1.1.1.1 im Teil-PSP Produkt-PSP 1.1.1.1 gibt es 3 Arbeitspakete. Der PSP kann diese Regel sicher stellen,
• Ein Strukturelement im PSP kann auch ein Teil-PSP sein. In dem Bild ist z.B. das Produkt 1.1.1.1 unter Projekt 1.1.1 ein eigenständiger PSP. Dieser ist fest vom Typ Produkt, muss also ein Produkt auf oberster Ebene haben. Der Produkt Teil-PSP hat wiederum ein Teil-PSP vom Typ Arbeitspaket. Auf diesem Weg kann man Teilaufgaben komplett an jemanden anderes delegieren, der den Teil-PSP dann unabhängig und isoliert von den anderen bearbeiten kann,
• Strukturelemente können innerhalb eines PSPs frei verschoben werden. Dabei müssen lediglich die festgelegten Regeln eingehalten werden, nämlich keine Vermischung von unterschiedlichen Elementen auf einer Ebene, sowie keine Zirkel in der Struktur. Da sich das alles im PSP-Aggregate abspielt, ist das kein Problem.

Ein Hauptprojekt wird über 2 Aggregates angelegt. Man braucht dafür aber keinen Prozess. Einfach erst das Projekt anlegen, und wenn das geklappt hat, den PSP vom Typ Projekt mit einer Referenz auf das Projekt auf oberster Ebene in der Struktur anlegen. Erst dann ist das Projekt im Lesemodell sichtbar.

Das läuft genau wie die Anlage eines Hauptprojektes. Wenn z.B. ein Arbeitspaket im PSP angelegt werden soll, wird erst das Arbeitspaket Aggregate erzeugt, danach die Referenz darauf im PSP.

Auch das ist nicht weiter kompliziert. Hier sind 3 Aggregates betroffen. Angenommen es handelt sich um ein Teilprojekt, das als PSP komplett an einen Teilprojektleiter delegiert werden soll. Dann wird das Teilprojekt angelegt, das PSP vom Typ Teilprojekt, und dann wird das PSP im übergeordneten PSP referenziert. Ein Teilprojekt-PSP ist im Lesemodell auch nicht sichtbar wenn es nicht referenziert wird, d.h. es wird kein neues Hauptprojekt rum schweben, sollte der letzte Schritt fehlschlagen.

Angenommen in dem Beispiel soll Projekt 1.1.1 an einen Teilprojektleiter delegiert werden, obwohl es bereits als Teil des Haupt PSP 1 angelegt wurde. Man würde im ersten Schritt einen Teilprojekt-PSP für das Projekt 1.1.1 anlegen: Im zweiten Schritt löscht man die ID-Referenzen auf Projekt 1.1.1 und Produkt 1.1.1.1 aus PSP 1 und legt eine neue Referenz auf das neue Teilprojekt PSP 1.1.1 an.

Auch hier gilt, dass das Ergebnis des ersten Schritts ohne den zweiten Schritt nicht sichtbar sein wird, weil das Teilprojekt PSP von niemanden referenziert wird. Daher ist auch das eine relativ einfache Umwandlung.

Falls ES⁵⁾ eingesetzt wird, ist nicht sicher gestellt, dass die Ereignisse der Aggregates PSP 1 und dem neuen Aggregate Teilprojekt-PSP 1.1.1 in der gewünschten Reihenfolge beobachtet und denormalisiert werden. Das Lesemodell verwendet immer die Ereignisse aus den PSPs, gemeinsam mit denen der referenzierten Aggregates. Nur was in beiden existiert wird auch angezeigt. Was kann passieren?

Das Lesemodell erhält erst die Ereignisse, in denen die Umwandlung in PSP 1 geschieht, d.h. das entfernen der Referenz auf Projekt 1.1.1 und Produkt 1.1.1.1, sowie das Hinzufügen auf das Teilprojekt-PSP 1.1.1. Das Ergebnis wäre, dass die Teilprojekt Referenz ins Leere zeigt, also auch noch nicht im Lesemodell angezeigt wird, und dass Projekt 1.1.1 samt Produkt 1.1.1.1 nicht mehr referenziert werden, also nicht im Lesemodell enthalten sind. Es kann also passieren, dass die gewandelten Objekte vorübergehend verschwinden. Schließliche Konsistenz sagt uns aber, dass die Objekte schließlich wieder erscheinen, und zwar mit 100%er Sicherheit - nur nicht wie lange das dauern wird⁶⁾

Wenn der letzte Schritt wieder rückgängig gemacht werden soll, würde in PSP 1 in einem Schritt die Referenz auf das Teilprojekt PSP aufgelöst werden, und das Projekt 1.1.1 und das Produkt 1.1.1.1 als Referenz wieder zurück in die Struktur aufgenommen werden. Danach kann das Teilprojekt PSP gelöscht werden.

Auch hier kann es passieren, dass das Löschen von dem Teilprojekt PSP als erstes beobachtet wird, und dass das gewandelte Teilprojekt somit vorübergehend aus dem Lesemodell verschwindet.

Das funktioniert ganz ähnlich. Hierbei entsteht aber ein neues sichtbares Aggregate, was bisher nicht der Fall war, es blieb alles noch Teil von PSP 1⁷⁾. Es muss also ein verteilter Prozess her, der am besten von einer Saga gesteuert wird. Wenn aus Projekt 1.1.1 ein Hauptprojekt werden soll, dann wird ein neuer PSP für das Projekt 1.1.1 angelegt, und zugleich das Projekt und das Produkt aus PSP 1 gelöscht: Am einfachsten ist der Prozess darüber zu steuern, dass der neue PSP 1.1.1 im Status schwebend angelegt wird, was eine Garantie dafür ist, dass er fest geschrieben werden kann und auch wieder gelöscht werden kann. Dann können das Projekt und das Produkt aus PSP 1 gelöscht werden, und der Status von PSP 1.1.1 auf fest gesetzt werden.

Abhängig der Reihenfolge der Ereignisbehandlung kann es sein, dass Projekt 1.1.1 und Produkt 1.1.1.1 entweder vorübergehend verschwinden⁸⁾, oder dass sie zweimal erscheinen⁹⁾. Das sind aber beides nur vorübergehende Zustände, die i.d.R. gar nicht beobachtet werden, und wenn ja, ist das System ja schließlich konsistent.

Das wird nicht erlaubt. Das ist genauso gefährlich wie das freie Umhängen in der Gesamten Projektstruktur, zwischen PSPs. Wenn ein Element des Hauptprojektes nämlich bereits ein Element aus der PSP referenziert, in die es gehängt werden soll, haben wir einen Zirkelbezug. Wandeln auf derselben Ebene ist erlaubt, Verschieben innerhalb einer PSP, oder Verschieben nach oben¹⁰⁾. Verschieben auf eine Ebene unter der eigenen birgt die Gefahr der Erzeugung eines Zirkelbezugs. Eventuell kann man das noch unter gewissen Umständen einbauen, aber erst mal wird das nicht erlaubt.

Das einfache Datenmodell¹¹⁾ sieht in etwa aus wie folgt: Wenn man nur die Haupt Projektstrukturpläne anzeigt, und Teilpläne durch Anklicken im UI aufruft, haben wir in der PSP Element Tabelle samt Detailtabellen alles, was wir zur Anzeige brauchen. Eine Denormalisierung bis zum untersten Element wäre auch sinnvoll, das spare ich mir aber für später auf, denn PRO•M kennt keine Teil-Projektstrukturpläne, und daher brauche ich für die Anzeige und Datenhaltung dafür erst mal keine Gedanken machen.