Methoden und Modelle zur Beschreibung, Bewertung und ... · Inventory Control System (200) Product Shipment System (Germany) (400) Campaign Management System (1500) Customer Complaint

© sebis 1070504-Wittenburg-Softwarekartographie

Softwarekartographie

Methoden und Modelle zur Beschreibung, Bewertung und Gestaltung von Anwendungslandschaften

2007-05-04

André WittenburgSoftware Engineering für betriebliche Informationssysteme (sebis)Ernst Denert-StiftungslehrstuhlLehrstuhl für Informatik 19Technische Universität München

wwwmatthes.in.tum.de


Agenda und Lernziele der Einheit

Agenda

Motivation und thematische Einordnung

Softwarekarten

UML für Softwarekarten?

Anwendung von Softwarekarten

Fazit

Lernziele der Einheit

Grundlagen der Softwarekartographie und von Softwarekarten als Architekturdokumentation kennen

Modellierungssprache für Softwarekarten grundlegend kennen

Verbindung zwischen Softwarekartographie und Enterprise ArchitectureManagement verstehen

Strukturierungsprinzipien für Anwendungslandschaften kennen


Literatur der Einheit

[IEE00] IEEE: IEEE Std 1471-2000 for Recommended Practice for Architectural Description of Software-Intensive Systems. IEEE Computer Society, 2000.

[se05] sebis: Enterprise Architecture Management Tool Survey 2005. TechnischeUniversität München, Chair for Informatics 19 (sebis), 2005.

[St73] Stachowiak, H.: Allgemeine Modelltheorie. 1. Auflage, Springer-Verlag, Wien, ISBN 3-211-81106-0, 1973.


Agenda


Malen von Architekturen

Architektur, Architekturdokumentation und Architekturmanagement

Management von Anwendungslandschaften

Softwarekarten



Fazit


Beispiel für eine gemalte Architekturdokumentation(1)


Beispiel für eine gemalte Architekturdokumentation(2)

Ist dies wirklich eine gute Architekturbeschreibung?

Wenn ja,

was bedeuten die Rechtecke?

was bedeuten gestrichelte Linien?

was bedeutet der rote Kasten?

was bedeuten die Farben?

gibt es nur drei Clients?

Die Syntax und Semantik der Notation sind unklar!


Architektur – Anforderungen und Begriff

Eine der ältesten Verwendungen des Begriffs Architektur in der Baukunst wirdVitruvius (auch Vitruv) zugeschrieben. Vitruvius verlangt von einer Architektur

Firmitas (Stabilität),

Utilitas (Zweckdienlichkeit) und

Venustas (Schönheit).

In der Informatik gibt der IEEE 1471 eine gute Definition für Architektur

„The fundamental organization of a system embodied in its components, theirrelationships to each other, and to the environment, and the principles guiding itsdesign and evolution.“ [IE00]

In der Informatik

soll die Stabilität eines Systems gegenüber neuen Anforderungen gewahrt sein.

verlangt die Zweckdienlichkeit, dass das System nicht an den Anforderungen vorbeigebaut wird.

ist die Schönheit etwas Ästhetisches und auch Sinnvolles.


Architekturdokumentation

Jedes System besitzt eine Architektur!

„Every system has an architecture […]“ [IE00, S. 4]

Eine Architekturdokumentation stellt eine

erfahrbare und

kommunizierbare

Beschreibung der Architektur dar.

Die Architekturdokumentation richtet sich an Stakeholder des beschriebenen Systems.

Die Architekturdokumentation muss(!) die Interessen der Stakeholder adressieren.

Eine Architekturdokumentation besteht aus verschiedenen Sichten auf die Architektur, die wiederum aus Modellen bestehen.

Einen guten, aber abstrakten Überblick liefert der IEEE 1471 [IE00].


Architekturmanagement

Ziel beim Architekturmanagement ist das Beherrschen bzw. Führen eines komplexen Systems

Die Modelle als Teil der Architekturbeschreibung unterstützen das Architekturmanagement,

indem sie für Diskussionen die Grundlage bilden.- Z.B.: Welche Änderungen sind geplant und wie wirken sich diese Veränderungen aus?

indem sie den Status quo und die Zukunft dokumentieren.

…

Gemalte Architekturdokumentationen sind gut für Diskussionen,

wobei der „Maler“ dabei sein muss, denn er kennt die Semantik.

aber ungeeignet für nachhaltige Dokumentationen.

Modellierte Architekturen

besitzen (hoffentlich!) eine Syntax und Semantik, die es dem Betrachter ermöglichen das Modell korrekt zu interpretieren.

können durch ein Werkzeug plus einer Methode nachhaltigen Nutzen bringen.


Enterprise Architecture

Die Enterprise Architecture (im Deutschen Unternehmensarchitektur) ist

