Enterprise Architecture Management
Endlich Agil!
Dr. Christopher Schulz
Schön, dass Sie da sind!
Es erwartet Sie…

Seite 2
Fallbeispiel
Montag – 30. September – 10:37 Uhr
Irgendwo in Süddeutschland in einem Büro…

Seite 3
Fallbeispiel: Michael Nagel benötigt ein neues Konzept
Klassisches Enterprise Architecture Management stößt an Grenzen
Bildquelle: Pixabay.com | rebcenter-moscow
Steigendes
Datenvolumen
Neue
Digitallösungen
Agile
Vorgehensmodelle
Wachsende
Fachbedarfe
Governance &
Zentralität
Standardisierung &
Qualitätsvorgaben
Struktur &
Planbarkeit
Konzepte &
Dokumentation

Seite 4
Fallbeispiel: Die fünf konkreten Probleme von Michael Nagel
Agile EAM Tools & Techniken
#1: Agile Mindset
Wodurch wird ein EAM agiler? #2: Added Value
Wie lässt sich der EAM Nutzen
aufzeigen?
#5: Application Standards
Wie wird eine IT-Landschaft richtig
standardisiert?
#3. EA Documentation
Welche EA Infos gehören
dokumentiert?
#4: Sofware Assessment
Wie wird Software unbürokratisch
genehmigt?

Seite 5
Gemeinsames Verständnis als Grundlage
Warm-up…
Was ist
Enterprise Architecture
Management?
Tipp: https://youtu.be/d6Is4g14r20

Seite 6
Die Architektur von Systemen
Eigenschaften, Beziehungen und Entwicklung
ISO/IEC/IEEE 42010 Systems and Software
Engineering – Architecture Description
„Die Architektur eines Systems umfasst die
Grundkonzepte und Eigenschaften eines
Systems in seiner Umwelt, verkörpert
durch dessen Elemente, Relationen und
durch die Prinzipien seines Entwurfs und
seiner Evolution.“
Quelle: pixabay.com | Free-Photos

Seite 7
Das ‚System‘ Enterprise Architecture (EA)
Ein Unternehmen besteht aus Elementen, Eigenschaften und Beziehungen
Enterprise Technical Architecture
Enterprise Application Architecture
Enterprise Business Architecture
▪ Capabilities
▪ Geschäftsprozesse
▪ Use-Cases
▪ Fachdomänen
▪ Business Services
▪ Organisationseinheiten
▪ Rollen
▪ …
▪ Applikationen
▪ Schnittstellen
▪ Applikationsdomänen
▪ Applikationsfunktionen
▪ Applikations-Services
▪ IT Service Prozesse
▪ Service Levels
▪ …
▪ Geschäfts-
objekte
▪ Informa-
tionsobjekte
▪ Daten-
objekte
▪ Infrastrukturkomponenten
▪ Hardware-Module
▪ Technologie-Plattformen
▪ Netzwerkelemente
▪ Infrastruktur Services
▪ Deployment Unit
▪ Execution Units
▪ …
Quelle: Icons von https://icons8.com
IT
Architektur
Fach-
Architektur
Enterprise
Information
Architecture

Seite 8
Städteplanung als Analogie
Herauszoomen und Blick auf die Gesamtarchitektur
Quelle: pixabay.com | designerpoint

Seite 9
palladio consulting
Unser Namensgeber
Andrea di Pietro della Gondola, genannt Palladio (1508 –
1580), war der bedeutendste Architekt der Renaissance in
Oberitalien. Palladio war der „erste große Berufsarchitekt“, der
nur als Architekt tätig war, ohne sich auf einem anderen Gebiet
der Kunst hervorzutun.
Sein Ziel war eine Architektur, bei der unter Beachtung
ästhetischer Prinzipien von Proportion und Ausgewogenheit
die Anforderungen an die Baufunktion, an die praktischen und
ideellen Bedürfnisse des Auftraggebers ebenso berücksichtigt
werden wie die Bedingungen, die sich aus den Gegebenheiten
des Bauplatzes ergaben.
Quelle: Text und Abbildung von https://de.wikipedia.org

