Leichtgewichtige Enterprise Architecture Was bedeutet das genau und wie kann man es in einer Organisation etablieren und auf Dauer festigen?

In diesem Whitepaper behandeln wir das Thema Leichtgewichtige Enterprise Architecture und wie man damit starten kann. Finden Sie heraus, in welcher Situation und in welchem Spannungsfeld sich die meisten Organisationen befinden. Welche Fragestellungen ergeben sich hieraus und wer sind eigentlich die wichtigsten Stakeholder und was sind ihre Wünsche und Informationsbedürfnisse für das Architektur Team? Wie kann man gezielt mit L-EAM anfangen und als Funktion etablieren?

Autoren: Danny Weinberger (EAMAKAD) Ingo Schrewe (incowia / EAMAKAD) Version: 1609 Veröffentlichung: 23.09.2016

Whitepaper Leichtgewichtige Enterprise Architecture

1

Was verstehen wir unter bestimmten Begrifflichkeiten? Bevor wir überhaupt etwas in die einzelnen Punkte eingehen, empfiehlt es sich grundsätzlich eine kurze Begriffsklärung vorzunehmen. Es gibt nichts Schlimmeres, als über Begriffe zu reden, die von unterschiedlichen Experten und Kollegen unterschiedlich verstanden oder interpretiert werden können. In der folgenden Tabelle haben wir einige Begriffe mit ihren Definitionen aufgenommen, die in diesem Kontext aus unserer Sicht relevant sind. Wir erheben natürlich keinerlei Anspruch auf Vollständigkeit, möchten aber in diesem Dokument verwendete Begriffe klarstellen. Begriff Digitale Strategie & Transformation

Leichtgewichtige Enterprise Architecture bzw. Lean EAM

Definition Beschreibt einen gesellschaftlichen, kulturellen und wirtschaftlichen Wandel (Digitale Revolution) mit der allgegenwärtigen Gestaltung, Nutzung und Herstellung von Informationen, Daten, Produkten und Dienstleistungen in der Gemeinschaft. Ein Handlungsplan, um den Wandel in der Organisation, Prozesse und Technologie auf den digitalen Gebieten umzusetzen. Enterprise Architecture mit dem Fokus, Nutzen (Mehrwert) zu schaffen durch den gezielten, strategisch ausgerichteten Einsatz von IT in den kundenorientierten Prozessen unter Berücksichtigung der wesentlichen Stakeholder-Gruppen und deren Sichten auf die Enterprise Architecture (oder auch IT Unternehmensarchitektur). Keep it simple and stupid / smart.

Agilität

Kunde

Stakeholder

Dabei entsteht Nutzen durch  die Fähigkeit, dass sich die IT im Unternehmen schnell an geplante oder ungeplante Veränderungen anpassen kann (= Agilität)  effiziente und effektive IT-Prozesse (=Professionalität)  den kontinuierlichen Wissensaustausch zwischen (allen) Unternehmensbereichen (=Offenheit)  stetiges Hinterfragen der Arbeitsweise, Ausrichtung und Fähigkeiten (=Innovationsfähigkeit und Unternehmenskultur) In der Lage sein, auf neue Situationen, Anforderungen und Möglichkeiten mit einer hohen Geschwindigkeit kontrolliert reagieren zu können. Eine Person, oder eine Organisation außerhalb der eigenen Organisation, die bestimmte Leistungen und Produkte in Anspruch nimmt bzw. diese käuflich erwirbt. Einzelpersonen, Teams oder Organisationen (Organisationsklassen), die ein bestimmtes Anliegen oder Interesse an den durch die IT Unternehmensarchitektur erzielten Ergebnisse haben. Unterschiedliche Stakeholder mit unterschiedlichen Rollen haben unterschiedliche Anliegen.

Tabelle 1 - Glossar der wichtigen Begriffe

EAMAKAD UG

www.eam-akademie.com

Seite 1 von 24

Whitepaper Leichtgewichtige Enterprise Architecture

2

Welche Situation bzgl. EAM finden wir vor? Viele Organisationen befinden sich in einem Spannungsfeld der besonderen Art, gerade im Zuge der Digitalisierung, siehe Abbildung 1 unten. Dabei müssen Sie auf folgende Punkte achten:  Sie müssen Agilität in der Fach- und IT Organisation erzielen, um auf neue Kundenanforderungen schnell eingehen und neue ZIEL Architekturen & Services agil aufbauen zu können  Sie müssen ständig ihre Architekturlandschaft im Hinblick auf Redundanzen und Kosteneinsparungen sowie Verbesserungen des IT & Architektur Managements anpassen, um effizienter und agiler zu werden, bzw. um mehr Freiraum für Innovationen zu haben und um ein stabiles und effizientes Management der IST Architektur zu gewährleisten  Sie müssen digitale Strategien, digitale Geschäftsmodelle und die Transformation hin zu einer digitalen Organisation gemeinsam von Fach- und IT Seite sicherstellen und neue digitale Fähigkeiten über die gesamte Organisation hinweg etablieren  Sie müssen bereichsübergreifende Innovationen fachlich, als auch IT seitig identifizieren und umsetzen. Dabei muss sich die IT bzw. das Architekturteam als Business Enabler verstehen, um Business Innovation aktiv mit der Fachseite treiben zu können

Abbildung 1- Spannungsfeld

Erschwerend kommt hinzu, dass Enterprise Architecture Management als Funktion zwar in vielen Organisationen etabliert ist, allerdings oft nur in „Architektur-Zirkeln“ gelebt wird. Häufig sind diese Bereiche auch nicht so in der Organisation positioniert, dass sie ihre EAM Rolle im vollen Umfang leben könnten, selbst wenn Sie wollten. Viele Stakeholder werden nur rudimentär adressiert, oder zu spät eingebunden, da teilweise Projekte bereits anfangen haben, obwohl kein Enterprise Architect eingebunden ist. Sehr schnell redet man dann auch von technischen Lösungen und fängt hektisch an, Fachprozesse und Architekturen zu modellieren und technische Konzepte zu erstellen, weil man ja schnell eine Lösung für ein Problem benötigt. Die Frage nach einer fachlichen strategischen Ausrichtung, Strategien, Geschäftsmodellen und gemeinsamen Vorgehensmodellen werden entweder nicht gestellt, oder selbst wenn ein Enterprise Architect diese Punkte erwähnt, werden diese von den Stakeholdern nicht richtig wahrgenommen.

