Current Topics in BPM and EA

Current Topics in BPM and EA IV WS 2011 Methods EA Frameworks Competence Center EA/Dr.-Ing. Marten Schönherr 1

Agenda Lernziele Thematische Einordnung/Abgrenzung g g Blueprints im Architekturmanagement Typ I Frameworks Typ II Frameworks Beispiel anhand von TOGAF Kritische Würdigung zur Verwendung von Frameworks Literatur BackUp: andere Ansätze aus SE, Operations und IT-Governance (RUP, ITIL, CobIT) 2 TU Berlin Systems Analysis 2

Lernziele Verständnis für diverse IT-Vorgehensmodelle Überblick über Enterprise Architecture Frameworks Modellierung, Sichten und Bestandteile eines Frameworks Frameworks im Kontext des Architekturmanagements Diskussion Aufwand vs. Nutzen 3 TU Berlin Systems Analysis 3

EA FRAMEWORKS TU Berlin Systems Analysis 4

Einordnung: IT Vorgehensmodelle 5 TU Berlin Systems Analysis 5

S Abgrenzung: IT Vorgehensmodelle Unternehmensgrenzen Kunde - Entwickler - Betreiber SPICE Gesamtunternehmen Prozessoptimierung / KVP Metriken SPICE SPICE Reifegradstufe f Einzelvorhaben Standard- prozess Zeitpunkt im Software- Lifecycle Prozessdurchführung Idee Projekt-/ Vorhabensmanagement Anforderungsmanagement Vorgehensmodell (z.b. V-Modell XT) ITIL Disposal ITIL oberflächlich vollständig Abdeckungstiefe 6 TU Berlin Systems Analysis 6

Was sind Blueprints (Blaupausen)? Bsp. Architektur-Blueprint Internetanwendungen einer Versicherung zzgl. Textdokumentation nach Keller (2006) 7 TU Berlin Systems Analysis 7

Blueprints beinhalten Standards, state of the art, best practice bietet Referenzarchitektur differenziert Sichten adressiert verschiedene Zielgruppen IST bzw. SOLL-Zustand der realen Situation einer Firma? Welche Position im Architekturmanagement? 8 TU Berlin Systems Analysis 8

Architekturmanagement nach Dern Architekturmanagement Architekturplanung: Entwicklung und Verfolgung von strategischen Vorgaben Management der Anwendungslandschaft Architekturstrategie Architekturprinzipien definieren Architekturentwicklung: Operative Projektarbeit Blaupausen und Referenzarchitekturen Projekten zur Verfügung stellen Projektberatung Durchführung von Architekturprojekten Quelle: Hess sd&m, in Anlehnung an Dern 9 TU Berlin Systems Analysis 9

Ziel Blueprint Architekturentwicklung über die Erstellung, Abstimmung und Abnahme von Blueprints Situativ reduziert auf relevante Aspekte, Sichten und Zielgruppenansprüche Gestaltung von Abstimmungsprozessen im Architekturmanagement (Architekturentwicklung) anhand von Blueprints Sichten können in Abhängigkeit der Zielgruppen von abstrakten rein fachlichen Schwerpunkten einer Architektur bis hin zu physischen h Aspekten variieren Funktionale und nicht-funktionale Aspekte werden unterschieden Es gehen sowohl IST als auch SOLL Aspekte ein, zumindest ist ein Ausschluss von IST-Aspekten nicht möglich 10 TU Berlin Systems Analysis 10

Gibt es methodische und generische Grundlagen für die Erstellung von Blueprints? Welche Aspekte sollen betrachtet werden? Welche Rollen sind typisch? Welche Sichten werden modelliert? Enterprise Architecture Frameworks als mögliche Lösung! 11 TU Berlin Systems Analysis 11

