Systemstruktur - mehr als mandantenfähig

Die Trennung der Energiewirtschaft in Marktrollen, die komplexer werdenden Verflechtungen der Organisationseinheiten der Unternehmen und nicht zuletzt der Wunsch, Cloud-Strukturen effizienter nutzen zu können haben dazu geführt, dass wir die aus CS 2.0 bekannte Struktur der Hauptmandanten und Mandaten in CS 3.0 weiterentwickelt haben zu dem, was wir die Systemstruktur nennen.

Ausgehend vom obligatorischen Wurzelknoten "System" kann aus einzelnen Elementen eine hierarchische Struktur aufgebaut werden, die extrem flexibel im Hinblick auf die Abbildung von Gesellschaftsstrukturen und die Umsetzung von IT-Betriebskonzepten ist. Dies ermöglicht es, unproblematisch auf einem System mehrere Gesellschaften mit mehreren Marktrollen abzubilden.

Katalogdaten - so zentral wie möglich

Die Infrastruktur der Plattform ermöglicht die zentrale Bereitstellung von Katalogdaten (Plz, Markteilnehmer, Banken, …). Diese Daten können in der Hierarchie weit oben (näher am Wurzelknoten) vorgehalten und von den darunter liegenden Elementen gemeinsam genutzt werden. Soll in einem Ast der zentrale Katalog nicht genutzt werden, kann eine alternative Version tiefer in der Hierarchie zur Verfügung gestellt werden.

Das gleiche Konzept verwendet Schleupen.CS für die Ablage von Druckvorlagen. Auch hier können allgemeine Vorlagen höher in der Hierarchie hinterlegt und auf den unteren Ebenen "überschrieben" werden.

Aggregationen

Mit umgekehrter Blickrichtung, also von den Ästen zur Wurzel hin, erlaubt die Systemstruktur die Implementierung von Aggregationen aus Daten der Äste, z.B. zur Darstellung in Dashboards.

Anmeldebereiche - Einschränkung der Sichtbarkeit von Daten und der Verfügbarkeit von Prozessen

Die Systemstruktur spielt darüber hinaus eine wichtige Rolle bei der Zugriffskontrolle. Anwender erhalten das Recht, sich an bestimmten Elementen der Systemstruktur anzumelden. Sie sehen nur die Daten, die für dieses Element vorgesehen sind und für die sie durch die Vergabe von Funktionsrechten autorisiert wurden. Elemente können vollständig vor Anwendern verborgen werden. So erfahren Mitarbeiter von Werk A z.B. nicht, dass Werk B in der gleichen Systemstruktur gehostet wird. Anmeldebereiche erlauben es darüber hinaus, Mitarbeitern mit querschnittlichen Aufgaben (z.B. im Shared Service), Zugriff auf Elemente in verschiedenen Ästen der Systemstruktur zu geben.

Systemtrennung - separierte Datenhaltung

Das Energiewirtschaftsgesetz schreibt die Entflechtung (engl. unbundling) des Verteilnetzbetriebes von anderen Marktrollen vor (siehe Seiten der BNetzA). Wichtige Hinweise zur Umsetzung der informatorischen Entflechtung mit dem Ziel, fremde Vertriebe gegenüber dem assoziierten Vertrieb diskriminierungsfrei zu behandeln, werden in den Gemeinsamen Auslegungsgrundsätzen der Regulierungsbehörden gegeben. Kapitel 3.2.6. führt aus, dass die Nutzung einer gemeinsamen IT-Infrastruktur zulässig ist, aber unter Transparenzgesichtspunkten eine vollständige Systemtrennung vorteilhaft ist. Verwirrend ist, dass auch hier der Begriff System verwendet, durch die Regulierungsbehörden aber nicht weiter definiert wird, was darunter zu verstehen ist. Im Markt hat sich als wichtiges Kriterium für die vollständige Systemtrennung, neben der Zugriffssteuerung, die Trennung der Datenbestände herauskristallisiert. Wir haben bereits gesehen, dass Länder über eigene DB-Schemas verfügen. Diese werden für jedes Systemstrukturelement getrennt instanziiert. Da Marktrollen über Elemente in der Systemstruktur abgebildet werden und für jedes Element eine eigenständige Datenhaltung existiert, ist das Kriterium der Datentrennung erfüllt.

Session Token

Die Plattform sorgt dafür, dass abhängig davon, für welches Systemstrukturelement ein Service aufgerufen wird, dieser beim Zugriff auf Daten, die richtige DB-Connection zugewiesen bekommt. Die hierfür notwenigen Informationen, werden über ein bei jedem Serviceaufruf mitgegebenes Session Token transportiert.

Eindeutige Identitäten - GUIDs

Was würde passieren, wenn die Daten eines Werkes aus einem System in anderes umziehen sollen?
Nichts! Schleupen.CS verwendet intern Global Unique Identifier - GUIDs als IDs für Daten. Das hat den Vorteil, dass z.B. die ID eines Kunden im Element "Vertrieb A" nicht zufällig identisch zu einem anderen Kunden in "Vertrieb B" sein kann, auch wenn diese in verschiedenen Systemen gehostet werden und damit keine Eindeutigkeitsmechanismen des Datenbanksystems (unique constraint) verwendet werden können.

GUIDs sind leider aufgrund ihrer Größe für die Nutzung durch Menschen etwas "sperrig". Aus diesem Grund verbergen wir diese so weit es geht vor Anwendern und bieten diesen, wo es nötig ist, alternative Repräsentationen (z.B. Kundennummern) an, die im Prinzip aber "nur" ein auf einem Element oder einem Ast der Systemstruktur gültiger Alias für die GUIDs sind.

Referentielle Integrität

Die beschriebene Datentrennung in Verbindung mit der Isolation der Länder untereinander (Microservices) beschränkt die Möglichkeit der Nutzung der von DB-Systemen zur Verfügung gestellten ACID-Transaktionen auf die Daten einer Instanz eines DB-Schema, d.h. auf die Daten eines Landes für ein Systemstrukturelement. Anforderungen bezüglich der referentiellen Integrität der Daten darüber hinaus, werden durch Kompensationen auf der Geschäftsprozess-Ebene implementiert.
Dies bedeutet im Umkehrschluss, dass wir keine verteilten Transaktionen mit Mehrphasen-commit nutzen. Der Verzicht auf solche Transaktionen erhöht zwar den Implementierungsaufwand, stabilisiert das System aber, da das zugrundeliegende XA-Protokoll nicht von allen DB-Herstellen gleich interpretiert und sicher implementiert wird. Die Integration mit der Software andere Hersteller wird vereinfacht.

Architektur: Systemstruktur

Betrachten wir nun den von uns verwendeten Technologie-Stack ...