EAMAKAD UG

www.eam-akademie.com

Seite 2 von 24

Whitepaper Leichtgewichtige Enterprise Architecture Gemeinsame Architekturentwicklungs- und Management Standards, auch über Fach- und IT Bereiche hinweg, sind oftmals nicht wirklich vorhanden bzw. etabliert. Für ein Digitalisierungsprogramm ist das allerdings unabdingbar. Schließlich muss man hier etwas pragmatisch, agil und schnell auf die Straße bringen und auf der Basis von Echtzeitdaten schnell Entscheidungen treffen können. Ein L-EAM Ansatz ist hierfür die Grundlage für den Erfolg. Es beginnt bereits damit, dass man Begriffe und Definitionen nicht organisationsweit abgestimmt und etabliert hat. Oft haben einzelne Bereiche ihre eigene Interpretation von Begriffen und man verbringt viel Zeit und Energie damit, diese in Projekten zu diskutieren und zu klären. Architekten sind genau in solchen Projekten regelmäßig „verhaftet“, haben mehrere davon gleichzeitig und müssen ad-hoc Ergebnisse liefern. Daher können Sie sich kaum auf ihre eigentliche Aufgabe als Enterprise Architect konzentrieren und die Qualität der Arbeit leidet dabei dramatisch. Gleichzeitig betreiben alle Beteiligten intensive „Feldforschung“, um aktuelle Daten und Informationen über die Architektur zu bekommen, die sie für ihre Architekturarbeit oder auch für Compliance Prüfungen, z.B.: Solvency II, Basel III, CoC, etc. benötigen. Die meistgenutzten Tools in diesem Zusammenhang heißen dann, Excel, Word, Powerpoint, Visio und was man sonst noch so findet. Im schlimmsten Fall gibt es von jedem Dokument dann noch unterschiedliche Versionen in unterschiedlichen Bereichen - und das Chaos ist perfekt. Selbst wenn es ein Architekturwerkzeug in der Organisation gibt, bleibt hier die Frage offen, wie der Architekturinhalt gepflegt wird und vor allem, wie das Architekturwerkzeug von allen Stakeholdern akzeptiert und genutzt wird. In der folgenden Abbildung 2 haben wir eine Kurzdarstellung der üblichen Probleme im EAM Umfeld aufgezeigt.

Abbildung 2 - Probleme bei EAM

EAMAKAD UG

www.eam-akademie.com

Seite 3 von 24

Whitepaper Leichtgewichtige Enterprise Architecture

Welche Fragen ergeben sich daraus?

3

Haben wir die heutige Situation vor Augen und wissen, was im Rahmen einer Digitalisierung auf uns zukommt, stellen sich zwangsläufig einige Fragen. Diese sind zu Beispiel:  Wie können die IT & das Architektur Team Wachstum für die Organisation generieren?  Wie können die IT & das Architektur Team neue Initiativen und Innovationen unterstützen?  Wie können die IT & das Architektur Team neue Einnahmequellen generieren?  Wie können wir digitale Fähigkeiten (Business & IT Capabilities) generieren und deren Komplexität beherrschbar machen – in der gesamten digitalen Community?  Wie können die IT & das Architektur Team helfen, Kosten zu senken, effizienter zu werden und gleichzeitig Agilität zuzulassen, um neues Geschäft in der digitalen Welt zu generieren?  Wie können die IT & das Architektur Team schnell und agil Mehrwert und Ergebnisse liefern, die für die Fachseite auch einen wirklichen Nutzen haben?  ... Das sind sicherlich nicht alle Fragen, aber zumindest einmal der wichtige Kern. Aber die Fragen zielen im Grunde auf einen Punkt ab, nämlich auf Enterprise Architecture Management (EAM). Wobei wir hier über neue Fähigkeiten im Rahmen der Digitalisierung sprechen, die im EAM zu etablieren sind. Wir brauchen also einen Ansatz, der die folgenden Punkte erfüllt.

Abbildung 3 - L-EAM Argumente und Ansätze

EAMAKAD UG

www.eam-akademie.com

Seite 4 von 24

Whitepaper Leichtgewichtige Enterprise Architecture

Stakeholder-Gruppen für Enterprise Architecture

4

Jetzt haben wir bereits über die aktuelle Situation und L-EAM bzw. die nächste Generation vom EAM gesprochen. Doch wo genau liegt eigentlich der wesentliche Nutzen einer Enterprise Architecture (EA) und wie kann man diesen erreichen? Der Nutzen ergibt sich immer dann, wenn Menschen im Unternehmen durch die Verwendung von EA Ergebnissen bessere Entscheidungen treffen können Grundsätzlich gibt es im Kontext von Enterprise Architecture vier unterschiedliche „Abnehmer“ von Architekturinformationen bzw. -Artefakten. Diese sind (siehe auch folgende Abbildung):    

Vorstand und Fachbereiche Manager IT und Architektur Architekten Programm- und Projekt-Manager

Abbildung 4 – EAM Stakeholder Gruppen

Jede dieser vier Interessensgruppen hat ihre eigenen Informationsbedarfe, Wünsche und Erwartungen an das Architekturteam und an die Unternehmens- und IT Architektur und blickt aus verschiedenen Perspektiven auf diese. Welche Bedürfnisse diese jeweiligen Stakeholder haben und welchen Nutzen Sie von einer Enterprise Architecture haben, wird im folgendem kurz dargestellt.

EAMAKAD UG

www.eam-akademie.com

Seite 5 von 24

Whitepaper Leichtgewichtige Enterprise Architecture Typische Fragen der Stakeholder sind in den vier Boxen in der Abbildung 5 beschrieben:

Abbildung 5 – typische Fragen

Daraus abgeleitet möchten die genannten Interessensgruppen bestimmte Zusammenhänge in der Architektur verstehen bzw. verfügbar haben, um daraus Nutzen ziehen zu können. In den folgenden Grafiken gehen wir gezielt auf die einzelnen Stakeholder-Gruppen ein.