Enterprise Architektur Frameworks (EAF) Enterprise Architecture is a description (model) of the basic arrangement and connectivity of parts of a system (either a physical or a conceptual object or entity) Typ 1 direkte Beschreibung eines Gesamtsystems Modell der Strukturen statische Aspekte (Komponenten, Interfaces etc.) dynamische Aspekte (Beziehung zw. stat. Aspekten) Typ 2 Projekte zur nachhaltigen Veränderung der Unternehmensarchitektur Modell der Aktivitäten, Konzepte, Entwicklung und Betrieb der Architektur Lebenszyklusaspekte aller betroffenen Subsysteme (ISO 15704, 2000) 12 TU Berlin Systems Analysis 12

EAF weitere Eigenschaften einer Enterprise Architecture Architekturregeln und -muster Abstraktion in der Modellierung ganzheitliche Betrachtungsweise (nicht IT-spezifisch) Konstruktionsmethoden th (Standards, d Referenzmodelle etc.) langfristig planender Charakter (Masterplan) 13 TU Berlin Systems Analysis 13

Typ I Architekturelemente Anwendungsorientierte Sichten Geschäfts- architektur Architektur- Ebenen Prozessarchitektur Applikationsarchitektur Anwendungsneutrale Sichten IT-Architektur Standardsoftware-Sicht Sicht Hafner/Winter 2005 14 TU Berlin Systems Analysis 14

Architekturelemente II Dern, 2003 15 TU Berlin Systems Analysis 15

Architektur - Architekturelemente III Foegen, 2003 16 TU Berlin Systems Analysis 16

Architektur - Architekturelemente IV Gemeinsamkeiten div. Ebenen zwischen Geschäftsund IT-Architektur Strategie Aufbau- Ablauf- Kausalität zwischen IT- und Unternehmenszielen wird thematisiertti i t Organisation Geschäftsprozess nicht identisch zu Prozessen in IT- Ebenen Strategische Elemente vorwiegend in den Geschäftsebenen Informationsarchitektur Kommuni- Anwendungs- Daten- kations- architektur architektur architektur Technologiearchitektur ISarchitektur 17 Krcmar, 1990 TU Berlin Systems Analysis 17

Vergleich der Ansätze Krcmar Dern Hafner/Schelp/Winter Foegen 18 TU Berlin Systems Analysis 18

Zachmann - Architekturanalogie Analogie zur Architektur, iteratives Vorgehen Auftragnehmer-Auftraggeber-Verhältnis (Verständnis) unterstellt Vermutung, dass jedes komplexe Produkt nach diesem Muster erbaut werden kann (Flugzeugbau) 19 TU Berlin Systems Analysis 19

Zachmann Verallgemeinert drei Rollen (Eigentümer/Auftraggeber, Designer/Architekt, Baumeister) Teilsichten in Abhängigkeit der Rollen und der Phase/fachliche Aspekte des Vorhabens Teilmodelle sind auch ohne den Gesamtkontext sinnvoll 20 TU Berlin Systems Analysis 20

Zachmann 3 generische Sichten (Material, Funktion, Ort) Analoge Übertragung in IT-Welt (Daten, Prozess, Netzwerk) Entwirft t Matrix mit Rollen und Sichten 21 TU Berlin Systems Analysis 21

(erweiterte) Zachmann Framework I Structure Activities Locations People Time Motivation (WHAT) (HOW) (WHERE) (WHO) (WHEN) (WHY) Objectives/ Scope (Planners View) Most significant business concepts Mission International view of where organization operates Human resource philosophies and strategies Annual planning Enterprise vision Enterprise Model Business Strategies and Offices and Positions and languages used (Business Owner s View) high-level business processes relationships between them relationships between positions Business events Goals, objectives, business policies Model of fundamental Concepts (Architect s View) Specific entities and relationships between them Business functions and tactics Roles played in each hlocation and relationships between roles Actual and potential ti Detailed business System events interactions rules between people Technology Model (Designer s View) System representation of Program functions/ Hardware, network, User interface Business rule System triggers entities and operations middleware design design relationships Detailed Representation (Builder s View) Implementation strategy for entities and relationships Implementation design of functions/ operations Protocols, hardware, components, deployed software items Implementation of Implementation of Implementation of user interfaces system triggers business rules Functioning System Classes, components, tables Deployed functions/ operations Deployed hardware, middleware and software Deployed user interface (including Deployed system Deployed software documentation) 22 Immon, Zachman, Geiger, 1997 TU Berlin Systems Analysis 22

