[PDF] [PDF] Klausurvorbereitung Architekturen betrieblicher Anwendungssysteme

7 Betriebliche Anwendungssysteme

Anwendungssysteme betreffende Themen, wie Architektur und Sicherheit, an die betriebliche Umgebung) besitzt ERP-Standardsoftware den Nachteil,

[PDF] Klausurvorbereitung Architekturen betrieblicher Anwendungssysteme

einem ERP-System realisiert werden? Wie kann die Auswahl und Einführung von ERP- Die Drei-Schichten-Architektur ist insbesondere für betriebliche 

[PDF] 2 - Architekturen von Anwendungssystemekey - LSWI - Universität

Architektur von ERP-Systemen Betriebliche Anwendungssysteme Der SAP Web Application Server setzt die Drei-Schichten-Architektur ein, um auf das WWW 

[PDF] Integrationslösungen im ERP-Umfeld State of the Art - SERES Unit

ihrer Eigenschaft als „integrierte betriebliche Anwendungssysteme“ nahezu alle ERP-Systeme sind meist in drei Schichten unterteilt (Three-Tier-Architektur):

[PDF] Betriebliche Anwendungssysteme - OPUS 4 – KOBV

14 sept 2011 · und des betrieblichen Anwendungssystems (ERP-System) für die Bearbei- tung und Regel-basierte Architektur statt indirekte Implementation

[PDF] 008 Klausuraufgaben - Fernuni Hagen

29 mar 2019 · Betriebliche Anwendungssysteme sowie Lehrstuhl für In der Architektur von ERP-Systemen umfasst die Logikschicht ausschließlich das Ba-

[PDF] Betriebliche Anwendungssysteme - Campus Koblenz — Universität

SS 2011 IWVI, Professur für betriebliche Anwendungssysteme 2 Prof Dr Petra Schubert ERP-Systeme ▫ Übung (3 KP): Kennenlernen eines konkreten ERP -Systems und Supply Chain Management - Architektur und Funktionen 

[PDF] Betriebliche Informationssysteme - TRANSCONNECT

28 nov 2019 · Anwendungssysteme unterstützen Menschen bei der Erledigung von Gronau, N , Enterprise Resource Planning: Architektur, Funktionen und 

[PDF] Künftige Anforderungen an ERP-Systeme Deutsche - OPUS

Allgemeine Begriffe wie Betriebliche Anwendungssysteme, ERP oder Business Softwa- re, die in allen vier Bereichen Architektur, Technologie, Betreibermodell 

[PDF] Betrieblicher Ausbildungsplan - Akademie für Sozial

[PDF] Betriebs- und Montageanleitung für Anbau- und

[PDF] Betriebs- und Wartungsanleitung für

[PDF] Betriebs-Berater für Medien Telekommunikation

[PDF] Betriebsanlagenverfahren V2

[PDF] Betriebsanleitung

[PDF] Betriebsanleitung - AL-KO

[PDF] betriebsanleitung - claus

[PDF] Betriebsanleitung - Inbetriebnahme Hydraulik

[PDF] Betriebsanleitung - Leuze electronic

[PDF] Betriebsanleitung - OPERTIS Produktkatalog

[PDF] Betriebsanleitung - SUNNY BOY STORAGE 2.5

[PDF] Betriebsanleitung Automatik-Schlauchaufroller Typ ST

[PDF] Betriebsanleitung CG 2000

[PDF] BETRIEBSANLEITUNG DCC-DECODER 6872

Univ.-Prof. Dr.ÐIng. habil. Norbert Gronau

Lehrstuhlinhaber | Chairholder August-Bebel-Str. 89 | 14482 Potsdam | Germany Tel +49 331 977 3322

Fax +49 331 977 3406 E-Mail ngronau@lswi.de Web lswi.deLehrstuhl fŸr Wirtschaftsinformatik

Prozesse und Systeme

UniversitŠt Potsdam

Chair of Business Informatics

Processes and Systems

University of Potsdam

KlausurvorbereitungArchitekturen betrieblicher Anwendungssysteme1