Abbildung 6 – Stakeholder Gruppe Vorstand / Fachseite EAMAKAD UG

www.eam-akademie.com

Seite 6 von 24

Whitepaper Leichtgewichtige Enterprise Architecture

Abbildung 7 – Stakeholder Gruppe Manager IT / Architektur

Abbildung 8 – EAM Stakeholder Architekten

EAMAKAD UG

www.eam-akademie.com

Seite 7 von 24

Whitepaper Leichtgewichtige Enterprise Architecture

Abbildung 9 – Stakeholder Gruppe Programm / Project Management

EAMAKAD UG

www.eam-akademie.com

Seite 8 von 24

Whitepaper Leichtgewichtige Enterprise Architecture

5

Die Stakeholder-Gruppen in den Enterprise Architecture Areas Jetzt wissen wir, welche Bedürfnisse und Wünsche die Stakeholder-Gruppen haben. Doch wie kann man nun eine leichtgewichtige Enterprise Architecture unter Berücksichtigung dieser Stakeholder aufbauen oder entwickeln? Eines können wir schon einmal vorausschicken: langwierige Diskussionen über Enterprise Architecture Strategien, Methoden, oder EA Tool Testung im Vorfeld helfen hier wenig und führen kaum zum Verständnis bei den Stakeholdern für dieses Thema. Hier helfen mehr Erfahrungen und Best Practices. Wie kann also pragmatisch und leichtgewichtig relativ schnell Nutzen für die Stakeholder geschaffen werden? Betrachten wir die Gruppe „Vorstände und Fachbereiche“: Der Leser stimmt uns mit Sicherheit zu, dass diese eine nicht so ganz unwichtige Stakeholder-Gruppe ist. Immerhin hat diese Gruppe das Geld und trifft am Ende des Tages geschäftliche Entscheidungen. Wir wissen, dass diese Stakeholder-Gruppe einen groben Überblick über die Architektur und ihre wichtigsten Komponenten haben möchte. Allerdings nicht im Hinblick auf einen Überblick über die inhaltliche Architekturlandschaft, sondern viel mehr im Hinblick auf Implikationen von Entscheidungen auf die Architektur und deren Kosten und Nutzen. Somit ist es die Aufgabe für einen Enterprise Architect, den Nutzen von neuen/geänderten Geschäftsmodellen und Geschäftsfällen (Business Cases) sowie deren Planung und Umsetzung im Architekturkontext modellieren und bewerten zu können. In dem Moment müssen wir uns also Gedanken machen, wie der Umfang und die Planung aussieht, wie Value Cases definiert werden können und wie wir daraus Benefits für diese Gruppe generieren können. All diese Aspekte sind Bestandteil eines der Gebiete der Enterprise Architecture, der „Enterprise Architecture Strategy“, siehe Abbildung unten.

Abbildung 10 – Stakeholder-Gruppe Vorstand / Fachbereich auf der EA Area Landkarte

EAMAKAD UG

www.eam-akademie.com

Seite 9 von 24

Whitepaper Leichtgewichtige Enterprise Architecture Wenn diese Stakeholder Gruppe einen Überblick über die Architekturlandschaft haben möchte, um Einflüsse, Kosten, etc. zu erkennen, bewegen wir uns aber auch im Bereich „Architecture Content“ – sprich Inhalte der Architektur. Welche Einflüsse haben Entscheidungen aus dem Vorstand bzw. den Fachbereichen auf die IST oder die ZIEL Architektur, wie kommt man vom IST zum ZIEL, welchen Nutzen hat man hieraus und was kostet uns das Ganze? Aber auch Fragen dazu, wie die IT die Fachseite mit Fähigkeiten und Funktionalitäten konkret unterstützen kann, spielen hier eine Rolle. Ein anderer Bereich ist für den Architekten jedoch auch sehr wichtig. Wenn wir uns schon über diese sehr wichtige Stakeholder-Gruppe unterhalten und diese hier betrachten, müssen wir auch über eine gute Kommunikations- und Business Engagement Strategy unterhalten und uns darüber Gedanken machen. Sprich, mit welcher Art von Artefakten bzw. Architekturreports „beglücke“ ich diese Stakeholder-Gruppe, wie kommuniziert man mit ihr über welche Kanäle wie oft wird welche Information wirklich transportiert? In diesem Moment bewegen wir uns im Gebiet „Community & Culture“, die eine der wichtigsten Enterprise Architecture Gebiete darstellt. Sie können eine noch so gute Architekturlandschaft und eine noch so gut ausgebildete und erfahrene Architekturgruppe haben. Wenn Sie keine gute Kommunikationsstrategie für Ihre Stakeholder haben, werden Sie nicht erfolgreich sein. Bevor wir kurz auf die anderen Stakeholder-Gruppen eingehen, lassen Sie uns kurz die Enterprise Architecture Gebiete beleuchten, die wir als eine „große Landkarte“ verstehen wollen. Sie dient zur Einordnung und Orientierung, wenn man im Unternehmen Aufgaben und Maßnahmen plant, umsetzt und bewertet, die durch IT beeinflusst werden und die das Erreichen der Unternehmensziele wesentlich unterstützen. Dabei beziehen sich die Gebiete auf die folgenden Inhalte: Enterprise Architecture Strategy: Die Unternehmensarchitektur (Enterprise Architecture) übersetzt die strategischen Ziele und Visionen einer Organisation in einen realisierbaren Blueprint für den Wandel in den Fach- und IT Bereichen. Ohne Enterprise Architecture Strategy & Vision, welche die Prinzipien und die Zielsetzung, die Ausrichtung und den Nutzen über alle Architekturgebiete repräsentiert, gibt es kaum eine Chance, einen greifbaren Mehrwert der Unternehmensarchitektur zu entwickeln. Methods & Frameworks: Die Methoden und Frameworks bilden die Basis für eine organisationsweite “Architektursprache” einschließlich Standards, Methoden, Frameworks, Vorgehensmodellen und Tools, um eine nutzenorientierte, nachhaltige und damit erfolgreiche EAM Funktion zu etablieren. Architecture Content: Der Architekturinhalt umfasst alle Aspekte und Artefakte der Unternehmensarchitektur, die man in folgende Architekturdomänen unterteilen kann:  Facharchitektur (oder Geschäftsarchitektur)  Datenarchitektur (oder Informationsarchitektur)  Anwendungsarchitektur (oder Anwendungslandschaft)  Technologiearchitektur (oder Infrastrukturarchitektur) Community & Culture: Die Unternehmensarchitektur ist nicht nur einfach eine Methode oder ein Framework. Es ist vielmehr eine Kultur der Zusammenarbeit in einer Organisation mit unterschiedlichen Stakeholdern. Diese Stakeholder müssen, entsprechend ihrer Bedürfnisse, mit den richtigen Methoden und Taktiken behandelt und zufrieden gestellt werden. Governance & Assurance: Die Governance der Architektur stellt sicher, dass die richtigen Personen die richtigen Dinge mit den richtigen Tools zur richtigen Zeit tun können. Die Governance-Funktion gibt dafür die Leitplanken vor, legt Rahmenbedingungen und Ziele fest, die geeignet gemessen und ausgewertet werden können.

