Wirtschaftsinformatik in der Praxis

Hallo zusammen!

Zeitschätzungen der Dauer, bis Projektteile fertiggestellt sein würden, gestalteten sich stets als schwierig. Nicht nur die schiere Größe des Projektes, bedingt durch die zum professionellen Einsatz nötige Tiefe der Anforderungen jedes Projektteils, sondern ebenfalls fehlende Erfahrungswerte bezüglich der Schätzung als Werkstudent trugen maßgeblich dazu bei. Insbesondere dann, wenn man wie ich bei der Bearbeitung universitärer Projekte gerne die Zeit außer Acht lässt und davon unabhängig arbeitet bis ein Projekt einen akzeptablen Stand erreicht. Zusätzlich nahmen etwa Fragen des Deployments in den jeweiligen Produktionsumgebungen, beispielsweise zur Sicherheit und Ausfallsicherheit, viel Zeit in Anspruch, ohne ein für technisch Außenstehende offensichtliches Ergebnis zu erzielen. Trotz dieses intransparenten Fortschritts lohnte sich der Fokus auf das Minimum Viable Product (MVP), auch wenn das Funktionalitätsspektrum bis zur „vollständigen Implementierung“ der Grundfunktionen nicht wuchs. Die letztendlich benötigte Zeit lag meist ein gutes Stück über der ursprünglichen Schätzung, hauptsächlich mit Blick auf die zur Verfügung stehenden Wochenstunden und die daraus resultierende absolute Dauer. Hier lohnte es sich, präventives Erwartungsmanagement mit Bezugnahme auf diese lediglich 10 in der Woche zur Verfügung stehenden Stunden vorzunehmen, um offene und ehrliche Kommunikation zu wahren.

Um grundsätzlich möglichst schnellen Fortschritt zu erzielen, Softwareunterstützung zu erfahren und IT-Sicherheit zu gewährleisten, rentierte sich in allen Fällen eine Recherche nach den aktuellen Best Practices und Standardlösungen, wie der für jede Kommunikation genutzten mTLS-Verschlüsselung. Ebenfalls gaben Industrienormen und technische Standards weiteren Aufschluss über die Handhabe üblicher Problemstellungen, welche sich häufig auch auf andere Bereiche des Systems übertragen ließen. So lieferten etwa standardisierte Datenaustauschmodelle für Energiesystemkomponenten Inspiration für die Modellierung von Zeitreihendatenpunktarten. Typische Anbindungsprotokolle zwischen Gateway und Geräten waren meist von der Industrie genormte, teilweise jedoch proprietäre Protokolle, die eher schlecht als recht dokumentiert waren und keinen Best Practices, wie etwa der Protokollversionierung, folgten, was für deutlichen Zeitaufwand auf meiner Seite sorgte. Falls möglich, lässt sich empfehlen, von der Verwendung proprietärer Schnittstellen abzusehen. In der Architektur etwa ersetzte eine Standardlösung die anfänglich gRPC-basierte Custom-Implementierung eines Persistent-Queue Services. Der eingesetzte Message Broker standardisierte effektiv und zeiteffizient das Protokoll, die Autorisierung und die Zuordnung unterschiedlicher Datenströme zu entsprechenden Services, während gleichzeitig Durability sichergestellt wurde. Wo möglich, lohnte es sich in jeder Situation, Standardkomponenten einzusetzen. Insbesondere in sicherheitsfokussierten Bereichen, wie etwa des Identity & Access Managements, der Zertifikatsverwaltung und auf der Nutzungsseite in der Authentifizierung und Autorisierung. Für diese sicherheitskritischen Systembestandteile sollte wenn möglich immer auf bereits bestehende Software zurückgegriffen werden, um Sicherheitslücken zu vermeiden.

Hallo zusammen!

Damit die Konzeption gestartet werden konnte, benötigte ich zuerst ein Verständnis über die Domain und die möglichen Anforderungen. Ich führte dazu Recherchen und Gespräche mit Stakeholdern durch, die entsprechendes Domain-Knowledge besaßen, mit dem Ziel, einen Anforderungskatalog zu erstellen. Gleichzeitig bat ich diese, sowie Personen mit Informatikbackground der Hagen GmbH, um die Niederschrift einiger Anforderungen, die sie persönlich für wichtig erachteten. Es entstand ein ungeordneter Anforderungskatalog, der sich grob in zwei Kategorien untergliedern ließ: Anforderungen auf Basis des Domain-Knowledge und technische Anforderungen an das System. Der Katalog gab mir einen groben Überblick über das Projekt, obwohl er weder komplett noch detailliert genug war, um ein vollständiges System-Design abzuleiten. Dies stellte sich im Nachhinein nicht als Nachteil dar, fehlte dieser Momentaufnahme nicht nur der Blick in die Zukunft, die neue Anforderungen und Prioritätsänderungen brachte, sondern auch mir die zeitlichen Möglichkeiten, bedingt durch die Wochenarbeitszeit, alle Anforderungen umsetzen zu können.