1. EinfŸhrung ERP-Systeme 2. EinfŸhrung Architekturmanagement 3. Frameworks fŸr das Architekturmanagement 4. Vom GeschŠftsprozess zur Softwarearchitektur 5. Klassische Software Architekturmuster 6. Enterprise Application Integration 7. Vorgehensmodell des Architekturmanagements 8. Aufnahme und Visualisierung von Anwendungslandschaften 9. WandlungsfŠhigkeit 3

Lerninhalte

Fragen4

Funktionsumfang

Integrationsumfang

Verwaltung

Der Begrif ERP

Quelle: Gronau 2010, S. 3f.Ressourcen

Informationen über Ressourcen Ziel: Durchführung von GeschŠftsprozessen Integration von mind. drei Ressourcen Material, Personal, KapazitŠten, Finanzen und Information mind. gemeinsame Datenhaltung Artikel, Platz(Lager), Personal, Maschinen, Geldmittel, Reserven, Hilfsmittel, Informationen 5

ModularitŠt

StandardisierungIntegration

Eigenschaften von ERP-Systemen

AutomatisierungGemeinsame Datenbasis Prozesse Abteilungen Durch Standardisierung von AblŠufen Teil- oder vollautomatisiert Realisierung durch Workfows 6

Funktionen und Aufgaben von ERP-Systemen

Horizontale und vertikale Integration (weitere)

Quelle: Mertens 2007, S. 68

Vorgehen und Dauer der Auswahlphase von AnwendungssystemenQuelle: CER 2014

Vorgehens-

modell konfigurieren

Istprozesse

analysieren

ROI-Analyse

Ziel des ERP-

Projektes

definieren

Auswahl-

Anforderungen

festlegen

Szenarien für

festlegen

Markt-

screening fizierung

Webcast

Anbieter-

tation

Referenz-

besuche Soll- prozess- definition

Prozess-

workshop

Vertrags-

verhand- lungen 9

1. EinfŸhrung ERP-Systeme 2. EinfŸhrung Architekturmanagement 3. Frameworks fŸr das Architekturmanagement 4. Vom GeschŠftsprozess zur Softwarearchitektur 5. Klassische Software Architekturmuster 6. Enterprise Application Integration 7. Vorgehensmodell des Architekturmanagements 8. Aufnahme und Visualisierung von Anwendungslandschaften 9. WandlungsfŠhigkeit 10

Lerninhalte

11 Ist wichtig fŸr Positionsbestimmung des Unternehmens und des IT-ManagementsDefnition

UnternehmensarchitekturQuelle: Niemann 2005, S. 21Eine 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 Stakeholder Darstellung von unterschiedlichen Aspekten von IT-Systemen (z.B. Schnittstellen) Entwicklung der Architektur Ÿber die Zeit (z.B. ein SOLL - IST Vergleich)

12

Aufbau einer UnternehmensarchitekturQuelle: Dern 2006, S. 0StrategieBusiness ArchitekturInformationsarchitekturIT-ArchitekturenIT-BasisinfrastrukturBusinessITBusiness TreiberInformationsbedarfOrganisationsstrukturBusinessfunktionenProzessarchitekturIS-PortfolioTechnologiestrategieArchitekturstrategieArchitekturprinzipienIstSollZugeordnetes Modell des SE-ProzessesAnwendungs-architekturPlattformstrategieSecurity- strategiePlattform 1Plattform ...13

UnternehmensarchitekturArten von ArchitekturenQuelle: Reussner/Hasselbring 2005, S. 1 sowie Sinz 2004, S. 315SoftwarearchitekturGrundlegende Organisation eines Anwendungssystems Prinzipien, die den Entwurf und die Evolution des Systems bestimmen

Betrachtung aller Elemente eines Unternehmens Anwendungen als Teil der IS-Architektur Ansammlung von Vorgehensweisen, Methoden und Elementen zur Planung, Realisierung und Nutzung betrieblicher Informationssysteme

