Über Agile Data Warehousing und Business Intelligence

Data Warehouses und Datenbanken unterscheiden sich nicht grundlegend. Es handelt sich um vertraute Systeme, beides sind relationale Datensysteme, die jedoch für unterschiedliche Zwecke entwickelt wurden. Ein Data Warehouse wird im Allgemeinen aufgebaut, um riesige Mengen historischer Daten zu speichern und einfache und komplexe Abfragen über diese Datensätze hinweg zu verarbeiten. Dies wird oft durch Online Analytical Processing Tools und Algorithmen ermöglicht. 

Hier kommt ein Data Warehouse zum geschäftlichen Einsatz:

Data-Warehouse-Anwendungsfälle konzentrieren sich auf die Bereitstellung von High-Level-Reporting und -Analysen, die zu fundierteren Geschäftsentscheidungen führen. Sie werden für folgende Zwecke eingesetzt:

1. Durchführung von Data Mining, um neue Erkenntnisse aus den in vielen großen Datenbanken gespeicherten Informationen zu gewinnen. Mining wird in großem Umfang durchgeführt und extrahiert viele Daten, um die richtigen Informationen zu liefern. 
2. Durchführung von Marktforschung durch die Analyse großer Datenmengen in der Tiefe. Die Warehouses dienen als Hort für Daten, auf die Anwendungen und Einzelpersonen zum Lernen zugreifen können. 
3. Ein Online-Unternehmen analysiert das Nutzerverhalten, um Geschäftsentscheidungen zu treffen. Die Analyse des Nutzerverhaltens erfordert ein ständiges Hin und Her zwischen der Datenbank und dem zugreifenden Nutzer. Das Data Warehouse erleichtert den Zugriff auf riesige Datenmengen, die bei Bedarf überprüft und sinnvoll genutzt werden können. 

Ein disziplinierter (agiler) Ansatz für die Data-Warehouse-Entwicklung 

Inception Phase: Was sollte in dieser Zeit getan werden? 

Dies ist sozusagen die Stunde Null. Während der Inception Phase bemüht sich das Team, Diskussionen zu führen und eine Richtung für sich selbst zu entwickeln. Dieser Prozess sollte nicht mehr als 2-5 Tage in Anspruch nehmen. Welche Punkte sollten während dieser Inception Phase behandelt werden?

• Teambildung - Es muss ein erstes Team gebildet werden, wobei jedes Mitglied nach besten Kräften beiträgt. Es ist im Allgemeinen schwierig, sicherzustellen, dass jedes Teammitglied in einigen Punkten auf dem gleichen Stand ist, aber das ist es, was Ihre Führungsqualitäten leisten müssen.
• Entwickeln Sie ein gemeinsames Resort oder eine Vision für das Business-Intelligence-Projekt. 
• Bringen Sie Ihre Vision in Einklang mit der Ausrichtung des Unternehmens. 
• Formulieren Sie eine erste technische Entwicklungs-, Ausführungs- und Ressourceneinsatzstrategie.
• Erstellen Sie einen ersten Entwurf des Release Plans.
• Sichern Sie sich die Finanzierung. 
• Schaffen Sie ein kollaboratives und begeistertes Arbeitsumfeld. 
• Identifizieren Sie potenzielle Risiken.

Die Construction Phase

Die Construction Phase ist die eigentliche Bauphase, in der das Team versucht, Ziele zu erreichen. 

• Produzieren Sie eine potenziell konsumierbare Lösung.
• Berücksichtigen Sie die sich ändernden Bedürfnisse der Stakeholder.
• Nähern Sie sich einer bereitstellbaren Version.
• Verbessern Sie die Qualität.
• Beweisen Sie die Architektur frühzeitig.

Die Transition Phase

In dieser Phase geht es darum, die Phase konsumierbar zu machen und den richtigen Zeitpunkt zu finden, um die bestmöglichen Lösungen bereitzustellen und sogar Workarounds für bereits aufgetretene Hürden zu finden. Während der Transition Phase ist das Team bestrebt, sicherzustellen, dass die Lösung konsumierbar ist und dass die Lösung bereitgestellt wird. 