Regeln des Zachman Frameworks Spalten haben keine Rangfolge Jede Spalte hat ein einfaches, grundlegendes und eindeutiges Modell (bspw. Daten Entity und Relationen) Zeilen sind klar abgegrenzt (keine Überschneidungen) Jede Zelle ist einmalig Alle Zellen einer Zeile erzeugen ein komplettes Modell für die Interessen/Verantwortlichkeiten dieser Rolle Die Methode (Framework) ist rekursiv (beliebig ;-) Jede Zelle e stellt t einen e eigenen e Aspekt der Architektur tu daralle Zellen zusammen bilden die Gesamtarchitektur Immon, Zachman, a Geiger, 1997 23 TU Berlin Systems Analysis 23

Zachman Framework II Strategische Ziele Business Modell IS-Modell Technolog. Modell Detailbeschreibung Physisches System Sicht Grobsicht Fachsicht Designsicht Codesicht Maschinensicht RunTime Aufgabe Ressourcen verteilung Pflichtenheft Geschäftsdesign Systemdesign Implementation Operating User & Entwickler Verantwortung Top-Mgmt. Fachabtlg. Entwickler Entwickler Rechenzentrum Daten Entity Relation Datenmodell Liste Geschäfts- objekte ERD Datenbankdesign Datenbanksystem Daten Prozesse Liste Geschäfts- prozesse Prozess- Beschreibu ng Funktionsbaum Datenflußdiagramm Funktionsdiagramm Programm Funktionen Netzwerk Liste geschäftsfunktionen Knoten Verbindungen Logistiknetzwerk Verteilte Systemarchitektur Hardwarearchitektur Netzwerkarchitektur Kommunikation Immon, Zachman, a Geiger, 1997 24 TU Berlin Systems Analysis 24

Zachmann- Rekursivität Framework kann auf beliebig vielen Ebenen abstrahiert angewendet werden Dadurch erscheint es flexibel aber auch sehr allgemein Guter allgemeiner Rahmen in der Praxis oft zu unspezifisch 25 TU Berlin Systems Analysis 25

ARIS Betriebswirtschaftliche Methode Basiert auf Modellierung von GP 4 Sichten 3 Ebenen Lebenszyklusaspekte stark vereinfacht Betriebswirtschaftliche Problemstellung Fachkonzept DV Konzept Fachkonzept ist stabil Implementierung 13 Betrachtungsfelder eigene Notation (EPK, eepk, VKD ) eigenes Toolset Ca. 150 Notationen Nur begrenzt als Typ II Architektur einsetzbar Fachkonzept DV-Konzept Implementierung Fachkonzept DV-Konzept Implementierung Fachkonzept DV-Konzept Implementierung Datensicht Steuerungssicht Funktionssicht 26 TU Berlin Systems Analysis 26

GRAI GIM Seit 70iger Jahren an LAP UNI Bordeaux/Frankreich zum Thema Architekturmodellierung (GRAI) Seit Ende 80iger mit integrierender Methodologie GIM Physical View Analysis Existing System Initialization User Requirements Definition of the Domain Funtional View Decisinal View Informational View Analysis Analysis Analysis Fokus produzierende Industrie (CIM) Detection of Inconsistencies 4 Grundelemente - Referenzmodell - Modellierungsframework - Modellierungsregeln - Vorgehensweise (s. Abb.) Physical View Design Consolidated User Requirements Functional View Decisinal View Design Design User Oriented Specification Informational View Design Entscheidungsprozesse werden Manufacturing Organization Information Design Design Design i.v. zu anderen Frameworks Technical oriented hervorgehoben Specification Implementation 27 New System TU Berlin Systems Analysis 27