EAMAKAD UG

www.eam-akademie.com

Seite 10 von 24

Whitepaper Leichtgewichtige Enterprise Architecture Capability & Competency: Um Enterprise Architecture im vollen Umfang und zum Unternehmen passend etablieren und leben zu können, benötigen die Organisation und alle Beteiligten entsprechende Kenntnisse und Fertigkeiten. Ein Rahmenwerk, mit dem dazu nötige Erfahrungen und Ausbildungen festgelegt werden können, hilft dabei, die notwendigen Kenntnisse zu erlangen.

Abbildung 11 – Enterprise Architecture Areas Allgemein

Jetzt haben wir also kurz die Enterprise Architecture Gebiete erläutert und sind bereits auf eine Stakeholder-Gruppe eingegangen. Nun haben wir aber noch weitere Stakeholder-Gruppen, die wir als Architekturteam „glücklich“ machen wollen. Lassen Sie uns also auch noch diese betrachten.

Die nächste Stakeholder-Gruppe sind die Manager der IT / Architektur. Ja, auch das ist eine wichtige Stakeholder-Gruppe, natürlich mit einem anderen Fokus. Hier möchte man einen detaillierten Blick auf die Architekturlandschaft haben und zwar bitte mit Echtzeitdaten für IST, ZIEL und das gesamte Portfolio und natürlich auch die Gaps und Redundanzen erkennen, um auf dieser Basis Aufwände, Kosten, Risiken, etc. evaluieren und steuern zu können. In Folge dessen bewegen wir uns auf anderen Gebieten in unserer Landkarte, wie Sie in der folgenden Abbildung sehen.

EAMAKAD UG

www.eam-akademie.com

Seite 11 von 24

Whitepaper Leichtgewichtige Enterprise Architecture Es liegt hier natürlich in der Natur der Sache, dass der Manager der IT & Architektur so ziemlich alle Gebiete auf dieser Landkarte betrachten muss und auch die Standards für Enterprise Architecture in der Organisation etablieren muss. Am Ende des Dokumentes gehen wir darauf ein, mit welchen Gebieten man geeignet starten sollte, um das Ganze von Anfang an wirklich leichtgewichtig zu halten.

Abbildung 12 – Stakeholder Gruppe Manager IT / Architektur auf der EA Area Landkarte

Die Architekten sind die nächste wichtige Stakeholder-Gruppe, die insbesondere fordert, so detaillierte Informationen über die Architekturlandschaft zu haben, wir nur möglich, um diese dann mit vordefinierten Blueprints, Templates, Artefakten, etc. schnell und einfach aktualisieren zu können. Auch die Konsolidierung von Informationen aus unterschiedlichen Quellen und die intensive Kommunikation mit den Fachbereichen liegt im Fokus dieser Gruppe. Folglich sind auch die Gebiete auf unserer Landkarte andere als bei den beiden bereits betrachteten Gruppen. Die Personen dieser Gruppe benötigen einen tiefen Einblick in die Architekturlandschaft auf dem Gebiet „Architecture Content“ und entwickeln hier Artefakte, die spezifisch für deren Arbeit sind. Man sollte jetzt also nicht glauben, dass man diese Artefakte gefahrlos einfach einmal an die Fachbereiche oder gar Vorstände senden kann. Da werden sie mit Sicherheit kaum bis gar nicht verstanden. Aber Designer und Architekten müssen sich sehr wohl Gedanken dazu machen, wie sie mit den Fachbereichen und Vorständen kommunizieren und wie sie den Nutzen Ihrer Arbeit (der Architektur) entsprechend darstellen.

Abbildung 13 – Stakeholder Gruppe Architekten auf der EA Area Landkarte

EAMAKAD UG

www.eam-akademie.com

Seite 12 von 24

Whitepaper Leichtgewichtige Enterprise Architecture Die Programm- und Projekt-Manager sind unsere letzte wichtige Stakeholder-Gruppe. Hier geht es nun darum, Einflüsse und Abhängigkeiten von Projekten auf die Architektur, Organisation, Architekturplanung und andere Projekte (und umgekehrt) frühzeitig zu erkennen und entsprechend zu steuern. Somit sind auch hier die Schwerpunkte auf unserer Landkarte wieder etwas anders gelagert und fokussieren sich sehr stark auf die Enterprise & Projekt Portfolio Planung und Steuerung, die Kommunikation, die Opportunities & Use Cases sowie der sich daraus ergebende Nutzen. Methodisch benötigt man hier typischerweise ein Projekt-Management-Vorgehen, wie PMI, Prince2 oder auch DPMA – wenn man nicht gerade sein eigenes Vorgehen hierfür hat.

Abbildung 14 – Stakeholder Gruppe Programm & Project Manager auf der EA Area Landkarte

Jetzt haben wir alle vier Stakeholder-Gruppen kurz beleuchtet und diese auf unserer Landkarte verortet. Legt man jetzt alle Bedürfnisse aller Gruppen zusammen und stellt diese auf unserer Landkarte dar, entsteht folgendes Bild.

Abbildung 15 – alle Stakeholder Gruppen auf der EA Area Landkarte

EAMAKAD UG

www.eam-akademie.com

Seite 13 von 24