die kohärente und ganzheitliche Architektur eines Unternehmens,

die nicht nur die Informationstechnologie sondern ebenso betriebswirtschaftliche Elemente umfasst.

Die Enterprise Architecture ist nicht starr,

sie verändert sich, soll aber stabil, zweckdienlich und (vielleicht) auch schön sein.

Elemente einer Enterprise ArchitectureGeschäfts-Schicht

Anwendungssystem-Schicht

Infrastruktur-Schicht

Infrastruktur-Service-Schicht

Geschäfts-Service-Schicht


Modelle von Anwendungslandschaften

Hauptmerkmale von Modellen nach Stachowiak [St73]

Abbildungsmerkmal: Modelle sind stets Modelle von etwas […]

Verkürzungsmerkmal: Modelle erfassen im allgemeinen nicht alle Attribute des durch sie repräsentierten Originals […]

Pragmatisches Merkmal: Modelle sind ihren Originalen nicht per se eindeutig zugeordnet. Sie erfüllen ihre Ersetzungsfunktion […]

Architekturdokumentationen von Anwendungslandschaften sind Modelle die andere Elemente der Enterprise Architecture mit einbeziehen

Organisationseinheiten, Geschäftsprozesse, Projektstatus, …


Anwendungslandschaften

Anwendungslandschaften

sind komplexe Systeme

bestehen aus hunderten bis zu tausenden (betrieblichen) Anwendungssystemen

Anwendungssysteme

unterstützte zahlreiche Geschäftsprozesse

werden von unterschiedlichen Organisationseinheiten genutzt

werden an verschiedenen Standorten betrieben

nutzen diverse Infrastrukturkomponenten


Softwarekartographie

Das Forschungsziel der Softwarekartographie ist die Entwicklung von

Modellen und Methoden zur Beschreibung, Bewertung und Gestaltung von Anwendungslandschaften.

Modelle der Softwarekartographie

Softwarekarten als graphische Modelle von Anwendungslandschaften

Automatisches Generieren der Softwarekarten und deren Pflege ermöglichen

Fokussierung liegt auf dem Modellieren, nicht dem Malen!

Visualisierungen im Einklang mit den Interessen der Stakeholder

Methoden der Softwarekartographie

Dokumentation von Anwendungslandschaften mit Softwarekarten

Evaluierung von Anwendungslandschaften mit Metriken und die Visualisierung dieser Metriken auf Softwarekarten

Gestaltung von Anwendungslandschaft mittels Softwarekarten


Sponsoren und Projektpartner

Sponsoren

Ernst Denert-Stiftung

Projektpartner

Deutsche Börse Systems


Agenda


Softwarekarten

Softwarekartentypen

Schichtenprinzip

Aufbau von Softwarekarten



Fazit


Ein paar echte Beispiele…


Relevante Informationen für die Softwarekartographie

Zentrales Untersuchungsobjekt: (betriebliche) Anwendungssysteme und ihre Umgebung

Klassifikation von relevanten Informationen

Funktionale- Organisationseinheiten, Geschäftsprozesse, Funktionsbereiche, Geschäftsservices, …

Planerische/Strategische- Strategien, Ziele, Projekte, Programme, …

- Lebenszyklen, Versionen, …

Wirtschaftliche- Betriebskosten, Wartungskosten, Investitionen, …

Technische- Schnittstellen, Programmiersprachen, Middleware-Systeme, Softwarearchitekturen, …

Operative- Uptime/Downtime von Systemen, Abhängigkeiten, (Geographische) Betriebsorte, …


Konsolidierung von Softwarekarten

Analyse von existierenden Darstellungen für Anwendungslandschaften

Konsolidierung der verschiedenen Karten zu drei Softwarekartentypen


Softwarekartentypen

Softwarekartentypen unterscheiden Modelle der Anwendungslandschaft nach den GestaltungsprinzipienSoftwarekarten mit Kartengrund zur Verortung

Kartengrund wird durch Cluster gebildet „Clusterkarte“- Beispiele für Cluster: Funktionsbereiche, Organisationseinheiten, Domänen, Standorte, …- Anwendungssysteme werde in den Clustern visualisiert

Kartengrund wird durch x- und y-Achse gebildet „Kartesische Karte”- Bspw. „Prozessunterstützungskarte“

x-Achse zeigt Geschäftsprozessey-Achse zeigt Organisationseinheiten, Systemtypen, Produkte, …Anwendungssysteme werden entlang den Elementen der Achsen visualisiert

- Bspw. „Zeitintervallkarte“x-Achse zeigt Zeitintervalley-Achse zeigt Anwendungssysteme, Anwendungssystemversionen, Prozessunterstützung, …Lebenszyklus von Anwendungssystemen oder einer Geschäftsprozessunterstützung werden entlang den Elementen der Achsen visualisiert

