Architektur
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
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 80-90 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.“
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
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
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
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
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
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“)
