Management der Informationssysteme Modellierung von Unternehmensarchitekturen

© Prof. T. Kudraß, HTWK Leipzig Fragen an das IS-Management Wie soll das Management der grundlegenden Bausteine von Informationssystemen gestaltet werden: Daten und Prozesse ? Wie wird der Lebenszyklus einer einzelnen Anwendung von der ursprünglichen Idee über Entwicklung und Betrieb? Wie kann die gesamte Systemlandschaft im Unternehmen harmonisch gestaltet werden, d.h. wie werden neue Informationssysteme aufeinander abgestimmt und ins bestehende Portfolio eingefügt?

© Prof. T. Kudraß, HTWK Leipzig Begriff Unternehmensarchitektur (Enterprise Architecture) Zusammenspiel von Elementen der Informationstechnologie und der geschäftlichen Tätigkeit im Unternehmen. Sie ist ge- kennzeichnet durch einen ganzheitlichen Blick auf die Rolle der IT im Unternehmen Architektur = Beschreibung (Modell) der grundsätzlichen Struktur der Teile eines Systems sowie der Zusammenhänge zwischen den einzelnen Elementen ISO-Standard Allgemeine Anforderungen an Unternehmensarchitektur ANSI/IEEE Std The fundamental organization of a system, embodied in its components, their relationships to each other and the environ- ment, and the principles governing ist design and evolution.

© Prof. T. Kudraß, HTWK Leipzig Ebenen und Gestaltungsobjekte der Unternehmensarchitektur Strategieebene:Produkte / Dienstleistungen Marktsegmente Strategische Unternehmensziele / Vorhaben / Projekte Interaktion mit Kunde oder Zulieferern Organisationsebene:Vertriebskanäle Geschäftsprozesse Organisationseinheiten Rollen / Verantwortlichkeiten Informationsflüsse / Standorte Integrationsebene:Applikationen und Applikationsdomainen Fachliche Services IS-Funktionalitäten Informationsobjekte Schnittstellen Softwareebene:Softwarekomponenten Datenstrukturen IT-Infrastrukturebene:Hardwarekomponenten Netzwerkkomponenten Software-Plattformen

© Prof. T. Kudraß, HTWK Leipzig Weiterentwicklung von Architekturen Typ1-Architektur vs. Typ2-Architektur – Typ1: Beschreibung der Unternehmensarchitektur zu einem bestimmten Zeitpunkt (Momentaufnahme) – Typ2: Schwerpunkt ist Prozess zur Weiterentwicklung der Unternehmensarchitektur Prozess zur Weiterentwicklung – Weiterentwicklung vom IST zum SOLL als Kreislauf betrachten – Geschäfts-/IT-Strategie bestimmt Transformation der Ist-Architektur – Regelmäßige Anpassung bei Änderungen – Ansätze in Enterprise Architektur Frameworks

© Prof. T. Kudraß, HTWK Leipzig Anwendungsszenarien für Unternehmensarchitektur Planung IT-Strategie IT/Business-Alignment Prozessoptimierung Architekturkonformität von Projekten Management des Anwendungsportfolios Qualitätsmanagement Security-Management Business-Continuity-Planung (IT-Notfallplanung) IT-Konsolidierung Standardsoftware-Einführung Compliance-Management Sourcing-Entscheidungen Unterstützung von Fusionen / Übernahmen / Teilungen

© Prof. T. Kudraß, HTWK Leipzig Praxisbeispiel: Unternehmensarchitektur bei der UBS AG Zürich Business Architecture – Tasks and targets at a strategic level – Business principles Application Architecture – Partitioning of business-oriented functionality into (reference) models according to different viewpoints Software Architecture – Set of rules (guidelines, patterns) for software development; may result in application infrastructure components Technical Architecture – Set of products (basic platforms) and a set of rules and patterns how to apply these products Operations Architecture – Elements and Processes needed to run the software system of the bank

