Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Enterprise Architecture Management - Endlich agil!

77 views

Published on

Michael Nagel hat ein Problem. Sein klassisches Management der Unternehmensarchitektur stößt an seine Grenzen. Digitalisierung, neue gesetzliche Anforderungen sowie ein sich ständig wandelnder Markt wirbeln in seiner Firma vieles durcheinander. Projekte laufen jetzt agil. Fachbereiche fordern, was sie von Tech-Giganten aus dem Privatleben kennen. Und die Menge der Daten - verdoppelt sich im Jahresrhythmus. Was also soll Michael Nagel tun?

Im Beitrag unterstützt Christopher Schulz. Live, interaktiv und praxisnah. Er nimmt Michael Nagel und die Teilnehmer mit auf einen Weg, vom Agilen Mindset im Enterprise Architecture Management bis zur Standardisierung der Applikationslandschaft im digitalen Zeitalter. Architekturmanagement dient den Fach- und IT-Bereichen. Agiles Enterprise Architecture Management vernetzt, sorgt für Effizienz und sichert Entscheidungen ab.

Published in: Business
  • Be the first to comment

  • Be the first to like this

Enterprise Architecture Management - Endlich agil!

  1. 1. Enterprise Architecture Management Endlich Agil! Dr. Christopher Schulz Schön, dass Sie da sind! Es erwartet Sie…
  2. 2. Seite 2 Fallbeispiel Montag – 30. September – 10:37 Uhr Irgendwo in Süddeutschland in einem Büro…
  3. 3. 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
  4. 4. 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?
  5. 5. Seite 5 Gemeinsames Verständnis als Grundlage Warm-up… Was ist Enterprise Architecture Management? Tipp: https://youtu.be/d6Is4g14r20
  6. 6. 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
  7. 7. 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
  8. 8. Seite 8 Städteplanung als Analogie Herauszoomen und Blick auf die Gesamtarchitektur Quelle: pixabay.com | designerpoint
  9. 9. 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
  10. 10. 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
  11. 11. Seite 12 Die EAM Vermittlerfunktion Einsatz auf strategischer und operativer Ebene Musterlösungen UnternehmenProjekte PrinzipienGeschäftsziele Strategie Leitplanken IT-SystemeFachprozesseIT-Komponente Dokumentation Schnittstellen
  12. 12. Seite 13 Problem #1: Schwergewichtiges EAM im Wolkenschloss Für die Stakeholder sind die EAM Prozesse zu abgehoben und langwierig Quelle: pixabay.com | SarahRichterArt
  13. 13. Seite 14 Ist das Wolkenschloss unser Schloss Neuschwanstein? Nicht ganz… Quelle: pixabay.com | SarahRichterArt | jh146
  14. 14. Seite 15 Fallbeispiel: Michael Nagel soll EAM agiler machen Raus aus dem Wolkenschloss mit Hilfe agiler Techniken Quelle: Agile Manifesto (deutsch), 2001
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. Seite 20 Problem #2: Unklarer Nutzen von EAM Stakeholder kennen den Mehrwert eines Architekturmanagements nicht Quelle: pixabay.com | RobinHiggins
  19. 19. 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
  20. 20. Seite 22 Die Pyramide der Nutzenelemente in der Praxis Fallbeispiel Apple Inc. Quelle: YouTube: First iPod Commercial 2001
  21. 21. 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)
  22. 22. Seite 24 Problem #3: Unverhältnismäßige Dokumentation der EA Stakeholder bemängeln zu ausführliche/fehlende Architekturdokumentation Quelle: www.pixabay.com | Pexels
  23. 23. 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?
  24. 24. 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
  25. 25. 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
  26. 26. 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?
  27. 27. Seite 29 Problem #4: Bürokratische Bewertung neuer Software Den Stakeholdern dauert die Beurteilung neuer Tools zu lange Quelle: www.pixabay.com | fulopszokemariann
  28. 28. Seite 30 Fallbeispiel: Michael Nagel soll Software schneller bewerten Umfassende Dokumentation von Software Anträgen ….
  29. 29. 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
  30. 30. 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
  31. 31. Seite 33 Problem #5: Wildwuchs in der IT-Systemlandschaft Stakeholder fordern die Standardisierung der Individual-Applikationen Quelle: www.pixabay.com | Efraimstochter
  32. 32. 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?
  33. 33. 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
  34. 34. 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
  35. 35. 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 ;)
  36. 36. 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
  37. 37. Seite 39 Bonus: 33 Tipps für Ihre Softwareauswahl palladio-consulting.de/Softwareauswahl

×