GRAI GIM Unterscheidet 3 Elemente - physisches System (Material i.s. einer Produktion) Schwerpunkte sind hier Simulation und Planung - Entscheidungssystem differenziert vom physischen System abhängige bzw. unabhängige Entscheidungen - Informationssystem beliefert Entscheidungssystem GRAI verwendet eigene Modellierungsnotationen Entscheidungsprozesse werden mit - GRAI Grid globale Sicht (Mgmnt.) - Top-Down - GRAI Nets detallierte Instanzmodellierung - Bottum Up GIM erweitert GRAI um Informationen (Daten +), Funktionen (Objekte) und physische Ebene (IT-Infrastruktur) Infrastruktur) GIM fokussiert auf frühe Lebenszyklusaspekte (Design Time) - Anforderungen - Systemdesign 28 TU Berlin Systems Analysis 28

CIMOSA Computer Integrated Manufacturing Open System Architecture 1984 ESPRIT europ. Forschungsprojekt ca. 10 Jahre Framework für wandelungsfähige IT-Systeme in CIM CIMOSA besteht aus: - Mod.-framework - Integrationsinfrastruktur - Systemlebenszyklus Implementierungs-unabhängiges Fachkonzept Mod.-framework differenziert Architektur, Modelle und Sichten Architektur von Referenz- nach individueller id Architektur Modellebene stellt Lebenszyklusaspekte von SW- Projekten dar Sichten sind: - Organisation - Ressourcen - Informationen - Funktionen Generation of views Function Generic Level Resource Information Organization Reference Architecture Partial Level Instantiation of Building blocks Particular Level Requirements Definition Model Design Specification Model Implementation Description Model Derivation of models 29 TU Berlin Systems Analysis 29

CIMOSA eigene Tools eigene und bekannte Notationen (UML, IDEF, ERD) Particular Enterprise Model Integrationsinfrastruktur führt Modell aus Framework rechnerbasiert als GPM aus (Modellinterpreter s. Abb.) release Integration Infrastructure Management Entity Particular Implementation Description Model Business Entity kein Industriestandard aber Grundlage mehrerer Normen (Enterprise Modelling EM, Constructs for EM) Common Entity Information Entity Information Technology Resources Presentation Entity Manufacturing Resources Enterprise Operation Resources 30 TU Berlin Systems Analysis 30

DoDAF Department t of Defense Architecture t Framework lange Historie im Department of Defense TAFIM, JTA, DoDTRM, C4ISR seit 80iger Jahren Ziele aller Ansätze: Stabilität, Interoperabilität und Kommunikation aller beteiligten Systeme der Streitkräfte im Einsatz DoDAF direkt aus C4ISR definiert Richtlinien zur Gesamtarchitekturbeschreibung und modellierung keine Designvorgaben für die Entwicklung oder Richtlinien zum Einkauf von Systemen besteht aus 3 Dokumenten - Teil I beschreibt Architekturmodellierung und deren Sichten sowie die zu erreichenden Ziele - Teil II beschreibt die zu verwendenden Notationen ausführlich - Teil III (nachgereicht) beschreibt anhand praktischer Bsp. die Umsetzung von I & II DoDAF differenziert 4 Sichten: - Operational (Menschen, Strukturen, Prozesse etc.) - Systems (entsprechende Systeme) - Technical Standards (detaillierte Beschreibung Systemkomponenten) - All (Zusammenhänge der drei ersten Sichten) 26 Methoden zur Architekturbeschreibung eigene Notationen (basierend auf IDEF1) und UML Core Architecture Data Model (CADM ) alle Daten relational (Verwaltung in DB s) 31 TU Berlin Systems Analysis 31

DoDAF 32 TU Berlin Systems Analysis 32

PERA Purdue Enterprise Architecture Framework Referenzmodell für CIM als Herkunft Vorgehen für CIM entwickelt und gleichzeitig Referenzmodell verbessert PERA teilt in IST (as is) und SOLL (to be) und schlägt Masterplan für die Überführung vor Branchenneutral Schlägt 28 Zustände im Lebenszyklus vor Spezifiziert für alle Zustände Aspekte der Elemente Resourcen, Menschen/Orga & IT Keine Vorgabe von Notationen bzw. Tools 33 TU Berlin Systems Analysis 33