PrŠsentationsschichtDatenhaltungsschichtAnwendungsschichtUnternehmensarchitekturOrganisations- architekturInformationssystem-architekturOrganisations- strukturGeschŠfts-prozesseElementeVorgehens-modelle14

Aufgaben und Ziele

IT-Governance

EfzienzSicherheitEfektivitŠt15

Anforderungs- und PortfoliomanagementZielsetzung erfolgt durch IT-Strategie, Steuerung durch IT-Governance.IT-Management Framework

Quelle: Niemann 2005, S. 39Fachliche Anforderungen erheben Anforderungen strukturieren und bewerten Projektportfolio aufbauen und bewerten

Programm- und ServicemanagementProgramme, Projekte und Services steuern

Architekturmanagement Technische Anforderungen erarbeiten Bebauungsplan erstellen Bebauungsplan umsetzen

IT-StrategieIT-GovernanceAnforderungs- und Portfolio- managementProgramm- und Service- managementUnternehmens- architektur- management16

1. EinfŸhrung ERP-Systeme 2. EinfŸhrung Architekturmanagement 3. Frameworks fŸr das Architekturmanagement 4. Vom GeschŠftsprozess zur Softwarearchitektur 5. Klassische Software Architekturmuster 6. Enterprise Application Integration 7. Vorgehensmodell des Architekturmanagements 8. Aufnahme und Visualisierung von Anwendungslandschaften 9. WandlungsfŠhigkeit 17

Die Grundabsichten eines (EA-) Rahmenwerkes sind es eine Strukturierung der Informationslandschaft vorzunehmen und die KomplexitŠt zu reduzierenZusammenfassung der DefnitionenQuelle: Vgl. Matthes 2011, S. 17Die Defnition des Begrifes Rahmenwerk ist nicht eindeutig Oft erfolgt die Defnition eines Rahmenwerkes in der Konzeptbeschreibung des Rahmenwerkes selbst Es lassen sich jedoch bei genauer Analyse †bereinstimmungen feststellen Theoretisch defniert sich ein Rahmenwerk Ÿber seinen Modellcharakter Rahmenwerke stellen Methodiken und Werkzeuge bereit die fortwŠhrende Architekturentwicklung unterstŸtzen FŸr Analyse, Entwurf, Implementierung und kontinuierliches Change Management18

InhaltlichZeitlichEntwicklung der Frameworks Quelle: Vgl. Shah, Kurdi 2007, S. 17fAusgewŠhlte FrameworksEng Verbunden mit Bedeutung der EA Frameworkkonzept seit Mitte 1980er Jahre Vorreiter Zachman Danach kontinuierliche Weiterentwicklung fŸr versah. Zielgruppen und InstitutionenErkenntnis der systematischen Aufbereitung von Informationswegen EinfŸhrung von unterschiedlichen Perspektiven Einige Frameworks nicht entwickelt, sondern Entstehung aufgrund praktischer AnwendungZachman, 1987 TOGAF, 1995 Gartner, 2005 Federal Enterprise Architecture (FEA), 2006

19

Zachman Ð 1987, erstes EA Framework, sehr komplex aber gut geeignet, um einen begrifichen Ordnungsrahmen zu erstellen. Das Zachman-Framework

Quelle: eigene Darstellung nach Sowa, Zachman 1992, S. 602 (Zitat S. 590), vgl. Matthes 2011, S. 13Software Architecture: Software Engineering System Architecture: System Engineering EA: System of Systems/ Enterprise EngineeringÒIf the computer is to do anything useful, the concrete things in the world must be related to the abstract bits in the computer. ZachmanÕs framework for information systems architecture (ISA) makes that link.Ó SOWA92, S. 590What? ÑÑÑÑ- DataHow? ÑÑÑÑ- FunctionWhere? ÑÑÑÑ- NetworkWhen? ÑÑÑÑÑ TimeWho? ÑÑÑÑÑ PeopleWhy? ÑÑÑÑÑ MotivationScopeList of EntitiesList of ProcessesList of Locations List of EventsList of Organizations / AgentsList of Goals/ StrategyPlannerEnterprise ModelEntity Relationship ModelProcess Flow DiagramLogistics NetworkMaster ScheduleOrganization ChartBusiness PlanOwnerSystem ModelData ModelData Flow DiagramDistributed System ArchitectureProcessing StructureHuman Interface ArchitectureKnowledge DesignerTechnology ModelData DesignStructure ChartSystem ArchitectureControl StructureHuman/ Technology InterfaceKnowledge DesignBuilderCompo-nentsData SchemataProgramNetwork ArchitectureTiming DefnitionSecurity ArchitectureKnowledge DefnitionSubcon-tractorFunctioning SystemDatabaseFunctionNetworkScheduleOrganisationStrategyEnterprise Architecture/ IS ArchitectureSystem Architecture Software Architecture 20

