View
6
Download
0
Category
Preview:
Citation preview
© 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
© sebis 2070504-Wittenburg-Softwarekartographie
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
© sebis 3070504-Wittenburg-Softwarekartographie
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.
© sebis 4070504-Wittenburg-Softwarekartographie
Agenda
Motivation und thematische Einordnung
Malen von Architekturen
Architektur, Architekturdokumentation und Architekturmanagement
Management von Anwendungslandschaften
Softwarekarten
UML für Softwarekarten?
Anwendung von Softwarekarten
Fazit
© sebis 5070504-Wittenburg-Softwarekartographie
Beispiel für eine gemalte Architekturdokumentation(1)
© sebis 6070504-Wittenburg-Softwarekartographie
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!
© sebis 7070504-Wittenburg-Softwarekartographie
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.
© sebis 8070504-Wittenburg-Softwarekartographie
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].
© sebis 9070504-Wittenburg-Softwarekartographie
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.
© sebis 10070504-Wittenburg-Softwarekartographie
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
© sebis 11070504-Wittenburg-Softwarekartographie
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, …
© sebis 12070504-Wittenburg-Softwarekartographie
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
© sebis 13070504-Wittenburg-Softwarekartographie
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
© sebis 14070504-Wittenburg-Softwarekartographie
Sponsoren und Projektpartner
Sponsoren
Ernst Denert-Stiftung
Projektpartner
Deutsche Börse Systems
© sebis 15070504-Wittenburg-Softwarekartographie
Agenda
Motivation und thematische Einordnung
Softwarekarten
Softwarekartentypen
Schichtenprinzip
Aufbau von Softwarekarten
UML für Softwarekarten?
Anwendung von Softwarekarten
Fazit
© sebis 16070504-Wittenburg-Softwarekartographie
Ein paar echte Beispiele…
© sebis 17070504-Wittenburg-Softwarekartographie
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, …
© sebis 18070504-Wittenburg-Softwarekartographie
Konsolidierung von Softwarekarten
Analyse von existierenden Darstellungen für Anwendungslandschaften
Konsolidierung der verschiedenen Karten zu drei Softwarekartentypen
© sebis 19070504-Wittenburg-Softwarekartographie
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”
© sebis 20070504-Wittenburg-Softwarekartographie
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)
© sebis 21070504-Wittenburg-Softwarekartographie
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, ...
© sebis 22070504-Wittenburg-Softwarekartographie
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
© sebis 23070504-Wittenburg-Softwarekartographie
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
© sebis 24070504-Wittenburg-Softwarekartographie
Agenda
Motivation und thematische Einordnung
Softwarekarten
Softwarekartentypen
Schichtenprinzip
Aufbau von Softwarekarten
UML für Softwarekarten?
Anwendung von Softwarekarten
Fazit
© sebis 25070504-Wittenburg-Softwarekartographie
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
© sebis 26070504-Wittenburg-Softwarekartographie
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]
© sebis 27070504-Wittenburg-Softwarekartographie
Visualisierung von Informationen auf Softwarekarten (2)
[se05]
© sebis 28070504-Wittenburg-Softwarekartographie
Visualisierung von Informationen auf Softwarekarten (3)
[se05]
© sebis 29070504-Wittenburg-Softwarekartographie
Agenda
Motivation und thematische Einordnung
Softwarekarten
Softwarekartentypen
Schichtenprinzip
Aufbau von Softwarekarten
UML für Softwarekarten?
Anwendung von Softwarekarten
Fazit
© sebis 30070504-Wittenburg-Softwarekartographie
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
© sebis 31070504-Wittenburg-Softwarekartographie
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
© sebis 32070504-Wittenburg-Softwarekartographie
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)
Inventory Control System (200)
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
full x specific intersection
A (1) supports P1 and P2 at O1
full y specific intersection
P1
O1
O2
A (1)
P2
full x specific intersection
A (1) supports P1 at O1 and O2
full y specific intersection
P1
O1
O2
A (1)
P2
full x specific intersection
A (1) supports P1 and P2 at O1 and O2
full y specific intersection
Creation Date: 2006-12-31Target Landscape SoCaStore
P1 P2
P1 is a predecessor of P2
x-sequence
Contact: EA-Group
© sebis 33070504-Wittenburg-Softwarekartographie
Agenda
Motivation und thematische Einordnung
Softwarekarten
UML für Softwarekarten?
Anwendung von Softwarekarten
Fazit
© sebis 34070504-Wittenburg-Softwarekartographie
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
© sebis 35070504-Wittenburg-Softwarekartographie
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
© sebis 36070504-Wittenburg-Softwarekartographie
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)
© sebis 37070504-Wittenburg-Softwarekartographie
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!
© sebis 38070504-Wittenburg-Softwarekartographie
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?
…
© sebis 39070504-Wittenburg-Softwarekartographie
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
© sebis 40070504-Wittenburg-Softwarekartographie
Agenda
Motivation und thematische Einordnung
Softwarekarten
UML für Softwarekarten?
Anwendung von Softwarekarten
Sichten und Betrachtungswinkel bei Softwarekarten
Operationen auf Softwarekarten
Strukturierungsprinzipien für Anwendungslandschaften
Szenarios zur Anwendung von Softwarekarten
Fazit
© sebis 41070504-Wittenburg-Softwarekartographie
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
…
© sebis 42070504-Wittenburg-Softwarekartographie
Prozessunterstützungskarte (2) –Ohne Integration
Acquisition
Headquarter
Subsidiary Munich
Subsidiary Hamburg
Subsidiary London
Warehousing Distribution
Warehouse
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Monetary Transaction
System (Germany) (300)
Monetary Transaction
System (Germany) (300)
Monetary Transaction
System (Germany) (300)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Campaign Management
System (1500)
Campaign Management
System (1500)
Campaign Management
System (1500)
Campaign Management
System (1500)
Customer Complaint System
(1900)
Customer Complaint System
(1900)
Customer Complaint System
(1900)
Monetary Transaction
System (Great Britain) (350)
Monetary Transaction
System (Germany) (300)
Monetary Transaction
System (Germany) (300)
Price Tag Printing System (Germany/
Munich) (1700)
Price Tag Printing System (Germany/Hamburg) (1720)
Price Tag Printing System (Great Britain) (1750)
POS System (Great Britain)
(1650)
POS System (Germany/
Hamburg) (1620)
POS System (Germany/Munich)
(1600)
Customer Relationship Management
System (2100)Online Shop (100)
Monetary Transaction
System (Germany) (300)
Monetary Transaction
System (Great Britain) (350)
Monetary Transaction
System (Germany) (300)
Product Shipment System (Germany)
(400)
© sebis 43070504-Wittenburg-Softwarekartographie
Prozessunterstützungskarte (3) –Vertikale Integration
Acquisition
Headquarter
Subsidiary Munich
Subsidiary Hamburg
Subsidiary London
Warehousing Distribution
Inventory Control System (200)
Monetary Transaction
System (Germany) (300)
Warehouse
Campaign Management
System (1500)
Customer Relationship Management
System (2100)Online Shop (100)
Monetary Transaction
System (Germany) (300)
Customer Complaint System
(1900)
Monetary Transaction
System (Germany) (300)
Inventory Control System (200)
Inventory Control System (200)
Monetary Transaction
System (Great Britain) (350)
Monetary Transaction
System (Germany) (300)
Price Tag Printing System (Germany/Hamburg) (1720)
Price Tag Printing System (Germany/
Munich) (1700)
Price Tag Printing System (Great Britain) (1750)
POS System (Germany/Munich)
(1600)
POS System (Germany/
Hamburg) (1620)
POS System (Great Britain)
(1650)
Monetary Transaction
System (Great Britain) (350)
Monetary Transaction
System (Germany) (300)
Product Shipment System (Germany)
(400)
© sebis 44070504-Wittenburg-Softwarekartographie
Prozessunterstützungskarte (4) –Horizontale Integration
Campaign Management
System (1500)
Monetary Transaction
System (Great Britain) (350)
Monetary Transaction
System (Germany) (300)
Price Tag Printing System (Germany/
Munich) (1700)
Price Tag Printing System (Germany/Hamburg) (1720)
Price Tag Printing System (Great Britain) (1750)
Product Shipment System (Germany)
(400)
POS System (Germany/Munich)
(1600)
POS System (Germany/
Hamburg) (1620)
POS System (Great Britain)
(1650)
Monetary Transaction
System (Germany) (300)
Monetary Transaction
System (Germany) (300)
Monetary Transaction
System (Germany) (300)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Campaign Management
System (1500)
Campaign Management
System (1500)
Campaign Management
System (1500)
Customer Complaint System
(1900)
Customer Complaint System
(1900)
Customer Complaint System
(1900)
Monetary Transaction
System (Germany) (300)
Monetary Transaction
System (Germany) (300)
Headquarter
Subsidiary Munich
Subsidiary Hamburg
Subsidiary London
Warehouse
Acquisition Warehousing Distribution
Customer Relationship Management
System (2100)
Online Shop (100)
POS System (Germany/Munich)
(1600)
POS System (Germany/
Hamburg) (1620)
POS System (Great Britain)
(1650)
Monetary Transaction
System (Great Britain) (350)
© sebis 45070504-Wittenburg-Softwarekartographie
Prozessunterstützungskarte (5) –Horizontale + Vertikale Integration
Acquisition
Headquarter
Subsidiary Munich
Subsidiary Hamburg
Subsidiary London
Warehousing Distribution
Inventory Control System (200)
Monetary Transaction
System (Germany) (300)
Warehouse
Inventory Control System (200)
Campaign Management
System (1500)
Customer Relationship Management
System (2100)Online Shop (100)
Monetary Transaction
System (Germany) (300)
Customer Complaint System
(1900)
Monetary Transaction
System (Germany) (300)
Monetary Transaction
System (Great Britain) (350)
Monetary Transaction
System (Germany) (300)
Price Tag Printing System (Germany/Hamburg) (1720)
Price Tag Printing System (Germany/
Munich) (1700)
Price Tag Printing System (Great Britain) (1750)
POS System (Germany/Munich)
(1600)
POS System (Germany/
Hamburg) (1620)
POS System (Great Britain)
(1650)
Monetary Transaction
System (Great Britain) (350)
Monetary Transaction
System (Germany) (300)
Product Shipment System (Germany)
(400)
© sebis 46070504-Wittenburg-Softwarekartographie
Agenda
Motivation und thematische Einordnung
Softwarekarten
UML für Softwarekarten?
Anwendung von Softwarekarten
Sichten und Betrachtungswinkel bei Softwarekarten
Operationen auf Softwarekarten
Strukturierungsprinzipien für Anwendungslandschaften
Szenarios zur Anwendung von Softwarekarten
Fazit
© sebis 47070504-Wittenburg-Softwarekartographie
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
Price Tag Printing System (Germany/Hamburg) (1720)
Application System 100
Application System 200
Process 1
Org. Unit 1
Org. Unit 2
Org. Unit 3
Process 2
Application System 100
Application System 100
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
Application System 100
Application System 100
Application System 100 Application System 200
Application System 300
Application System 300
Process 1
Org. Unit 1
Org. Unit 2
Org. Unit 3
Process 2
Price Tag Printing System (Germany/Hamburg) (1720)
Application System 100
Application System 200
Application System 300
© sebis 48070504-Wittenburg-Softwarekartographie
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)
Process 1
Org. Unit 1
Org. Unit 2
Org. Unit 3
Process 2
Price Tag Printing System (Germany/Hamburg) (1720)
Application System 100
Application System 200
Process 1
Org. Unit 1
Org. Unit 2
Org. Unit 3
Process 2
Application System 100
Application System 100
Application System 100 Application System 200
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
Price Tag Printing System (Germany/Hamburg) (1720)
Application System 100
Application System 200
Application System 200
Process 1
Org. Unit 1
Org. Unit 2
Org. Unit 3
Process 2
Application System 100
Application System 100
Application System 100 Application System 200
Application System 200
© sebis 49070504-Wittenburg-Softwarekartographie
Veränderungen in der Anwendungslandschaft und ihre Visualisierung – Beispiel 3
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
Application System 100
Application System 100
Application System 100 Application System 200
Application System 300
Application System 200
Process 1
Org. Unit 1
Org. Unit 2
Org. Unit 3
Process 2
Price Tag Printing System (Germany/Hamburg) (1720)
Application System 100
Application System 200
Application System 300
Application System 300
Process 1
Org. Unit 1
Org. Unit 2
Org. Unit 3
Process 2
Price Tag Printing System (Germany/Hamburg) (1720)
Application System 100
Application System 200
Application System 300
Application System 300
Application System 200
Process 1
Org. Unit 1
Org. Unit 2
Org. Unit 3
Process 2
Application System 100
Application System 100
Application System 100 Application System 200
Application System 300
Application System 200Application System 200
Application System 200
© sebis 50070504-Wittenburg-Softwarekartographie
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
© sebis 51070504-Wittenburg-Softwarekartographie
Agenda
Motivation und thematische Einordnung
Softwarekarten
UML für Softwarekarten?
Anwendung von Softwarekarten
Sichten und Betrachtungswinkel bei Softwarekarten
Operationen auf Softwarekarten
Strukturierungsprinzipien für Anwendungslandschaften
Szenarios zur Anwendung von Softwarekarten
Fazit
© sebis 52070504-Wittenburg-Softwarekartographie
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
© sebis 53070504-Wittenburg-Softwarekartographie
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, …
© sebis 54070504-Wittenburg-Softwarekartographie
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
© sebis 55070504-Wittenburg-Softwarekartographie
Strukturierungsprinzipien für Anwendungs-landschaften – Horizontale vs. Vertikale Integration (2)
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
?
© sebis 56070504-Wittenburg-Softwarekartographie
Quelle: BMW Group – Strategie, Planung und Steuerung Group IT
Strukturierungsprinzipien für Anwendungs-landschaften – Horizontale vs. Vertikale Integration (3)
Einführung von vertikaler Integration kann horizontale Integration aufbrechen
Aufbrechen + Extrahieren
© sebis 57070504-Wittenburg-Softwarekartographie
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
© sebis 58070504-Wittenburg-Softwarekartographie
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
© sebis 59070504-Wittenburg-Softwarekartographie
Agenda
Motivation und thematische Einordnung
Softwarekarten
UML für Softwarekarten?
Anwendung von Softwarekarten
Sichten und Betrachtungswinkel bei Softwarekarten
Operationen auf Softwarekarten
Strukturierungsprinzipien für Anwendungslandschaften
Szenarios zur Anwendung von Softwarekarten
Fazit
© sebis 60070504-Wittenburg-Softwarekartographie
Szenarios zur Anwendung von Softwarekarten
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
© sebis 61070504-Wittenburg-Softwarekartographie
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
© sebis 62070504-Wittenburg-Softwarekartographie
Beispiel eines Szenarios –Ist-, Plan- und Soll-Landschaften (2)
Beispielhaftes Informationsmodell zur Visualisierung von Ist-, Plan- und Soll-Landschaften
© sebis 63070504-Wittenburg-Softwarekartographie
Beispiel eines Szenarios –Ist-, Plan- und Soll-Landschaften (3)
Ist-LandschaftAcquisition
Headquarter
Subsidiary Munich
Subsidiary Hamburg
Subsidiary London
Business Process A
Warehousing Distribution
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
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Monetary Transaction
System (Germany) (300)
Monetary Transaction
System (Germany) (300)
Monetary Transaction
System (Germany) (300)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Campaign Management
System (1500)
Campaign Management
System (1500)
Campaign Management
System (1500)
Campaign Management
System (1500)
Customer Complaint System
(1900)
Customer Complaint System
(1900)
Customer Complaint System
(1900)
Monetary Transaction
System (Great Britain) (350)
Monetary Transaction
System (Germany) (300)
Monetary Transaction
System (Germany) (300)
Price Tag Printing System (Germany/
Munich) (1700)
Price Tag Printing System (Germany/Hamburg) (1720)
Price Tag Printing System (Great Britain) (1750)
POS System (Great Britain)
(1650)
POS System (Germany/
Hamburg) (1620)
POS System (Germany/Munich)
(1600)
Customer Relationship Management
System (2100)Online Shop (100)
Monetary Transaction
System (Germany) (300)
Monetary Transaction
System (Great Britain) (350)
Monetary Transaction
System (Germany) (300)
Product Shipment System (Germany)
(400)
© sebis 64070504-Wittenburg-Softwarekartographie
Beispiel eines Szenarios –Ist-, Plan- und Soll-Landschaften (4)
Plan-Landschaft per 2007-07-01Acquisition
Headquarter
Subsidiary Munich
Subsidiary Hamburg
Subsidiary London
Business Process A
Warehousing Distribution
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
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Monetary Transaction
System (Germany) (300)
Monetary Transaction
System (Germany) (300)
Monetary Transaction
System (Germany) (300)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Campaign Management
System (1500)
Campaign Management
System (1500)
Campaign Management
System (1500)
Campaign Management
System (1500)
Customer Complaint System
(1900)
Customer Complaint System
(1900)
Customer Complaint System
(1900)
Monetary Transaction
System (Germany) (300)
Price Tag Printing System (Germany/
Munich) (1700)
Price Tag Printing System (Germany/Hamburg) (1720)
Price Tag Printing System (Great Britain) (1750)
POS System (Great Britain)
(1650)
POS System (Germany/
Hamburg) (1620)
POS System (Germany/Munich)
(1600)
Customer Relationship Management
System (2100)Online Shop (100)
Monetary Transaction
System (Germany) (300)
Monetary Transaction
System (Germany) (300)
Product Shipment System (Germany)
(400)
Monetary Transaction
System (Germany) (300)
Monetary Transaction
System (Germany) (300)
Monetary Transaction
System (Germany) (300)
© sebis 65070504-Wittenburg-Softwarekartographie
Beispiel eines Szenarios –Ist-, Plan- und Soll-Landschaften (5)
Soll-LandschaftAcquisition
Headquarter
Subsidiary Munich
Subsidiary Hamburg
Subsidiary London
Business Process A
Warehousing Distribution
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
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Monetary Transaction
System (Germany) (300)
Monetary Transaction
System (Germany) (300)
Monetary Transaction
System (Germany) (300)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Inventory Control System (200)
Campaign Management
System (1500)
Campaign Management
System (1500)
Campaign Management
System (1500)
Campaign Management
System (1500)
Customer Complaint System
(1900)
Customer Complaint System
(1900)
Customer Complaint System
(1900)
Monetary Transaction
System (Germany) (300)
Price Tag Printing System (1770)
POS System (1670)
Customer Relationship Management
System (2100)Online Shop (100)
Monetary Transaction
System (Germany) (300)
Monetary Transaction
System (Germany) (300)
Product Shipment System (Germany)
(400)
Monetary Transaction
System (Germany) (300)
Monetary Transaction
System (Germany) (300)
Monetary Transaction
System (Germany) (300)
Price Tag Printing System (1770)
Price Tag Printing System (1770)
POS System (1670)
POS System (1670)
© sebis 66070504-Wittenburg-Softwarekartographie
Beispiel eines Szenarios –Ist-, Plan- und Soll-Landschaften (6)
Konformität der Plan-Landschaft per 2007-07-01 mit der Soll-Landschaft
Verti
cal A
lignm
ent
© sebis 67070504-Wittenburg-Softwarekartographie
Beispiel eines Szenarios –Ist-, Plan- und Soll-Landschaften (7)
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
…
© sebis 68070504-Wittenburg-Softwarekartographie
Agenda
Motivation und thematische Einordnung
Softwarekarten
UML für Softwarekarten?
Anwendung von Softwarekarten
Fazit
© sebis 69070504-Wittenburg-Softwarekartographie
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!
© sebis 70070504-Wittenburg-Softwarekartographie
Ein Beispiel aktueller Forschungsarbeit:Software Cartography Tool (1)
© sebis 71070504-Wittenburg-Softwarekartographie
Ein Beispiel aktueller Forschungsarbeit:Software Cartography Tool (2)
© sebis 72070504-Wittenburg-Softwarekartographie
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.
© sebis 73070504-Wittenburg-Softwarekartographie
Vielen Dank für Ihre Aufmerksamkeit!
Diskussion...
Informationen zum Forschungsprojekt unterhttp://www.softwarekartographie.de und http://wiki.softwarekartographie.de
© sebis 74070504-Wittenburg-Softwarekartographie
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).
Recommended