Softwarekarten ohne Kartengrund zur VerortungKein Kartengrund zur VerortungKarten werden wie Graphen aufgebaut „Graphlayout Karte”


Softwarekartentyp 1: 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)


Softwarekartentyp 2: Kartesische Karte(Prozessunterstützungskarte)

Verortung der Elemente auf x- und y-Achse

x-Achse für Geschäftsprozesse- Ebenen 0 bis 3

- Lineare Prozesse

- Notation als Wertschöpfungskette

y-Achse für Organisationseinheiten, Systemklassen, Produkte, ...


Softwarekartentyp 2: Kartesische Karte(Zeitintervallkarte)

Verortung der Elemente entlang der x- und y-Achse

x-Achse für die Zeit

y-Achse für zeitabhängige Elemente- Anwendungssysteme, Anwendungssystemversionen,

- Projekte, Programme,

- ...

An Gantt-Diagramme angelehnt


Softwarekartentyp 3: Graphlayout Karte

Keine Verschachtelung oder Positionierung entlang von Achsen

Anwendung von Algorithmen zum Layout von Graphen

Spring,

Hierarchisch

Sugiyama

…

Zumeist ad hoc aus Repositories generiert


Agenda


Softwarekarten

Softwarekartentypen

Schichtenprinzip




Fazit


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

Verbindungen

Kennzahlen

Kartengrund

Anwendungs-systeme


Visualisierung von Informationen auf Softwarekarten (1)

Org

Headquarter Subsidiary Hamburg Subsidiary LondonSubsidiary Munich

Warehouse

Online Shop (100)

Inventory Control

System (200)

Monetary Transactions

System (Germany)

(300)

Monetary Transactions

System (Great Britain)

(350)

Product Shipment System

(Germany) (400)

Accounting System (500)

Costing System (600)

Human Resources

System (700)

Data Warehouse

(800)

Fleet Management System (900)

Business Traveling

System (1000)

Document Management

System (1100)

Supplier Relationship Management

System (1200)

MIS (1300)

Financial Planning

System (1400)

POS System (Germany/

Munich) (1600)

Campaign Management

System (1500)

POS System (Germany/Hamburg)

(1620)

POS System (Great Britain)

(1650)

Price Tag Printing System

(Germany/Munich) (1700)

Price Tag Printing System

(Germany/Hamburg)

(1720)

Price Tag Printing System (Great Britain)

(1750)

Worktime Management (Germany/

Munich) (1800)

Worktime Management (Germany/Hamburg)

(1820)

Worktime Management (Great Britain)

(1850)

Customer Relationship Management

System (2100)

Customer Complaint

System (1900)

Customer Satisfaction

Analysis System (2000)

Legend

App (Id)

Organizational Unit hosts Business Application

[se05]



[se05]



[se05]


Agenda


Softwarekarten

Softwarekartentypen

Schichtenprinzip




Fazit


Visualisierungselemente von Softwarekarten

Gestaltungsmittel (engl. Map Symbols)In der Kartographie sind Gestaltungsmittel die Basiselemente von KartenSoftwarekarten unterscheiden

- Flächartige Gestaltungsmittel (engl. Planar Map Symbols)Rechtecke, Ellipsen, Polygone, Chevrons

- Lineare Gestaltungsmittel (engl. Linear Map Symbols)Linien, Pfeile, Polylinien, …

Jedes Gestaltungsmittel besitzt eine Menge von Gestaltungsvariablen- Beispiel Rechteck: Mittelpunkt, Höhe, Breite, Füllfarbe, Rahmenfarbe, …

Gestaltungsregeln (engl. Visualization Rules)Positionierung von Elementen auf Softwarekarten wird durch Gestaltungsregeln ausgedrücktMuss-Gestaltungsregeln, müssen für eine korrekte Semantik erfüllt sein

- Bspw. Verschachteln eines Rechtecks für ein Anwendungssystem innerhalb eines Rechtecks für einen Betriebsstandort

Ziel-Gestaltungsregeln, sollen so gut wie möglich erfüllt sein, umeine gute und ästhetische Softwarekarten zu erhalten

- Bspw. Minimieren der Fläche eines Rechtecks für einen Cluster, …

A

A

A

BA

B

A


Aufbau einer Softwarekarte

Eine gute Softwarekarte besitzt neben dem Kartenfeld

ein Titelfeld

Enthält Titel, Autor, Erstellungsdatum, Kontakt (Person, Rolle oder Gruppe)

Softwarekarten visualisieren unterschiedliche Status zu verschiedenen Zeitpunkten- Titel beschreibt, ob es sich beispielsweise um eine Ist- oder Plan-Landschaft handelt

- Erstellungsdatum erlaubt Rückschlüsse auf den Stand der Informationen

