Motivation – Warum Lean EAM?

Veröffentlicht: von

Zum Praxiserfolg von EAM gibt es kaum verlässliche Studien, aber viele Meinungen. Diese changieren zwischen „Schlüssel zum Erfolg“ und „unnütz“.

Kritische Stimmen zu EAM sind nicht schwer zu finden – nachfolgend eine Auswahl:

  • Wirkungslos? “Of … 93 agencies …, 22 agencies (…) increased their maturity, 24 (…) decreased their maturity, and 47 (…) remained the same.” [1]
  • 40% Fehlschläge? “… by 2012 40% of today’s [2007] enterprise architecture programs will be stopped” [2]
  • 66% Fehlschläge? “… it turns out that 66 percent of programs did not fulfill expectations.” [3]
  • 90% Fehlschläge? “My guess is that more than 90% never really resulted in anything useful” [4]

Woran liegt das? Vielleicht trifft ja die EAM-Zunft zu einem gewissen Grad eine Mitschuld an diesem teilweise negativen Bild.

Der Anspruch an EAM ist hoch: EAM ist das zentrale Instrument für die strategische Steuerung und geschäftsorientierte Gestaltung der IT. Aber EAM ist in der Regel ohne eigene formale Macht, um diese Ziele zu erreichen. Es ist also auf ein umfassendes „Buy-In“ angewiesen, seitens der Fachseite, des IT-Managements, der operativen IT- und Software-Experten und des eigenen Vorstands.

EAM steht also im Dauer-Spagat:

  • Will viel bewirken mit wenig Macht
  • Muss viel erklären, aber nicht immer wird zugehört

Wenn einer EAM-Organisation dieser Spagat nicht gelingt, entstehen EAM-Zerrbilder, wie im Buch Collaborative EA detailliert beschrieben. Zwei seien hier beispielhaft genannt:

Im Wolkenkuckucksheim

01 Cloud Cuckoo
  • EA-Gruppe entkoppelt von IT-Organisation
  • Kaum Einsicht in die wirklichen Herausforderungen „am Boden“
  • Folgt dem Mythos vom “Big Picture”, dieses aber dann über-abstrahiert bis zur Bedeutungslosigkeit
  • Adressiert keine Frage von Relevanz mehr

 Die Gralshüter der Weisheit

monk or maybe sorcerer
  • EA-Gruppe versteht sich als Gralshüter diverser Richtlinien und Standards
  • Nutzen der Regeln nicht hinterfragt – bestenfalls irrelevant, schlimmstenfalls kreativitätshemmend
  • Reales Beispiel aus einem deutschen DAX-Konzern: EAM-Team allein zuständig für das Service-Design des unternehmensweiten ESB (Spezifikation des Designs, nicht Abnahme!)
  • EAM-Gruppe wird zum Flaschenhals
  • Projekte umgehen die Nutzung des ESB und das Anbieten von Services, wenn möglich

Architektur im Elfenbeinturm

In solchen Fällen kann EAM sein volles Potential nicht entfalten. Wenn EAM-Prozesse zu schwerfällig und unflexibel sind, droht die „Architektur im Elfenbeinturm“. In großen Organisationen führt die Zersplitterung von gestalterischer Verantwortung auf viele Rollen oft zu Silodenken und damit zu einer latenten Kommunikationsblockade zwischen EAM, Fachseite und eigener IT.

In kleinen und mittleren IT-Organisationen liegt das Problem meist etwas anders. Hier sind eine Handvoll konzeptioneller Gestalter für alles zuständig. Klassisches EAM wird hier eher in der „Jugend forscht“-Ecke verortet, und wäre in der Tat auch meist überdimensioniert.

In beiden Fällen – bei großen, unübersichtlichen wie auch bei kleinen IT-Organisationen – schafft Lean EAM als skalierbarer und leichtgewichtiger EAM-Ansatz Abhilfe. Die Grundideen des Lean EAM entstammen den Lean Management-Prinzipien, die aus der Industrie auf das Architekturmanagement übertragen werden. EAM wird damit schlank und effizient. Lean EAM steuert den evolutionären Fluss der Veränderung strategisch, reduziert Verschwendung und stellt so einen hohen Wertschöpfungsbeitrag sicher.

Weiterlesen: Prinzipien des Lean EAM

Referenzen


Bildrechte:
Foto © DNY59, http://deutsch.istockphoto.com/stock-photo-7390920-flip-chart.php
Foto © RTimages, http://deutsch.istockphoto.com/stock-photo-4423171-box-man-thinking.php
Foto © starush, http://deutsch.istockphoto.com/stock-photo-5512653-monk-or-maybe-sorcerer.php?st=8d97b09