Seite 10
Enterprise Architecture Management (EAM) entwickelt die EA
Systematisch von der Ist-EA, über die Plan-EA zur Soll-EA
DefinitionAbleitung
Ist-EA Soll-EAPlan-EA2 Plan-EA3Plan-EA1
Enterprise Technical
Architecture
Enterprise Application
Architecture
Enterprise Business
Architecture
EnterpriseInform.
Architecture
Enterprise Technical
Architecture
Enterprise Application
Architecture
Enterprise Business
Architecture
EnterpriseInform.
Architecture
Enterprise Technical
Architecture
Enterprise Application
Architecture
Enterprise Business
Architecture
EnterpriseInform.
Architecture
Enterprise Technical
Architecture
Enterprise Application
Architecture
Enterprise Business
Architecture
EnterpriseInform.
Architecture
Erhebung
StakeholderEA Tool DokumentationCMDB
Quelle: Icons von https://icons8.com
Technical Architecture
Application Architecture
Business Architecture
Information
Architecture

Seite 12
Die EAM Vermittlerfunktion
Einsatz auf strategischer und operativer Ebene
Musterlösungen
UnternehmenProjekte
PrinzipienGeschäftsziele
Strategie
Leitplanken
IT-SystemeFachprozesseIT-Komponente
Dokumentation Schnittstellen

Seite 13
Problem #1: Schwergewichtiges EAM im Wolkenschloss
Für die Stakeholder sind die EAM Prozesse zu abgehoben und langwierig
Quelle: pixabay.com | SarahRichterArt

Seite 14
Ist das Wolkenschloss unser Schloss Neuschwanstein?
Nicht ganz…
Quelle: pixabay.com | SarahRichterArt | jh146

Seite 15
Fallbeispiel: Michael Nagel soll EAM agiler machen
Raus aus dem Wolkenschloss mit Hilfe agiler Techniken
Quelle: Agile Manifesto (deutsch), 2001

Seite 17
Manifest für Agile Softwareentwicklung
12 Prinzipien hinter dem Agilen Manifest
Unsere höchste Priorität ist es,
den Kunden durch frühe und
kontinuierliche Auslieferung
wertvoller Software zufrieden zu
stellen.
Heiße Anforderungsänderungen
selbst spät in der Entwicklung
willkommen. Agile Prozesse
nutzen Veränderungen zum
Wettbewerbsvorteil des Kunden.
Liefere funktionierende Software
regelmäßig innerhalb weniger
Wochen oder Monate und
bevorzuge dabei die kürzere
Zeitspanne.
Fachexperten und Entwickler
müssen während des Projektes
täglich zusammenarbeiten.
Errichte Projekte rund um
motivierte Individuen. Gib ihnen
das Umfeld und die
Unterstützung, die sie benötigen
und vertraue darauf, dass sie die
Aufgabe erledigen.
Die effizienteste und effektivste
Methode, Informationen an und
innerhalb eines Entwickl-
ungsteams zu übermitteln, ist im
Gespräch von Angesicht zu
Angesicht.
Funktionierende Software ist das
wichtigste Fortschrittsmaß.
Agile Prozesse fördern
nachhaltige Entwicklung. Die
Auftraggeber, Entwickler und
Benutzer sollten ein gleich-
mäßiges Tempo auf unbe-
grenzte Zeit halten können.
Ständiges Augenmerk auf
technische Exzellenz und
gutes Design fördert Agilität.
Einfachheit -- die Kunst, die
Menge nicht
getaner Arbeit zu maximieren --
ist essenziell.
Die besten Architekturen,
Anforderungen und Entwürfe
entstehen durch
selbstorganisierte Teams.
In regelmäßigen Abständen
reflektiert das Team, wie es
effektiver werden kann und
passt sein Verhalten
entsprechend an.
Quelle: Agile Manifesto (deutsch), 2001