G. Implemen-tation GovernanceC.

Information Systems ArchitectureE.

Opportunities f Solutions ArchitectureA.

Architecture VisionH. Architecture Change ManagementF.

Migration ArchitectureB.

Business ArchitectureD.

Technology ArchitectureH. Architecture Change ManagementPrimel. Framework f Principles21

TOGAF Enterprise ContinuumQuelle: Vgl. Matthes 2011, S. 195fEnterprise ContinuumArchitecture ContinuumSolutions ContinuumArchitecture Context and RequirementsDisplayed SolutionsGeneric

ArchitectureSpecifc ArchitectureAdaption for useGeneralisation for futureGeneric SolutionsSpecifc SolutionsAdaption for useGeneralisation for future22

1. EinfŸhrung ERP-Systeme 2. EinfŸhrung Architekturmanagement 3. Frameworks fŸr das Architekturmanagement 4. Vom GeschŠftsprozess zur Softwarearchitektur 5. Klassische Software Architekturmuster 6. Enterprise Application Integration 7. Vorgehensmodell des Architekturmanagements 8. Aufnahme und Visualisierung von Anwendungslandschaften 9. WandlungsfŠhigkeit 23

Lerninhalte

FragenWas ist eine Softwarearchitektur und welche Bestandteile hat diese? Welche Ziele werden mit dem Software Architekturmanagement verfolgt? Was ist Metamodellierung und in welchem Zusammenhang steht diese mit der MDA? Was ist MDA und welche Ziele werden damit verfolgt? Welche Herausforderung exisitieren beim MDA?

24

Hruschka 2006Die Architektur eines Softwaresystems defniert dessen Komponenten und deren Zusammenwirken Ÿber Schnittstellen. Sie beschreibt die Struktur von Komponenten. Architektur betrachtet sowohl statische als auch dynamische Aspekte und zeigt damit sowohl den Bauplan als auch den Ablaufplan fŸr Software auf.

Hasselbring 2006Eine Softwarearchitektur ist die grundlegende Organisation eines Systems, dargestellt durch dessen Komponenten, deren Beziehungen zueinander und zur Umgebung sowie den Prinzipien, die den Entwurf und die Evolution der Systeme bestimmen.

In aktueller Literatur fndet man auch den Begrif ãSoftwarebauelementeÒ.25

ZusammenfassungDarstellung von Komponenten Beziehung zwischen den Komponenten Beziehung zur Umgebung Struktur eines Anwendungssystems Programmierung im Gro§en Verdeutlicht ZusammenhŠnge und Strukturen

Defnitionen von Software-Architekturen26

BausteinsichtLaufzeitsichtDie verschiedenen Sichten bilden ein umfassendes Bild der Software-Architektur.KontextsichtVier Arten von SichtenQuelle: Starke 2005: Efektive Software-ArchitekturenVerteilungssicht Zeigen den Zusammenhang des Systems mit seiner Umgebung aus der Vogelperspektive Schnittstellen nach au§en Interaktion mit wichtigen Stakeholdern Notation 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 Laufzeit Dynamische Strukturen Notation z.B. durch UML-Sequenz, AktivitŠts- oder Kollaborations/Kommunikationsdiagramme