Whitepaper Leichtgewichtige Enterprise Architecture Jetzt stellen Sie sich einfach einmal vor, Sie wollten eine Enterprise Architecture Funktion in Ihrer Organisation für alle sechs EA-Gebiete und alle Stakeholder-Bedürfnisse gleichzeitig aufbauen. Nicht, dass dies schon viele Unternehmen versucht haben, aber erfahrungsgemäß kann das nicht zum Erfolg führen. Denn alleine die Farbvielfalt zeigt, dass man es nicht allen gleichzeitig recht machen kann und schon gar nicht gleichzeitig. Es ist also essentiell, dafür den bestmöglichen Startpunkt, die richtige Verteilung zu finden, um Aufwand und Nutzen in Balance zu bringen. Um es gleich vorweg zu sagen, es gibt nicht DEN Weg, den man grundsätzlich umsetzen kann. Dazu sind die Organisationen und deren Situationen viel zu unterschiedlich. Gehen wir also in folgendem Abschnitt hierauf ein. Lassen Sie uns jedoch vorher kurz über mögliche Visualisierungsformen reden.

EAMAKAD UG

www.eam-akademie.com

Seite 14 von 24

Whitepaper Leichtgewichtige Enterprise Architecture

6

Artefakte für die Visualisierung von Informationen für die Stakeholder-Gruppen Bei der Visualisierung geht es vor allem darum, welche Artefakt-Typen (Diagramme, Matrizen, Kataloge) für welche Stakeholder-Gruppe am besten „funktionieren“, d.h. die Inhalte verständlich für diese Gruppen darstellen. In der folgenden Abbildung sind einige unterschiedlichen Typen dargestellt. Man sollte aber jetzt nicht davon ausgehen, dass man pro Typ ein Artefakt erstellt. Auch hier gibt es Varianzen, die unterschiedlich aussehen und wirken können.

Abbildung 16 – Typen von Artefakten

Grundsätzlich gesprochen, können wir zwischen Katalogen, Matrizen und Diagrammen unterscheiden. Gehen wir kurz hierauf ein. Kataloge:  Strukturierte Listen mit architektonischen Ergebnissen und Inhalten einer ähnlichen Art, die als Referenz verwendet werden.  Werden für die Steuerung oder für Referenzzwecke genutzt.  Enthalten Metadaten entsprechend einem Metamodell, die Abfragen und Analyse Funktionen unterstützen. Kataloge eignen sich vor allem für eine detaillierte Darstellung, zum Beispiel ein TechnologiestandardKatalog oder Anwendungs-Portfolio-Katalog. „Abnehmer“ für diese detaillierten Informationen sind vor allem die Stakeholder-Gruppe der Architekten. Wenn wir beispielsweise über einen Prinzipienkatalog oder ein Glossar reden, ist dies aber auch für die Stakeholder-Gruppen der Manager IT & Architektur und Vorstand / Fachbereiche von Interesse.

EAMAKAD UG

www.eam-akademie.com

Seite 15 von 24

Whitepaper Leichtgewichtige Enterprise Architecture Matrizen:  Ein Format für die Darstellung von Beziehungen zwischen zwei (oder mehreren) architektonischen Elementen Matrizen werden verwendet, um Beziehungen zwischen diesen Elementen darzustellen. Beispielsweise kann eine CRUD-Matrix zeigen, welche Anwendungen bestimmte Arten von Daten erstellen, lesen, aktualisieren oder löschen. Diese Information ist ebenfalls für die Stakeholder-Gruppe der Architekten sehr interessant, da sie hier detaillierte Zusammenhänge erkennen können.

Diagramme:  Diagramme sind Darstellungen von architektonischen Inhalten und Elementen in einem grafischen Format.  Sind eine Visualisierungsmethode, um architektonische Inhalte auf Vollständigkeit schnell überprüfen zu können.  Jedes dieser Diagramme kann mehrmals für eine Architektur mit anderen Stil oder Inhalt erstellt werden, um den aktuellen Anforderungen der Stakeholder gerecht zu werden. Frei nach dem Motto: „Bilder sagen mehr, als tausend Worte.“ eignen sich Diagramme vor allem für die Stakeholder-Gruppen Vorstand / Fachbereiche und Manager IT & Architektur. Zum Beispiel eignen sich Business Footprint-Diagramme, um den Zusammenhang zwischen technischen Komponenten und den fachlichen Zielen darzustellen. Man kann aber auch über unterschiedliche Capability Maps reden (Business und/oder IT Capabilities), die die Zusammenhänge der Capabilities auf unterschiedlichen Ebenen darstellen. Gleichzeitig können Sie einen IT Bebauungsplan erstellen, um den Weg von der IST zur ZIEL Architektur graphisch für die Manager IT & Architektur und Programm & Projekt Manager darzustellen. Es gibt also durchaus unterschiedliche Wege und Mittel, wie man eine Information transportieren kann. Die Frage ist dann immer, welche Information wird wirklich benötigt und wie versteht diese Gruppe die Information am besten.

EAMAKAD UG

www.eam-akademie.com

Seite 16 von 24

Whitepaper Leichtgewichtige Enterprise Architecture

Leichtgewichtige Enterprise Architecture – Methoden und Vorgehen

7

7.1 Leichtgewichtige Methoden und Ansätze Gerade die oben erwähnten sechs Enterprise Architecture Areas (Gebiete) mit all ihren Facetten und die vielen unterschiedlichen Stakeholder-Anforderungen können natürlich dazu führen, dass Sie in Ihrer Rolle als Enterprise Architect nicht wissen, womit Sie zuerst anfangen sollen, denn es ist einfach zu viel. Daher haben wir hier einige unserer Empfehlungen (Best Practices) zusammengestellt, die Ihnen helfen sollen, Ihr Leben zu erleichtern und von Beginn an auf der Erfolgsspur zu sein und es zu bleiben. Die folgenden drei Maxime sollten dabei Ihr Handeln bestimmen: 1. Verstehen Sie Ihre Kunden! Im Grunde können Sie hier jeden Satz anfangen mit: „Der Kunde möchte….“ und können diesen Satz weiter ausformulieren, je nach Situation und Ziel. Diese „Übung“ klingt harmlos, hat es aber durchaus in sich. 2. Schaffen Sie Transparenz! Sorgen Sie dafür, dass Sie jederzeit mit Echtzeitdaten Transparenz über ihre Architektur und Situation haben, um schnell und auf fundierter Basis Entscheidungen treffen zu können. 3. Kommunizieren Sie passend! Sorgen Sie für einen Informationsaustausch und zwar Zielgruppengerecht.