Elemente der Modellierung in PERA 34 TU Berlin Systems Analysis 34

TOGAF - Struktur The Open Group Architectural Framework Online verfügbar, open source Lizenz Part I Introduction Part II Architecture Development Method (ADM) Part III Enterprise Continuum Part IV Resources 35 TU Berlin Systems Analysis 35

TOGAF - Definitionen TOGAF is a framework - a detailed method and a set of supporting tools - for developing an enterprise architecture. It is described in a set of documentation published by The Open Group on its public web server, and may be used freely by any organization wishing to develop an enterprise architecture for use within that organization. Enterprise Architecture differentiates: - Business (Process) Architecture - Data Architecture - Application Architecture t - Technology Architecture. 36 TU Berlin Systems Analysis 36

TOGAF Definitionen Architektur I Architecture (Grundlage für TOGAF): The definition of an architecture used in ANSI/IEEE Std 1471-2000 is: the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution. TOGAF spezifiziert Architecture has two meanings depending upon its contextual usage: - Af formal ldescription of a system, or a detailed dplan of fthe system at component level to guide its implementation. - The structure of components, their interrelationships, and the principles and guidelines governing their design and evolution over time. 37 TU Berlin Systems Analysis 37

TOGAF Definitionen Architektur II An architecture description is a formal description of an information system, organized in a way that supports reasoning about the structural properties of the system. It defines the components or building blocks that make up the overall information system, and provides a plan from which products can be procured, and systems developed, that will work together to implement the overall system. It thus enables you to manage your overall IT investment in a way that meets the needs of your business. An architecture framework is a tool which can be used for developing a broad range of different architectures. It should describe a method for designing an information system in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks. 38 TU Berlin Systems Analysis 38

TOGAF Definitionen Architektur III Enterprise Architecture The primary reason for developing an enterprise architecture is to support the business by providing the fundamental technology and process structure for an IT strategy. This in turn makes IT a responsive asset for a successful modern business strategy EA Framework Using an architecture framework will speed up and simplify architecture development, ensure more complete coverage of the designed solution, and make certain that the architecture selected allows for future growth in response to the needs of the business. 39 TU Berlin Systems Analysis 39

Reihenfolge definiert, i iterative ti Abarbeitung empfohlen, allerdings Rückkoplung und spätere Anpassung möglich Part II Architecture Development Method jeweils definiert: - Objectives - Approach - Inputs -Steps - Outputs Req. Magmt. Als zentraler Prozess definiert i und Templates vorgeschlagen http://www.volere.co.uk/template.htm l h 40 TU Berlin Systems Analysis 40

Part II ADM jede Phase der Methode ist detailliert beschrieben Modellierungs- und Dokumentations- konstrukte sind definiert http://www.opengroup.or g/architecture/togaf8- e/toga doc/arch/ 41 TU Berlin Systems Analysis 41

Part III Enterprise Continuum Introduction The Enterprise Continuum in Detail Architecture Continuum Solutions Continuum Enterprise Continuum and Your Organization TOGAF Foundation Architecture: Technical Reference Model TRM Concepts High-level l Breakdown TRM in Detail Detailed Platform Taxonomy TOGAF Foundation Architecture: Standards Information Base Introduction Open Group Standards Using the SIB and Linked Resources TOGAF Integrated Information Infrastructure Reference Model Basic Concepts 42 TU Berlin Systems Analysis 42

Enterprise Continuum Hilfswerk zur Unterstützung des Architekturentwicklungsprozesses: - enthält wieder verwendbare Referenzmodelle, Modelle, Muster, Beschreibungen - TOGAF hat ein Standart Kontinuum, dieses dient Unternehmen als anzupassende Basis um ein unternehmensbezogenes Kontinuum aufzubauen - Komponenten TOGAF Kontinuum: - TRM =Technical Reference Model - SIB = Standart Information Base - III-RM = Integrated Information Infrastructure Reference Model 43 TU Berlin Systems Analysis 43