© Prof. T. Kudraß, HTWK Leipzig Enterprise Architecture Frameworks Frameworks unterstützen Unternehmensarchitektur Beispiele: – Zachman Framework (1987): Einflussreicher Vorläufer heutiger Frameworks – The Open Group Architecture Framework (TOGAF) – Enterprise Architecture Frameworks amerikan. Behörden: FEAF, E2AF, DoDAF Werkzeuge – IBM Rational System Architect – IDS Scheer: ARIS – alfabet: planningIT – Casewise: Corporate Modeler

© Prof. T. Kudraß, HTWK Leipzig TOGAF Umfassender Ansatz für Entwurf, Planung, Implementierung und Wartung von Unternehmensarchitekturen Entwickelt durch die Open Group Aktuell (2009): Version 9 Kostenfrei verfügbar 4 Architekturbereiche: Geschäftsarchitektur, Informations- und Datenarchitektur, Anwendungsarchitektur, Technologiearchitektur definiert Prozess zur Architekturentwicklung (Architecture Development Method, ADF)

© Prof. T. Kudraß, HTWK Leipzig Architekturbereiche Geschäftsarchitektur:Strategie, Organisation, Geschäftsprozesse des Unter- nehmens, Ergebnis der Geschäftsprozessmodellierung Informations- und Daten-Daten mit ihren Beziehungen, die für die Durchführung architekturder Geschäftsprozesse benötigt werden Datenmodell (stabil, vollständig, konsistent) Informationsgruppen (Rollen) mit gleichem Info-Bedarf Anwendungsarchitektur:Anwendungen für die Ausführung der Geschäftsprozesse stabiles Anwendungsportfolio Funktionalität / Informationen Technologiearchitektur:Elemente für Aufbau und Betrieb der IT-Infrastrukturstabiles Anwendungsportfolio Basis für Beschaffung, Integration und Betrieb von Anwendungen Basisarchitekturen Weitere Architekturen möglich: Sicherheitsarchitektur Betriebsarchiektur

© Prof. T. Kudraß, HTWK Leipzig Architecture Development Method (ADF)

© Prof. T. Kudraß, HTWK Leipzig TOGAF - Bestandteile 1. TOGAF Architecture Develoment Method (ADM) Methodik für Architekturentwicklung Guidelines für Tools Verweise auf Case Studies 2. Enterprise Continuum = virtuelles Repository Zwei Referenzmodelle: Foundation Architecture: Technical Reference Model (TRM), Standards Information Base (SIB) Integrated Information Infrastructure Reference Model (III- RM) 3. TOGAF Resource Base Guidelines, Templates u.ä. für Enterprise Architects

© Prof. T. Kudraß, HTWK Leipzig Referenzmodelle Vgl. Begriff Modell: wovon-wozu-für wen? Referenzmodell: nicht nur im Kontext eines IS, sondern auch in weiteren Anwendungskontexten Referenzmodell – Ebenen- und Architekturmodelle – Metamodelle, Referenzmodelle, Tools zur Anwendung von Referenzmodellen Ein Referenzmodell ist ein für eine Branche oder einen ganzen Wirtschaftszweig erstelltes Modell, das allgemeingültigen Charakter haben soll. Es dient als Ausgangslösung zur Entwicklung unternehmens- spezifischer Modelle (Becker/Schütte, 1996).

© Prof. T. Kudraß, HTWK Leipzig Referenzmodelle (Forts.) Beispiele – SAP R/3 Referenzmodell – ISO/OSI Referenzmodell – WFMC-Referenzmodell (Workflow Management) Bereitstellung von Referenzmodellen durch Softwarehersteller – Dokumentationsfunktion – Zur Entscheidungsunterstützung beim Softwarekauf – Schulung der Mitarbeiter – Dokumentation der betrieblichen Abläufe, die durch die Software unterstützt wird

