Lehrstuhl für Wirtschaftsinformatik und Electronic Government Universität Potsdam
Chair of Business Information Systemsand Electronic GovernmentUniversity of Potsdam
Univ.-Prof. Dr.–Ing. habil. Norbert Gronau Lehrstuhlinhaber | Chairholder
August-Bebel-Str. 89 | 14482 Potsdam | Germany
Tel +49 331 977 3322Fax +49 331 977 3406
E-Mail [email protected] lswi.de
KlausurvorbereitungZusammenfassung Architekturen betrieblicher Anwendungssysteme
1. Einführung ERP-Systeme2. Einführung Architekturmanagement3. Vom Geschäftsprozess zur Softwarearchitektur4. Klassische Software Architekturmuster5. Integration6. Wandlungsfähigkeit7. Aufnahme von Anwendungslandschaften8. Visualisierung von Anwendungslandschaften9. Bewertung von Anwendungslandschaften
Funktionsumfang
Integrationsumfang
Verwaltung
Der Begriff ERP
Quelle: Gronau 2010, S. 3f.
Ressourcen
Informationen über RessourcenZiel: Durchführung von Geschäftsprozessen
Integration von mind. drei RessourcenMaterial, Personal, Kapazitäten, Finanzen und Information
mind. gemeinsame Datenhaltung Artikel, Platz(Lager), Personal, Maschinen, Geldmittel, Reserven, Hilfsmittel, Informationen
Modularität
Standardisierung
Integration
Eigenschaften von ERP-Systemen
Automatisierung
Gemeinsame DatenbasisProzesseAbteilungen
Konfigurierbare Lösungen (Customizing)Komponentenbasierte Lösungen (Konfiguration)Nachträgliche Ergänzung möglich
Annahmen über Standardaufgaben Verfahrensabläufe in UnternehmenAbbildung in Referenzprozessen möglichRealisierung durch Modularität
Durch Standardisierung von AbläufenTeil- oder vollautomatisiertRealisierung durch Workflows
Funktionen und Aufgaben von ERP-Systemen
Quelle: Gronau 2010, S. 5
Aufgaben Funktionen
Disposition- Automatisierung von Routinevorgängen
Administration- Datenhaltung für Geschäftsvorfälle
Information- Kennzahlenbildung
Analyse- Auswertungen, Zeitreihenmodelle
Fertigung- Bestandsführung- Materialbedarfsplanung- Einkauf- Produktionsplanung
Vertrieb- Auftragseingang- Rechnungsstellung- Verkaufsanalysen
Rechnungswesen- Forderungen und Verbindlichkeiten- Buchführung- Anlagenbuchhaltung- Budgetplanung und -überwachung
Finanzwesen- Liquiditätsmanagement- Finanzplanung
Personalwesen- Lohn- und Gehaltsabrechnung- Zuschläge und Prämien
Horizontale und vertikale Integration (weitere)
Quelle: Mertens 2007, S. 6
Aufgabenverteilung betrieblicher Informationssysteme
Quelle: Gronau 2010, S.11
ERP-Systeme sind an eine Vielzahl von anderen Anwendungssystemen angebunden.
Buy-Side In-Side Sell-Side
Supply Chain Management
NetzwerkplanungNetzweite Ausführungsplanung
E-Procurement
B2B-MarktplätzeAuktionenAusschreibungen O
PE
RAT
IVA
NA
LYTI
SC
HERP
Finanz- und Rechnungswesen
Produktion und Logistik
Vertrieb
Personal OP
ER
ATIV
AN
ALY
TIS
CH
CRM
Elektronische Marktplätze (B2B, B2C)
Auktionen
Ausschreibungen
OP
ER
ATIV
AN
ALY
TIS
CH
Lieferanten Kunden
Querschnittssysteme
Wissensmanagement Bürosysteme Dokumentenmanagmentsystem OP
ER
ATIV
AN
ALY
TIS
CH
Unternehmensgrenze
Bereitstellung
Aufgabe der Materialwirtschaft
Quelle: Gronau 2014, S. 55
Versorgung
Mit benötigtem MaterialRoh- Hilfs- und Betriebsstoffe, Baugruppen und Einzelteile, ErsatzteileDienstleistungen, die fremdbeschafft werden
In der richtigen MengeIn der richtigen QualitätZur richtigen ZeitAm richtigen Ort
Informations- und Materialfluss in der Materialwirtschaft
Quelle: Wiendahl
Das ERP-System bildet die Informationsflüsse zur Steuerung und Verwaltung der Materialflüsse ab.
Bestand führen
Beschaffen
Lagern und Bereitstellen
Bedarf ermitteln
Kundenauftrag Vertriebsauftrag
Produktionsprogramm
Lagerung
Teilefertigung
Montage
Wareneingang
Versand
InformationsflussMaterialfluss
Vertriebsdate Ressourcendaten BeschaffungsdatenMaterialdaten
Datenbasis
Auftragsbestand Auftragseingang Marktinformationen Kundendatei Fertigerzeugnisse
Schichtkalender Maschinen Personal
Lieferantendaten Bestandsdaten Bestelldaten
Stammdaten für Material Erzeugnisstruktur-daten Stücklisten
make-to-order(Einzelfertigung)
make-to-stock(Serienfertigung)
Überblick über die Produktionsplanung und -steuerung
Produktionsplanung (Materialbedarfsplanung)
Kapazitätsplanung
Fertigungssteuerung
Grunddatenverwaltung
Absatz-und Produktionsgrobplanung
Primärbedarfsplanung
Arbeitsplanung
Absatz-Angebotserstellung / Vorkalkulation
Auftragseingang
Projektplanung
Controlling
Material Arbeits-pläne
Maschinen Hilfs-mittel
Doku-mente
Quelle: Gronau 2014, S. 103
Unternehmensübergreifende Planung und Steuerung
Quelle: Gronau 2014, S. 216
Beispiel einer Supply Chain
Quelle: Gronau 2014, S. 206
Rohstoff-lieferant
Teile-lieferant
Endprodukt-hersteller
EndkundeEinzel-handel
Großhandel/ Distributions-
zentrum
Komponenten-lieferant
Materialfluss
Informationsfluss
Organisatorische Bedeutung
Stammdaten repräsentieren reale Geschäftsobjekte mit dem Ziel, die Prozesse mit den benötigten Daten / Informationen zu versorgen.
Was sind Stammdaten?
Quelle: Schemm 2009, S. 20
Technische Definition
Fundamentale Grundlage einer OrganisationGrundlage für effiziente Geschäftsprozesse
Geringe ÄnderungshäufigkeitEindeutige Nummerierung (UID)Kontinuierliches Datenvolumen
Daten
Zustandsdaten Abwicklungsdaten
Stammdaten Bestandsdaten Bewegungsdaten Änderungsdaten
Organisatorische Herausforderungen
Mit zunehmender Integration der Lieferketten steigen die Anforderungen.
Herausforderungen im Stammdatenmanagement
Heterogene Anwendungslandschaften
Unterschiedliche Terminologie und FelddefinitionenQualitätsanforderungen erfüllen (z.B. Konsistenz) Komplexe Abhängigkeiten (z. B. Changemanagement)Veraltete Architekturen der AnwendungssystemeRedundante Datenhaltung
Organisatorische Bedeutung und Verwendung von StammdatenAbhängigkeit zu Funktionen (z. B. Kalkulation)Aufbau von Know-how in den Fachabteilungen Definition und Kontrolle der Stammdatenmanagementprozesse
ERP-System
PLM-System
CRM-System
Verzeichnis
Kriterien für Stammdatenqualität
Quelle: Apel 2010, S. 20 ff
Stammdaten-qualität!
Korrektheit)und)Fehlerfreiheit!
Konsistenz!
Aktualität)und)Gül7gkeit!
Vollständigkeit! Redundanz;freiheit!
Einheitlichkeit)und)
Eindeu7gkeit!
Prozesse des Stammdaten-managements!
Verwendete Datenquellen!
Zeitvorteile durch Standardsoftware
Quelle: Gronau 2012, S. 27
Standardsoftware ist in ihrer grundlegenden Form sofort verfügbar!
Problem-erkenntnis Entwicklung/Test Anpassung
Problem-erkenntnis
Anforderungs-spezifikation
AnpassungAlternativen-auswahl
ProjektstartAufnahme
Produktivbetrieb
Vorgehen bei Individualentwicklung
Vorgehen bei Einführung von Standardsoftware Zeitgewinn
Anforderungs-spezifikation
Vorgehen und Dauer der Auswahlphase von Anwendungssystemen
Quelle: CER 2014
Vorgehens- modell
konfigurieren
Istprozesse analysieren
ROI-Analyse
Ziel des ERP-Projektes definieren
Auswahl-Anforderungen
festlegen
Szenarien für Präsentation
festlegen
Markt- screening
Präquali- fizierung Webcast
Anbieter- präsen-tation
Referenz- besuche
Soll-prozess-definition
Prozess-workshop
Vertrags- verhand-lungen
Tätigkeit Skalierbare Aufgabe
Tätigkeit Selektierende Aufgabe
Tätigkeit Optionale Aufgabe
Stei
geru
ng d
er A
usw
ahls
iche
rhei
t
Zeit
Fehler bei der Auswahl von Standardsoftware
Quelle: vgl. Gronau 2012, S. 111ff
Auslösende Motive
Unklare ZielsetzungenÜberzogene Erwartungen
fördert
Fehlende Analyse, Konzeption undWirtschaftlichkeitsbetrachtung
bestreitetNotwendigkeit
Umfangreiche ZeitdauerHohe verbleibende
Unsicherheit gegenseitige
Abhängig-keit
baut auf
lässt zu
Auswahlentscheidung
Sichten des Referenzmodells von SAP ERP
Quelle: Gronau 2014, S. 279
Die Einführung eines ERP-Systems zählt zu den komplexesten, teuersten und risikoreichsten Projekten, die ein Unternehmen aufgreifen kann.
Testdaten
Vorgehensmodell der Einführung von Standardsoftware
Projektorganisation überprüfen
Feinspezifikation „Workshop-Phase“ Testsystem Testdaten Testnutzer
Prototyping Anwendungs-system
Testnutzer
Pilotbetrieb Anwendungs-system Echtdaten
Produktivbetrieb Anwendungs-system
Echtdaten Produktiv-nutzer
Proj
ektd
okum
enta
tion
Qua
lität
ssic
heru
ng
Pilotnutzer
Customizingfaktoren
Quelle: Gronau 2014, S. 277
Customizing dient der individuellen Anpassung an technisch und organisatorische Anforderungen.
Lebenszyklus von Anwendungssystemen
Quelle: In Anlehnung an Heinrich 2002, S. 37
Systemnutzen
Systemnutzung
Einführung Wachstum Sättigung/Reife Rückgang AbschaffungEntwicklung/Kauf
Systemkosten
Was ist ein ERP System?Welche Aufgaben und Funktionen können mit einem ERP-System realisert werden?Was sind Stammdaten und warum sind diese Daten für Unternehmen so wichtig?Wie kann die Auswahl und Einführung von ERP-Systemen realisiert werden?
Lernfragen
1. Einführung ERP-Systeme2. Einführung Architekturmanagement3. Vom Geschäftsprozess zur Softwarearchitektur4. Klassische Software Architekturmuster5. Integration6. Wandlungsfähigkeit7. Aufnahme von Anwendungslandschaften8. Visualisierung von Anwendungslandschaften9. Bewertung von Anwendungslandschaften
Wichtig für Positionsbestimmung des Unternehmens und des IT-Managements
Definition
Unternehmensarchitektur
Quelle: Niemann 2005, S. 21
Eine Unternehmensarchitektur ist eine strukturierte und aufeinander abgestimmte Sammlung von Plänen für die Gestaltung der IT-Landschaft eines Unternehmens.
Dimensionen
Verschiedene Detailstufen (z.B. Bezug zu Prozessen oder Standorten)Ausrichtung auf die spezielle StakeholderDarstellung von unterschiedlichen Aspekten von IT-Systemen (z.B. Schnittstellen)Entwicklung der Architektur über die Zeit (z.B. ein SOLL - IST Vergleich)
Umwelttubulenzen und Komplexität machen eine Unternehmensarchitektur unabdingbar!
Umweltturbulenzen
Notwendigkeit einer Unternehmensarchitektur
Quelle: Niemann 2005, S. 14-15
Marktbewegungen, Veränderungen der Geschäftsfelder, Anpassung der Organisation = UmweltturbulenzenUmweltturbulenzen erzeugen Anforderungen an die Unternehmens IT Unternehmensarchitektur bildet ein Analyse- und Steuerungsinstrument
Komplexität des Unternehmens
GrößeStrukturRäumliche Verteilung
Aufbau einer Unternehmensarchitektur
Quelle: Dern 2006, S. 0
Strategie
BusinessArchitektur
Informationsarchitektur
IT-Architekturen
IT-Basisinfrastruktur
Business IT
Business Treiber Informationsbedarf
Organisationsstruktur
Businessfunktionen
Prozessarchitektur
IS-Portfolio Technologiestrategie
Architekturstrategie
ArchitekturprinzipienIst Soll
Zugeordnetes Modell des SE-Prozesses
Anwendungs-architektur
Plattformstrategie Security-strategiePlattform 1 Plattform ...
Informationssystemarchitektur
Quelle: Gronau 2006, S. 47
Zusammenwirken technologischer, organisatorischer und psychosozialer Aspekte bei der Entwicklung und Nutzung von betrieblichen soziotechnischen Informationssystemen
Informationssystem
Anwendungssystem
Softwaresysteme zur Datenhaltung, Datenverarbeitung und Datenpräsentation in Bezug auf eine konkrete betriebliche Aufgabe oder Funktion
Informationssystem
Verbindung von Menschen und Maschinen, die Informationen erzeugen oder benutzenSoziotechnische Informationssysteme
Anwendungssystem
Mensch innerhalb eines Unternehmens
Unternehmensarchitektur
Ansammlung von Vorgehensweisen, Methoden und Elementen zur Planung, Realisierung und Nutzung betrieblicher Informationssysteme
Arten von Architekturen
Quelle: Reussner/Hasselbring 2005, S. 1 sowie Sinz 2004, S. 315
Softwarearchitektur
Grundlegende Organisation eines AnwendungssystemsPrinzipien, die den Entwurf und die Evolution des Systems bestimmen
Betrachtung aller Elemente eines UnternehmensAnwendungen als Teil der IS-Architektur
Präsentationsschicht
Datenhaltungsschicht
Anwendungsschicht
Unternehmensarchitektur
Organisations-architektur
Informationssystem-architektur
Organisations-struktur
Geschäfts-prozesse Elemente Vorgehens-
modelle
Analysieren
Für eine konsolidierte Unternehmensarchitektur müssen alle Phasen der Entwicklung zyklisch überprüft werden.
Unternehmensarchitekturzyklus
Quelle: Niemann 2005, S. 38
Strategisches Architekturmanagement
Planen / überprüfen
Strategisches ArchitekturmanagementOperatives Architekturmanagement
Ausführen / dokumentieren
Operatives Architekturmanagement
Aufgaben und Ziele
Die richtigen Dinge richtig und sicher tun.
IT-Governance
Quelle: Niemann 2005, S. 29
Organisation, Steuerung und Kontrolle der IT eines UnternehmensZiel = Konsequente Ausrichtung der IT-Strategie an der UnternehmensstrategiePlanung, Steuerung und Anpassung der IT-RessourcenErfüllung der Erwartung an die IT = EffektivitätPlanen, steuern und Performance messen = EffizienzRisiken, die durch den falschen Einsatz der IT entstehen können, minimieren = Sicherheit
Effizienz
Sicherheit
Effektivität
Anforderungs- und Portfoliomanagement
Zusammenspiel der Prozesse von Anforderungs-, Portfolio-, Programm-, Service- und Unternehmens-architekturmanagement unter der Zielsetzung der IT-Strategie und der Steuerung durch die IT-Governance
IT-Management Framework
Quelle: Niemann 2005, S. 39
Fachliche Anforderungen erhebenAnforderungen strukturieren und bewertenProjektportfolio aufbauen und bewerten
Programm- und Servicemanagement
Programme, Projekte und Services steuern
Architekturmanagement
Technische Anforderungen erarbeitenBebauungsplan erstellenBebauungsplan umsetzen
IT-Strategie
IT-Governance
Anforderungs- und Portfolio-management
Programm-und Service-management
Unternehmens-architektur-management
Architekturmanagement
Prozess zur Erstellung einer UnternehmensarchitekturPlanung, Organisation, Kontrolle und Steuerung der Entwicklung einer UnternehmensarchitekturUmfasst die Verbindung von Geschäfts-, Anwendungs- und SystemarchitekturAufteilung in strategisches und operatives ArchitekturmanagementPersonalposition in einem Unternehmen Chef Information Officer (CIO)
Was ist Architekturmanagement?
Quelle: Niemann 2005, S. 23
Planung, Entwicklung, Nutzung und Pflege der Unternehmensarchitektur
Aufagben des Architekturmanagements
Quelle: Niemann 2005, S. 23
Architekturmanagement beschreibt Verfahrensweisen zur engen Verzahnung von Geschäft, IT-Anwendungen und IT-Infrastrukturen
Architektur-management
Operative Prozesse zur durchgängigen Umsetzung der Unternehmensarchitektur
Definition der Dokumentationsverfahren
Analyse- und Planungsmethodik
EvaluationsverfahrenWerkzeuge und deren Integration in die Werkzeuglandschaft
Vorgehensweisen und Verantwortlichkeiten
Kennzahlen und Controlling
Strategische Prozesse zur Dokumentation, Analyse und Planung
Verbindung von Programm und Servicemanagement zum Architekturmanagement erfolgt über das operative Architekturmanagement
Einordung von strategischem Architekturmanagement
Quelle: Niemann 2005, S. 177
IT-Strategie
IT-Governance
Anforderungs- und Portfolio-management
Programm-und Service-management
Unternehmens-architektur-management
Strategisches Architekturmanagement
Operatives Architekturmanagement
Aufgaben
Erheben der GeschäftsarchitekturAuswertung des Anforderungs- und PortfoliomanagementsAnalyse der AnwendungslandschaftSynchronisation zwischen Anforderungs- und Portfoliomanagement und den Ergebnissen der AnwendungslandschaftsanalyseErstellen eines "Bebauungsplans"
Strategisches Architekturmanagement
Quelle: Niemann 2005, S. 173
Bebauungsplan
IST-Zustand des AnwendungsportfoliosGeplante SOLL-Zustände
Strategisches Architekturmanament ist nicht...
AnforderungsmanagementPriorisierungBudgetierung der Neuprojekte und Wartungvorhaben
Anwendungslandschaft planen und entwickeln
Geschäftsarchitektur planen und entwickeln
Diese Teilprozesse sind Aufgabe des strategischen Architekturmanagements
Prozesse des strategischen Architekturmanagements
Quelle: Niemann 2005, S. 172-173
Unternehmensarchitektur planen und entwickeln
Festlegen der Struktur, von Inhalten und der Visualisierung in Form von DokumentenDefinition von Methodik und Prozesse des Architekturmanagements
Auswertungsverfahren festlegen und anwendenDefinition der Messverfahren und "key performance indicators"
Erheben der Elemente der GeschäftsarchitekturDokumentation von Zielen, Rahmenbedingungen, Risiken, Geschäftsprozessen, Produkte, Organisationseinheiten, fachliche Services und Komponenten
Direkte Einbeziehung in Projekte und Wartungsarbeiten sowie zur Synchronisation mit dem Programm- und Servicemanagement
Aufgaben
Operatives Architekturmanagement
Quelle: Niemann 2005, S. 175
Umsetzung der Vorhaben aus dem strategischen ArchitekturmanagementUmsetzung der Software- und SystemarchitekturTransformation in die operative WirklichkeitDefinition von ReferenzarchitekturenDefinition von Einsatzszenarien
Systemarchitektur planen und entwickeln
Referenzarchitekturen planen und entwickeln
Diese Teilprozesse sind Aufgabe des operativen Architekturmanagements
Prozesse des operativen Architekturmanagements
Quelle: Niemann 2005, S. 175-176
Softwarearchitektur planen und entwickeln
Erhebung aller Parameter, die Architekturentscheidungen beeinflussenAuswahl geeigneter Referenzarchitekturen oder Entwicklung neuer ArchitekturszenarienEntwicklung technischer PrototypenBewertung von ArchitekturszenarienUmsetzung der Architekturvorhaben
Technologieplanung für Projekte oder LinienvorhabenSpezifikation von SystemarchitekturenAusführung von Technologieprojekten
Identifikation und Spezifikation von EntwicklungslinienBewertung der EntwicklungslinienAbleiten und Spezifizieren von ReferenzarchitekturenNutzung und Weiterentwicklung der Referenzarchitekturen
Ziele der Planung:
Analysieren der Dokumente des strategischen Architekturmanagements wie Landkarte oder zugrunde liegende Datenmodelle.
Ziele der Analyse:
Analyse und Planung
Quelle: Niemann 2005, S. 125
Analyse der vorhandenen IT-SystemeIdentifikation von SchwachstellenVerbesserung des aktuellen AnwendungsportfoliosAbhängigkeit zwischen den Systemen der Anwendungslandschaft
Integration vorhandener SystemeAnregung neuer LösungenTechnologieberatung
Analysemethoden
Quelle: Niemann 2005, S. 128-130
Untersuchungsbereich Beschreibung des Analyseverfahrens Typische Fragestellungen
Abhängigkeiten
Abdeckung
Schnittstellen
Heterogenität
Komplexität
Verknüpfte Elemente werden aus der Unternehmensarchitektur selektiert
Welche anderen Elemente sind betroffen, wenn wir die Infrastrukturkomponente X ablösen?
Abdeckung fachlicher Bereiche, z.B. Prozess/Produktmatrix
Welche Redundanzen oder Lücken gibt es bei der IT-Unterstützung für den Prozess X und das Produkt Y und die Organisationseinheit Z?
Analyse der Schnittstellen zw. Anwendungssystemen hstl. Art, Anzahl, Komplexität, Häufigkeit/Aktualität, Performance, Stabilität, Verfügbarkeit
Gibt es Brüche bei der Unterstützung des Prozesses X? Sind Produktübergreifende Gemeinsamkeiten in Prozessschritten auch übergreifend gelöst?
Die Heterogenität der IT-Assets in definierten Einsatzfeldern wird analysiert, z.B. Prozess/Produktmatrix.
Anzahl der Entwicklungslinien pro EinsazfeldAnzahl der Infrastrukturkomponenten pro Zeile
Anzahl der Komponenten in der Unternehmensarchitektur und Anzahl ihrer Beziehungen
Wie viele Anwendungssysteme mit wie vielen Schnittstellen existieren?Wie viele Infrastruktursysteme mit wie vielen Schnittstellen existieren?
Weitere Analysemethoden
Quelle: Niemann 2005, S. 128-130
Untersuchungsbereich Beschreibung des Analyseverfahrens Typische Fragestellungen
Konformität
Kosten
Nutzen
Compilance Rules:Einhalten von Standards und Ermittlung des Abweichungsgrades.
Werden existierende Standards eingehalten?Werden die definierten Referenzarchitekturen implementiert?Anteil der Komponenten, die außerhalb des Standards liegen?Werden gesetzliche Vorgaben, Marktstandards und Normen eingehalten?
Reporting über kumulierte Erstellungs-, Betriebs- und Wartungskosten.
Welche Kosten sind durchgängig über alle Ebenen der Unternehmensarchitektur mit der IT-Unterstützung des Produktes X verbunden?
Nutzenkalkulation z.B. in prozentualem Beitrag zur Erreichung von Unternehmenszielen
Welchen Beitrag zur Unterstützng der Unternehmensziele leistet das Anwendungssystem X?
Eine konsolidierte Unternehmensarchitektur ermöglicht umfangreiche Analysen.
IT-Bebauungsplan
Quelle: Niemann 2005, S. 155
Nutzung der Erkenntnisse und Ergebnisse der Analysephase
Aufgaben
Planung der Infrastrukturlandschaft (technische Ausrichtung)Planung der Anwendungslandschaft (fachliche Ausrichtung)Notwendige Ergänzung zum PortfoliomanagementDient der Zukunftssicherheit und StabilitätBeseitigung unnötiger HeterogenitätErstellt den SOLL-Zustand der Anwendungslandschaft
Darstellung aller Anwendungssysteme zu ...
Geschäftsprozessen / TeilprozesseDen implementierten GeschäftskomponentenDen beinhalteten SoftwarekomponentenDen genutzten InfrastrukturkomponentenDen Organisationseinheiten
1. Einführung ERP-Systeme2. Einführung Architekturmanagement3. Vom Geschäftsprozess zur Softwarearchitektur4. Klassische Software Architekturmuster5. Integration6. Wandlungsfähigkeit7. Aufnahme von Anwendungslandschaften8. Visualisierung von Anwendungslandschaften9. Bewertung von Anwendungslandschaften
Zusammenfassung
Darstellung von KomponentenBeziehung zwischen den KomponentenBeziehung zur UmgebungStruktur eines AnwendungssystemsProgrammierung im GroßenVerdeutlicht Zusammenhänge und Strukturen
Definitionen von Software-Architekturen
Ziele einer Softwarearchitektur im Lebenszyklus von Standardsoftware
Anpassbarkeit (Prozesse, Daten, Funktionen)
Erweiterbarkeit (Können neue Funktionen ergänzt werden?)
Wartbarkeit/Updatefähigkeit
Skalierbarkeit
Beherrschung der Komplexität
Entwicklungder Anwendung Einführung Benutzung /
Weiterentwicklung Abschaffung
Integrationsfähigkeit (Fremdanwendungen)
Testbarkeit (Ist der Systemzustand validierbar?)
Die Beschreibung sollte in einer einheitlichen Struktur erfolgen.
Verschiedene Sichten ermöglichen die Berücksichtigung aller Interessensgruppen (Stakeholder)
Sichten in Software-Architekturen
Quelle: Starke 2005: Effektive Software-Architekturen
Die Umgebung, der in dieser Sicht
beschriebenen Bausteine
Begründungen für Entwurfsentscheidu
ngen, Analysen, Annahmen
Querverweis
Kurzbeschreibung
Kontext
Hintergrund-informationen
Zugehörige Sichten Sonstiges
Glossar
Variabilitäten
Elementkatalog
Erwartete Änderungen: WAS
kann sich WO ändern?
Sichten
benutzt
Die Elemente und Beziehungen dieser
SichtDiagramme
Bausteinsicht
Laufzeitsicht
Die verschiedenen Sichten bilden ein umfassendes Bild der Software-Architektur.
Kontextsicht
Vier Arten von Sichten
Quelle: Starke 2005: Effektive Software-Architekturen
Verteilungssicht
Zeigen den Zusammenhang des Systems mit seiner Umgebung aus der VogelperspektiveSchnittstellen nach außenInteraktion mit wichtigen StakeholdernNotation z.B. durch Use Cases
Statische Struktur der Architekturbausteine des Systems, Subsysteme, Komponenten und deren Schnittstellen zueinander Notation z.B. durch UML-Klassendiagramme
Beschreibt das Zusammenwirken der Bausteine zur LaufzeitDynamische StrukturenNotation z.B. durch UML-Sequenz, Aktivitäts- oder Kollaborations/Kommunikationsdiagramme
InfrastruktursichtBeschreibung der Hardwarekomponenten (Rechner, Prozessoren, NetztopologienSystem aus BetreibersichtNotation z.B. durch UML-Einsatzdiagramme
1. Einführung ERP-Systeme2. Einführung Architekturmanagement3. Vom Geschäftsprozess zur Softwarearchitektur4. Klassische Software Architekturmuster5. Integration6. Wandlungsfähigkeit7. Aufnahme von Anwendungslandschaften8. Visualisierung von Anwendungslandschaften9. Bewertung von Anwendungslandschaften
Stilbeschreibung
Die Drei-Schichten-Architektur ist insbesondere für betriebliche Anwendungssysteme etabliert
Schichtensysteme
Quelle: Shaw 1996, S. 25
Hierarchische OrganisationZur Verfügungstellung von Services für die übergeordnete SchichtBenutzung der Services der darunterliegenden SchichtStilkomponenten = SchichtStilkonnektoren = Interaktionsbestimmende Protokolle zwischen den Schichten
Kern-schicht
Basis-Funktionen
Nützliche Systeme
BenutzerKomposition von verschiedenen Elementen
Ablaufsteuerung
Die grundlegendeste Anwendung des Schichten-Musters ist die Client/Server-Architektur.
Anwendung des Schichten-Musters in betrieblichen Anwendungssystemen Client-Server-Architekturen
Quelle: Hasselbring 2006
Enthält die Anwendungslogik, häufig umgesetzt als FAT-Client
Stellt die für die Bearbeitung der Funktionen dem Clienten die notwendigen Daten zur Verfügung
Server
Client
Layer 1: Dienstanbieter
Layer 2: DienstnutzerEigenschaften
Trennung von Datenhaltung und DatenverarbeitungKeine Verantwortung für die Datenspeicherung und sämtlicher damit verbundener Konzeptionen der Clienten-KomponenteClienten-Komponente nutzt die zugesicherten Dienste der Server-Komponente
Die Client-Server-Architektur lässt sich weiter unterteilen.
Anwendung des Schichten-Musters in betrieblichen AnwendungssystemenDrei-Schichten-Architektur
Quelle: Hasselbring 2006
Präsentation
Geschäftslogik
Datenhaltung
Dienstanbieter
Layer 1
Layer 3
Layer 2
Dienstnutzer
Dienstnutzer
Dienstanbieter
Server
Client
Eigenschaften
Weitere Dekomposition der Client-KomponenteBusinesslogik wird getrennt von der PräsentationVariante 1: Geschäftslogik ist Teil des Servers (Thin-Client)Variante 2: Geschäftslogik ist Teil des Clienten (FAT-Client)
Anwendung des Schichten-Musters in betrieblichen Anwendungssystemen Web-Informationssystem-Architektur
Quelle: Hasselbring 2006
Web-Client
Web-Server
Geschäftslogik
Datenhaltung
Anwendungslogik
Layer 4
Layer 3
Layer 2
Layer 1
Eigenschaften
Präsentationslayer weiter unterteilt in Web-Server und Web-ClientWebserver übernimmt Aufbereitung der DatenWebclient ist ein WebbrowserAufbereitung der Daten für die Präsentation im Webserver = Serverseitige Präsentation
Grundprinzipien einer Service orientierten Architektur
Quelle: Dostalu.a.,2005,S.12
Dienstverzeichnis
Dienstanbieter Dienstnutzer
1. Veröffentlichen 2. Suchen 3. Verweis auf Dienst
4. Abfrage der Beschreibung
5. Nutzung des Dienstes
Lose Kopplung
Dynamisches Finden und Einbinden von Diensten Bindung zur Laufzeit
Grundlegende Merkmale einer SOA
Quelle: Dostal2005,S.9
Dienstsuchverzeichnis
Ermöglicht das Finden relevanter Dienste Zugriff auf Instanzen des Diensteverzeichnisses Wissen über die Kategorie in welcher der Dienst eingebunden ist Anmeldung des Dienstes im Verzeichnis
Schnittstellen zur Kommunikation
Verwendung von (möglichst) offenen Standards fördert die AkzeptanzMaschinenlesbar
Wiederverwendung
Gekapselte Dienste Mehrfach verwendbar in verschiedenen Umgebungen ohne Aufwand
Komponentenorientierung ist durch die Trennung von Schnittstelle und Implementierung gegeben
Beispiel Servicenutzung im Geschäftsprozess
Web Service basierte SOA und Standards
Quelle: Dostal u.a.,2005
Simple Object Access Protocol (SOAP)
Beschreibt das XML-basierte Nachrichtenformat der Kommunikation und dessen Einbettung in ein Transportprotokoll
Web Services Description Language (WSDL)
XML-basierte Beschreibungssprache, um Web Services (Dienste) zu beschreiben
Universal Description, Discovery and Integration protocol (UDDI)
Beschreibt einen Verzeichnisdienst für Web Services, Spezifiziert eine standardisierte Verzeichnisstruktur für die Verwaltung von Web Services Metadaten (allg. Anforderungen, Web Services Eigenschaften, benötigte Informationen zum Auffinden von Web Services)
Anwendungsszenario: UDDI als branchenspezifischer Marktplatz
Quelle: Dostal u.a., 2005, S. 104ff.
Administration
Dienstanbieter Dienstnutzer
Autorisieren
Bindung
RichtlinienRichtlinien
Bindung
UDDI-MarkplatzSuchenVeröffentlichen
Geschäftsbeziehung
1. Einführung ERP-Systeme2. Einführung Architekturmanagement3. Vom Geschäftsprozess zur Softwarearchitektur4. Klassische Software Architekturmuster5. Integration6. Wandlungsfähigkeit7. Aufnahme von Anwendungslandschaften8. Visualisierung von Anwendungslandschaften9. Bewertung von Anwendungslandschaften
Integration bezogen auf IT
Der Integrationsbegriff besitzt sowohl Zustands- als auch Prozessaspekte.
Allgemeine Begriffsfindung (Wörterbuch)
Was bedeutet Integration?
Quelle: Thränert 2005, S. 11 f; Lebender 2003, S. 19f
Wiederherstellung eines GanzenEinbeziehung, Eingliederung in ein größes GanzesZustand in dem sich etwas befindet, nach dem es integriert worden ist
Unternehmensinterne Integration von Anwendungssystemen = Enterprise Application Integration (EAI)Unternehmensübergreifende Integration von Anwendungssystemen = Business-to-Business-Integration (B2B-Integration)
Mehrdimensionales Thema mit verschiedenen Sichten und Aspekten
Integrationsstärke
Integrationsbereich
Der Zustandsaspekt der Integration beschreibt das Was und Wie der Integration.
Integrationsobjekt
Zustandsaspekte der Integration
Quelle: Thränert 2005, S. 14-19
Was soll integriert werden?Z.B. Geschäftsstrategien, Währungssysteme, Anwendungssysteme, etc.
Kennzeichnung durch IntegrationsobjektZ.B: Integrationsobjekt = CRM-System -> Integrationsbereich = Anwendungssysteme in einer AnwendungssystemlandschaftUnterschiedliche Methoden und Herangehensweisen für Integrationsbereiche
Wie soll integriert werden?Ausmaß an Autonomie eines IntegrationsobjektesFeste, mittlere und lose Verbindung, gemessen am Aufwand der Desintegration
Integrationsansatz
Die Prozessaspekte der Integration beschreiben den Vorgang der Integrierung in Projektform.
Prozessaspekte der Integration
Quelle: Thränert 2005, S. 19f
Prozess der Integrierung
Innerhalb eines IntegrationsprojektesÜberführung von einem Integrationszustand in einen anderenAuswahl eines Integrationsansatzes mit Methoden und Mittel
Methode, die zur Integrierung angewandt wirdIntegrationsvorgehenIntegrationsmethodenIntegrationswerkzeuge und -technologien
Zentraler Bestandteil einer Integrationsinfrastruktur ist eine Middlewarekomponente.
Integrationsinfrastruktur
Quelle: Lebender 2003, S. 14; Bild: https://docs.puppetlabs.com/mcollective/images/middleware-magic.gif
Middleware als grundlegende TechnologieMiddleware = Software auf einer Zwischenschicht; ermöglicht die Kommunikation mehrerer SystemeMiddleware-Technologie auf jeder Ebene des SchichtenmodellsHauptvertreter sind Application Server & Message Broker
Middleware
Aufgabe des Message Brokers Adapter bzw. KonnektorMessage Broker
Integrationsinfrastruktur
Quelle: Lebender 2003, S. 17
Nachrichtenvermittler zwischen zwei oder mehreren SystemenVerwaltung und Überwachung der Schnittstellen Eine Schnittstelle pro System
Weiterleitung der Datenpakete an die jeweilige AnwendungB.B. Umwandeln der Daten in geforderte Datenformate
Ausgleichen und Verbergen der Unterschiede verschiedener SchnittstellenVerwaltung der Beziehung zwischen Anwendungen
Application Server Application Server = Integrationsplattform, wenn
Die Middlewaretechnologien der 2. Generation ermöglichen eine Integration entlang der Wertschöpfungskette.
Middleware der 2. Generation
Entwicklung von Middleware
Quelle: Lebender 2003, S. 15f
Blick auf semantische IntegrationVerfahren zur (automatischen) Transformation der InformationenI.d.R. Laufzeitumgebung
Zentrale PlattformZugriff auf grundlegende Dienste (z.B. Middleware-Funktionalität der 1. Generation)Zugänglich machen von Daten und Diensten für weitere SystemeSkalierbar, meist durch Cluster-Lösungen
Datenkonvertierungsdienste angeboten werdenVerbindung von Komponenten unterschiedlicher Herkunft möglichIntegration von Daten unterschiedlicher Quellen möglich
Aufgabe des Message Brokers Adapter bzw. KonnektorMessage Broker
Integrationsinfrastruktur
Quelle: Lebender 2003, S. 17
Nachrichtenvermittler zwischen zwei oder mehreren SystemenVerwaltung und Überwachung der Schnittstellen Eine Schnittstelle pro System
Weiterleitung der Datenpakete an die jeweilige AnwendungB.B. Umwandeln der Daten in geforderte Datenformate
Ausgleichen und Verbergen der Unterschiede verschiedener SchnittstellenVerwaltung der Beziehung zwischen Anwendungen
Integrationsansätze
Quelle: Aier 2004, S. 36ff; Lebender 2003, S. 17ff
Aufbauend auf Schichtenmodell der betrieblichen AnwendungssystemeIntegrationsansätze für alle SchichtenAuswahl erfolgt im Projekt
Prozess-integration
Prozessschicht Prozessschicht
User InterfaceIntegration
Präsentationsschicht Präsentationsschicht
Anwendungs-integration
Applikationsschicht Applikationsschicht
Daten-integration
Datenschicht Datenschicht
Anwendungssystem 1 Anwendungssystem 2 Überblick
Zentrale Integrationsplattformen
Integrationsformen
Quelle:
Point to Point Integration
Jedes System ist direkt mit jedem notwendigen System verbunden
Bereitstellung einer zentralen PlattformZum Teil mit vorgefertigten Adaptern
System A
System C
System B
System X System Y System Z
System N System M
System A
System C
System B
System X System Y System Z
System N System M
EAI-Middleware(Adapter & Messaging-Bus)
Vier-Ebenen EAI-Architekturmodell
Integrationsformen
Application nEnterprise Application IntegrationApplication m
ObjectLayer
Data Layer
Function Layer
Business Process Layer
Application Layer
ObjectLayer
Data Layer
Function Layer
Object Meta Model
Data Meta Model
Function Meta Model
Event Handling Message Routing
Message Queue
Message Queue
Connector Connector
Connector Connector
Application Layer
1. Einführung ERP-Systeme2. Einführung Architekturmanagement3. Vom Geschäftsprozess zur Softwarearchitektur4. Klassische Software Architekturmuster5. Integration6. Wandlungsfähigkeit7. Aufnahme von Anwendungslandschaften8. Visualisierung von Anwendungslandschaften9. Bewertung von Anwendungslandschaften
Warum ist Wandlungsfähigkeit notwendig?
Quelle: Gronau 2006b, S. 37
Die Wandlungsnotwendigkeit ergibt sich auf Grund von Umweltturbulenzen.
Dynamische Anpassung der
ERP-Systeme
Umfeld
Produkte, Technologien
Wettbewerber Wissenschaftliche Methoden
Soziale und politische Faktoren
Mitarbeiter
Wirtschaft, Finanzen
Märkte, Kunden
Flexibilität AnpassungsfähigkeitWandlungsfähigkeit
Defintionen um Wandlungsfähigkeit
Quelle: Gronau 2005, S. 27
ist die Eigenschaft eines Systems, sich selbst effizient und schnell an veränderte Anforderungen anpassen zu können.
ist die Eigenschaft eines Systems, auf einen Änderungsbedarf ein entsprechend aktivierbares Änderungspotenzial im System gegenüberzustellen.
ist die Eigenschaft eines Systems, den Änderungsbedarf eigenständig zu erkennen, geeignete Alternativen werden von außen bereitgestellt.
Wer erkennt den Änderungsbedarf? Wer entwickelt geeignete alternativen
FlexibilitätAnpassungsfähigkeitWandlungsfähigkeit
extern externSystem externSystem System
Warum ist Wandlungsfähigkeit notwendig?
Quelle: Gronau 2006b, S. 37
Eigenschaften wandlungsfähiger
ERP-Systeme
Selbstähnlichkeit
Selbstorganisation
UnabhängigkeitVerfügbarkeit
Modularität
Skalierbarkeit
InteroperabilitätWissen
Selbstauskunft des Systems
Kommunikation mit anderen Systemen
Strukturbildende Fähigkeiten des
Systems
Autonomie der Subsysteme,Plattformunabhängigkeit
Zugriffsmöglichkeiten zu jeder Zeit,an jedem Ort
Strukturaufbau aus unabhängigen
Systemen
Bidirektionale kapazitätsmäßige
Anpassung
Ähnliche Strukturen auf
unterschiedlichen Ebenen
1. Einführung ERP-Systeme2. Einführung Architekturmanagement3. Vom Geschäftsprozess zur Softwarearchitektur4. Klassische Software Architekturmuster5. Integration6. Wandlungsfähigkeit7. Aufnahme von Anwendungslandschaften8. Visualisierung von Anwendungslandschaften9. Bewertung von Anwendungslandschaften
Zuordnung der Teilschritte
Für eine konsolidierte Unternehmensarchitektur müssen alle Phasen der Entwicklung zyklisch überprüft werden.
Unternehmensarchitekturzyklus
Quelle: Niemann 2005, S. 38
Analysieren - Strategisches ArchitekturmanagementPlanen - Strategisches & Operatives ArchitekturmanagementAusführen - Operatives ArchitekturmanagementDokumentieren - Strategisches ArchitekturmanagementÜberprüfen - Strategisches & Operatives Architekturmanagement
Ziele
Die IT-Landschaftsplanung stellt den Ausgangspunkt für zahlreiche Analysen dar.
IT-Landschaftsplanung
Quelle: Niemann 2005, S. 79
SteuerungPlanungWeiterentwicklungVermeidung von Heterogenität und RedundanzenIntegrationsprojekte
Was wird aufgenommen?
Quelle: Niemann 2005, S. 77
Die Anwendungslandschaft verbindet die Inhalte der Architekturebenen.
Geschäftsarchitektur
Ziele, Strategien, Rahmenbedingungen Prozesse Komponenten Organisation/
Lokation
Anwendungsarchitektur
Anwendungssystem-komponenten Daten Schnittstellen Schichten
Systemarchitektur
Entwicklungs-umgebungen
Test-umgebungen
Integrations-umgebungen
Abnahme-umgebungen
Produktions-umgebungen
Die Anwendungslandschaft ermöglicht die Analyse und Planung des Architekturmanagements.
Wozu dient eine Anwendungslandschaft?
Anwendungslandschaft
Quelle: Niemann 2005, S. 80
Verbindung zwischen Geschäftsprozess, Anwendungssystem und InfrastrukturkomponentenAuswirkungen von Ersetzungen oder Ablösungen einzelner Bestandteile der InfrastrukturAusfallfolgenabschätzungPlanung von neuanzuschaffender Hard- oder Software bei anstehendem GroßprojektAnalyse der Geschäftsprozesse hinsichtlich der Mengengerüste (Transaktionen, Datenbankzugriffe, Datenvolumina), der zeitlichen Entwicklung und IT-Kosten für die Bearbeitung der Geschäftsprozesse
Anforderungen ForschungsbereicheAnwendungslandschaften
Motivation
Quelle: GI-AK "WI-AWL" unter http://www.anwendungslandschaft.de/
Bei einzelnen Anwendungen architektonische Gestaltungsgrundsätze wurde behandeltFokus auf die Gestaltung ganzer Anwendungslandschaften (synonym: Application-Landscape), so dass sie architektonischen Qualitätsansprüchen genügen
FlexibilitätAdaptierbarkeit und WartbarkeitIntegrationsfähigkeitEnterprise Architecture Management = Integration von Betrachtungsebenen mit Schwerpunkt auf Anwendungsarchitektur, Überführung Business-Architektur in Anwendungsarchitektur, Qualitätskriterien für die Bewertung
GI-Arbeitskreis "Enterprise Architecture" (gegründet 2002)GI-Arbeitskreis "Anwendungslandschaften" (gegründet 2006)
Erinnerung: Betrachtungsebenen der Unternehmensarchitektur
Quelle: Dern: Management von IT-Architekturen
Strategie
Geschäfts-prozesse
IS-Architektur
IT-Architektur
Modell desSE-Prozesses
Anwendungs-Architektur
IT-Basisinfrastruktur
IT-Architektur
Proj
ekt-
Port
folio
man
agm
.
Geschäftsprozess-management
IT-Architektur-management
Management der Basisinfrastruktur
IS-P
ortfo
liom
anag
emen
t
Softw
aree
ntw
ickl
ung
Inno
vatio
nsm
anag
emen
t
Kontinuierliche AufgabenInitiale Aufgaben
Aufgaben beim Management der Unternehmensarchitektur
Quelle: Winter (2006)
Auswahl der betrachteten Artefakte und des Abstraktionsgrades, Schlüsselbegriffe, Schnittstellen zu anderen VerzeichnissenIm Sinne eines Systemanalyseprojektes durchführbar
Architektur-Entwicklung
Anforderungen indenifizieren/verwalten
Architektur-Entwicklung
Architektur-Artefakte pilotieren/entwickeln/integrieren
Architektur-Führung
Strategieanforderungen identifizierenArchitektur-Führung
As-Is-Architektur beurteilen
Architektur-Führung
Architekturprinzipien aktualisieren
Architektur-Führung
Verbreitung und Effektivität messenArchitektur-Vertretung
z.B. Zielgruppen-Projekte unterstützten
Architektur-Kommuniaktion
Konsolidiertes Vorgehensmodell für dasApplikations-Architekturmanagement nach Winter (2005)
Quelle: Winter (2005)
Rollenmodell zum Management von IT-Architekturen
Quelle: Dern: Management von IT-Architekturen (2006), S. 108
BusinessichtBusinessichtBusinessichtBusinessicht
ArchitektursichtArchitektursichtArchitektursichtArchitektursichtIT-Architekt (auf Unternehmensebene)IT-Architekt (auf Unternehmensebene) IT-Architekt (auf Projektebene)IT-Architekt (auf Projektebene)
InfrastruktursichtInfrastruktursichtInfrastruktursichtInfrastruktursichtService-Manager System-Ingeneur
SoftwareentwicklungssichtSoftwareentwicklungssichtSoftwareentwicklungssichtSoftwareentwicklungssichtProjektleiterProjektleiter Software-IngeneurSoftware-Ingeneur
ManagementsichtManagementsichtManagementsichtManagementsichtIT-Controller Process-Owner IS-Owner IS-Verantwortliche
Businessarchitekt
Security-Ingeneur
1. Einführung ERP-Systeme2. Einführung Architekturmanagement3. Vom Geschäftsprozess zur Softwarearchitektur4. Klassische Software Architekturmuster5. Integration6. Wandlungsfähigkeit7. Aufnahme von Anwendungslandschaften8. Visualisierung von Anwendungslandschaften9. Bewertung von Anwendungslandschaften
Motivation
Notwendigkeit, die IT-Landschaften in geeigneter Form zu beschreiben
Dokumentation einer Anwendungslandschaft
Komplexe und schlecht dokumentierte IT-Landschaften Starke Abhängigkeit von einer funktionierenden IT-Landschaft Stetig steigende Zahl von InformationssystemenStarke Vernetzung durch unterschiedlichste Technologien Unzureichender Überblick über IT-Landschaft birgt Risiken und Kosten
Softwarekartographie: Darstellung von IT-Landschaften durch Softwarekarten
Wissenswertes
Softwarekartographie
Ursprünge in der KartographieBeschreibung von AnwendungslandschaftenStellt Mittel zur Verfügung, mit deren Hilfe IT-Landschaften dargestellt werden könnenInteressengruppen zur IT-LandschaftArten von Softwarekarten
Definitionen
Softwarekartographie
Quelle: Matthes 2004, LMW05
Softwarekartographie: Beschreibung der Modelle und Methoden zur Dokumentation und graphischen Darstellung von Anwendungslandschaften durch SoftwarekartenAnwendungslandschaft: Gesamtheit aller Informationssysteme in einem UnternehmenSoftwarekarte: Repräsentation der Anwendungslandschaft, Fokus auf Gestaltung und Planung der komplexen InformationsinfrastrukturZiel der Softwarekartographie:Darstellung der gesamten Anwendungslandschaft und Verbindung von verschiedenen Betrachtungsebenen
NutzenBeherrschung der hohen Komplexität der AnwendungslandschaftBessere Planung von ProjektenErkennen von Veränderungen der AnwendungslandschaftErreichen der strategischen Ziele
Wirtschaftliche Aspekte Fachliche Aspekte Planerische Aspekte
Anforderungen an Softwarekarten
Quelle: Matthes 2004
Zeitliche Veränderung der AnwendungslandschaftAbstimmung und Priorisierung von parallel laufenden Programme und Projekte Zeitliche Analyse der Anwendungslandschaft zur Unterscheidung von Ist-, Soll- und Plan-Anwendungslandschaften
Verschiedene Kostenarten bei Entwicklung, Betrieb, Wartung, etc. von Informationssystemen Visualisierung der verschiedenen Kostenarten, IT-Kennzahlen und Balanced Scorecard
Kombination von Organisationseinheiten, Prozesse, Geschäftsobjekte und Funktionsbereiche mit Informationssystemenz.B. auch die Anzahl von Nutzern oder quantifizierbarer Nutzen von Informationssystemen
Clusterkarte
Clusterkarten erlauben es Anwendungen Organisationseinheiten zuzuordnen
Arten von Softwarekarten I
Quelle: Matthes 2004, Lauschke 2005
Visualisierung aller Systeme des UnternehmensZuordnung der Systeme zu Funktionsbereichen (logischen Einheiten)Kartengrund gibt Clusterung vorDarstellung der Schnittstellenbeziehungen zwischen diesen Systemen In Schichten lassen sich neue Cluster und Anwendungen aufbringen, die bei Bedarf miteinander verbunden werden können, um sie in Beziehung zu setzen.Durch Verbindungen kann der Datenaustausch zwischen den Anwendungen dargestellt werden.
Prozesskarte
Prozesskarten erlauben es bestimmte fachliche Aspekte zu visualisieren.
Arten von Softwarekarten II
Quelle: Matthes 2004, Lauschke 2005
Visualisierung der IT-Projekte mit den betroffenen Systemen und deren Entwicklungsstand bzw. ProjektfortschrittZuordnung von Anwendungen zu Prozessen, sowie Ausprägungen eines Merkmals oder Entitäten, wie zum Beispiel Organisationseinheiten
Horizontale: Prozesse, bzw. Prozessschritte der WertschöpfungskettenVertikale:Visualisierende Merkmal, bzw. Entitäten denen Anwendungssysteme zugeordnet werden
1. Einführung ERP-Systeme2. Einführung Architekturmanagement3. Vom Geschäftsprozess zur Softwarearchitektur4. Klassische Software Architekturmuster5. Integration6. Wandlungsfähigkeit7. Aufnahme von Anwendungslandschaften8. Visualisierung von Anwendungslandschaften9. Bewertung von Anwendungslandschaften
Die Abdeckungsanalyse erlaubt das Erkennen von Redundanzen und Lücken in der Anwendungslandschaft.
Aufbau
Abdeckungsanalyse
Fachliche Gliederung der AnwendungslandschaftProdukt/Prozess-MatrixErkennen von Redundanzen und LückenVertiefende Untersuchung hinsichtlich:Negativer Auswirkung der Redundanzen auf "Time to Market" bei Einführung neuer ProdukteIT-Kosten zur Unterhaltung der redundanten SystemeFachliche Argumente für den Erhalt der RedundanzenIst eine Zusammenfassung möglichDetailuntersuchung bei Lücken:Gründe für LückenAuswirkung der Lücken auf das Geschäft und die IT (ev. Medienbrüche)Entsehende RisikenKosten zur Beseitigung der Lücken
Die Analyse der Heterogenität ist der eigentliche Kern des Architekturmanagements.
Ablauf
Analyse der Heterogenität
Analysemittel ist wieder die Matrix, aber Ersetzung der Produkte durch OrganisationseinheitenZuordnung von Anwendungssystemen zu Geschäftsprozessen und OrganisationseinheitenAnalyse auf Entwicklungslinien der AnwendungssystemeHohe Anzahl von Entwicklungslinien pro Zelle = Indikator für HeterogenitätZusätzlich Erhebung von Werten zur Verbereitung und absoluter Anzahl der SystemeUntersuchungen:Verhältnis von Entwicklungslinien zu OrganisationseinheitenBegründung ev. durch organisatorische UnterschiedeWildwuchs?Eigenheiten einzelner Organisationseinheiten, die auf ihr eigenes IT-System bestehen?
Die Analyse der Komplexität ist momentan nicht operationalisierbar.
Wissenswertes
Analyse der Komplexität
Kaum MetrikenMessung der Komplexität ganzer Anwendungslandschaften auf Grund von fehlenden Instrumenten nicht möglichGenerell gilt: CAL = f (AAS, AIF)McCabe-Metrik: Berechnung der inneren Komplexität von Softwaresystemen Komplexität K eines Systems ergibt sich aus der Anzahl von Knoten und der Anzahl der KantenBislang keine Bechmarks für AnwendungslandschaftenErmittelte Kennzahl = Indikator für Fortschritt
Die Analyse der Komplexität ist momentan nicht operationalisierbar.
Wissenswertes
Analyse der Komplexität
Kaum MetrikenMessung der Komplexität ganzer Anwendungslandschaften auf Grund von fehlenden Instrumenten nicht möglichGenerell gilt: CAL = f (AAS, AIF)McCabe-Metrik: Berechnung der inneren Komplexität von Softwaresystemen Komplexität K eines Systems ergibt sich aus der Anzahl von Knoten und der Anzahl der KantenBislang keine Bechmarks für AnwendungslandschaftenErmittelte Kennzahl = Indikator für Fortschritt
Konformität für IT-Governance
Die Prüfung auf Konformität ist eine Kernaufgabe des Architekturmanagements.
Compliance Rules Prüfungen(entsprechen Existenzbedingungen)
Analyse der Konformität
Dokumentation zu definierten Elementen der UnternehmensarchitekturVerfahrensbeschreibungen Gesicherte Verfahren für Backup, Recovery, Autorisierung etc.Security Policy
Konformität zu den ReferenzarchitekturenAusschließlicher Einsatz von im Warenkorb befindlichen EntwicklungswerkzeugenUnternehmensinterne Zertifizierung für alle InfrastrukturkomponentenKonvergenz der Entwicklungslinien hin zur Referenzarchitektur
Eine Nutzenanalyse ist auf sehr unterschiedlichen Wegen möglich und kaum operationalisierbar.
Wissenswertes
Analyse des Nutzens
Nutzenanalyse dient der Priorisierung von zu ergreifenden MaßnahmenVerschiedene Herangehensweisen:Summe der InvestitionenBewertet durch Nutzer oder BetreuerWirkung auf UnternehmenszieleUnterstützungsgrad für die GeschäftsprozesseBewertung des max. Schadens bei AusfallKaum MetrikenIdentifikation der Prozesse mit hoher Bedeutung für den Unternehmenserfolg und Produkte mit aktuell hohem UmsatzanteilHerleitung über Matrix möglich