eine Legende

Erklärt die Gestaltungsmittel, ihre Gestaltungsvariablen und die Gestaltungsregeln- Gestaltungsmittel (bspw. Rechteck) werden unterschiedlich benutzt

Bringt Klarheit über die verwendete Semantik

Ist obligatorisch für eine gute Softwarekarte

Map Symbols & Visual Variables Visualization Rules

Legend

A

Unit A

Business application system A with status unmodified A

B

C

B and C belong to A

nesting

A

A

A

A

A

A

C A reads from B via interconnection named C B

A nesting

A is functional assigned to B

A B

A

A

A

Business application system A with status newBusiness application system A with status to be retired

Business application system A with status modified

CA B A writes to B via interconnection named C

C

A B A reads from and writes to B via interconnection named C

A B

attachmentattachment

Interconnection between A and B named C

C


Eine gute Softwarekarte

Acquisition Distribution

Online Shop(100)

Warehousing

Inventory Control System (200)

Product Shipment System (Germany)

(400)

Campaign Management

System (1500) Customer Complaint System(1900)

Headquarter

Subsidiary Munich

Subsidiary Hamburg

Subsidiary London

Warehouse

Customer Relationship Management System

(2100)


Map Symbols & Visual Variables Visualization Rules

Legend

Monetary Transactions System (300)

Monetary Transactions System (300) POS SystemPrice Tag Printing

System

A Business process A

Business application system A with id 1 and status unmodified

A (1)

A (1) Business application system A with id 1 and status modified

A Organizational unit AP1

O1

O2

A (1)

P2

full x specific intersection

A (1) supports P1 at O1

full y specific intersection

P1

O1

O2

A (1)

P2


A (1) supports P1 and P2 at O1


P1

O1

O2

A (1)

P2


A (1) supports P1 at O1 and O2


P1

O1

O2

A (1)

P2


A (1) supports P1 and P2 at O1 and O2


Creation Date: 2006-12-31Target Landscape SoCaStore

P1 P2

P1 is a predecessor of P2

x-sequence

Contact: EA-Group


Agenda


Softwarekarten



Fazit


Relevanz des Metamodells (1)

Que

lle: B

éziv

in, J

.: M

odel

Eng

inee

ring:

Fro

mP

rinci

ples

to P

latfo

rms,

TU

Wie

n, V

ortra

g, M

ärz,

200

5


Relevanz des Metamodells (2)

Que

lle: B

éziv

in, J

.: M

odel

Eng

inee

ring:

Fro

mP

rinci

ples

to P

latfo

rms,

TU

Wie

n, V

ortra

g, M

ärz,

200

5


Metamodell und Modellierungssprache

Ein Metamodell ist ein Modell über ein Modell

Ein Metamodell beschreibt die Syntax und Semantik einer Modellierungssprache(Hinweis: Die Semantik wird nicht immer zum Metamodell dazugezählt)


Softwarekarten und UML (1)

Unified Modeling Language (UML) 2.0 beinhaltet

Erweiterungsmechanismen wie Stereotypen und UML-Profiles- Können zur Modellierung von Anwendungslandschaften genutzt werden

- Bspw.: Heberling, M.; Maier, C.; Tensi, T.: Visual Modelling and Managing the Software Architecture Landscape in a large Enterprise by an Extension of the UML. In: OOPSLA, Workshop DSVL, Seattle, 2002.

Konzepte mit geringer oder unzureichender Semantik in UML

Farbe für Symbole bzw. Gestaltungsmittel- Es existieren ein paar Ansätze zur Modellierung mit Farben außerhalb der OMG

Größe von Symbolen bzw. Gestaltungsmitteln- Eine Klasse wächst mit der Anzahl der Attribute und Methoden (vertikal) und der Länge der Namen

dieser (horizontal)

Positionierung von Symbolen ist nicht wohldefiniert- Strukturdiagramme nutzen Verschachtelung für Klassen in Paketen,

- Komponentendiagramme nutzen Verschachtelung für Klassen in Komponenten,

- Verteilungsdiagramme nutzen Verschachtelung für Artefakte in Knoten, …

Softwarekarten nutzen Farben, Größen und Positionierungen wesentlich extensiver und müssen diese ebenso definieren!


Softwarekarten und UML (2)

Anzahl von Klassen in UML

UML 1.1: ca. 120

UML 1.5: ca. 200

UML 2.0: ca. 260

Anwendung von Klassendiagrammen zur Modellierung von Anwendungslandschaften kann mehrdeutig und somit gefährlich sein

Was ist eine Assoziationsklasse, die Support heißt und an eine Assoziation zwischen einem Anwendungssystem und einem Prozess gehängt wird?

Was ist die Sichtbarkeit von Attributen bei eine Klasse?

