Dem Elfenbeinturm keine Chance - EAM-Initiative · Moderieren einer Architektur-Kultur Quelle: nach Bente, Bombosch, Langade (2012): Collaborative Enterprise Architecture, Morgan

© 2014 Stefan Bente

Dr. Stefan BenteVortrag auf der Softwareforen Leipzig, 17. November 2014

Dem Elfenbeinturm keine ChanceAgile und kollaborative Ansätze im EAM

Dieser Vortrag will Werkzeuge und Anregungen zum Weiterdenken

liefern

„Male selbst bunt“Bild: Nevit (Own work) [GFDL

(http://www.gnu.org/copyleft/fdl.html)

or CC-BY-SA-4.0-3.0-2.5-2.0-1.0

(http://creativecommons.org/licenses

/by-sa/4.0-3.0-2.5-2.0-1.0)], via

Wikimedia Commons,

http://commons.wikimedia.org/wiki/Fil

e%3AMandala_11.svg

17.11.2014 Dr. Stefan Bente | Dem Elfenbeinturm keine Chance | Softwareforen Leipzig2

Über den Praxiserfolg von EAM gibt es kaum verlässliche Studien,

aber viele Meinungen …

Bild: Wikimedia, Nikodem Nijaki (Own work), http://commons.wikimedia.org/wiki/File:Balance_scale_IMGP9755.jpg

„weitgehend

nutzlos“

„Schlüssel

zum Erfolg“

Hier einige kritische Stimmen …


http://commons.wikimedia.org/wiki/File:Balance_scale_IMGP9755.jpg

Einige EAM-skeptische Stimmen …

Nach 10 Jahren Einsatz von EAM in der amerikanischen Verwaltung:

“Of … 93 agencies …,

22 agencies (…) increased their maturity,

24 (…) decreased their maturity, and

47 (…) remained the same.”

United States General Accounting Office (2004)

“… by 2012 40% of today's [2007] enterprise

architecture programs will be stopped”

Gartner Group (2007) (**)

Quellen: siehe Nottizseite

“… it turns out that 66 percent of programs

did not fulfill expectations.”

Sven Roelevens (2010) (***)

“My guess is that more than 90% never really

resulted in anything useful”

Ivar Jacobsson (2007)

Wirkungs-

los?

40% Fehl-

schläge?

66% Fehl-

schläge?

90% Fehl-

schläge?


EAM

techn. Strukturen

Übereinkünfte

Interaktionen

Wie kann das sein?

In einem komplexen Umfeld verfolgt EAM einen hohen Anspruch …

Jedes Unternehmen ist ein komplexes sozio-technisches System

EAM begreift sich hier als Ordnungsrahmen

IT-Infrastruktur

Softwareplattformen

Regeln und Vorgaben

Zuschnitt Fachprozesse

Architekturprozesse

Datenmodelle

Zuschnitt IT-Systeme

EAM beschäftigt sich sowohl mit technischen wie mit kommunikativen Aspekten

Architekten wirken daher in vielen Rollen einer Organisation,

und haben zahlreiche direkte Schnittstellen

17.11.2014 Dr. Stefan Bente | Dem Elfenbeinturm keine Chance | Softwareforen Leipzig

SW-System

Hardware (Server)

Infrastruktur (Netzwerk, Telefonie, ...)

Application Server, Plattformen...ERP

Integrationssysteme (ESB, Orchestrierung, ...)

Geschäftsprozesse

Manager

Fachseite

Prozess-

Architekt

Fachseite

Business

AnalystProjekt-

Manager

Projekt-

Architekt

IT-ProjektteamProzess-

Berater

Beratung

Strategie-

Berater

Beratung

Enterprise-

Architekt

Betriebs-

Dienstleister

DL-Steuerung

Beratung

IT-Prozess-Berater

Business

AnalystProjekt-

ManagerProjekt-

Architekt

Software-Dienstleister

CIO

Enterprise-

ArchitektVorstands-

Assistent

IT-Vorstand

IT-Manager

Security-

Architekt

Komponenten-

Architekt

IT-Abteilung

Prod.-

Manager

Eigene

Stationen

6

Wie funktioniert das im Projektalltag? Beispiel:

Das Round Robin der Missverständnisse

7 17.11.2014 Dr. Stefan Bente | Dem Elfenbeinturm keine Chance | Softwareforen Leipzig

Ihr müsst die

Unternehmensstandards

bei der Technologie-

Auswahl einhalten.

Enterprise-

Architekt

Wenn ich nicht Framework

XYZ benutzen darf, wird das System

ein Wartungsalbtraum.

Mich interessieren im

Moment nur Meilensteine.

Womit werdet ihr am

schnellsten fertig?

Projekt-

Architekt

Projekt-

Manager

Das Projekt ist strategisch

extrem wichtig. Bei Ärger mit

IT-Vorgaben besorge ich beim

Vorstand eine Ausnahme-

genehmigung.

Warum versteht

der mich

nicht ???

Warum versteht

der mich

nicht ???

Warum versteht

der mich

nicht ???

Warum versteht

der mich

nicht ???

fachlicher

Sponsor

Der Enterprise-Architekt:

weißer Ritter, oder einsamer Missionar unter Heiden?

EAM ist i.d.R. ohne eigene formale Macht

Auf „Buy-In“ angewiesen

IT-Management

Fachseite

IT-Experten

Dabei ist EAM selbst hochkomplex:

Exotische Methodik, teure Tools

Sehr erklärungsbedürftig

EAM steht also im Dauer-Spagat:

Will viel bewirken mit wenig Macht

Muss viel erklären, aber nicht immer wird zugehört

Sie kennen sicher die folgenden EAM-Zerrbilder, bei denen

dieser Spagat aus verschiedenen Gründen nicht funktioniert …

EAM-Zerrbild 1: Im Wolkenkuckucksheim

EA-Gruppe entkoppelt von IT-Organisation

(also Projekt-Architekten, Entwickler,

Infrastruktur-Experten, …)

Kaum Einsicht in die wirklichen

Herausforderungen „am Boden“

Folgt dem Mythos vom “Big Picture”

Oft über-abstrahiert bis zur

Bedeutungslosigkeit

Adressiert keine Frage von

Bedeutung mehr

Hierarchische Suche und

semantisches „Drill-In“ unmöglich

Hauptgefahr: Verdeckt Verständnis-

Lücke zwischen EA und IT-Wirklichkeit

Konsequenz: EA-Organisation wird von allen ignoriert


EAM-Zerrbild 2: In der Werkstatt des Chefmechanikers

IT-Vorstand definiert sich nur als Verwalter der IT

“Chief Technology Mechanic” (Broadbent & Kitzis)

IT vorrangig durch Kostendruck getrieben

Wenig strategische Planung

Enterprise Architekt arbeitet oft de fakto als

Projekt-Architekt oder Technik-Experte

Bsp. Automobilkonzern: Enterprise-

Architekt als einziger echte JEE-Experte

Geht oft einher mit einseitiger Ausrichtung

der EA auf Technologie-Themen

Wenig fachliches Know-How

EA-Organisation wird von Fachseite nicht ernst genommen

17.11.2014 Dr. Stefan Bente | Dem Elfenbeinturm keine Chance | Softwareforen Leipzig10 17.11.2014 Dr. Stefan Bente | Dem Elfenbeinturm keine Chance | Softwareforen Leipzig10

EAM-Zerrbild 3: Die Gralshüter der Weisheit

EA-Gruppe versteht sich als Gralshüter diverser

Richtlinien und Standards, z.B.

Dokumentations- & Coding-Stil

Bsp.: Bestimmtes Login-Modul

Nutzen der Regeln nicht hinterfragt, bestenfalls

irrelevant, schlimmstenfalls kreativitätshemmend

Beispiel DAX-Konzern:

EA-Gruppe als alleiniger Entscheidungs-

träger für gewisse Design-Fragen

z.B. Service-Design für unternehmensweiten

ESB

Konsequenz: Projekte umgehen EA-Gruppe

Z.B. durch Auswahl „nicht

zustimmungspflichtiger“ Technologie

EA-Organisation wird von Fachseite ignoriert und von IT-Seite umgangen


Grundlegende These: EAM erfüllt seinen Zweck dann am besten,

wenn es den Spagat zwischen zu viel und zu wenig Ordnung schafft


Der Mittelweg entlang der Chaoslinie

Wie kann man sehen, ob EAM sich

auf diesem Mittelweg bewegt?

EAM-Cockpit als pragmatisches, informelles Bewertungsinstrument:

Die grundsätzlichen Dimensionen


Organisation Zeit

Flughöhe

Durchsetzungsfähigkeit

Planungshorizont

Geschwindigkeit

1313

EAM-Cockpit als pragmatisches, informelles Bewertungsinstrument:

Alle Dimensionen in ihrem Zusammenspiel


Organisation Zeit

Flughöhe

niedrig hoch

Der Chef-

entwickler

Der Bewohner des

Elfenbeinturms

Breit und

doch detailliert

Planungshorizont

kurz lang

Der Hausmeister

für die CRs

Ein tiefer Blick in

die Kristallkugel

Balance zwischen Ad-Hoc-

Aufgaben und Planung


schwach dominant

Der einsame Rufer

in der Wüste

Der Gralshüter

der Weisheit

Kontrolle

wo nötig

Geschwindigkeit

langsam schnell

Im Stau Auf der Dauer-

baustelle

Evolution statt

Revolution oder Stillstand

Flughöhe


Planungshorizont

Geschwindigkeit

1414

In Werkstatt des

ChefmechanikersBreit und doch detailliert

Im Wolken-

kuckucksheim

Hauptfokus IT-TechnologieBalance aus „Big Picture“, Technik und

FachlichkeitStrategie

Organisation Teil der IT-OrganisationUnabhängige Stabsstelle beim

(IT-) VorstandKann überall sein

Vernetzung Mit IT-OrganisationMit IT, Fachseite und Management

gleichermaßen

Höheres Management

oder gar nicht

Team-Zusam-

mensetzungIT-Experten

Mischung aus IT- und Fachexperten

sowie “Mittlern”

(Ehemalige)

Strategieberater

niedrig hoch

Flughöhe

niedrig hoch niedrig hoch


Der einsame Rufer

in der WüsteKontrolle wo nötig

Der Gralshüter

der Weisheit

RegelnKultur des

Regelbrechens

Wenige Architekturprinzipien, die

strikt eingehalten werden

Viele detaillierte IT-

Standards mit starker

Umsetzungskontrolle

ProzesseWenige oder keine EA-

Prozesse

Kern-EA-Prozesse sind allgemein

akzeptiert und werden “gelebt”

Umfassendes EA-

Prozess-Rahmenwerk

Kommunikation Jeder spricht mit jedemKontinuierliche Kommunikation

Architekten / Entwickler / Fachseite

Nur entlang streng

definierter Kanäle

Rolle des

Architekten

Ratgeber, wenig

Autorität/Verantwortung

Technischer Leiter, Mentor, Auditor,

mit gewisser formaler Autorität

Unerbittlicher Kämpfer

gegen Regelverstöße

schwach dominant


schwach dominant schwach dominant


Der Hausmeister

für die CRs

Balance zwischen Kurz- und

Langfrist

Ein tiefer Blick in

die Kristallkugel

Zukunftsvision Keine Visionparallele Szenarien mit relativ

kurzem Zeithorizont

Feingranulare, langfristig

geplante Zukunftsvision

Planung Nur Ad-HocFeingranular nur für kurzfristigen

Horizont, sonst RoadmapDetaillierte Planung

FokusReaktiv,

gegenwartsorientiert

Balanzierung der Aufmerksamkeit

zwischen heute und morgen

Proaktiv,

zukunftsorientiert

kurz lang

Planungshorizont

kurz lang kurz lang


Im Stau EvolutionAuf der

Dauerbaustelle

Erneuerung der

IT-LandschaftHauptsächlich Wartung

Ablösung von IT-Systemen nach

festen Kriterien, mit AugenmaßRadikale Umbrüche

Neue Business

Capabilities

Erweiterung/Layering

bestehender SystemeFall-zu-Fall-Entscheidungen Neue Systeme

OutsourcingWartung inhouse,

Neuentwicklung externFall-zu-Fall-Entscheidungen

Neuentwicklung intern,

Legacy-Outsourcing

Technologie-

wechselLate Adoption

Technologiewechsel wenn notwendig

oder es geschäftlichen Mehrwert gibtEarly Adoption

langsam schnell

Geschwindigkeit

langsam schnell langsam schnell


Die drei Leitlinien des Kollaborativen EAM …

• statt bürokratischen Prozeduren und unnötigen Dokumenten

Schlanke IT-Prozesse und

-Regeln

• anstatt die gesamte Zukunft minutiös vorauszuplanen

Evolutionäre IT-Problemlösung

• statt Expertenwissenaus dem Elfenbeinturm

Fördern und Moderieren

einerArchitektur-

Kultur

Quelle: nach Bente, Bombosch, Langade (2012): Collaborative Enterprise Architecture, Morgan Kaufmann, Boston (Übersetzung durch Vortragenden)


… und konkrete Anregungen zur Umsetzung

Quelle: nach Bente, Bombosch, Langade (2012): Collaborative Enterprise Architecture, Morgan Kaufmann, Boston (Übersetzung durch Vortragenden)

1. Bemessungsansatz:

„Wie viel EAM ist nötig“

2. Lean EAM

3. EAM Kanban

4. Agile Kommunikation

5. Architekturportal



-Regeln





einerArchitektur-

Kultur


1. Bemessungsansatz: „Wie viel EAM ist nötig“

IT-Management folgt einem idealtypischen Zyklus …


Strategie

Geschäfts-

Architektur

IT-

Architektur

Betriebs-

Organisation


Konkreter heißt dies:


Strategie

Geschäfts-

Architektur

IT-

Architektur

Betriebs-

OrganisationIT-Service-

Management

Markt-

Fokus

Fach-

Organisation

Architektur-

Management

Fasst IT als Menge von

Services auf

Oft der Hauptfokus der

Beratung

Betrachtet Struktur von

IT-Landschaften

Wird oft ausgelassen!

Reife der Aufbau- und

Ablauf-Organisation für

Geschäftsprozesse

Wird Hand in Hand mit IT-

Prozessen analysiert

Manchmal ist Beratung

hier Teil des Auftrags

Ausrichtung des

Gesamtunternehmens in

Bezug auf den Markt

Teil der Geschäftsstrategie

Ist als (Kurz-)Analyse i.d.R.

Teil der Beratung


Zwei Kernthesen zu diesem Bemessungsansatz

Zwei Kernthesen beschreiben dieses Modell:

Aus diesen Grundgedanken leitet sich ein Ansatz für

„Wieviel EAM ist nötig“ ab

Ausge-

glichener

Ausbaugrad

Ausgeglichener Ausbaugrad in

den Dimensionen meistens

sinnvoll

1

Vollständig-keit

Betrachtung dieser

Dimensionen genügt in erster

Näherung bei mittelgroßen IT-

Organisationen

2


Strukturiertes

Tagesgeschäft

Service-

Orientierung

Service-

Organisation

Strategisches

Service-

Management

IT Service

Management

Architektur-

Management

Fach-

Organisation

Markt-

Fokus

Projekt-

Architektur

Architektur-

Prozesse

Strategisches

Architektur-Management

Architektur-

Organisation

Einzel-

Projekt

Multi-Projekt

Markteroberung

Marktexpansion –

Neue Märkte

Strukturiertes

Tagesgeschäft Dedizierte

Geschäfts-

Prozesse Ausprägung

Organisations-

einheiten

Etablierung

Verbesserungs-

prozesse


Lässt sich auch als ein gekoppelter Bemessungsansatz betrachten!


Quelle: Nach einer Methodik erarbeitet durch Cassini und sbc

4

3

1

2

Im Folgenden konzentrieren wir uns auf die Dimension

„Architektur-Management“


Projekt-

ArchitekturArchitektur von IT-

Projekten wird geplant

und nachgehalten

Dokumentation und

Management von

Architektur ist Aufgabe

der Projektteams,

Noch keine zentrale

Steuerung

1

Architektur-

ProzesseWesentliche

Architekturprozesse

sind definiert

Ist- und Soll-Architektur

sind unternehmens-

weit beschrieben

Rollen zur

Überwachung der

Architektur

(Governance)

vorhanden

2

Architektur-

OrganisationAufbau

Steuerungssysteme

zur Messung der

Architekturreife

Architektur-

management fest in

Unternehmenskultur

verankert

Architektur-

dokumentation

kontinuierlich gepflegt

3

Strategisches

Architektur-

ManagementEntwicklung der IT-

Architektur richtet sich

an Geschäftsstrategie

aus

Kontinuierliche

Optimierung der

Architekturprozesse

Entwicklung zur

selbstlernenden

Organisation

4


Weitere Diagnose-Instrumente zur Einordnung der IT-Organisationen

„Nur

Desktops“

Niedrig Hoch

IT-Affinität

der Branche

IT-

Komplexität

Fachliche

Standard-

Software

Eigen-

Entwicklung

IT-Organisation

managed nur

Basis-IT

IT-Organisation

managed auch

Fachapplikationen

Verantwortung der IT-

Organisation

5 500

Größe der IT-

Organisation

50

Ungewöhnlich

hohe

Komplexität

Ungewöhnlich

niedrige

Komplexität

Diese Instrumente unterstützen bei der Einordnung der IT-Organisation



Beispiel 1 – Gut aufgestellt, aber fast ganz ohne Architektur


Strukturiertes

Tagesgeschäft

Service-

Orien-

tierung

Service-

Orga-

nisation

Strategisches

Service-

Management

Projekt-

Architektur

Architektur-

Prozesse

Strategisches


Architektur-

Organisation

Einzel-

Projekt

Multi-Projekt

Markteroberung

Marktexpansion –

Neue Märkte

Strukturiertes

TagesgeschäftDedizierte

Geschäfts-

Prozesse

Aus-

prägung

Organisations-

einh.

Etablierung

Verbesserungs-

prozesseIT Service

Management

Architektur-

Management

Fach-

Organisation

Markt-

Fokus

„Nur

Desktops“Niedrig Hoch

IT-Affinität der Branche

IT-

Komplexität

Fachliche

Standard-

Software

Eigen-

Ent-

wicklung

5 500

Größe der IT-Organisation

50

nur

Basis-IT

auch

Fachapplikationen

Verantwortung der IT-Organisation

Einige komplexe Eigenentwicklungen

Fachseite betreibt erfolgreich BPM

IT historisch gewachsen, kommt oft an Kapazitätsgrenzen, kein wirklicher

Bebauungsplan

Mittelständisches,

global agierendes

Logistik-Unternehmen

4

3

1

3


Beispiel 2 – Weg vom „Hey, Joe“-Modus


Strukturiertes

Tagesgeschäft

Service-

Orien-

tierung

Service-

Orga-

nisation

Strategisches

Service-

Management

Projekt-

Architektur

Architektur-

Prozesse

Strategisches


Architektur-

Organisation

Einzel-

Projekt

Multi-Projekt

Markteroberung

Marktexpansion –

Neue Märkte

Strukturiertes


Geschäfts-

Prozesse

Aus-

prägung

Organisations-

einh.

Etablierung

Verbesserungs-

prozesseIT Service

Management

Architektur-

Management

Fach-

Organisation

Markt-

Fokus

„Nur



IT-

Komplexität

Fachliche

Standard-

Software

Eigen-

Ent-

wicklung

5 500


50

nur

Basis-IT

auch

Fachapplikationen


Fachbehörde mit kleiner IT braucht ein Steuerungsinstrument, um dem

„Management-Chaos“ zu entgehen

Da die IT im wesentlichen nur die Desktop-Clients verwaltet, reicht hier ein einfacher

ITSM-Ansatz

Fachbehörde des

Bundes

1

1 0 1


Beispiel 3 – Gesamtorganisation hinkt Geschäftspolitik hinterher


Hohe (selbstgemachte) Komplexität in der IT durch aggressive Zukaufspolitik

Rolle des Enterprise-Architekten existiert, aber ohne hinreichende Macht in der

Organisation

Gesamtorganisation kommt der Geschäftspolitik nicht hinterher

Mittelständischer

Hersteller von

Handwerks-/Baubedarf

Strukturiertes

Tagesgeschäft

Service-

Orien-

tierung

Service-

Orga-

nisation

Strategisches

Service-

Management

Projekt-

Architektur

Architektur-

Prozesse

Strategisches


Architektur-

Organisation

Einzel-

Projekt

Multi-Projekt

Markteroberung

Marktexpansion –

Neue Märkte

Strukturiertes


Geschäfts-

Prozesse

Aus-

prägung

Organisations-

einh.

Etablierung

Verbesserungs-

prozesseIT Service

Management

Architektur-

Management

Fach-

Organisation

Markt-

Fokus

4

2

2

2

5 500


50

nur

Basis-IT

auch

Fachapplikationen


„Nur



IT-

Komplexität

Fachliche

Standard-

Software

Eigen-

Ent-

wicklung


Beispiel 4 – IT gut gemanaged, EAM mit wenig Durchgriff


Hoher Regulationsdruck (Solvency II, MaRisk, IFRS, ...)

Angestrebt wird ISO 20.000 Zertifizierung aus Compliance-Gründen

EAM existiert, aber mit wenig Durchgriff auf das tatsächliche Geschehen

Mittelständische

Versicherung

Strukturiertes

Tagesgeschäft

Service-

Orien-

tierung

Service-

Orga-

nisation

Strategisches

Service-

Management

Projekt-

Architektur

Architektur-

Prozesse

Strategisches


Architektur-

Organisation

Einzel-

Projekt

Multi-Projekt

Markteroberung

Marktexpansion –

Neue Märkte

Strukturiertes


Geschäfts-

Prozesse

Aus-

prägung

Organisations-

einh.

Etablierung

Verbesserungs-

prozesseIT Service

Management

Architektur-

Management

Fach-

Organisation

Markt-

Fokus3

2

2

3

5 500


50

nur

Basis-IT

auch

Fachapplikationen


„Nur



IT-

Komplexität

Fachliche

Standard-

Software

Eigen-

Ent-

wicklung


Beispiel 5 – Fehlende Produktmanagement-Prozesse


Strukturiertes

Tagesgeschäft

Service-

Orien-

tierung

Service-

Orga-

nisation

Strategisches

Service-

Management

Projekt-

Architektur

Architektur-

Prozesse

Strategisches


Architektur-

Organisation

Einzel-

Projekt

Multi-Projekt

Markteroberung

Marktexpansion –

Neue Märkte

Strukturiertes


Geschäfts-

Prozesse

Aus-

prägung

Organisations-

einh.

Etablierung

Verbesserungs-

prozesseIT Service

Management

Architektur-

Management

Fach-

Organisation

Markt-

Fokus

„Nur



IT-

Komplexität

Fachliche

Standard-

Software

Eigen-

Ent-

wicklung

5 500


50

nur

Basis-IT

auch

Fachapplikationen


Ziel: Schaffung eines geschäftlichen Ökosystems, so dass die öffentliche Hand sich

aus der stark steuernden / regulierende Rolle zurückziehen kann

Technisch anspruchsvolle, gut geplante IT-Infrastruktur

Service- und Produktmanagement-Rollen suboptimal ausgeprägt

Sicherheits-

Infrastruktur , Verbund

Bundesbehörden /

Privatwirtschaft

3

1

2

0

2. Lean EAM

Poppendiecks unterscheiden 7 Arten „Waste“ in Software-Entwicklung

Produktion Software

In-Process Inventory Partially Done Work

Over-Production Extra Features

Extra Processing Extra Processes

Transportation Handoffs

Motion Task Switching

Waiting Delays

Defects Defects


17.11.2014Dr. Stefan Bente | Dem Elfenbeinturm keine Chance |

Softwareforen Leipzig33

2. Lean EAM

Matrix, um Waste in EAM-Prozessen und -Produkten zu identifizieren

Enterprise-

Architektur-BereichUnfertige

Arbeit

Über-

Architektur

Redun-

dante

Prozesse Übergaben

Wechsel

zwischen

Aufgaben

Ver-

zögerungen Fehler

EA-1: Definition der IT-

Strategie

EA-2: Architektur-

Modellierung

EA-3: Strategische

Entwicklung der IT-

Landschaft

EA-4: Mitgestaltung des

Projekt-Portfolios

EA-5: Entwicklung /

Überwachung von IT-

Standards

EA-6: IT-

Risikomanagement

EA-7: Ausbau der

Architekturorganisation

EA-8: Leitung und

Begleitung von IT-

Projekten

1 2 3 4 5 6 7

Fach-Knowhow existiert nicht in formaler Form

In Spezifikation fehlen wichtige Aspekte

Viel (aber unstrukturierte) Information

Modellnotation, die das Zielpublikum nicht versteht

Zu viele Abstimmungsrunden

mit zu vielen Teilnehmern

Viele zustimmungspflichtige

Hierarchieebenen und

Beteiligte

Entscheidungsfindung auf so

hoher Ebene, dass die

Implikationen nicht mehr

vollständig verstanden werden


3. EAM Kanban

Architekturarbeit ist detailreich und komplex, wird aber oft im Stil

von „freischaffenden Künstlern“ gemanaged


Per Email verschickte

Excel-Tasklisten als

„Default-

Managementtool“

3. EAM Kanban

TOGAF lässt auch iterative „Depth First“-Verfeinerungen zu


Initiali-

sierung

AArchitektur-

visionB

Geschäfts-

Architektur

CInformations-

Architektur

DTechnologie-

Architektur

FProjekt-

Planung

GProjekt-

Umsetzung

HArchitektur-

Change-

Mgmt.

EProjekt-

Kandidaten

Anforderungs-

Management

Quelle: nach OpenGroup, Übersetzung durch den Vortragenden

AB

C

DF

G

H

E

AB

C

DF

G

H

E

AB

C

DF

G

H

E

Kanban is very well suited to be adapted to various project

frameworks


Backlog PlanDevelop Test

Deploy LiveOngoing Done Ongoing Done

Team 1

Team 2

Team 3

…

…

…

…

……

…

…

…

… …

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

…

Kanban kann leicht an verschiedene Prozesse angepasst werden:

Hier ein Kanban-Board für Softwareprojekte

Direction of progress

3. EAM Kanban

Ein „EA-Kanban-Board“ nutzt die durch TOGAF vorgegebene Struktur.


3. EAM Kanban

Verbundene Kanban-Boards für verschiedene Architektur-Ebenen


IT-Bereich 4


Architekturboard nach

“Scrum-of-Scrums”-Muster

IT-Bereich 2

IT-Bereich 1


Architekturboard

Enterprise-

Architekt

EA-Gruppe

IT-Bereich 3

Architekt

oder anerkannter

Experte


Architekturboard als dezentrale Alternative zu Vollzeit-EAM-Team

bei kleineren Organisationen

Zentrales Modell:

Team von Enterprise-Architekten in

Vollzeit

Chef-Architekt =

Linienvorgesetzte der

Teammitglieder

Vorteil: Schlagkräftig

Nachteil:

Manchmal nicht durchsetzbar

Henne-Ei-Problem:

Erfolge Stellengenehmigung

Risiko: Elfenbeinturm


Dezentrales Modell:

Architekturboard = Mitgliedern

verschiedener

Organisationseinheiten

Jeweils mit Teil der Arbeitszeit ins

Architekturboard delegiert

Vorteil:

Mitglieder „wirken“ weiter in

ihren Heimatorganisationen

Nachteil:

Risiko: Zeit-Commitments für

Architekturboard nicht

eingehalten

Ohne Einfluss, wenn nicht in

Prozessen verankert

5. Architekturportal

Architekturportal für transparente EAM ermöglicht Beitrag aus allen

Ebenen


Wie vermeiden wir den Elfenbeinturm?


Bild:(c) Wikimedia, Mayqel

Vielen Dank für Ihre

Aufmerksamkeit!



-Regeln





einerArchitektur-

Kultur

Documents

Dem Elfenbeinturm keine Chance - EAM-Initiative · Moderieren einer Architektur-Kultur Quelle: nach Bente, Bombosch, Langade (2012): Collaborative Enterprise Architecture, Morgan