Datenmanagement und Architektur

© Prof. T. Kudraß, HTWK Leipzig Integrierte Informationsverarbeitung Beispiel Hochschul-Informationssysteme (IT-Rahmenkonzept für Verwaltung und Management der bayerischen staatlichen Universitäten vom Bayrischen SMWFK, 2001) Integrierte Informationsverarbeitung ist durch die einmalige und ausschließliche Datenerfassung an der primären Datenquelle, eine medienbruchfreie Bearbeitung sowie eine durchgängige Prozessunterstützung unter Beachtung von Wirtschaftlichkeitsgrundsätzen gekennzeichnet Läßt sich durch die Weiterentwicklung der bestehenden Softwaresysteme oder durch die Einführung eines integrierten Systems realisieren Weiterentwicklung der bestehenden Systeme verfolgt eine objektorientierte (Daten)Integration der in den meisten Uni- Verwaltungen bereits eingesetzten operativen Verfahren

© Prof. T. Kudraß, HTWK Leipzig Erfahrungen im Data Management Larry English (1996) – 70 percent of all computer printouts were used to re-enter data into other databases. – One company reported that percent of developers time was devoted to maintaining interfaces, copying and transforming data from database to database. – Another company reported expending $100 million per year in patching programs and fixing errors in data, created when passing data from one system to another. Dough Erickson (1996) – between 20 percent and 40 percent – one estimate puts the figure at 50 percent – of all labor costs in the U.S. is dedicated to gathering, storage, retrieval, reconciliation and reporting of the information used to run an enterprise.

© Prof. T. Kudraß, HTWK Leipzig Erfahrungen im Data Management (2) Bill Smith (1996) – 70 percent of the lines of code in your company that your are maintaining are doing nothing but moving data from system to system, file to file – 40 percent of the machine cycles are expended moving data, doing no productive work – in einer Bank, für die er arbeitete, waren Kunden-daten redundant in 129 Dateien gespeichert – soweit bekannt – Statistically, the average data fact is stored 10.8 times redundantly.. this is neither smart nor cheap. Fazit: – häufig sind redundante Daten unnötig – Informationen fließen hin und her – höhere Arbeitskosten zum Datenabgleich – Kontrolle durch Entscheidungsträger außerhalb der IT beeinträchtigt

© Prof. T. Kudraß, HTWK Leipzig Datenmanagement und Architektur Anforderungen an das Datenmanagement im Informationszeitalter – Hohe Datenqualität – Aktualität der Daten – Umgang mit Veränderungen (Change Management) Konzept der Architektur bekannt aus klassischen Ingenieurdisziplinen (Bauwesen, Maschinenbau) Bei richtigem Vorgehen (d.h. unter Berücksichtigung der Enterprise Architektur) schnellere und billigere Ergebnisse – Vermeidet, redundante Dinge zu bauen – Wiederverwendung von Daten Unmittelbarer Return on Investment

© Prof. T. Kudraß, HTWK Leipzig Was ist Architektur Definition (nach Zachmann) – Architecture is that set of design artifacts, or descriptive representations (models), that are relevant for describing an objects such that it can be produced to requirements (quality) as well as maintained over the period of its useful life (change) Granularität – Objekte von unterschiedlicher Granularität (Stücklistenbeziehung zwischen Komponenten) – jede Komponente hat eigene Architektur, muss aber in die Architektur der übergeordneten passen (Konsistenz), gilt analog für Programm, System, Applikation – Wenn etwas unterhalb Enterprise-Ebene gebaut wird, ist Konsistenz zum Architektur-Framework zu berücksichtigen – Gewinn auf lokaler Ebene kann zu Enterprise-Problemen führen (z.B. Verletzung globaler Integrität)

© Prof. T. Kudraß, HTWK Leipzig Zachman Architektur-Framework Beschreibt die Design-Artifakte an den Schnittpunkten zwischen den Rollen im Entwurfsprozess und verschiedenen Dimensionen Dimensionen (Spalten) – WHAT: Daten – HOW: Funktionen – WHERE: Netzwerk / Orte – WHO: Menschen / Organisationen – WHEN: Zeit / Ereignisse – WHY: Motivation / Ziele & Strategien Sichtweisen von verschiedenen Rollen (Zeilen) – Kontext / Anwendungsbereich - Planer – Konzeptuelles Modell - Business Owner – System-Modell (logisch) – Designer – Technologie-Modell (physisch) – Software-Entwickler (Builder) – Detaillierte Repräsentation – Auftragnehmer – Lauffähige System bzw. Unternehmen

© Prof. T. Kudraß, HTWK Leipzig Data Warehouse als Lösung? Läßt sich ein historisch bedingtes Fehlen einer unternehmensweiten Datenarchitektur kompensieren? Daten in existierenden Systemen (Legacy-Systeme) sind – unvollständig – inkonsistent – inkorrekt – redundant – unzureichend nutzbar für das Management Aufbau eines Data Warehouse umfasst – Extraktion – Transformation – Bereinigung (Cleansing) – Integration – Verteilung der Daten

© Prof. T. Kudraß, HTWK Leipzig Data Warehouse als Lösung? (Forts.) Hauptaufwand in einem Data Warehouse Projekt ist Reverse Engineering Mit unternehmensweiter Datenarchitektur keine Notwendigkeit für Reverse Engineering! Mit Architektur: – Aufbau des DWH straight-forward (spezialisierte DB laden) – Einfache Konstruktion eines neuen Schemas – Auswertung in verschiedenen Dimensionen – Suche nach Mustern in Datenbeständen Ohne Architektur: – gesteigerte Frustration im Unternehmen – ausufernde Kosten – nach Implementierung: ein weiteres redundantes Legacy File mit neuem Namen (Data Warehouse) Zitat Bill Imnon (Vater der Data Warehouse Idee): I never said to build a mess on top of a mess! I said this is the opportunity to clean up the mess!