© Prof. T. Kudraß, HTWK Leipzig Referenzmodelle: Metamodelle & Architekturmodelle UML – Funktionsmodell: Funktionen des Systems aus der Sicht des Anwenders (Use Cases) – Objektmodell: Klassendiagramm mit Attributen, Assoziationen, Operationen – Dynamisches Modell: Aktivitäts-, Sequenz- und Zustandsbedingungen ARIS (Scheer) – Datensicht: Entity-Relationship-Modell – Organisationssicht: Organigramm – Vorgangssicht: Funktionsbaum – Steuerungssicht: Ereignisgesteuerte Prozessketten (EPK) MDA – Beschreibung eines Informationssystems unabhängig von der technologischen Ebene

© Prof. T. Kudraß, HTWK Leipzig Metamodelle (Wirtschaftsinformatik) Organisations- Sicht Funktionssicht Datensicht Steuerungssicht Leistungssicht Scheer Organisation Funktionen Daten Personal Österle Leistungssicht Lenkungssicht Ablaufsicht Ferstl/Sinz Organisations- Sicht Funktions- Sicht Datensicht Gehring Prozess- Sicht Organisations- struktursicht Aktivitäts- struktursicht Informations- struktursicht Gadatsch

© Prof. T. Kudraß, HTWK Leipzig SAP R/3 Referenzmodell Anwendungskomponentenmodell Business-Objekt Ereignis Funktion SAP R/3 - Referenzmodell Interaktionsmodell Business-Objekt Datenmodell Prozessmodell Organisationsmodell Ereignis Funktion

© Prof. T. Kudraß, HTWK Leipzig SAP Solution Map – Automotive OEM – Edition 2004

© Prof. T. Kudraß, HTWK Leipzig Verwendung von Referenzmodellen bei Einführung von Software Alternative 1: – Spezifikation künftiger Systeme nur auf Basis des Referenzmodells – setzt voraus, dass alle (auch spezialisierte Funktionalitäten) beschrieben sind – anderenfalls Verlust an Individualität Alternative 2: – Vergleich eigener Modelle mit dem Referenzmodell der Software Anpassungsbedarf (Customizing) – Anpassung der Software vs. Anpassung des Unternehmens – Regel: Relevanz des Geschäftsprozesses (wie wettbewerbs- kritisch?) bestimmt Entscheidung IF Prozess wichtig THEN Änderung der Standardsoftware veranlassen ELSE Veränderung des Prozesses durch Softwareeinführung akzeptieren (z.B. Bildschirm-Masken oder Reports)

© Prof. T. Kudraß, HTWK Leipzig ARIS ARIS = Architektur integrierter Informationssysteme Eine methodenorientierte Architektur Ein Programm zur Unterstützung bei der Modellierung Unterscheidung – ARIS Haus (die Idee) – ARIS Toolset (das Programm) Beschreibung von Unternehmen und Anwendungssystemen Verwendung betriebswirtschaftlicher Beschreibungstechniken Geschäftsprozess steht im Mittelpunkt der Betrachtung Komplexitätsreduzierung durch Sichtenbildung

© Prof. T. Kudraß, HTWK Leipzig Die vier Sichten des ARIS-Hauses

© Prof. T. Kudraß, HTWK Leipzig Die drei Beschreibungsebenen – Von Problem zur IT (Daten- und Prozessbeispiele) fachliche Sprachwelt halbformale Beschreibungsmethoden (Lieferant produziert Artikel) Modellhafte Abbildung der betrieblichen Realität unter Berücksichtigung einer formalisierten Beschreibungsmethode (ERM bzw. EPK) Einbezug von DV-Spezifika (Relationen bzw. Kontrollflüsse) Übertragung auf die konkreten DV- Komponenten (SQL-Code bzw. Java-Code)

© Prof. T. Kudraß, HTWK Leipzig Sichten und Ebenen ARIS-Architektur

© Prof. T. Kudraß, HTWK Leipzig Modellierungstechniken auf Fachkonzeptebene