Seite 18
Blick durch die EAM Brille
Enterprise Architecture Management nach agilen Prinzipien ausrichten
Unsere höchste Priorität ist es,
den Kunden durch frühe und
kontinuierliche Auslieferung
wertvoller Software zufrieden zu
stellen.
Heiße Anforderungsänderungen
selbst spät in der Entwicklung
willkommen. Agile Prozesse
nutzen Veränderungen zum
Wettbewerbsvorteil des Kunden.
Liefere funktionierende Software
regelmäßig innerhalb weniger
Wochen oder Monate und
bevorzuge dabei die kürzere
Zeitspanne.
Fachexperten und Entwickler
müssen während des Projektes
täglich zusammenarbeiten.
Errichte Projekte rund um
motivierte Individuen. Gib ihnen
das Umfeld und die
Unterstützung, die sie benötigen
und vertraue darauf, dass sie die
Aufgabe erledigen.
Die effizienteste und effektivste
Methode, Informationen an und
innerhalb eines Entwickl-
ungsteams zu übermitteln, ist im
Gespräch von Angesicht zu
Angesicht.
Funktionierende Software ist das
wichtigste Fortschrittsmaß.
Agile Prozesse fördern
nachhaltige Entwicklung. Die
Auftraggeber, Entwickler und
Benutzer sollten ein gleich-
mäßiges Tempo auf unbe-
grenzte Zeit halten können.
Ständiges Augenmerk auf
technische Exzellenz und
gutes Design fördert Agilität.
Einfachheit - die Kunst, die
Menge nicht getaner Arbeit zu
maximieren - ist essenziell.
Die besten Architekturen,
Anforderungen und Entwürfe
entstehen durch
selbstorganisierte Teams.
In regelmäßigen Abständen
reflektiert das Team, wie es
effektiver werden kann und
passt sein Verhalten
entsprechend an.
Quelle: Agile Manifesto (deutsch), 2001

Seite 19
Agilität auf allen Ebenen einer Enterprise Architecture
Je nach Aufgabe stehen andere Ebenen und Elemente im Fokus
Enterprise Technical Architecture
Enterprise Application Architecture
Enterprise Business Architecture
▪ Capabilities
▪ Geschäftsprozesse
▪ Use-Cases
▪ Fachdomänen
▪ Business Services
▪ Organisationseinheiten
▪ Rollen
▪ …
▪ Applikationen
▪ Schnittstellen
▪ Applikationsdomänen
▪ Applikationsfunktionen
▪ Applikations-Services
▪ IT Service Prozesse
▪ Service Levels
▪ …
▪ Geschäfts-
objekte
▪ Informa-
tionsobjekte
▪ Daten-
objekte
▪ Infrastrukturkomponenten
▪ Hardware-Module
▪ Technologie-Plattformen
▪ Netzwerkelemente
▪ Infrastruktur Services
▪ Deployment Unit
▪ Execution Units
▪ …
IT
Architektur
Business
Architektur
Enterprise
Information
Architecture
Quelle: Icons von https://icons8.com

Seite 20
Problem #2: Unklarer Nutzen von EAM
Stakeholder kennen den Mehrwert eines Architekturmanagements nicht
Quelle: pixabay.com | RobinHiggins

Seite 21
Fallbeispiel: Michael Nagel soll den Nutzen von EAM nachweisen
Der Mehrwert von EAM für die Wertschöpfung eines Unternehmens
Funktional
Emotional
Lebensveränderung
Gesellschaftliche Wirkung
spart zeit sorgt für
Einkünfte
senkt
Risiken
organisiert integriert verbindetvereinfacht
senkt den
Aufwand
vermeidet
Ärger
senkt
Kosten
Qualität Vielfalt
Sensorische
Attraktivität
klärt auf
Wohlergehen
nimmt Sorgen belohnt
therapeutischer
Wert
Spaß und
Unterhaltung
Nostalgie Design und
Ästhetik
Attraktivität
Image
schafft Zugang
Motivation
schafft
Hoffnung
Zugehörigkeit
und Einbindung
Selbst-
verwirklichung
Vererben
Selbsttranszendenz
Quelle: Angelehnt an Almquist et al.: Was Produkte wertvoll macht. HBM 10/2016 | Symbole von Icons8.com
Möglicher Nutzen EAM