Durch die Änderung der Prioritäten einzelner Anforderungen und dem Hinzufügen neuer Anforderungen über die Zeit in Kombination mit der zur Verfügung stehenden geringen Wochenstundenzahl mussten Designentscheidungen flexibler Natur getroffen werden, um einen anpassungsfähigen Systemkern zu schaffen. Dies möchte ich am Beispiel des Schema-Designs der Datenbank verdeutlichen:

Für den Start des Schema-Designs erwies sich die allseits bekannte ER-Modellierung als sehr nützlich, um erste Ideen zu skizzieren und stets eigene Gedankengänge selbstkritisch beleuchten zu können. Implizit wurde so nach und nach ebenfalls das möglichst kleinste Universe of Discourse festgelegt, um keine unnötige Komplexität einzubringen. Doch trotz guter Modellierung wurden Auswirkungen mancher Abwägungen erst durch die sukzessive Implementierung des Gesamtsystems deutlich. Hierbei musste das Datenbankschema häufiger iterativ angepasst werden, da sich Edge Cases zeigten. So war beispielsweise ein teilweises Redesign des Schemas nötig, um zeitpunktgenaue Neuzuweisungen von Gateways zu Installationen und an den Gateways angeschlossenen Geräten zu diesen Installationen darstellen zu können. Das Problem, dass Geräte und Gateways, die von einer Installation zur anderen wechseln können, deren bereits produzierte Daten jedoch im System mit der korrekten Zuordnung verbleiben sollten, musste abstrakt genug gelöst werden, um auch zukünftigen Gerätetypen, unbekannter Art und Konfiguration, Sorge zu tragen, sowie Daten korrekt zuordnen zu können, die aufgrund von Teilsystemausfällen unbekannter Art noch nicht (vollständig) übermittelt wurden. Diese iterative Entwicklungsarbeit an der Datenbank wurde durch das Führen eines statischen, versionsverwalteten DDL-Skripts zur Erstellung des Schemas beschleunigt. So konnten Änderungen, die das Schema offen für spätere Erweiterungen machten, schneller erprobt werden.

Hallo zusammen!

Mein Name ist Jens, ich studiere Wirtschaftsinformatik im Master und arbeite seit über 2 Jahren als Werkstudent bei der HE – HagEnergy GmbH in Peine. Das auch Hagen Energiesysteme & Gebäudetechnik genannte Unternehmen wurde erst 2023 von Torben und Christian Hagen ausgegründet. Es ist ein Handwerksbetrieb mit etwa 30 Mitarbeitern. Wesentliche Unternehmenszwecke sind die Installation von Solar- und Energiesystemen bis in den Megawattbereich sowie die Bereitstellung weiterer Dienstleistungen innerhalb dieses Gebietes. Die länger existierende Schwesterfirma Hagen GmbH, die Unternehmen bezüglich der Arbeitssicherheit berät, entwickelt bereits seit einigen Jahren eigene digitale Systeme für beispielsweise das technische Prüfmanagement, Unterweisungsmanagement und Gefahrenstoffverzeichnis.
Mit Blick auf immer stärker vernetzte Energiesystemkomponenten und steuerbare Verbrauchseinrichtungen suchte die HE – HagEnergy GmbH einen Werkstudenten zur Entwicklung eines Energiemanagementsystems.

Das zu entwickelnde Energiemanagementsystem sollte insbesondere Möglichkeiten der Remote-Datenerfassung bieten. Potenzielle weitere Einsatzfelder lagen in den Bereichen des dynamischen Lastmanagements von Ladepunkten und der Verbrauchs- und Einspeiseoptimierung. Während der gesamten Zeit wurden mir große Lern- und Gestaltungsfreiräume von der Konzeption und dem Anforderungsmanagement über die Systemarchitektur und der Implementierung bis hin zum Minimum Viable Product (MVP) gewährt. Innerhalb dieser Bereiche bot sich mir eine fachliche Breite und Tiefe, die ich bei anderen Unternehmen, aufgrund von Bereichsspezialisierungen und fehlender persönlicher Autonomie, nicht hätte einsehen können. Dies ermöglichte mir eine signifikante und eigenständige persönliche Weiterentwicklung, die mir als eher autodidaktisch veranlagtem Menschen sehr zugute kam. Meine wöchentliche Arbeitszeit belief sich aufgrund eigener Entscheidung, vorwiegend wegen des Zeitaufwands für das Studium, auf verhältnismäßig geringe 10 Wochenstunden, von denen seit einem Jahr auch ein kleiner Teil für Entwicklungen innerhalb der Hagen GmbH aufgewendet wurde. Beide Firmen boten aus meiner Sicht stets ein sehr gutes Arbeitsklima. Die Möglichkeit zum Home-Office, kurze Dienstwege und persönlicher Umgang ließen insbesondere das Vorantreiben des Projektes meist weniger als einsame Arbeit, sondern eher als ein gemeinsames Ziel erscheinen.

In den folgenden zwei Blog-Beiträgen möchte ich euch meine Learnings und Erfahrungen aus der eigenständigen Konzeption und Entwicklung des Systems näher bringen. Dazu findet ihr im nächsten Beitrag Learnings, die das Anforderungsmanagement und die Konzeption betreffen. Der darauffolgende Beitrag beschreibt meine Erfahrungen zu Zeitschätzungen und der Nutzung von standardisierten Elementen.