© Prof. T. Kudraß, HTWK Leipzig Organisationssicht Bildet die Funktionen ausführenden Mitarbeiter, die Organisationseinheiten sowie deren Struktur untereinander ab

© Prof. T. Kudraß, HTWK Leipzig Datensicht Beschreibt Informationsobjekte, deren Attribute und Beziehungen Informationsobjekte werden von Funktionen erzeugt, verwendet oder manipuliert und erhalten in Ereignissen definierte Zustände Datenmodelle dienen zur Klärung und Strukturierung der betrieblichen Begriffswelten, werden aber vor allem für Anforderungsdefinitionen von DV- Anwendungssystemen genutzt Darstellung als Fachbegriffsmodell (FBM) Bestellung Auftrag FB Lagerauftrag FB Beschaffungs- auftrag FB bildet ab Darstellung als Entity-Relationship-Modell (ERM) Ort Kunden-Nr Name Datum Kunde Artikel Bestellung Gewicht Benennun g Artikel-Nr. (0,n)

© Prof. T. Kudraß, HTWK Leipzig Funktionssicht Beschreibt und ordnet die durch Ereignisse ausgelösten Funktionen

© Prof. T. Kudraß, HTWK Leipzig Funktionssicht – Gliederungskriterien Auftrag bearbeiten Auftrag prüfen Grunddaten erfassen Positionsdaten erfassen Kundenauftrag erfassen Kundendaten erfassen Finanzdaten erfassen Bestelldaten erfassen Kundenauftrag bearbeiten Kundenauftrag anlegen Kundenauftrag ändern Kundenauftrag löschen 1. Prozess-Schritt 2. Prozess-Schritt 3. Prozess-Schritt Prozessorientierte Funktionsgliederung 1. Verrichtung 2. Verrichtung 3. Verrichtung 1. Teilfunktion 2. Teilfunktion 3. Teilfunktion Verrichtungsorientierte Funktionsgliederung Objektorientierte Funktionsgliederung

© Prof. T. Kudraß, HTWK Leipzig Steuerungssicht Bildet die durch die Sichtenbildung verlorenen Zusammenhänge in einer eigenen Darstellung redundanzfrei ab Das Zusammenwirken der unterschiedlichen Komponenten wird durch die Prozessmodellierung beschrieben Ereignisse zeigen Übergänge auf

© Prof. T. Kudraß, HTWK Leipzig EPK Sichtenintegration

© Prof. T. Kudraß, HTWK Leipzig Hintergrundinformationen zu ARIS Entwicklungsgeschichte – Idee: Prof. Dr. August-Wilhelm Scheer, Institut für Wirtschaftsinformatik der Universität Saarbrücken – Hersteller: 1984/85 IDS – Prof. Scheer Gesellschaft für integrierte Datenverarbeitungssysteme mbH – Seit Anfang 1999: IDS Scheer AG am Neuen Markt – Produkt: ARIS Toolset seit Version 3.x im größeren Einsatz, seit Version 6.0 auch mit relationaler Datenbank (Oracle) – Name: Bis Version 4.12 als ARIS-Toolset seit Version 5.0 als ARIS e-Business Suite aktuell als ARIS Design Platform

© Prof. T. Kudraß, HTWK Leipzig Nutzen der Modellierung mit ARIS Objekte werden genau einmal, einheitlich definiert Modelle erhalten ein einheitliches Layout (Vorlagen) Änderungen an einem Objekt (z.B. Umbenennung einer Stelle) werden auf alle Modelle in der Datenbank übertragen Redundant angelegte Objekte lassen sich konsolidieren Es existieren Zusatzfunktionen – Web Publisher, Business Publisher – Auswertungsreports (z.B. für Prozesshandbuch) – Analysereports – Simulationskomponente – Prozesskostenrechnung (Activity Based Costing, ABC) – Balanced Scorecard (BSC)