Nicht-funktionale Anforderungen im Data Warehousing
Das Enterprise Data Warehouse ist mehr als nur Berichte und Dashboards. Es gibt auch weitere technische Komponenten, die umgesetzt werden müssen, sogenannte nicht-funktionale Anforderungen.
In diesem Artikel:
Warum nicht-funktionale Anforderungen wichtig sind
In unseren Schulungen und Beratungsprojekten betonen wir häufig den Grundsatz, den „geschäftlichen Nutzen in den Mittelpunkt zu stellen“. Geschäftlicher Nutzen im Enterprise Data Warehousing bedeutet: "etwas, das für das Unternehmen einen Mehrwert darstellt" (auch wenn es offensichtlich klingt, manchmal sollte man es einfach aussprechen).
In der Regel stellen Unternehmen ein Budget für ein Enterprise Data Warehouse zur Verfügung, weil sie Berichte oder Dashboards mit umsetzbaren Informationen erhalten möchten. Gleichzeitig ist das wichtigste Gegenargument, dass ein Enterprise Data Warehouse mehr ist als nur Berichte und Dashboards. Es gibt zahlreiche technische Komponenten (nicht-funktionale Anforderungen), die ebenfalls umgesetzt werden müssen, unter anderem:
- Infrastruktur und Speicherlösungen
- Netzwerkarchitektur und Sicherheit
- Mehrere Umgebungen
- Leistungsoptimierung
- Aufrechterhaltung der Sicherheit
- Löschung personenbezogener Daten aufgrund von Datenschutzvorgaben
- Dokumentation
- Automatisierte, kontinuierliche Auslieferung
- Eine Teststrategie ist erforderlich
- Nachvollziehbarkeit und Datenherkunft
- Operative Aspekte
- Datenqualität und Datenbereinigung (gute, schlechte und problematische Daten)
- Daten- und Informationsverwaltung
- Metadatenmanagement
- Data-Warehouse-Automatisierung
Das ist völlig in Ordnung, und wir stimmen dem uneingeschränkt zu. Allerdings haben all diese nicht-funktionalen Anforderungen für die Fachanwender nur eine nachgelagerte Priorität. In der Regel ist es ihnen nicht wichtig, ob das Enterprise Data Warehouse mit einer besonders modernen Technologie entwickelt wurde oder ob die Bereitstellung vollständig automatisiert erfolgt.
Wen interessiert das? Mich, weil ich technikorientiert bin. Aber sollte es den Fachbereich tatsächlich interessieren? Die kurze Antwort lautet: na ja, vielleicht.
Nein, denn es war nicht ihre ursprüngliche Absicht, ein Enterprise Data Warehouse einzuführen, um sich mit technischen Details auseinanderzusetzen. Ich vermute, die Idee entstand eher aus dem Bedarf nach Reporting und Dashboards.
Ja, denn sie möchten eine solide Lösung – dokumentiert, getestet, stabil und zuverlässig. Die Umsetzung all dieser nicht-funktionalen Anforderungen hat also durchaus Priorität, aber eben nur eine zweitrangige.
Und niemand erwartet, dass diese nicht-funktionalen Anforderungen bereits im ersten Sprint vollständig umgesetzt werden. In der Regel steht dafür mehr Zeit zur Verfügung. Natürlich wird langfristig erwartet, dass die entsprechenden Funktionalitäten bereitstehen. Aber eben nicht gleich zu Beginn.
Die regelmäßige Lieferung von geschäftlichem Nutzen – also zum Beispiel Berichte oder Dashboards – zeigt dem Fachbereich den Fortschritt im Projekt und macht deutlich, wofür investiert wird und in welchem Umfang. Genau deshalb liegt unser Fokus in den Projekten auf der Bereitstellung von konkretem geschäftlichem Nutzen, ohne dabei die nicht-funktionalen Anforderungen aus dem Blick zu verlieren. Diese haben jedoch eine zweitrangige Priorität.
Fazit
Zusammenfassend lässt sich sagen: Die zeitnahe Bereitstellung von geschäftlichem Nutzen in Form von Berichten und Dashboards ist ein zentraler Bestandteil im Enterprise Data Warehousing. Ebenso wichtig ist jedoch die Berücksichtigung nicht-funktionaler Anforderungen wie Infrastruktur, Sicherheit, Leistungsoptimierung sowie Datenverwaltung. Auch wenn diese Aspekte häufig eine nachgelagerte Priorität haben, sind sie entscheidend für den Aufbau eines robusten, skalierbaren und wartbaren Data Warehouses.
- Michael Olschimke (Scalefree)
Hello Michael,
Agree on it. But how do we ensure the prioritized non technical requirements are been on boarded into subsequent sprints if business is too focused on the
business value.
Is there any middle path approach you suggest when it comes to Non functional requirements of EDW.
Hi Prabhu,
in our sprints, we always have some non-functional requirements included in the workload. While the focus is clearly on business value, every sprint is also delivering some non-functional requirements. The prioritization of both sets of functionalities is done by the business side (while I have to admit that the prioritzation of non-functional requirements is more “driven” than “done” by the business).
Hope that helps,
Mike