Hieraus lassen sich wiederum Aktivitäten ableiten, von denen sich die folgenden bewährt haben: Zu 1: Verstehen Sie Ihren Kunden! 

Identifizieren Sie die „Stakeholder“, die aus Unternehmenssicht den größten Bedarf (und damit den größten Nutzen) an einer transparenten und dynamischen IT haben und bleiben Sie hartnäckig, bis Sie einen Workshop-Termin vereinbart haben.



Stimmen Sie mit diesen Interessentengruppen ab, welche die drei wichtigsten IT-Aspekte, Ergebnisse, Artefakte o.ä. sind, die den größten Nutzen darstellen (würden) und in welcher Form man diese am liebsten bekommen und verwenden würde.



Stellen Sie sicher, dass Sie und Ihr Partner (Kunden sollten immer auch Partner sein) von den gleichen Dingen reden, vereinbaren Sie Definitionen, tragen diese in eine erste Version eines Glossars ein und zeigen Sie Beispiele von möglichen Ergebnissen. auf.

Zu 2: Schaffen Sie Transparenz! 

Schaffen Sie die Grundlagen, damit die wichtigsten Interessenten an Ihrer ITUnternehmensarchitektur aktuelle, korrekte und relevante Informationen erhalten.



Verwenden Sie dazu verständliche Mittel der Darstellung. Sie können zu Beginn durchaus mehrere Varianten vorlegen und einigen sich dann auf diejenigen, die Ihrem Partner am besten passen und die er vor allem verstehen kann.



Bleiben Sie kreativ und zeigen Sie immer mal etwas Neues und Interessantes auf.



Liefern Sie auf jeden Fall regelmäßig und pünktlich das Vereinbarte und bitten Sie um direktes, unmittelbares Feedback.

EAMAKAD UG

www.eam-akademie.com

Seite 17 von 24

Whitepaper Leichtgewichtige Enterprise Architecture 

Legen Sie für alle Informationen definierte Messkriterien und Zielgrößen für die Kriterien fest o

Legen Sie diese auch ohne konkrete Vorgaben Ihrer Partner/Interessenten/Stakeholder fest und präsentieren sie diese.

o

Sofern Sie falsch liegen, passen Sie diese an. Das ist allemal besser, als keine zu haben.

Zu 3: Kommunizieren Sie passend! 

Schlagen Sie den Partnern/Stakeholdern/Interessensgruppen vor, wie der Informationsaustausch, die Wissensgenerierung erfolgen kann, z.B. durch o

regelmäßige und unregelmäßige gegenseitige Wissensmärkte / Work Café, etc. – seien Sie hier ruhig kreativ und nutzen Sie die Chance des Informationsaustausches!

o

gegenseitige Besuche, bei denen man anderen über die Schulter schaut. Die tägliche Arbeit und die damit zusammenhängenden Herausforderungen helfen dabei, den anderen zu verstehen. Das wirkt oft Wunder!

o

Lessons Learned mit allen Beteiligten. Oft gefordert in den Organisationen, aber selten wirklich konsequent praktiziert, um einen Nutzen für sich hieraus zu ziehen.

o

gemeinsame Schulungen / Trainings zu Fach- oder IT-Themen (z.B.: Digitalisierung, Innovationen, etc.) untermauern Ihre Kompetenzen gegenüber Ihren Stakeholdern und sorgen für ein besseres Verständnis untereinander.

o

etc.

Nachdem wir Ihnen die drei Maxime an die Hand gegeben haben, möchten wir noch mögliche Methoden und Ansätze aufführen, die Ihnen helfen werden, eine leichtgewichtige Enterprise Architecture aufzubauen. Die folgende Auflistung stellt einfach nur eine Reihe von Methoden dar, die man in diesem Kontext einsetzen kann. Im Laufe der nächsten Whitepapers werden wir auf die einzelnen Methoden näher eingehen und den Zusammenhang mit L-EAM darstellen.        

Lean Demand Management, Stakeholder Analyse & Management Customer Journey Ansatz, vor allem Wertstrom Analyse bzw. E2E Wertschöpfungskette Analyse, Customer Journey Canvas, Business Model Canvas, Kundenwert Analyse, MVP Ansatz (Minimum Viable Product), Leichtgewichtige Zusammenarbeitsmodelle und noch viele mehr.

EAMAKAD UG

www.eam-akademie.com

Seite 18 von 24

Whitepaper Leichtgewichtige Enterprise Architecture

7.2

Vorgehen für eine leichtgewichtige Enterprise Architecture

Abbildung 17 – der Weg hin zur leichtgewichtigen Enterprise Architecture

7.2.1

Ramp-up

Wir sind eingangs auf die Stakeholder-Gruppen und die Artefakte eingegangen und genau darin liegt der Schlüssel. Die Frage am Anfang ist, wer sind die wichtigsten Stakeholder-Gruppen und was sind deren Wünsche und Ziele und welchen Nutzen muss man hierfür darstellen? Man sollte allerdings auch nicht in die Falle tappen und alle Stakeholder-Gruppen als gleich wichtig einstufen. Das wird auch gerne getan, hilft aber am Ende auch nicht weiter (siehe die farbige Punktewolke oben). Es geht somit tatsächlich darum, Ihre aktuelle Situation zu bewerten und die wirklich wichtigsten Stakeholder-Gruppen zu identifizieren sowie deren Wünsche und Ziele zu erfassen. Das kann in einer Organisation der Fachbereich sein, weil dieser vielleicht gerade eine neue digitale Geschäftsstrategie erstellt und beispielsweise über Produktmodularisierung für Endkundenprodukte redet und man hierfür eine neue Architektur benötigt. In einer anderen Organisation kann das aber auch die Stakeholder-Gruppe der Programm- und Projekt Manager sein, weil hier gerade eine Vielzahl an Projekten läuft, und eine entsprechende PortfolioPlanung und -Steuerung notwendig ist, die man im Rahmen von EAM mit etablieren kann. Häufig haben wir die Situation erlebt, dass man über Anwendungsmodernisierung bzw. Harmonisierung redet, im Grunde also einen bestimmten Teil der Anwendungslandschaft modernisieren möchte und im gleichen Atemzug eine EAM Funktion etablieren möchte. In diesem Moment betrachten wir die Stakeholder-Gruppen Manager IT & Architektur und Designer & Architekten und stellen dabei fest, dass wir uns sofort in allen Gebieten unserer Landkarte bewegen. Aber auch hier kann man gezielt vorgehen. Kommen mehrere Stakeholder-Gruppen zusammen, was ja auch sein kann, sollte man zumindest eine dieser zwei Gruppen priorisieren und damit beginnen. Beides auf einmal anzufangen ist nicht zu empfehlen, da dann die Komplexität sprunghaft ansteigt und daraus eher eine „Mission Impossible“ werden kann und sich die positiven Erfahrungen mit EAM nicht einstellen werden. EAMAKAD UG