Infrastruktursicht Beschreibung der Hardwarekomponenten (Rechner, Prozessoren, Netztopologien System aus Betreibersicht Notation z.B. durch UML-Einsatzdiagramme

29

1. EinfŸhrung ERP-Systeme 2. EinfŸhrung Architekturmanagement 3. Frameworks fŸr das Architekturmanagement 4. Vom GeschŠftsprozess zur Softwarearchitektur 5. Klassische Software Architekturmuster 6. Enterprise Application Integration 7. Vorgehensmodell des Architekturmanagements 8. Aufnahme und Visualisierung von Anwendungslandschaften 9. WandlungsfŠhigkeit 30

Lerninhalte

FragenWas ist eine Softwaremuster und woher kommen diese? Welche Ziele werden mit dem Softwaremuster verfolgt? Wie werden Softwaremuster dokumentiert? Warum sind Schichtenarchitekturen so erfolgreich? Welche Bestandteile hat eine Service orientierte Architektur?31

StilbeschreibungDie Drei-Schichten-Architektur ist insbesondere fŸr betriebliche Anwendungssysteme etabliertSchichtensystemeQuelle: Shaw 1996, S. 25Hierarchische Organisation Zur VerfŸgungstellung von Services fŸr die Ÿbergeordnete Schicht Benutzung der Services der darunterliegenden Schicht Stilkomponenten = Schicht Stilkonnektoren = Interaktionsbestimmende Protokolle zwischen den SchichtenKern- schichtBasis- FunktionenNŸtzliche SystemeBenutzerKomposition von verschiedenen ElementenAblaufsteuerung32

Die grundlegendeste Anwendung des Schichten-Musters ist die Client/Server-Architektur.Anwendung des Schichten-Musters in betrieblichen Anwendungssystemen

Client-Server-ArchitekturenQuelle: Hasselbring 2006EnthŠlt die Anwendungslogik, hŠufg umgesetzt als FAT-ClientStellt die fŸr die Bearbeitung der Funktionen dem Clienten die notwendigen Daten zur VerfŸgungServerClientLayer 1: DienstanbieterLayer 2: DienstnutzerEigenschaftenTrennung von Datenhaltung und Datenverarbeitung Keine Verantwortung fŸr die Datenspeicherung und sŠmtlicher damit verbundener Konzeptionen der Clienten-Komponente Clienten-Komponente nutzt die zugesicherten Dienste der Server-Komponente

33

Die Client-Server-Architektur lŠsst sich weiter unterteilen.Anwendung des Schichten-Musters in betrieblichen Anwendungssystemen Drei-Schichten-Architektur

Quelle: Hasselbring 2006PrŠsentationGeschŠftslogikDatenhaltungDienstanbieterLayer 1Layer 3Layer 2DienstnutzerDienstnutzerDienstanbieterServerClientEigenschaftenWeitere Dekomposition der Client-Komponente Businesslogik wird getrennt von der PrŠsentation Variante 1: GeschŠftslogik ist Teil des Servers (Thin-Client) Variante 2: GeschŠftslogik ist Teil des Clienten (FAT-Client)

34
Anwendung des Schichten-Musters in betrieblichen Anwendungssystemen

Web-Informationssystem-ArchitekturQuelle: Hasselbring 2006Web-ClientWeb-ServerGeschŠftslogikDatenhaltungAnwendungslogikLayer 4Layer 3Layer 2Layer 1EigenschaftenPrŠsentationslayer weiter unterteilt in Web-Server und Web-Client Webserver Ÿbernimmt Aufbereitung der Daten Webclient ist ein Webbrowser Aufbereitung der Daten fŸr die PrŠsentation im Webserver = Serverseitige PrŠsentation

35

Web Service basierte SOA und Standards

Quelle: Dostal u.a.,2005Simple 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

36
Lose Kopplung Dynamisches Finden und Einbinden von Diensten Bindung zur Laufzeit Wiederverwendung Gekapselte Dienste Mehrfach verwendbar in verschiedenen Umgebungen ohne Aufwand Komponentenorientierung ist durch die Trennung von Schnittstelle und Implementierung gegeben 37

1. EinfŸhrung ERP-Systeme 2. EinfŸhrung Architekturmanagement 3. Frameworks fŸr das Architekturmanagement 4. Vom GeschŠftsprozess zur Softwarearchitektur 5. Klassische Software Architekturmuster 6. Enterprise Application Integration 7. Vorgehensmodell des Architekturmanagements 8. Aufnahme und Visualisierung von Anwendungslandschaften 9. WandlungsfŠhigkeit 38

Lerninhalte

FragenWie wird Integration im Sinne der Wirtschaftsinformatik defniert? Welche Integrationstechnologien existieren und auf welcher Ebene der Integration fnden diese Anwendung? Wie ist EAI defniert? Was ist eine Middleware? Was ist der Unterschied zwischen EAI und Middleware?

39

Unternehmensinterne Integration von Anwendungssystemen = Enterprise Application Integration (EAI) UnternehmensŸbergreifende Integration von Anwendungssystemen = Business-to-Business-Integration (B2B-Integration)

40

Middleware41

IntegrationsansŠtze

Quelle: Aier 2004, S. 36f; Lebender 2003, S. 17fAufbauend auf Schichtenmodell der betrieblichen Anwendungssysteme IntegrationsansŠtze fŸr alle Schichten Auswahl erfolgt im Projekt

Prozess- integrationProzessschichtProzessschichtUser Interface IntegrationPrŠsentationsschichtPrŠsentationsschichtAnwendungs- integrationApplikationsschichtApplikationsschichtDaten- integrationDatenschichtDatenschichtAnwendungssystem 1Anwendungssystem 2†berblick 42

Zentrale IntegrationsplattformenIntegrationsformen (1/2)Point to Point IntegrationJedes System ist direkt mit jedem notwendigen System verbunden

Bereitstellung einer zentralen Plattform Zum Teil mit vorgefertigten Adaptern

System ASystem CSystem BSystem XSystem YSystem ZSystem NSystem MSystem ASystem CSystem BSystem XSystem YSystem ZSystem NSystem MEAI-Middleware (Adapter f Messaging-Bus)43

Vier-Ebenen EAI-ArchitekturmodellIntegrationsformen (2/2) Application nEnterprise Application IntegrationApplication mObject LayerData LayerFunction LayerBusiness Process LayerApplication LayerObject LayerData LayerFunction LayerObject Meta ModelData Meta ModelFunction Meta ModelEvent Handling Message RoutingMessage QueueMessage QueueConnectorConnectorConnectorConnectorApplication Layer44

1. EinfŸhrung ERP-Systeme 2. EinfŸhrung Architekturmanagement 3. Frameworks fŸr das Architekturmanagement 4. Vom GeschŠftsprozess zur Softwarearchitektur 5. Klassische Software Architekturmuster 6. Enterprise Application Integration 7. Vorgehensmodell des Architekturmanagements 8. Aufnahme und Visualisierung von Anwendungslandschaften 9. WandlungsfŠhigkeit 45

AnforderungenForschungsbereicheEnterprise Architecture Management legt den Schwerpunkt auf die Anwendungsarchitektur, †berfŸhrung der Business-Architektur in Anwendungsarchitektur und QualitŠtskriterien fŸr die BewertungAnwendungslandschaftenMotivationQuelle: GI-AK fWI-AWLf unter http://www.anwendungslandschaft.de/Bei einzelnen Anwendungen architektonische GestaltungsgrundsŠtze wurde behandelt Fokus auf die Gestaltung ganzer Anwendungslandschaften (synonym: Application-Landscape), so dass sie architektonischen QualitŠtsansprŸchen genŸgenFlexibilitŠt Adaptierbarkeit und Wartbarkeit IntegrationsfŠhigkeit Enterprise Architecture Management = Integration von BetrachtungsebenenGI-Arbeitskreis fEnterprise Architecturef (gegrŸndet 2002) GI-Arbeitskreis fAnwendungslandschaftenf (gegrŸndet 2006)

46

Konsolidiertes Vorgehensmodell fŸr das Applikations-ArchitekturmanagementQuelle: Winter (2005)AZP = ArchitekturzielgruppenprojekteArchitektur-FŸhrungArchitektur-EntwicklungArchitektur-KommunikationArchitektur-VertretungStrategieanforderungen identifzierenI.1Aktuelle Architekturen beurteilenI.2Architekturprinzipien aktualisierenI.3Architekturprinzipien aktualisierenI.4Weitere Anforderungen identifzierenII.1Anforderungen verwaltenII.2Architekturartefakte (AA) pilotierenII.3AA entwickelnII.4AA integrierenII.5AA identifzierenIII.1AA kommunizierenIII.2AZP unterstŸtzenIV.1AA-Implementierungen bereitstellenIV.2AZP beurteilenIV.347

Phasen der Ist-Analyse

Erhebung und Untersuchung des gegenwŠrtigen ZustandsIST-Aufnahme Geignete MethodeErfassung des Ist-Zustandes Geeignete DatenquellenIST-Dokumentation Geeignete ModelleDarstellung des IST-Zustandes Geeignete WerkzeugunterstŸtzungPotentialanalyse Geeignete Analyse- und BewertungsmethodenAnalyse des Ist-Zustandes Geeignete PriorisierungQuelle: Gronau 201748

SoftwareentwicklerProjektleiter Software Ingenieure

ManagementCIO

49

1. EinfŸhrung ERP-Systeme 2. EinfŸhrung Architekturmanagement 3. Frameworks fŸr das Architekturmanagement 4. Vom GeschŠftsprozess zur Softwarearchitektur 5. Klassische Software Architekturmuster 6. Enterprise Application Integration 7. Vorgehensmodell des Architekturmanagements 8. Aufnahme und Visualisierung von Anwendungslandschaften 9. WandlungsfŠhigkeit 50

Lerninhalte

Was wird aufgenommen?Quelle: Niemann 2005, S. 77Die Anwendungslandschaft verbindet die Inhalte der Architekturebenen.GeschŠftsarchitekturZiele, Strategien, RahmenbedingungenProzesseKomponentenOrganisation/

ZieleDie IT-Landschaftsplanung stellt den Ausgangspunkt fŸr zahlreiche Analysen dar.IT-LandschaftsplanungQuelle: Niemann 2005, S. 79Steuerung Planung Weiterentwicklung Vermeidung von HeterogenitŠt und Redundanzen Integrationsprojekte Ñ> Welche Daten und Bestandteile mŸssen nun dazu aufgenommen werden?

53

Zuordnung der TeilschritteFŸr eine konsolidierte Unternehmensarchitektur mŸssen alle Phasen der Entwicklung zyklisch ŸberprŸft werden. UnternehmensarchitekturzyklusQuelle: Niemann 2005, S. 38Analysieren - Strategisches Architekturmanagement Planen - Strategisches f Operatives Architekturmanagement AusfŸhren - Operatives Architekturmanagement Dokumentieren - Strategisches Architekturmanagement †berprŸfen - Strategisches f Operatives Architekturmanagement

54

MotivationNotwendigkeit, die IT-Landschaften in geeigneter Form zu beschreibenDokumentation einer Anwendungslandschaft Komplexe und schlecht dokumentierte IT-Landschaften Starke AbhŠngigkeit von einer funktionierenden IT-Landschaft Stetig steigende Zahl von Informationssystemen Starke Vernetzung durch unterschiedlichste Technologien Unzureichender †berblick Ÿber IT-Landschaft birgt Risiken und Kosten

SoftwarekartographieDarstellung von IT-Landschaften durch Softwarekarten55 56

DefnitionenSoftwarekartographieQuelle: Matthes 2004, LMW05Softwarekartographie: Beschreibung der Modelle und Methoden zur Dokumentation und graphischen Darstellung von Anwendungslandschaften durch Softwarekarten Anwendungslandschaft: Gesamtheit aller Informationssysteme in einem Unternehmen Softwarekarte: ReprŠsentation der Anwendungslandschaft, Fokus auf Gestaltung und Planung der komplexen Informationsinfrastruktur Ziel der Softwarekartographie:

Darstellung der gesamten Anwendungslandschaft und Verbindung von verschiedenen BetrachtungsebenenNutzenBeherrschung der hohen KomplexitŠt der Anwendungslandschaft Bessere Planung von Projekten Erkennen von VerŠnderungen der Anwendungslandschaft Erreichen der strategischen ZieleHauptbeitrag der Softwarekartographie ist die Bereitstellung und Methodik zur

Dokumentation der Architektur von Anwendungslandschaften57

Wirtschaftliche Aspekte Fachliche Aspekte Planerische Aspekte Anforderungen an SoftwarekartenQuelle: Matthes 2004Zeitliche VerŠnderung der Anwendungslandschaft Abstimmung 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 Informationssystemen z.B. auch die Anzahl von Nutzern oder quantifzierbarer Nutzen von Informationssystemen

58

Operative Aspekte Technische Aspekte Anforderungen an Softwarekarten (Fortsetzung)Quelle: Matthes 2004Implementierungssprache eines Informationssystems Verbindungen (Schnittstellen) Eigenschaften wie Architektur oder genutzter Middleware ZusammenhŠnge in der gesamten Anwendungslandschaft Ziele: Homogenisierung von Datenbanksystemen, Enterprise Application Integration oder Individual- vs. Standardsoftware

Bezug auf den unmittelbaren Betrieb von Informationssystemen und damit verbundene Ereignisse BerŸcksichtigung von Domino-Efekten bei AusfŠllen oder der Ablauf von zeitgesteuerten Prozessen

59
60

Prozesskarte Prozesskarten erlauben es bestimmte fachliche Aspekte zu visualisieren.Arten von Softwarekarten IIQuelle: Matthes 2004, Lauschke 2005Visualisierung der IT-Projekte mit den betrofenen Systemen und deren Entwicklungsstand bzw. Projektfortschritt Zuordnung von Anwendungen zu Prozessen, sowie AusprŠgungen eines Merkmals oder EntitŠten, wie zum Beispiel Organisationseinheiten Horizontale:

visualisierende Merkmal, bzw. EntitŠten denen Anwendungssysteme zugeordnet werden 61

1. EinfŸhrung ERP-Systeme 2. EinfŸhrung Architekturmanagement 3. Frameworks fŸr das Architekturmanagement 4. Vom GeschŠftsprozess zur Softwarearchitektur 5. Klassische Software Architekturmuster 6. Enterprise Application Integration 7. Vorgehensmodell des Architekturmanagements 8. Aufnahme und Visualisierung von Anwendungslandschaften 9. WandlungsfŠhigkeit 62

Lerninhalte

FragenWas ist WandlungsfŠhigkeit? Wie kann WandlungsfŠhigkeit ermittelt werden? Welche Kriterien der WandlungsfŠhigkeit gibt es? Welche Eigenschaften hat eine wandlungsfŠhige Softwarearchitektur?63

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 alternativenFlexibilitŠtexternexternAnpassungsfŠhigkeitSystemexternWandlungsfŠhigkeitSystemSystem64

Ermittlung der WandlungsfŠhigkeit von ERP-SystemenQuelle: Andresen 2006Festlegen des Betrachtungsbereichs bspw. ERP-System, IT-Infrastruktur eines UnternehmensSystemspezifsche Betrachtung

Anwenden des ReferenzmodellsAnwenden der systemneutralen KriterienProzessbasierte Betrachtung

Anwenden der ReorganisationsansŠtzeAnwenden der geschŠftsspezifschen KriterienIntegration und Interpretation ZusammenfŸhren der Ergebnisse Portfoliodarstellung Ableiten von Handlungsstrategien und RichtlinienIntegrierte, gesamthafte WandlungsfŠhigkeitgeschŠftsspezifsche WandlungsfŠhigkeitTechnische WandlungsfŠhigkeit243561Legende:ErgebnisArbeitsschritt65

quotesdbs_dbs27.pdfusesText_33