Seite 22
Die Pyramide der Nutzenelemente in der Praxis
Fallbeispiel Apple Inc.
Quelle: YouTube: First iPod Commercial 2001

Seite 23
Die Pyramide der Nutzenelemente in der Praxis
Nutzenargumentation bei Apple Inc.
Apple iPod
„A 1.000 Songs
in your Pocket“
➢ Spaß & Unterhaltung
(Speicherplatz)
Quelle: pixabay.com – mikefoster | Free-Photos | charlie0111
Apple MacBook Air
„Carries you
through the day“
➢ Vermeidet Ärger
(Akkulaufzeit)
Apple Watch
„Run your day.
Right from your wrist.“
➢ Organisiert
(Funktionsumfang)

Seite 24
Problem #3: Unverhältnismäßige Dokumentation der EA
Stakeholder bemängeln zu ausführliche/fehlende Architekturdokumentation
Quelle: www.pixabay.com | Pexels

Seite 25
Fallbeispiel: Michael Nagel soll Geschäftsobjekte dokumentieren
Geschäftsobjekte können mit über 30 Attributen beschrieben werden
Geschäfts
objekt
Bezeichnung
• Name
• ID
• Beschreibung
Owner
• Name
• Mail, Telefon
• Abteilung
Zuordnung
• Prozesse
• Projekte
• Applikationen
Struktur
• Format
• Granularität
• Notation
Status
• Schutzbedarf
• Reifegrad
• Kritikalität
Zugriff
• Methode
• Schutz
• Klasse
Beschreibung
• Schlagworte
• Anhänge
• Kommentare
Version
• Erstellung
• Aktivitäten
• Versionsnumm
er
Spontane Reaktion…
▪ Reicht das aus?
▪ Was gibt es noch?
▪ Wie können wir die Pflege verankern?
Nach einer Denkpause…
▪ Wer hat Informationsbedarfe?
▪ Wie sehen diese Bedarfe aus?
▪ Ist das wiederkehrend realisierbar?

Seite 26
Anwendungsfeld Orientierungskarte
Jede Darstellungsform erfüllt andere Wissensziele
Schatzkarte
Glücksritter
Navigationskarte
Autofahrer
Weltkarte
Geographieschüler
Wohnungslageplan
Büromitarbeiter
Skigebietsplan
Wintersportler
Städteplan
Urlaubstourist
▪ Fußwege
▪ Sehenswürdigkeiten
▪ Parks
▪ …
▪ Länder
▪ Meere
▪ Flüsse
▪ …
▪ Räume
▪ Notausgänge
▪ Feuerlöscher
▪ …
▪ Straßen
▪ Kreuzungen
▪ Parkplätze
▪ …
▪ Abfahrten
▪ Lifte
▪ Loipen
▪ …
▪ Pfade
▪ Fallen
▪ Schatz
▪ …
Quelle: Symbole von https://icons8.com

Seite 27
Anwendungsfeld EAM
Jede Darstellungsform erfüllt andere Wissensziele
Terminplan
Projektmanager
SIPOC
Fachexperte
Zustandsdiagramm
Applikationstester
CRUD-Matrix
Clearing Executive
Organigramm
Abteilungsleiter
Technisches Datenmodell
Programmcodeentwickler
▪ Entitäten
▪ Attribute
▪ Kardinalitäten
▪ …
▪ Zustand
▪ Ereignisse
▪ Ausgaben
▪ …
▪ Rollen
▪ Geschäftsobjekte
▪ Berechtigungen
▪ …
▪ Prozessschritte
▪ Lieferant & Abnehmer
▪ Input & Output
▪ …
▪ Funktionen
▪ Personen
▪ Berichtswege
▪ …
▪ Aufgaben
▪ Meilensteine
▪ Wochen
▪ …
S I P O C
Quelle: Symbole von https://icons8.com