www.eam-akademie.com

Seite 19 von 24

Whitepaper Leichtgewichtige Enterprise Architecture Hat man also die Top-Stakeholder-Gruppe identifiziert und deren Wünsche und Ziele erfasst, sollten Sie eine Stakeholder- Management-Funktion, kombiniert mit einer Kommunikationsstrategie, etablieren. Das wird gerne oft unterschätzt und wenig praktiziert, aber genau hier liegt der Schlüssel zum Erfolg.

7.2.2

IST & ZIEL Welt

Im Nachgang werden dann die aktuellen Informationen zur IST Situation erfasst und entsprechende Informationen eingeholt, um eine aktuelle „Wasserstandsmeldung“ zu bekommen. Im Idealfall hat man hier gleich ein EA Tool zur Verfügung, welches diese Informationen liefern kann. Falls das nicht vorhanden ist, kann man sich mit einem Open Source Tool helfen, was man schnell einsetzen kann. Besser ein mittelmäßiges EA Tool, als kein EA Tool. Man sollte aber nicht zu viel Zeit in der Anfangsphase dafür aufwenden, um ein EA Tool auszuwählen. Das verzögert den Vorschritt teilweise massiv. Wenn wir auf unser Beispiel der Anwendungsharmonisierung gehen, ist es wichtig, die Architektur- Inhalte für die Anwendungsarchitektur und die der zu unterstützenden Facharchitektur zu evaluieren. Sprich, welche Anwendung unterstützt mit welchen Funktionalitäten welche Fachbereiche und Prozesse in der heutigen IST-Welt und wie soll die ZIEL-Welt in der Fach- und Anwendungsarchitektur aussehen und welche neuen Fähigkeiten braucht man. Auf der Basis der Informationen werden dann Verbesserungsszenarien und hieraus abgeleitet Use Cases dargestellt, die man dann priorisiert angehen kann. Die entsprechenden Architekturinhalte für die Fachund Anwendungsarchitektur werden für die ausgewählte Stakeholder-Gruppe erstellt, Visualisierungsund Modellierungsmethoden entwickelt, erprobt und schließlich etabliert. Dabei ist es jedoch wichtig, dass man Quick Wins definiert und den Nutzen dieser und der neuen ZIEL-Architekturen den Stakeholdern geeignet präsentiert. Wie man das Ganze dann modelliert, oder ob man dies überhaupt modelliert, hängt von Ihrer Organisation ab. Man kann das nach gängigen Standards, wie BPMN, UML, ArchiMate, oder ähnliches angehen. Man kann aber auch sagen, dass man gar nicht groß modellieren möchte und sich beispielsweise nur einen Überblick über die Architektur und das Portfolio verschaffen möchte. Auch das kann man machen, je nachdem, was am besten für einen selbst funktioniert und wie man EAM leben möchte.

7.2.3

L-EA Management

Hat man das alles getan, kommen wir jetzt an den eigentlichen Punkt der L-EA Management Etablierung als Funktion und Prozess. Warum steht es hier am Ende der Phasen und wieso gibt es eine Verbindung zur Set Up Phase? Das ist wahrscheinlich die Frage, die sich jetzt einige Leser stellen. Stellen wir das also kurz klar. Die erfahrenen Leser werden uns mit Sicherheit zustimmen, wenn wir folgende Aussagen treffen: 1. Wir können erst dann wirklich sinnvoll über eine Governance- und über eine ManagementFunktion reden, wenn wir wissen, was wir eigentlich govern und managen wollen – sprich, wir müssen den Inhalt kennen. Richtig? 2. Allerdings müssen wir auch bestimmte Basiselemente hieraus am Anfang festlegen, um überhaupt den Architekturinhalt erstellen zu können. Auch richtig? Was bedeutet das jetzt? Wenn wir zum Beispiel eine Anwendungslandschaft modernisieren möchten und eine neue Fach- und Anwendungslandschaft aufbauen wollen, die – zum Beispiel – auch Agilität ermöglichen soll, müssen wir definieren, was wir unter dem Begriff „Agilität“ verstehen und diesen auch kommunizieren.

EAMAKAD UG

www.eam-akademie.com

Seite 20 von 24

Whitepaper Leichtgewichtige Enterprise Architecture So verhält sich das auch mit anderen wichtigen Begrifflichkeiten, die wir dann in ein kleines Glossar eintragen und kommunizieren sollten. Wenn wir dann zum Beispiel mit anderen Stakeholder in der IST Analyse oder in der ZIEL Definition interagieren müssen, wissen diese Gruppen dann, was wir unter diesem Begriff verstehen und verfallen damit nicht in regelmäßige Diskussionen über Begrifflichkeiten. Das muss ja nicht gleich in ein Glossar mit hunderten Begriffen ausarten. Aber man kann zumindest mit den wichtigsten 5-10 Begriffen anfangen (siehe oben) und die Basis für die folgenden Phasen legen. Alles Weitere kann man dann später angehen. Genauso verhält sich das, wenn wir über Prinzipien, Leitlinien oder Governance reden. Wenn wir den Anspruch haben, eine agile Architektur zu etablieren, benötigen wir auch Leitlinien und Prinzipien hierfür, die wir zumindest kurz beschreiben sollten. Auch hier reden wir nicht von einem riesigen PrinzipienMachwerk, was kaum jemanden interessiert, sondern eher über eine Hilfestellung für die IST- und ZIELDefinition. Das Selbe haben wir natürlich bei Visualisierung, Modellierung und auch bei Methoden, Standards, Kompetenzen, etc. Eine gewisse Basis braucht man für alle diese Punkte am Anfang, die man aber dann im Nachgang und durch die Erprobung feinjustiert und etabliert. Genau das passiert dann in der letzten Phase, wenn wir L-EA Management als Funktion etablieren.