Was ist eine Komponente, die Klassen mit dem Stereotyp Anwendungssystementhält?

…


Spracharchitektur von UML 2.0 –Abstrakte und Konkrete Syntax

OMG beschreibt die abstrakte Syntax informell

Nur Teile der abstrakten Syntax werden mittels OCL oder BNF definiert

OMG besitzt keine formale oder semi-formale Definition der konkreten Syntax

Konkrete Syntax wird mittels Notationstabellen beschrieben

Beispiel aus der UML Superstructure 2.0


Agenda


Softwarekarten



Sichten und Betrachtungswinkel bei Softwarekarten

Operationen auf Softwarekarten

Strukturierungsprinzipien für Anwendungslandschaften

Szenarios zur Anwendung von Softwarekarten

Fazit


Prozessunterstützungskarte (1) –Verschiedene Sichten auf eine Landschaft

Für eine Softwarekarte können vier Betrachtungswinkel (Viewpoints) unterschieden werden

Ohne Integration: Kein Symbol wird in x- oder y-Richtung gedehnt

Vertikale Integration: Symbole werden (nur) in y-Richtung gedehnt

Horizontale Integration: Symbole werden (nur) in x-Richtung gedehnt

Horizontale + Vertikale Integration: Symbole werden in x- und y-Richtung gedehnt

… die obige Aufzählung unterscheidet nicht hinsichtlich der Visualisierung von zusätzlichen Attributen, wie Standardkonformität, SLA-Erfüllungsgrad etc.

Probleme die durch die Darstellung der Integration entstehen

Wenn ein Anwendungssystem zwei Geschäftsprozesse unterstützt, die nicht direkte Vorgänger oder Nachfolger sind, funktioniert das Dehnen der Symbole nicht!

Zwei oder mehr Symbole repräsentieren das gleiche Anwendungssystem

Wenn ein Anwendungssystem von mehr als einer Organisationseinheit genutzt, welche nicht als Nachbarn visualisiert werden, funktioniert das Dehnen der Symbole nicht!

Zwei oder mehr Symbole repräsentieren das gleiche Anwendungssystem

…


Prozessunterstützungskarte (2) –Ohne Integration

Acquisition

Headquarter

Subsidiary Munich

Subsidiary Hamburg

Subsidiary London

Warehousing Distribution

Warehouse






Monetary Transaction

System (Germany) (300)















Campaign Management

System (1500)

Campaign Management

System (1500)

Campaign Management

System (1500)

Campaign Management

System (1500)

Customer Complaint System

(1900)


(1900)


(1900)


System (Great Britain) (350)





Price Tag Printing System (Germany/

Munich) (1700)

Price Tag Printing System (Germany/Hamburg) (1720)

Price Tag Printing System (Great Britain) (1750)


(1650)


Hamburg) (1620)

POS System (Germany/Munich)

(1600)


System (2100)Online Shop (100)








(400)


Prozessunterstützungskarte (3) –Vertikale Integration

Acquisition

Headquarter

Subsidiary Munich

Subsidiary Hamburg

Subsidiary London





Warehouse

Campaign Management

System (1500)






(1900)











Munich) (1700)



(1600)


Hamburg) (1620)


(1650)






(400)


Prozessunterstützungskarte (4) –Horizontale Integration

Campaign Management

System (1500)






Munich) (1700)




(400)


(1600)


Hamburg) (1620)


(1650)












Campaign Management

System (1500)

Campaign Management

System (1500)

Campaign Management

System (1500)


(1900)


(1900)


(1900)





Headquarter

Subsidiary Munich

Subsidiary Hamburg

Subsidiary London

Warehouse

Acquisition Warehousing Distribution


System (2100)

Online Shop (100)


(1600)


Hamburg) (1620)


(1650)




Prozessunterstützungskarte (5) –Horizontale + Vertikale Integration

Acquisition

Headquarter

Subsidiary Munich

Subsidiary Hamburg

Subsidiary London





Warehouse


Campaign Management

System (1500)






(1900)









Munich) (1700)



(1600)


Hamburg) (1620)


(1650)






(400)


Agenda


Softwarekarten







Fazit


Veränderungen in der Anwendungslandschaft und ihre Visualisierung – Beispiel 1

Neue Geschäftsprozessunterstützung durch ein neues Anwendungssystem

Ergebnis: (create new MapSymbol)

Process 1

Org. Unit 1

Org. Unit 2

Org. Unit 3

Process 2


Application System 100


Process 1

Org. Unit 1

Org. Unit 2

Org. Unit 3

Process 2



Application System 100 Application System 200

Ohn

e In

tegr

atio

nV

ertik

ale

Inte

grat

ion

Process 1

Org. Unit 1

Org. Unit 2

Org. Unit 3

Process 2






Process 1

Org. Unit 1