Seite 28
DM-NRW Formel
Die fünf Dokumentationsprinzipien im Enterprise Architecture Management
Quelle: www.pixabay.com | skeeze
Dringlich Minimal
Nützlich Realistisch Wirtschaftlich
„Welche EA Infos sind
bereits heute
erforderlich?“
„Welche EA Infos
werden in 80% der
Fälle benötigt?
„Welche EA Infos
stiften wiederkehrend
Mehrwert?“
„Welche EA Infos
lassen sich wieder-
kehrend pflegen?
„Welche EA Infos
erzeugen mehr Nutzen
als Kosten?

Seite 29
Problem #4: Bürokratische Bewertung neuer Software
Den Stakeholdern dauert die Beurteilung neuer Tools zu lange
Quelle: www.pixabay.com | fulopszokemariann

Seite 30
Fallbeispiel: Michael Nagel soll Software schneller bewerten
Umfassende Dokumentation von Software Anträgen
….

Seite 31
EAM Interviewlandkarte
Erfassung Architektur-Beschreibungen leichtgewichtig und visuell
2. Geschäftsprozesse & Tools
▪ Welche Geschäftsprozesse und Aufgaben unterstützt das Tool?
▪ Warum ist das Tool erforderlich (z.B. neuer Prozess, Prozessanpassungen)?
▪ Welche bestehenden Tools unterstützen diese Geschäftsprozesse bisher?
3. Architektur & Funktion
▪ Was sind die wichtigsten Funktionen des Tools?
▪ Welche alternativen bereits verfügbaren Tools haben ähnliche Funktionen?
▪ Auf welcher Systemarchitektur basiert das Tool?
4. Finanzierung & Lizenzen
▪ Wie viele Personen werden das Tool kurz- bzw. mittelfristig nutzen?
▪ Wer übernimmt die Lizenzkosten?
▪ Wer trägt die Investitionskosten für das Tool?
5. Betrieb & Wartung
▪ Wer ist nach
Einführung für das
Tool verantwortlich?
▪ Wie erfolgt die
Wartung und
Weiterentwicklung des
Tools?.
▪ Auf welchem Weg
erhalten neue Nutzer
Zugang zum Tool?
1. Hersteller &
Sicherheit
▪ Welche Beziehung
bestehen zum
Hersteller (z.B.
Dienstleister)?
▪ Wie schützenswert
sind die im Tool
gespeicherten Daten?
▪ Wo speichert das Tool
seine Nutzdaten &
Verwendungsdaten?
Interviewdatum | Interviewpartner | Fachbereich Status: dokumentiert
Quelle: Schulz: Die EAM-Interviewlandkarte - Architekturarbeit leichtgewichtig und visuell. OBJEKTspektrum, 2017| Icons von https://icons8.com

Seite 32
EAM Interviewlandkarte
Interviewleitfaden und –protokoll in einem
2. Geschäftsprozesse & Tools
▪ Welche Geschäftsprozesse und Aufgaben unterstützt das Tool?
▪ Warum ist das Tool erforderlich (z.B. neuer Prozess, Prozessanpassungen)?
▪ Welche bestehenden Tools unterstützen diese Geschäftsprozesse bisher?
3. Architektur & Funktion
▪ Was sind die wichtigsten Funktionen des Tools?
▪ Welche alternativen bereits verfügbaren Tools haben ähnliche Funktionen?
▪ Auf welcher Systemarchitektur basiert das Tool?
4. Finanzierung & Lizenzen
▪ Wie viele Personen werden das Tool kurz- bzw. mittelfristig nutzen?
▪ Wer übernimmt die Lizenzkosten?
▪ Wer trägt die Investitionskosten für das Tool?
5. Betrieb & Wartung
▪ Wer ist nach
Einführung für das
Tool verantwortlich?
▪ Wie erfolgt die
Wartung und
Weiterentwicklung des
Tools?.
▪ Auf welchem Weg
erhalten neue Nutzer
Zugang zum Tool?
1. Hersteller &
Sicherheit
▪ Welche Beziehung
bestehen zum
Hersteller (z.B.
Dienstleister)?
▪ Wie schützenswert
sind die im Tool
gespeicherten Daten?
▪ Wo speichert das Tool
seine Nutzdaten &
Verwendungsdaten?
Interviewdatum | Interviewpartner | Fachbereich Status: dokumentiert
Beschreibende Fragen
vor
Spekulativen Fragen
Offene Fragen
vor
Geschlossene Fragen
Einfache & kurze Fragen
vor
Langen & komplizierten Fragen
Einfühlende & ernsthafte Fragen
vor
Unfaire & bloßstellenden Fragen
Quelle: Schulz: Die EAM-Interviewlandkarte - Architekturarbeit leichtgewichtig und visuell. OBJEKTspektrum, 2017| Icons von https://icons8.com