Part III Enterprise Continuum Kontextuelle Einordnung/Verortung des jeweiligen Beteiligten Fehlerfreie Kommunikation zwischen Beteiligten Paradigma der unterschiedlichen Betrachtungsebenen einer Enterprise Architecture 44 TU Berlin Systems Analysis 44

Technisches Referenzmodel Grobe Struktur Verfeinerte Struktur 45 TU Berlin Systems Analysis 45

TRM TRM =Technical Reference Model: - beinhaltet Taxonomie, mit Hilfe welcher Diskussion über Informationssysteme/-architekturen auf einheitlicher Begriffsbasis stattfinden können - beinhaltet ein Model, welches allgemeine Komponenten eines Systems darstellt - anhand dieses können unternehmenseigene Informationssysteme/- architekturen entwickelt werden Grobe Struktur: - Anwendungsportabilität ermöglichen (Definition Standartservices die durch Anwendungsplattform zu Verfügung gestellt werden müssen) - Interoperabilität (Anwendung unabhängig von Kommunikationsumgebung > Standartdienste mit denen Plattform umgehen können muss) Verfeinerte Struktur - Nennung von Servicekategorien 46 TU Berlin Systems Analysis 46

Integrated Information Infrastructure Reference Model 47 TU Berlin Systems Analysis 47

III-RM III-RM = Integrated Information Infrastructure Reference Model (-> Model noch im Aufbau) - Überschneidet sich mit dem TRM, jedoch liegt beim III-RM der Schwerpunkt bei den Anwendungskomponenten und der Anwendungssoftware - Ziel ist das ermöglichen das Information ohne Einschränkungen schnell verschiedenen Bereichen verfügbar gemacht werden kann. (Kurzfristiges Zusammenstellen eines Expertenteams t aus verschiedenen Bereichen > Zugang zu Informationen aus den einzelnen Bereichen muss zeitnah möglich sein) 48 TU Berlin Systems Analysis 48

Part IV Resources Architecture Board Architecture Compliance Architecture Contracts Architecture Governance Architecture Maturity Models Architecture Patterns Architecture Principles Architecture e Skills Framework weiterhin Cases, Glossar, EA Tools, Mapping mit anderen EA (Zachmann) 49 TU Berlin Systems Analysis 49

GERAM Framework Components Elemente eines EA Frameworks Engineering Methoden Modellierungssprachen Generische Elemente Partielle Modelle Spezifische Modelle Tools Module Operationale IT-Systeme GERA EEM EMLs Generalised Enterprise Enterprise Engineering Enterprise Modeling Reference Architecture Methodology Languages Identifies concepts of Describe processes of Modeling constructs for Enterprise Integration Enterprise Engineering Human, process & IT employs utilise implemented in GEMCs Generic Enterprise Modeling Concepts define the meaning of EETs PEMs modeling constructs Enterprise Engineering Partial Enterprise Models Tools Provide reusable refrence Support of models support Enterprise Engineering used to build EMs Enterprise Models Enterprise models to support analysis & operation EMOs Enterprise Modules provide implementable modules used to implement 50 EOS Enterprise operational Systems support tth the operation of a particular Enterprise ISO, 15740, 2000 TU Berlin Systems Analysis 50

Lebenszyklusaspekte Identification Concept Requirements life-cycle pha ases Preliminary design Design Detailed design Implementation Operation Decommission 51 ISO, 15740, 2000 TU Berlin Systems Analysis 51

Projekte Life-cycle phases Identification Concept Requirements Preliminary design Design Detailed design Implementation Enterprise Engineering Projects Redesign/ continuous improvement project Operation Decommission Enterprise Operation Decommissioning project Time 52 ISO, 15740, 2000 TU Berlin Systems Analysis 52