Setzen Sie auf kontinuierliches Testen 

Einige Tests können in die Transition Phase fallen. Idealerweise sollten alle Tests während der Construction Phase stattfinden, mit Ausnahme eines letzten Durchlaufs Ihrer Regressionstestsuite, um sicherzustellen, dass Sie bereit für die Auslieferung sind. 

Dokumentieren Sie die Ergebnisse

Einige Teams lassen die Dokumentation, oder zumindest einen Teil der Dokumentation, bis zum Ende des Lebenszyklus schleifen. Dies ist eine Vorgehensweise, die als Document Late bezeichnet wird, obwohl ich einen kontinuierlichen Dokumentationsansatz bevorzuge, der bereits beschrieben wurde.

Stellen Sie bei Bedarf Änderungen am Datenbankschema bereit 

Ein Teil Ihrer gesamten Bereitstellungsbemühungen wird die Bereitstellung von Änderungen am Datenbankschema sein. Wenn Sie einen Datenbank-Refactoring-Ansatz verfolgt haben, ist dies sehr einfach, da Ihre Änderungsskripte bereits ausgeführt und vollständig getestet werden. Bevor Sie die Schemaänderungen vornehmen, sollten Sie ein Backup der Datenbank erstellen.

Migrieren Sie Produktionsdaten in ein neues Schema

Die einzige potenzielle sekundäre Aktivität besteht darin, alle sekundären Dokumentationen, wie z. B. Ihr logisches Datenmodell (LDM) oder Ihre Metadatendokumentation, fertigzustellen, von denen Sie glauben, dass sie in Zukunft einen echten Mehrwert bieten werden. 

Bewährte Praktiken, um Sie in Gang zu bringen 

Analysieren Sie die Änderungsanforderungen 

Eine geänderte Anforderung spät im Lebenszyklus ist ein Wettbewerbsvorteil, solange Sie darauf reagieren können. Anstatt einen strengen Change-Management-Prozess zu übernehmen, der zum größten Teil auf der Verhinderung von Änderungen basiert, können Sie stattdessen einen agileren Ansatz für das Change Management wählen, bei dem Ihre Stakeholder ihre Meinung leicht ändern können, während der Fortschritt voranschreitet. 

Holen Sie vor der Durchführung von Iterationen Inputs von den Stakeholdern ein 

Die Durchführung kurzer Iterationen, die vielleicht ein paar Wochen dauern, und die Bereitstellung funktionierender Software am Ende jeder Iteration führt oft dazu, dass die Stakeholder viel mehr daran interessiert sind, mehr Software zu erhalten, als mehr Spezifikationen zu erhalten.

Iterationen kontinuierlich herausfinden, immer besser machen 

Iterationen dieser Länge bieten mehr Möglichkeiten, das Projekt effektiv zu steuern, da die regelmäßige Bereitstellung funktionierender Software mehr Feedback liefert. 

Bringen Sie Lean Data Governance in die Praxis ein 

Traditionelle Command-and-Control-Ansätze für die Data Governance scheinen in der Praxis sehr schlecht zu funktionieren. 

Die 2006 DDJ-Umfrage zum aktuellen Stand der Data-Management-Praktiken zeigte, dass 66 % der Entwicklungsteams sich dafür entscheiden, die Datengruppe ihrer Organisation zu "umgehen", und wenn sie dies tun, liegt dies zu 75 % daran, dass sie die Datengruppe als zu schwierig in der Zusammenarbeit, zu langsam in der Reaktion oder als nicht ausreichend wertvoll erachten, um den Aufwand der Zusammenarbeit mit ihnen zu rechtfertigen. 

Zusammenfassung

Data Warehousing und Business Intelligence haben einen langen Weg zurückgelegt und müssen in diesem Zeitalter des technologischen Fortschritts parallel eingesetzt werden können. Dies stellt sicher, dass sie Hand in Hand arbeiten und Prozesse und Teams nahtlos funktionieren, um erstklassige Business-Intelligence-Anwendungen zu liefern.