Org. Unit 2

Org. Unit 3

Process 2







Neue Geschäftsprozessunterstützung durch ein existierendes Anwendungssystem

Ergebnis: (create new MapSymbol) OR (stretch existing MapSymbol)

Process 1

Org. Unit 1

Org. Unit 2

Org. Unit 3

Process 2




Process 1

Org. Unit 1

Org. Unit 2

Org. Unit 3

Process 2




Ohn

e In

tegr

atio

nV

ertik

ale

Inte

grat

ion

Wenn die Geschäftsprozessunterstützung von Anwendungssystemversionenvisualisiert wird, können die Darstellungen anders aussehen.

Process 1

Org. Unit 1

Org. Unit 2

Org. Unit 3

Process 2





Process 1

Org. Unit 1

Org. Unit 2

Org. Unit 3

Process 2







Konsolidiere die Geschäftsprozessunterstützung von zwei Anwendungssystemen

Ergebnis: (delete obsolete MapSymbol) AND ((create new MapSymbol) OR (stretch existing MapSymbol))

Ohn

e In

tegr

atio

nV

ertik

ale

Inte

grat

ion

Process 1

Org. Unit 1

Org. Unit 2

Org. Unit 3

Process 2






Process 1

Org. Unit 1

Org. Unit 2

Org. Unit 3

Process 2






Process 1

Org. Unit 1

Org. Unit 2

Org. Unit 3

Process 2







Process 1

Org. Unit 1

Org. Unit 2

Org. Unit 3

Process 2





Application System 200Application System 200



Veränderungen in der Anwendungslandschaft und ihre Visualisierung – Fortsetzung

… weitere Beispiele sind möglich

Ablösen eines existierenden Anwendungssystems durch ein neues Anwendungssystem

Dekomposition eines Anwendungssystems in mehrere Systeme

Ersatzloses Herauslösen eines Anwendungssystem


Agenda


Softwarekarten







Fazit


Strukturierungsprinzipien für Anwendungs-landschaften – 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


Strukturierungsprinzipien für Anwendungs-landschaften – 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, …


Strukturierungsprinzipien für Anwendungs-landschaften – Horizontale vs. Vertikale Integration (1)

Vollständige Integration der Anwendungslandschaft durch Kombination von horizontaler und vertikaler Integration

Alle Geschäftsprozesse bei allen Organisationseinheiten wird durch ein einzigesAnwendungssystem unterstützt

Unrealistisch und viel zu komplex!

Quelle: BMW Group – Strategie, Planung und Steuerung Group IT



Was ist die bevorzugte Lösung, vertikale oder horizontale Integration?

Jeder Fall benötigt eine individuelle Entscheidung- Vorteile und Nachteile abwägen, um eine passende Lösung zu finden

Unterstützungsprozesse (auch Sekundärprozesse), wie Accounting, HR etc., sind Kandidaten für vertikale Integration

Primärprozesse (Produktion, Vertrieb etc.), welche einen Diversifikationscharakter besitzen, benötigen eine niedrige vertikale Integration, um Flexibilität zu erhalten bzw. zu erreichen

?


Quelle: BMW Group – Strategie, Planung und Steuerung Group IT


Einführung von vertikaler Integration kann horizontale Integration aufbrechen

Aufbrechen + Extrahieren


Strukturierungsprinzipien für Anwendungs-landschaften – Entkopplung

Cluster-Bildung (auch Building Blocks)

Organisationseinheiten

Domänen oder Sparten oder „Lines of Business“

Einführung von Fassaden zwischen Clustern

Ziele

„Separation of Concerns“

Komplexität beherrschen- Schnittstellenreduktion zwischen den Clustern mittels definierter Kommunikationswege

Cluster A Cluster B

Gekoppelte Systeme Entkoppelte Systeme

FassadeAnwendungssystem

Cluster A Cluster B


Weitere Strukturierungsprinzipien für Anwendungslandschaften

Musterarchitekturen und Musterlösungen

Standardisierte Vorgaben für Softwarearchitekturen inkl. Lösungsbausteinen- Musterarchitektur: 4-tier-architecture mit Thin-Client, Webserver, Applikationsserver

und Datenbank

- Musterlösung: Internet Exporer, Apache HTTP Server, BEA WebLogic und Oracle 9i

Service-orientierung

Definition von Infrastruktur-Services, z.B.- E-Mail-Service, LAN-Service, Datenbank-Service, …

Definition von Business-Services- Fokussierung auf fachliche Definition von Schnittstellen

- Ermöglicht Wiederverwendung standardisierte Kommunikation

Service-orientierung und SLAs vereinfachen IT-Controlling- Einführen von Service-Level-Agreements (SLA)

- SLAs können verrechnet werden


Agenda


Softwarekarten







Fazit