Lebenszyklus unterschiedlicher Elemente entity A entity B identification concept requirements operation { preliminary design design detailed d design { implementation operation decommission 53 ISO, 15740, 2000 TU Berlin Systems Analysis 53

Entity Type 2 Generische Entities Entity Type 1 Engineering Implementation Entity Entity Type 3 Strategic Management Entity Initiates, defines, supports Identification Concept Enterprise Entity Entity Type 4 Requirements Identification Product Entity Preliminary design Design Detailed design Concept Requirements Identification Entity Type 5 Methodology Entity Implementation Operation Decommissioning Develops, builds Preliminary design Design Detailed design Implementation Operation Develops, builds Concept Requirements Preliminary design Design Detailed design Decommissioning Implementation Identification Operation Concept Decommissioning Requirements Preliminary design Design Detailed design Supports Implementation Task 2 Operation Decommissioning Establishes Task 1 Task 3 Task 4 ISO, 15740, 2000 54 TU Berlin Systems Analysis 54

vom Referenzmodell zum konkreten Modell Views Generic Partial Particular Instantiation Identification Concept Requirements Preliminary design Design Detailed design Implementatio n Operation Decommissio i n Life-cycle phases Reference Architecture Particular Architecture 55 ISO, 15740, 2000 TU Berlin Systems Analysis 55

VISUALISIERUNG TU Berlin Systems Analysis 56

Bsp. Views { { { Generic Partial } Subdivision according to genericity Particular Instantiation Identification Concept Requirements Preliminary design Design Detailed design Implementation Operation Decommission Life-cycle phases Reference Architecture Customer service Management and control } } Software Hardware} Subdivision according to purpose of activity Subdivision according to physical manifestation Resource Organisation Subdivision Information } according to model content t Function Subdivision according Machine to means of Human } implementation Particular Architecture 57 ISO, 15740, 2000 TU Berlin Systems Analysis 57

Clusterkarte Partitionierung der Karte mittels logischer Einheiten nach Funktionsbereichen, Organisationseinheiten, Positionierung der Cluster (ohne definierte Semantik) durch Optimierung der Kartengröße Positionierung von verwandten Elementen möglichst nahe beieinander Unternehmensstandards (bspw. Kunde am rechten Rand Cluster Zugriffskanäle rechts) Quelle: Wittenburg-Softwarekartographie ( sebis) TU Berlin Systems Analysis 58

Prozessunterstützungskarte Verortung der Elemente auf x- und y-achse x-achse für Geschäftsprozesse Ebenen 0 bis 3 Lineare Prozesse Notation ti als Wertschöpfungskette tt y-achse für Organisationseinheiten, Systemklassen, Produkte,... Quelle: Wittenburg-Softwarekartographie ( sebis) TU Berlin Systems Analysis 59

Verortung der Elemente entlang der x- und y-achse x-achse für die Zeit y-achse für zeitabhängige Elemente Zeitintervallkarte Anwendungssysteme, Anwendungssystemversionen, Projekte, Programme,... An Gantt-Diagramme angelehnt Quelle: Wittenburg-Softwarekartographie ( sebis) TU Berlin Systems Analysis 60

Softwarekarten und Schichten Darstellung von Aspekten auf verschiedenen Schichten Beziehungen von Anwendungssystemen und anderen Elementen der EA (Prozesse, Einheiten, ) Verbindungen (Schnittstellen) unterschiedlicher Detaillierungsgrade mit versch. Gestaltungsmitteln Kennzahlen mittels versch. Gestaltungsmittel Kennzahlen Verbindungen AnwendungsA d systeme Kartengrund g Quelle: Wittenburg-Softwarekartographie ( sebis) TU Berlin Systems Analysis 61

Visualisierung von Informationen auf Softwarekarten (1) Quelle: Wittenburg-Softwarekartographie ( sebis) [se05] TU Berlin Systems Analysis 62

Eine gute Softwarekarte Quelle: Wittenburg-Softwarekartographie ( sebis) [se05] TU Berlin Systems Analysis 65

Prozessunterstützungskarte (2) ohne Integration Quelle: Wittenburg-Softwarekartographie ( sebis) [se05] TU Berlin Systems Analysis 66