Kurz noch ein Hinweis am Rande bezüglich TOGAF 9.1. Der aufmerksame Leser, der mit TOGAF 9.1 näher vertraut ist, wird feststellen, dass die eben genannten Punkte Teil der sogenannten „Preliminary Phase“ sind und das ganz am Anfang durchgegangen werden muss laut TOGAF. Danny Weinberger selbst hat viele Jahre als TOGAF Zertifizierungstrainer gearbeitet und kennt das daher sehr gut. Er und wir als EAMAKAD Team haben aber die Erfahrung gemacht, dass man bei dieser Herangehensweise sich schnell in strategische Dauerdiskussionen verzetteln und über Wochen und Monate hinweg nur in dieser Phase aufhalten kann, ohne nennenswerte Erfolge gegenüber den Stakeholdern zu liefern. Deshalb haben wir hier diese Aufteilung in den graumarkierten Kästchen des Bildes gemacht und ziehen bestimmte Basiselemente hieraus vor und finalisieren den Rest in Gänze am Ende. Weiterhin wird dem aufmerksamen Leser aufgefallen sein, dass der Ansatz mit den Stakeholder-Gruppen und den Artefakten ebenfalls im TOGAF 9.1 in einer Art und Weise behandelt wird – nämlich im Teil Views & Viewpoints. Dies ist der Teil, wo man über die Artefakte und die Architecture Views redet. Auch hier sind bestimmte Architecture Views definiert, jedoch nicht nach Stakeholder-Gruppen, wie wir das getan haben, sondern nach Architecture Views, wie Business Architecure View, oder Software Engineering View. Diese Architecture Views waren jedoch nicht immer leicht verständlich für die Teilnehmer in den Kursen und manchmal auch zu abstrakt, ehrlich gesagt. Von daher macht es mehr Sinn, direkt über StakeholderGruppen zu reden, vor allem wenn wir auch über ein Stakeholder-Management in diesem Kontext reden. Somit wird Enterprise Architecture greifbarer an Menschen und handelnden Personen orientiert und man kann es direkt miteinander verknüpfen. In der Abbildung 18 finden Sie den Weg beschrieben, wie wir Sie bei der Etablierung einer leichtgewichtigen Enterprise Architecture begleiten können. Dabei fokussieren wir uns auf folgende drei Phasen, die wir danach kurz beschreiben:   

Wissen vermitteln Wissen etablieren Wissen festigen

EAMAKAD UG

www.eam-akademie.com

Seite 21 von 24

Whitepaper Leichtgewichtige Enterprise Architecture

Abbildung 18 – der Weg der Begleitung durch das EAMAKAD Team

Wissen vermitteln: Lernen Sie unseren Ansatz der leichtgewichtigen Enterprise Architecture in unserem Kurs bzw. Workshop „Leichtgewichtige Unternehmensarchitektur (L-EAM)“ kennen und lernen Sie, wie Sie sich selbst helfen können. Verstehen Sie, welche Fähigkeiten und Fertigkeiten Sie benötigen, um Enterprise Architecture leichtgewichtig zu etablieren und kombinieren Sie dies mit den Kursen „Wissens- und InnovationsManagement für digitale Organisationen“ und „Lean Management 1: Lean Techniken“. Wissen etablieren: Nachdem Sie das Wissen der leichtgewichtigen Enterprise Architecture verinnerlicht haben, können Sie mit uns gemeinsam diesen Ansatz in Ihrer Organisation etablieren. Nutzen Sie dabei unser Wissen und unsere Erfahrungen aus dem gesamten Netzwerk und gehen Sie mit uns gemeinsam durch die Phasen, die wir hier im Kapitel 5 beschrieben haben. Wir unterstützen Sie dabei gezielt durch Training on the Job & Coaching bzw. Sprint Maßnahmen, die richtigen Entscheidungen zur richtigen Zeit mit den richtigen Kollegen zu treffen. Wir führen mit Ihnen gemeinsam einen Health Check durch, etablieren die L-EAM Fähigkeiten und Steuerungsmechanismen. Wissen festigen: Haben Sie L-EAM erfolgreich etabliert, besteht die Herausforderung darin, dies in der Organisation zu festigen und weiter zu optimieren. Wir führen mit Ihnen gemeinsam regelmäßig vereinbarte Health Checks durch, um Ihren Reifegrad auf diesem Gebiet zu ermitteln und Handlungsempfehlungen für Verbesserungen zu identifizieren. Profitieren Sie dabei auch hier vom Wissen aus unserem Netzwerk und von unserem Reifegradmodell, welches wir hier zu Grunde legen.

EAMAKAD UG

www.eam-akademie.com

Seite 22 von 24

Whitepaper Leichtgewichtige Enterprise Architecture

7.3

Was kann die leichtgewichtige Enterprise Architecture für die Organisationen leisten und was haben Sie davon? Wenn man unterschiedliche Modelle analysiert, kommt immer wieder und relativ schnell die Frage hoch, was bringt mir das und in welchem Zeitraum haben wir den Nutzen hieraus? Im folgenden Bild haben wir die wichtigsten Argumente für eine leichtgewichtige Enterprise Architecture aufgelistet. Natürlich könnten wir hier noch einige mehr, auch von TOGAF & Co, hinzufügen. Aber diese Punkte sind die wichtigsten und vor allem die Greifbarsten für die meisten Unternehmen.

Abbildung 19 – Argumente für eine leichtgewichtige Enterprise Architecture

EAMAKAD UG

www.eam-akademie.com

Seite 23 von 24