Planen der Weiterentwicklung von Anwendungslandschaften

Ist-, Plan- und Soll-Landschaften

Visualisierung von Veränderungen in der Landschaft auf Softwarekarten

Darstellen und Beobachten der Konformität mit Musterarchitekturen

Beobachten der Erfüllung von Service Level Agreements

Analysieren der Abhängigkeiten von Infrastrukturelementen und Anwendungssystemen

… und viele Weitere

Vgl. „Enterprise Architecture Management Tool Survey 2005“ von sebis


Beispiel eines Szenarios –Ist-, Plan- und Soll-Landschaften (1)

Ist-Landschaft

Repräsentiert den Status quo an einem bestimmten Datum

Plan-Landschaft

Repräsentiert einen Status in der Zukunft an einem bestimmten Datum

Veränderungen ergeben sich durch geplante (und gehehmigte) Projekte

Es existieren mehr als eine Plan-Landschaft- Bspw. Plan-Landschaft per „2007-07-01“ und per „2008-01-01“

Soll-Landschaft

Repräsentiert einen angestrebten Zustand in der Zukunft

Veränderungen sind von strategischem Charakter

Ist eine Art von Vision



Beispielhaftes Informationsmodell zur Visualisierung von Ist-, Plan- und Soll-Landschaften



Ist-LandschaftAcquisition

Headquarter

Subsidiary Munich

Subsidiary Hamburg

Subsidiary London

Business Process A


Warehouse

A

Map Symbols

B (1)

C

Business Application B with Id 1

Organizational Unit C

„A“ is supported by „B (1)“ and used at „C“

A

Visualization Rules

B (1)C

Horizontal Alignment

Verti

cal A

lignm

ent

Legend






















Campaign Management

System (1500)

Campaign Management

System (1500)

Campaign Management

System (1500)

Campaign Management

System (1500)


(1900)


(1900)


(1900)








Munich) (1700)




(1650)


Hamburg) (1620)


(1600)










(400)



Plan-Landschaft per 2007-07-01Acquisition

Headquarter

Subsidiary Munich

Subsidiary Hamburg

Subsidiary London

Business Process A


Warehouse

A

Map Symbols

B (1)

C




A

Visualization Rules

B (1)C


Verti

cal A

lignm

ent

Legend






















Campaign Management

System (1500)

Campaign Management

System (1500)

Campaign Management

System (1500)

Campaign Management

System (1500)


(1900)


(1900)


(1900)




Munich) (1700)




(1650)


Hamburg) (1620)


(1600)








(400)









Soll-LandschaftAcquisition

Headquarter

Subsidiary Munich

Subsidiary Hamburg

Subsidiary London

Business Process A


Warehouse

A

Map Symbols

B (1)

C




A

Visualization Rules

B (1)C


Verti

cal A

lignm

ent

Legend






















Campaign Management

System (1500)

Campaign Management

System (1500)

Campaign Management

System (1500)

Campaign Management

System (1500)


(1900)


(1900)


(1900)



Price Tag Printing System (1770)

POS System (1670)








(400)









POS System (1670)

POS System (1670)



Konformität der Plan-Landschaft per 2007-07-01 mit der Soll-Landschaft

Verti

cal A

lignm

ent



Weitere Betrachtungswinkel (Viewpoint) zur Analyse der Ist-, Plan und Soll-Landschaften sind möglich

Verwendung von Transparenz zur Visualisierung von zwei Landschaften in einer Sicht (View)

Verwendung von Fächern (analog Compartments einer UML-Klasse) zur Darstellung weiterer Informationen

Verwendung der Füllfarbe von Gestaltungsmitteln zur Visualisierung unterschiedlicher Status

…


Agenda


Softwarekarten



Fazit


Fazit: Malen vs. Modellieren

Für das Management sollten die Informationen im Bild stimmig sein.

Wie das Bild entsteht, ist „fast“ egal.

Modellierungswerkzeuge helfen, - Bilder zu bauen, die konsistent mit den Informationen sind,

- ermöglichen es die Bilder zu modifizieren und

- gleichzeitig die Daten zu aktualisieren.

Aus den Bildern werden Modelle!

Es entwickeln sich zusehend Methoden im EA Management, die Modelle verwenden, um die EA derart zu gestalten, dass IT und Geschäft effizienter und effektiver zusammenarbeiten.

In Präsentationen sind die gemalten Bilder vorherrschend, - aber wenn jemand nachfragt, wie die Bedeutung einzelner Elemente ist,

- so sollte ein Modell, welches eine Semantik und Syntax hat und

- welches einen konsistenten Informationsstand widerspiegelt,

- existieren… hier helfen Werkzeuge!


Ein Beispiel aktueller Forschungsarbeit:Software Cartography Tool (1)