Prozessunterstützungskarte (3) Vertikale Integration Quelle: Wittenburg-Softwarekartographie ( sebis) [se05] TU Berlin Systems Analysis 67

Prozessunterstützungskarte (4) Horizontale Integration Quelle: Wittenburg-Softwarekartographie ( sebis) [se05] TU Berlin Systems Analysis 68

Prozessunterstützungskarte (5) Horizontale + Vertikale Integration Quelle: Wittenburg-Softwarekartographie ( sebis) [se05] TU Berlin Systems Analysis 69

Veränderungen in der Anwendungslandschaft und ihre Visualisierung Beispiel 1 Neue Geschäftsprozessunterstützung durch ein neues Anwendungssystem Ergebnis: (create new MapSymbol) Ve ertikale Inte egration Ohne Inte egration Quelle: Wittenburg-Softwarekartographie ( sebis) [se05] TU Berlin Systems Analysis 70

Veränderungen in der Anwendungslandschaft und ihre Visualisierung Beispiel 2 Neue Geschäftsprozessunterstützung durch ein existierendes Anwendungssystem Ergebnis: (create new MapSymbol) OR (stretch existing MapSymbol) Verti Integr kale ration Ohne Integ gration Wenn die Geschäftsprozessunterstützung von Anwendungssystemversionen visualisiert wird, können die Darstellungen anders aussehen. Quelle: Wittenburg-Softwarekartographie ( sebis) [se05] TU Berlin Systems Analysis 71

Veränderungen in der Anwendungslandschaft und ihre Visualisierung Beispiel 3 Konsolidiere die Geschäftsprozessunterstützung von zwei Anwendungssystemen Ohne Inte egration Ergebnis: (delete obsolete MapSymbol) AND ((create new MapSymbol) OR (stretch existing MapSymbol)) Ver rtikale Inte gration Quelle: Wittenburg-Softwarekartographie ( sebis) [se05] TU Berlin Systems Analysis 72

Strukturierungsprinzipien für Anwendungslandschaften Vertikale Integration Vertikale Integration Mehrere Organisationseinheiten nutzen das gleiche Anwendungssystem für denselben Geschäftsprozess oder verschiedene Produkte werden von dem gleichen Anwendungssystem unterstützt Erzielen von Skaleneffekten (Economies of Scale) Reduzieren von Betriebs- und Wartungskosten Aber: Flexibilität der einzelnen Organisationseinheit wird reduziert Quelle: Wittenburg-Softwarekartographie ( sebis) [se05] TU Berlin Systems Analysis 73

Strukturierungsprinzipien für Anwendungslandschaften Horizontale Integration Horizontale Integration Zahlreiche aufeinanderfolgende Geschäftsprozesse werden durch das gleiche Anwendungssystem unterstützt Reduzieren von Betriebs- und Wartungskosten Aber: Horizontale Integration ist nicht in jedem Fall zielgerichtet Teilen von Zuständigkeiten erhöht die Flexibilität, Wartbarkeit, Quelle: Wittenburg-Softwarekartographie ( sebis) [se05] TU Berlin Systems Analysis 74

Beispiel eines Szenarios Ist-, Plan- und Soll-Landschaften (3) Ist-Landschaft Quelle: Wittenburg-Softwarekartographie ( sebis) [se05] TU Berlin Systems Analysis 75

Beispiel eines Szenarios Ist-, Plan- und Soll-Landschaften (4) Plan-Landschaft per 2007-07-01 Quelle: Wittenburg-Softwarekartographie ( sebis) [se05] TU Berlin Systems Analysis 76

Beispiel eines Szenarios Ist-, Plan- und Soll-Landschaften (5) Soll-Landschaft Quelle: Wittenburg-Softwarekartographie ( sebis) [se05] TU Berlin Systems Analysis 77

Beispiel eines Szenarios Ist-, Plan- und Soll-Landschaften (6) Konformität der Plan-Landschaft per 2007-07-01 mit der Soll-Landschaft Quelle: Wittenburg-Softwarekartographie ( sebis) [se05] TU Berlin Systems Analysis 78