Seite 33
Problem #5: Wildwuchs in der IT-Systemlandschaft
Stakeholder fordern die Standardisierung der Individual-Applikationen
Quelle: www.pixabay.com | Efraimstochter

Seite 34
Fallbeispiel: Michael Nagel soll die Systemlandschaft standardisieren
211 Individualapplikationen mit jeweils ~30 hinterlegten Attributen
Bei welcher
Applikation anfangen?
Welche Attribute bei
der Bewertung
berücksichtigen?
Welche Konsequenzen
einer Standardisierung
betrachten?
Wie sollen
Entscheidungen
dokumentiert werden?

Seite 35
Standardisierung ≠ Standardisierung
Ziele für die Standardisierung der Systemlandschaft
Kauf- statt
Individual-
software
Senkung
Gesamtanzahl
Zukunfts-
sichere
Technologie
und Hersteller
Redundanz-
freie Prozess-
unterstützung
Reduzierte
Komponenten
-vielfalt
Begrenzte
Zahl von
Herstellern
Standardisierung im Rahmen der Geschäftsziele
„Welche messbaren und terminierten Ziele verfolgen
wir mit einer Standardisierung?“
Standardisierung entlang definierter Kriterien
„Aufgrund welcher Parameter gehört eine Applikation
zum Standard?“
Standardisierung auf Basis eines Business Cases
„Was bringt und kostet die Angleichung einmalig und
wiederkehrend?“
Fokus UntersuchungsauftragLegende
Standardisierung
Applikations-
landschaft

Seite 36
Software-Standardisierung mittels der 2-Phasen-Filtermethode
Mit 7+7 Fragen zur Entscheidung
Individual
Applikation
1. Fachlicher Ersatz
3. Technischer Eignung
4. Projektaufwand
2. Internes Knowhow
Lösungs-Filter
Konsequenzen der Standardisierung
Problem-Filter
Gründe für die Standardisierung
1. Geringe Nutzen
3. Alternative Standardsoftware
5. Hohe Wartungskosten
7. Sicherheitsrisiko 7. Interne Kapazität
2. Fachliche Defizite
4. Veraltete Technologie
6. Weggang Knowhow-Träger
5. Umsetzungsrisiken
6. Systemschnittstellen

Seite 37
Fallbeispiel: Und Michael Nagel?
Hat ein agiles EAM und kann nun einen Kurzurlaub einlegen
Bildquelle: Pixabay.com | Pexels
#1: Agile
Mindset
#2: Added Value
#5: Application
Standards
#4: Sofware
Assessment
#3: EA
Documentation
Kurzurlaub ;)

Seite 38
Enterprise Architecture Management – endlich agil!
Questions & Answers
“Die Neugier steht immer an erster
Stelle eines Problems, das gelöst
werden will.”
- Galileo Galilei
Business Analyst &
Enterprise Architect
Dr. Christopher Schulz
Managing Partner
c.schulz
@palladio-consulting.de
+49 (0) 176 493 47889

Seite 39
Bonus: 33 Tipps für Ihre Softwareauswahl
palladio-consulting.de/Softwareauswahl