Ein Beispiel aktueller Forschungsarbeit:Software Cartography Tool (2)


Abschließend zwei Zitate…

„These pictures are meant to entertain you. There is no significant meaning to thearrows between the boxes.“

(A speaker at a recent software architecture conference, coming to a complex butultimately inadequate boxes-and-lines everywhere viewgraph of her system'sarchitecture and deciding that trying to explain it in front of a crowd would not be a good idea.)

Quelle: Clements, P. et al.: Documenting Software Architectures: Views and Beyond. Addison-Wesley, Boston, The SEI Series in Software Engineering, 2003.

„(...) we have tried out several tools in this area, without much success. It seems to methe tool vendors do not understand the difference between modelling and drawing, which I think is of fundamental importance. Their metamodels are rather complex, butnot integrated within themselves.“

Quelle: Riihinen, J., Chief Enterprise Architect, Business Infrastructure of Nokia, in an email correspondence, 2005.


Vielen Dank für Ihre Aufmerksamkeit!

Diskussion...

Informationen zum Forschungsprojekt unterhttp://www.softwarekartographie.de und http://wiki.softwarekartographie.de


Bibliographie zur Softwarekartographie[Bu07] Buckl, S. et al.: A Pattern based Approach for constructing Enterprise Architecture Management Information Models. In: 8. internationale Tagung

Wirtschaftsinformatik 2007, Karlsruhe, 2007.[ELW05] Ernst, A.; Lankes, J.; Wittenburg, A.: Werkzeuge für das Architekturmanagement großer IT-Landschaften. In: is report 12/2005, OXYGON Verlag,

2005. [Er06a] Ernst, A.; Lankes, J.; Schweda, C.; Wittenburg, A.: Tool Support for Enterprise Architecture Management - Strengths and Weaknesses. In: The

Tenth IEEE International EDOC Conference (EDOC 2006), Hong Kong, 2006.[Er06b] Ernst, A.; Lankes, J.; Schweda, C.; Wittenburg, A.: Using Model Transformation for Generating Visualizations from Repository Contents - An

Application to Software Cartography. Technische Universität München, Institut für Informatik, Lehrstuhl für Informatik 19, Technischer Bericht TB0601, 2006.

[FMW05] Fischer, F.; Matthes, F.; Wittenburg, A.: Improving IT Management at the BMW Group by Integrating Existing IT Management Processes. In: TheNinth IEEE International EDOC Conference (EDOC 2005), Enschede, Niederlande, 2005.

[LMW05a] Lankes, J.; Matthes, F.; Wittenburg, A.: Softwarekartographie: Systematische Darstellung von Anwendungslandschaften. In: 7. internationale Tagung Wirtschaftsinformatik 2005, Bamberg, 2005.

[LMW05b] Lankes, J.; Matthes, F.; Wittenburg, A.: Architekturbeschreibung von Anwendungslandschaften: Softwarekartographie und IEEE Std 1471-2000. In: Software Engineering 2005, Essen, 2005.

[LMW05c] Lankes, J.; Matthes, F.; Wittenburg, A.: Softwarekartographie als Beitrag zum Architekturmanagement. In (Aier, S., Schönherr, M. Hrsg.): Unternehmensarchitekturen und Systemintegration, Band 3, Gito, Berlin, 2005.

[LMW06] Lankes, J.; Matthes, F.; Wittenburg, A.: Exkurs Softwarekartographie. In (Keller, W.): IT-Unternehmensarchitektur – Von der Geschäftsstrategie zur optimalen IT-Unterstützung. dpunkt.Verlag, Heidelberg, 2006.

[MW04a] Matthes, F.; Wittenburg, A.: Softwarekarten zur Visualisierung von Anwendungslandschaften und ihren Aspekten - Eine Bestandsaufnahme. Technische Universität München, Fakultät für Informatik, Lehrstuhl für Informatik 19, Technischer Bericht, 2004.

[MW04b] Matthes, F.; Wittenburg, A.: Softwarekartographie: Visualisierung von Anwendungslandschaften und ihrer Schnittstellen. In: Informatik 2004 -Informatik verbindet!, Ulm, Deutschland, 2004.

[MW06] Matthes, F.; Wittenburg, A.: Tool-Auswahl erfordert Detailwissen. In: Computerwoche 38, 2006.[se05] sebis: Enterprise Architecture Management Tool Survey 2005. Technische Universität München, Chair for Informatics 19 (sebis), 2005.[Wi07] Wittenburg, A., Fischer, F.; Hallermeier, T.; Matthes, F.: Building an integrated IT governance platform at the BMW Group. 2007 (to be published).

Documents

Methoden und Modelle zur Beschreibung, Bewertung und ... · Inventory Control System (200) Product Shipment System (Germany) (400) Campaign Management System (1500) Customer Complaint