Finds documents with both search terms in any word order, permitting "n" words as a maximum distance between them. Best choose between 15 and 30 (e.g. NEAR(recruit, professionals, 20)).
Finds documents with the search term in word versions or composites. The asterisk * marks whether you wish them BEFORE, BEHIND, or BEFORE and BEHIND the search term (e.g. lightweight*, *lightweight, *lightweight*).
Der vorliegende Beitrag beschreibt die Einführung einer Organisationeinheit für das Enterprise Architecture Management in einem deutschen Logistikunternehmen. Die Anwendungslandschaft besteht aus wenigen Eigenentwicklungen sowie verschiedenen Standardsoftwaresystemen, von denen einige durch Konfiguration, andere aber durch Nicht-Standard-Erweiterungen angepasst werden. Die Einführung der Organisationseinheit erfolgt im Rahmen eines Action-Research-Projects, welches sich über drei Phasen gezogen hat. Ziel des Beitrags ist die Ableitung von Empfehlungen für ähnliche Vorhaben auf Basis der Erprobung von Konzepten aus der Literatur sowie den Erfahrungen aus ihrer praktischen Umsetzung.
Der Verlag bleibt in Hinblick auf geografische Zuordnungen und Gebietsbezeichnungen in veröffentlichten Karten und Institutsadressen neutral.
1 Motivation und Hintergrund
Enterprise Systems (ES) unterstützen betriebliche Prozesse in einem Unternehmen – auch über Funktionsgrenzen hinweg (Xu 2011). Einführung und Management eines ES werden bereits seit einiger Zeit untersucht, sind aber immer noch mit Herausforderungen verbunden (Strong und Volkoff 2004; Soja und Paliwoda-Pȩkosz 2009). Insbesondere, wenn die Anwendungslandschaft aus vielen Anwendungssystemen und Schnittstellen zwischen diesen besteht, bietet sich ein strukturiertes Vorgehen wie Enterprise Architecture Management (EAM) an. Mit etablierten EAM-Methoden und Werkzeugen kann eine ganzheitliche Sicht auf die Fachseite erstellt und damit eine Anwendungslandschaft mit Standardsoftware und Eigenentwicklungen abgeleitet werden.
Für die Einführung einer EAM-Organisation gibt es in der Literatur allgemeine Hinweise – bspw. in TOGAF (The Open Group 2022a). Konkrete Handlungsanweisungen für eine solche Veränderung unter Berücksichtigung organisationaler Spezifika gibt es selten. Change Management bietet konkrete Vorgehen (Kotter 2012; Cawsey et al. 2016), jedoch werden spezifische Aspekte des Managements von ES oder EAM nicht berücksichtigt. Spezielle Einschränkungen, wie zum Beispiel mangelnde Einbindung der Fachseite oder fehlende Governance bleiben außen vor (Adikpe et al. 2024).
Advertisement
Der vorliegende Beitrag beschreibt die Einführung einer Organisationseinheit für das Management von ES in einem Unternehmen (Geschäftsfeld in einem Konzern). Dessen Anwendungslandschaft ist geprägt durch Standardsoftwaresysteme und Eigenentwicklungen. Der Grad der Anpassung der Standardsoftware variiert zwischen Konfiguration (Customizing) und Individualisierung durch Erweiterungen. Erhöht wird die Komplexität der Anwendungslandschaft durch Schnittstellen zwischen Systemen.
Ziel des Beitrags ist die Dokumentation der Erfahrungen, damit ähnlich gelagerte Vorhaben in anderen Unternehmen davon profitieren können. Es werden Empfehlungen aus der Literatur und eigene Maßnahmen umgesetzt und deren Erfolg evaluiert. Zunächst erfolgt ein kurzer Abriss über den aktuellen Stand der Forschung in Abschn. 2, gefolgt von einer Einführung in die hier gewählte Forschungsmethode, Action Research, in Abschn. 3. Die Situation zu Beginn des Vorhabens wird in Abschn. 4 beschrieben, gefolgt von der Dokumentation der Durchführung in Abschn. 5. Die Struktur in diesem Abschnitt ist dabei so gewählt, dass die Motivation für einzelne Maßnahmen erkennbar ist und so auf andere Kontexte übertragen werden kann. Der Beitrag schließt mit einer Reflektion der Ergebnisse (Abschn. 6) und einer zusammenfassenden Darstellung abgeleiteter Handlungsempfehlungen in Abschn. 7.
2 Aktueller Stand der Forschung
EAM-Publikationen konzentrieren sich meist auf die Visualisierung von Architekturen sowie Frameworks (dt. Rahmenwerke), wie z. B. ArchiMate (Wierda 2021) oder The Open Group Architecture Framework (TOGAF 10) (The Open Group 2022b). Zur Gewährleistung einer ganzheitlichen Sicht wird für das EAM ein Top-Down-Ansatz vorgeschlagen (Op’t Land et al. 2008; Lankhorst et al. 2017). Ein solcher Top-down-Ansatz wird in der Literatur jedoch seit einiger Zeit kritisch diskutiert, da er zu sehr auf Dokumente und Vorgaben fokussiert statt (ggf. kurzfristig) konkrete Probleme zu lösen (Bente et al. 2012; Wierda 2015; Jung 2019). Als Ursachen werden bspw. genannt: Vielzahl verschiedener Visualisierungsarten (Kotusev 2017), eine ungenügende organisatorische Verankerung im Unternehmen (Lange et al. 2016), fehlende Unterstützung seitens des Managements (Olsen 2017) oder mangelhafte Kommunikation (Banaeianjahromi und Smolander 2017).
Anstatt einer auf langfristige Planung ausgerichteten Organisation, schlägt Wierda (2015) ein Vorgehen ähnlich dem eines Schachspielers vor. Er lässt zwar langfristige Ziele zu, empfiehlt jedoch Architekturmaßnahmen regelmäßig an neue Gegebenheiten anzupassen. Vor einem ähnlichen Hintergrund stellen Bente et al. (2012) einen EAM-Ansatz vor, der Elemente u. a. aus dem Lean Management und agiler Methoden wiederverwendet. Greefhorst und Proper (2011) schlagen mehrere Prinzipien für die Gestaltung von Enterprise Architecture (EA) vor. Hanschke (2012) stellt einen Governance artigen Ansatz für EAM vor, betont dabei auch Aspekte, die für ein kollaborativ aufgestelltes EAM notwendig sind. Ähnliche Hinweise findet man in Burrows. Er adaptiert Prinzipien aus dem agilen Umfeld und dem Lean Management, um die Arbeit an den Bedürfnissen der Nutzer von IT auszurichten (Burrows 2019). Whittle und Myrick (2005) definieren ein Team ausschließlich für Business Architecture, für die Zusammenarbeit mit Stakeholdern. Kuehn (2023) widmet sich in drei Kapiteln explizit der Interaktion eines Business-Architecture-Teams. Dabei behandelt sie auch die Einordnung des Architektur-Teams in die Gesamtorganisation und mögliche Zusammenarbeitsmodelle.
Advertisement
Es gibt derzeit keine umfangreiche Handlungsanweisung für die EAM-Einführung, es lässt sich jedoch ein Trend zu einer kollaborativen Arbeitsweise erkennen. Auch Methoden aus dem Change Management können für Veränderungen an ES und für EAM adaptiert werden. Dies erfolgt analog der Einführung einer Organisationseinheit, welche mit einer klaren Vision frühzeitig erste Erfolge liefert (Kotter 2012; Cawsey et al. 2016).
3 Forschungsmethode
Die Durchführung des Forschungsprojekts erfolgt gemäß der Methode Action Research. Sie kann angewendet werden, wenn ein Forscher die Anwendung von Theorien mit Praktikern untersuchen möchte (Baskerville und Wood-Harper 1998; Avison et al. 1999). Action Research unterstützt die Durchführung von Änderungen und die Reflektion von deren Auswirkungen (Greenwood 2018). Es wird ein iterativer, reflektierender Prozess umgesetzt (Baskerville und Wood-Harper 1998).
Ein Forscher übernimmt im vorliegenden Projekt gemäß (Baskerville und Wood-Harper 1998) sowie (Greenwood 2018) die beratende Rolle eines Experten. Er unterstützt bei der Formulierung des Ziels und von Maßnahmen für die nächste Veränderung. Durchgeführt werden die Änderungen vom Chefarchitekten des Logistikunternehmens, der als Praktiker direkt in den Untersuchungsgegenstand eingebunden ist. Er setzt die Maßnahmen um und reflektiert anschließend den Erfolg mit dem Forschenden. Der Chief Information Officer (CIO) ist als Sponsor unmittelbar am Erfolg der Einführung einer EAM-Organisation interessiert. In seinem Verantwortungsbereich liegen alle ES.
Das Vorhaben ist vom CIO initiiert, so dass es gemäß Avison et al. (2001) als vom Kunden dominiert angesehen werden kann (client dominated). Es werden keine formalen Kontrollstrukturen festgelegt oder schriftlich dokumentiert, so dass die Kontrolle informal gestaltet ist (vgl. hierzu auch (Avison et al. 2001)). Die finale Lösung ist zu Beginn des Projekts nicht klar definiert und auch die Reaktion der Beteiligten nicht absehbar. Die Planung und die Evaluierung werden vom Chefarchitekten im Austausch mit Forscher und CIO übernommen. Jede Phase beginnt mit einer Diagnose der aktuellen Situation (diagnostic stage in (Baskerville 1999)). Die Akzeptanz und der Mehrwert des EAM werden evaluiert und der Erfolg der vorangegangenen Änderungsmaßnahmen besprochen. Dies hat sich retrospektiv als sehr wertvoll herausgestellt, da die meisten Änderungen in einem sozialen System stattfinden. Die Änderungen im sozialen System werden im Rahmen der therapeutischen Phase weitgehend vom Chefarchitekten mit Unterstützung des CIO durchgeführt. Der Forscher ist im Rahmen der begleitenden Beobachtung (vgl. hierzu (Hult und Lennung 1980)) beratend tätig, indem er die Anwendung neuer Ansätze entwirft und die Evaluierung der Ergebnisse moderiert.
Mit Action Research werden mehrere Ziele verbunden: Der Forscher soll Vorschläge aus der Literatur einbringen und bei der Evaluation der Ergebnisse unterstützen. Gleichzeitig stellt er sicher, dass die Erfahrungen angemessen dokumentiert werden und auf andere Kontexte übertragen werden können. Praktiker können bei ähnlichen Vorhaben von bestätigten Annahmen und Erfolgsfaktoren profitieren. Die Einführung erstreckte sich über einen Zeitraum von 18 Monaten ab Ende 2021.
4 Ausgangssituation
Das Unternehmen deckt ein Geschäftsfeld in einem Konzern ab und gliederte sich in Geschäftsbereiche, welche Überlappungen bei Zuständigkeiten und Leistungen aufweisen. Zwischen der Fachseite in den Geschäftsbereichen und der IT-Abteilung besteht eine strikte organisatorische Trennung. Die IT agiert als eine zentral arbeitende Organisation für Wartung und Weiterentwicklung von ES. Anforderungen werden bei der zentralen IT gesammelt, die wiederum die Anforderungen aufnimmt und deren Umsetzung plant (inkl. dem Zuweisen von Ressourcen). Die fachliche Verantwortung verbleibt innerhalb der Geschäftsbereiche und außerhalb der IT.
Analog zum Product Owner (PO) aus agilen Methoden agieren sog. Proxy PO (PPO) als Schnittstelle zwischen Fachseite und IT. Sie sind in der IT angesiedelt und können aufgrund der fehlenden fachlichen Verantwortlichkeiten, die Anforderungen nur aufnehmen und an die IT weiterleiten. Priorisieren oder fachlich detaillieren konnten sie diese nicht. Aufgrund der Trennung von Business (Anforderungsmanagement) und IT (technische Umsetzung und IT-Ressourcenmanagement) zeigen sich deutliche Hemmnisse beim Management der ES, bspw.:
Verzögerungen bei der Umsetzung (mehrere Monate)
Verzögerte Weiterleitung fachlicher Änderungen
Priorisierung anhand Verfügbarkeit von IT-Ressourcen statt Fachlichkeit
Fehlende Abstimmung bzgl. Umsetzungsfortschritt
Als Folge ergibt sich eine Atmosphäre, in der sich die Geschäftsbereiche von der IT blockiert und ignoriert fühlen, die IT wiederum missverstanden.
Vor diesem Hintergrund erfolgt eine Dezentralisierung der IT (Allweyer 2020) in Produktlinien (PL), welche die Wertschöpfung für ein Produkt abdecken: Leasing & Fuhrparkmanagement, Mobility Services (bspw. Leihe von Mobilitätsmitteln für den Individualverkehr im Privat- und Geschäftskundenbereich) und digitale Mobilitätslösungen (bspw. Mobilitätsbudget zur flexiblen Kombination verschiedener Verkehrsangebote). Jede PL hat dedizierte IT-Ressourcen, um deren Verfügbarkeit und eine fachliche Steuerung sicherzustellen. Dies ermöglicht eine fachliche Priorisierung von Anforderungen (vgl. hierzu auch (Schwartz 2019), S. 17). Das Entwicklerteam einer PL erhält die technische Verantwortung für die ES, womit eine Autonomie bzgl. Architektur und Technologieentscheidungen einhergeht. IT-Ressourcen werden fachlich unter einem zentralen CIO zusammengeführt und es kommt Scrum als agile Methode zum Einsatz. Teilweise betreiben PL Outsourcing von Entwicklung und Betrieb von ES aufgrund fehlender interner IT-Ressourcen. Das Anforderungsmanagement verbleibt im Verantwortungsbereich der jeweiligen PL.
Zur Schaffung eines Gesamtblicks entsteht der Bedarf einer übergreifend wirkenden Architekturinstanz. Initial durch einen externen Berater fachlich konzipiert, wird die Aufgabe an den neu eingestellten Chefarchitekten übergeben. Die Ausgangslage aus Sicht des Chefarchitekten lässt sich wie folgt zusammenfassen:
Fragmentierte Anwendungslandschaft
Hoher Aufwand durch Redundanzen bei vorhandenen ES
Einführung von EAM durch externen Berater ohne Vernetzung im Unternehmen
Projekte durch individuelle Interessen der PL getrieben
Kaum Wissenstransfer zwischen den Teams
Entscheidungen über die Weiterentwicklung der ES-Landschaft nicht abgestimmt
5 Einführung der EAM-Organisation
Die Einführung der Architektur-Disziplin lässt sich dem hier vorliegenden Aufsatz ex post in vier aufeinander aufbauenden Phasen zusammenfassen (vgl. Abb. 1). Die vierte Phase ist nur angedeutet, da das Projekt aufgrund eines Wechsels des Praktikers in eine neue Rolle im Konzern nicht weiter begleitet werden konnte.
Die durch den externen Berater nicht aufgebaute Vernetzung stellt ein Problem dar, da Kommunikation für Architekturarbeit notwendig ist (Lange et al. 2016; Banaeianjahromi and Smolander 2017; Kurnia et al. 2020; Brée and Karger 2022). Überdies muss der Mehrwert von EAM vermittelt werden (Ajer and Olsen 2018; Guo et al. 2019). Funktionierende Kommunikation und ein klarer Nutzen sind wichtiger als Artefakte und Methoden (Lange et al. 2016). Lange et al. (2016) sowie Hohpe (2020) empfehlen sogar, dass Architekten explizit in Projekten mitarbeiten sollten.
Somit werden folgende Ziele gesetzt:
Aufbau von Kommunikationswegen für EA zu Projekten
Schaffen von Verständnis in den PL für Mehrwert der EA
Zur Feststellung der Zielerreichung wird beobachtet, ob das Unterstützungsangebot aktiv angefragt wird. Auch wird als positiver Indikator gewertet, wenn gemeinsame Termine wahrgenommen oder durch die PL proaktiv geplant werden.
5.1.2 Maßnahmen
Die Umsetzung von Maßnahmen konzentriert sich zu Beginn auf ausgewählte Entwicklungsprojekte, da die Mitarbeit von Architekten bisher nicht etabliert ist.
Maßnahme A: Projektunterstützung
Zu Beginn steht der Aufbau einer Arbeitsbeziehung zu Projektmanagement und PO, um die Ziele, Bedarfe und Probleme der PL zu verstehen und mit geeigneten Methoden zu unterstützen. Die Zusammenarbeit erfolgt durch die aktive oder teils auch moderierende Teilnahme des Architekten bei Regelterminen zur Priorisierung und Planung von fachlichen Anforderungen sowie der Entwicklung von Lösungskonzepten. Hierbei führt der Architekt auch das Konzept der Fachdomänen für die Bündelung fachlich zusammengehöriger Anforderungen ein. Sie werden in Workshops durch den Architekten mit den Teams und POs mittels der Methode des Event Storming aus dem Domain-driven Design entwickelt. Fachdomänen und deren Beziehungen werden kollaborativ dokumentiert und gepflegt. Genutzt werden sie für die Einordnung von Anforderungen, wodurch eine fachliche Bündelung frühzeitig erfolgt und als Grundlage für die Planung verwendet wird. Zudem ist eine tiefere fachliche Durchdringung aufgrund des Diskurses während der Zuordnung zu beobachten.
Maßnahme B: Architekturberatung
Die Unterstützung beginnt mit der Begleitung der Entwicklerteams über mehrere Sprints und einem Aufbau des Verständnisses bzgl. der eingesetzten Vorgehensmodelle, bestehender Herausforderungen und Probleme. Nach einer Bestandsaufnahme werden durch die Architektur drei thematische Schwerpunkte für die Beratungsleistung gewählt:
1.
Bewerten von Lösungsoptionen bei der Weiterentwicklung von ES
2.
Dokumentieren von Architekturentscheidungen
3.
Beschreiben einer Lösungsarchitektur
Mit der Einführung standardisierter Qualitätsattribute (auf Grundlage der ISO 25010) wird der Bedarf der PL zur Schaffung vergleichbarer Kriterien für die Bewertung von Lösungsoptionen erfüllt. Es wird auch dem bisherigen Problem entgegengewirkt, dass Betrachtungen meist anhand singulärer Aspekte auf technologischer oder operativer Ebene erfolgen. Der Projektleitung liegen damit für die Bewertung von Lösungsoptionen standardisierte und objektiv vergleichbare sowie fachlich bewertbare Informationen vor. Auf Basis dieser Empfehlungen können Verantwortliche die Auswirkungen auf den Geschäftsnutzen eruieren und eine fundierte Entscheidung fällen.
Solche Entscheidungen müssen zusammen mit den Anforderungen und zu Grunde liegenden Annahmen dokumentiert werden (Hohpe 2020). Hierfür wird eine Struktur definiert, die ausgerichtet ist an der Form der Architecture Decision Records (ADRs). Bei diesem Ansatz liegt der Fokus auf der Entscheidung und den zugrundeliegenden Annahmen, was damit konkret die Bedürfnisse der Stakeholder adressiert (Buchgeher et al. 2023). Für die Dokumentation der Lösungsarchitektur wird das Arc42-Template (www.arc42.org) in vereinfachter Form eingeführt. Nach einer Abstimmung mit allen Teams und der bedarfsgerechten Verfeinerung der Vorlage ist die gemeinsame Vereinbarung getroffen, dass alle Projekte ihre Dokumentationen nach gleichem Schema durchführen. Das Arc42-Template fungiert als vollständiges Rahmenwerk und umfasst die folgenden Inhalte:
Systemkontext und relevante Umsysteme
Schnittstellen für die Integration mit Umsystemen
Relevante Qualitätsanforderungen
Fundamentale Architekturentscheidungen
Mit der vereinheitlichten Dokumentation sind mehrere Erwartungen verknüpft: Dokumentierte Entscheidungen können von weiteren Akteuren verwendet werden (bspw. IT-Sicherheit oder IT-Betrieb). Überdies kann das darin dokumentierte Wissen in zukünftigen Projekten genutzt werden.
Maßnahme C: Regelmeeting
Vom Architekten wird ein wöchentlicher, freiwilliger Regelaustausch zwischen den Teams organisiert und moderiert. Inhalte, gesammelt in einer offenen Themenliste, richten sich nach den Bedarfen und Vorschlägen der Entwickler. Am Ende eines Termins wird das Thema für den Folgetermin ausgewählt. Durch den Architekten wird der inhaltliche Fokus ergänzt um das Teilen von Erfahrungen aus dem Einsatz eingeführter Architekturmethoden. Explizit erwünscht und gefördert ist auch das Teilen missglückter Ansätze und aufgetretener Probleme.
5.1.3 Reflektion
Die Unterstützung durch den Architekten wird von zumindest einer PL regelmäßig aktiv angefragt, da der Mehrwert für die Projektleiter wahrnehmbar ist. Die Lösung(-soption)en werden angenommen und auch in den Anwendungssystemen umgesetzt. Insbesondere wird der Architekt vermehrt in sog. Refinement Meetings für die detaillierte Umsetzung der ES eingeladen. Vom PO und einzelnen Entwicklern wird eine positive Wahrnehmung signalisiert und es werden vereinzelt Vorgaben oder unternehmensweite Lösungen angefragt. Für zwei PL hat sich das Unterstützungsangebot als weniger relevant herausgestellt, da überwiegend Standardsoftware durch Konfiguration angepasst wird. Das Unterstützungsangebot der Architekten fokussiert hingegen auf Softwareentwicklung sowie Erweiterung von ES.
In der Zusammenarbeit ist deutlich geworden, dass die Kommunikation nur gut funktioniert, wenn der Architekt auf die spezifischen Anforderungen der jeweiligen Projekte eingeht und nicht auf architektonisch sauberen Lösungen beharrt. Wenn kein Mehrwert für das Projekt erkennbar ist, kann ein Beharren seitens des Architekten zu Widerständen führen.
Das eingeführte Regelmeeting findet statt und es werden aktuelle Themen aus den Projekten diskutiert. Die Initiative für Planung und Durchführung liegt am Ende der ersten Phase noch immer beim Architekten. Er plant die Termine, fordert aktiv Themen und lädt die Beteiligten ein.
Verbesserungsmaßnahmen
Folgende Aspekte fließen in anschließende Phasen ein:
Die Unterstützung der Projekte soll beibehalten und eine kontinuierliche Begleitung sichergestellt werden. Die ersten Erfolge sollen verstetigt und die verbleibenden Projekte für eine Zusammenarbeit gewonnen werden.
Für häufig auftretende Themen sollen einheitliche Architekturlösungen und eine methodische Unterstützung geschaffen werden.
Weiterhin soll ein gemeinsames Verständnis geschaffen werden, einheitliche Lösungsansätze zu nutzen.
5.2 Phase 2: Ableiten von Leitlinien
5.2.1 Problemstellung und Zielsetzung
Nach ersten Erfolgen in der Projekt-Unterstützung durch den Architekten gibt es immer noch fehlende Kommunikationsbeziehungen (bspw. einzelne Projekte haben das Angebot des Architekten nicht aufgenommen). Auch gibt es kein einheitliches Vorgehen bei der Architektur oder gemeinsame Standards.
Lücken in den Kommunikationsbeziehungen sollen geschlossen werden, um ein übergreifendes Vorgehen zu ermöglichen. Dies ist auch motiviert durch Ansyori et al. (2018), die eine interne Vernetzung von Architekten sowie eine ausgeprägte Architekturkompetenz (Operational Excellence) als kritische Erfolgsfaktoren für die Umsetzung von EAM in Organisationen identifiziert haben. Daraus ergibt sich folgende Hypothese zur Ableitung von Leitlinien: Aus realistischen Projektszenarien abgeleitete Standards sind überzeugende Hilfsmittel zur Gestaltung gemeinsamer Leitlinien und ein Einsatz dieser Leitlinien auf freiwilliger Basis fördert deren Akzeptanz anhand konkreten Nutzens.
Kommunikationswege werden im Rahmen der abschließenden Evaluierung als unternehmensweit stabil erachtet, wenn der Rat oder die Unterstützung durch die Architektur von allen Projekten angefragt werden bzw. die Architektur einbezogen ist in die Planung von Weiterentwicklungen. Eine Akzeptanz von Leitlinien wird daran festgemacht, dass bei abweichendem Vorgehen eine dokumentierte schlüssige Begründung durch das Projekt erfolgt ist.
5.2.2 Maßnahmen
Maßnahme A: Lückenschluss
Die bisherigen Initiativen der Architektur können Bedarfe von Projekten mit Eigenentwicklung erfolgreich abdecken. Geringere Mehrwerte zeigen sich für die Beschaffung von Standardlösungen und der Erweiterung von ES durch externe Dienstleister. Eine gezielte Begleitung solcher Projekte offenbart teilweise neue Ansatzpunkte der Unterstützungsleistung. Dazu gehören bspw.:
Treffen von Make-or-Buy-Entscheidungen
Definition von qualitativen und technischen Anforderungen an Lieferanten
Rahmenbedingungen zur technischen Integrierbarkeit in die Unternehmenslandschaft
Beratung bei querschnittlichen Konzepten, bspw. IT-Security, Datenschutz oder Monitoring.
Für alle Unterstützungsleistungen werden Methodik sowie Dokumentation abgestimmt und in einem zentralen Repository der Architektur in Form von Templates abgelegt. Die projektspezifischen Dokumentationen erfolgen dagegen weiterhin eigenverantwortlich innerhalb der Projekte. Auch in diesem Kontext muss der Architekt auf spezifische Anforderungen eingehen, wobei Auswahl, Beschaffung und Stilllegung einzelner Anwendungen im Vordergrund stehen (somit der gesamte Lebenszyklus von ES).
Maßnahme B: Bereitstellen von Leitlinien
In den Projekten sind einige gleichartige Anforderungen offensichtlich geworden, z. B. Architektur-Rahmenbedingungen für Ausschreibungen oder die Integration von Anwendungen. Für diese werden zusammen mit den Projekten Regeln entwickelt oder etablierte Lösungen abgestimmt:
Treffen von Entscheidungen bzgl. Reuse, Buy oder Make
Standardlösungen (bspw. Workflow-Plattform)
Integrationsmuster (bspw. nachrichten-, stream- oder dateibasiert)
Aus den unterschiedlichen Zielsetzungen der einzelnen Projekte ergibt sich eine Diversität an Regulierungsfeldern und auch eine inhaltliche Bandbreite an Leitlinien. Nicht alle Leitlinien sind für jedes Projekt gleichermaßen relevant. Abweichungen zu diesen Leitlinien werden dokumentiert und auf diese Weise transparent festgehalten.
5.2.3 Reflektion
Fehlende Kollaborationsbeziehungen können aufgebaut werden und eine steigende Nachfrage nach Architekten zeigt ein besseres Vertrauensverhältnis. Der konkrete Nutzen von frühzeitig eingeführten Leitlinien hat sich als wesentlicher Treiber bestätigt. Leitlinien schreiben keine Lösungen vor, sondern lassen ausreichend Freiheitsgrade. Dadurch haben sie nicht den Charakter einer genauen Arbeitsanweisung und deren Auswahl sowie Anpassung an Projektspezifika muss durch Architekten begleitet werden. Aus dem Erfolg der Maßnahme ergibt sich folglich eine Auslastung bei der Architektur jenseits der verfügbaren Kapazität. Dies kann nur bedingt durch dokumentierte Leitlinien kompensiert werden.
Die aus Projektszenarien und Bedarfen abgeleiteten Leitlinien werden von den Projekten akzeptiert, jedoch unterschiedlich priorisiert. Freiwilligkeit ermöglicht eine geringe Einstiegshürde für Leitlinien und deren Beachtung hängt hauptsächlich von der Akzeptanz durch die jeweiligen Projektleiter ab. Für eine gleichmäßige Einhaltung sollte ein höherer Grad an Verbindlichkeit durch eine übergeordnete Instanz (Management) geschaffen werden.
Verbesserungsmaßnahmen
Aus der Reflektion ergeben sich Verbesserungsmaßnahmen für die nächste Phase:
Verstetigen der projektspezifischen Unterstützung sowie Definition weiterer Leitlinien
Ausbau der Kapazitäten im Architekturteam für den Ausbau der Architekturarbeit
Identifikation akzeptierter Leitlinien, die als verpflichtend durch das Management kommuniziert werden können
5.3 Phase 3: Erfolge generieren
5.3.1 Problemstellung und Zielsetzung
Die Nachfrage nach Unterstützung bringt die bestehenden Architekturressourcen an ihre Kapazitätsgrenzen. Eine Verstetigung der projektspezifischen Unterstützung ist jedoch wichtig, um die Akzeptanz aufrechtzuerhalten und nachhaltig im Unternehmen zu verankern. Die auf Freiwilligkeit beruhende Einführung von Architektur-Leitlinien reduziert die Einstiegshürden, jedoch bleibt deren Akzeptanz weiterhin abhängig von den jeweiligen Projektleitern. Anforderungen aus der konzernweiten Ausrichtung des Anwendungslandschaft – adressiert an den CIO – schaffen einen zusätzlichen Bedarf an Steuerungselementen. Damit erhalten die unternehmensweiten Leitlinien auch auf Management-Ebene eine zunehmende Bedeutung.
Es werden Kapazitäten im Architekturteam und Architekturkompetenz in den Teams aufgebaut sowie Kanäle zur Wissensteilung zwischen Architekturschaffenden etabliert, um damit Architekturarbeit zu skalieren. Zur Erhöhung der Verbindlichkeit von Leitlinien, wird der Geltungsbereich angehoben auf strategisch architekturrelevante Handlungsfelder der PL. Diese Leitlinien liegen stärker im Fokus des Managements, sodass eine Unterstützung für eine verpflichtende Einführung angenommen wird. Zur Unterstützung des (oberen) Managements werden einheitliche Darstellungen benötigt, wie das konzernweit abgestimmte Domänenmodell mit Geschäftsfähigkeiten (engl. Business Capabilities). Solch eine Business Capability Map ist ein verbreitetes Werkzeug und stellt gemäß Pfannenstiel (2023) einen fachlich-funktionalen Ordnungsrahmen dar, der für die Gestaltung von ES verwendet werden kann. Leider ist die aktuelle Version des Domänenmodells aus dem klassischen Geschäftsmodell entstanden und deckt innovative Produkte des hier betrachteten Unternehmens nicht ab. Deswegen muss das existierende Domänenmodell ergänzt und modifiziert werden.
5.3.2 Maßnahmen
Maßnahme A: Architekturkompetenzen in der Fläche ausbauen
Eine projekt- und teamübergreifende Community als architekturfokussiertes Austauschformat wird eingeführt (genannt Community of Practice Architektur, CoPA). Damit entsteht ein virtuelles Team aus interessierten Projektmitarbeitern, welches Kapazitätsengpässe der derzeitigen Architekturschaffenden reduziert. Die Entscheidungshoheit über Lösungsoptionen verbleibt dabei weiterhin im gesamten Projekt-Team. Weiterhin werden Kompetenzen innerhalb der Teams verbreitet, was sich positiv auf die Gesamtreife der Architekturarbeit auswirkt. Zudem begegnet dieses Modell dem Risiko der Schaffung von Inselwissen.
Aus den bisherigen Erfahrungen der direkten Projektunterstützung und anhand von Governance-Anforderungen aus dem Konzern werden durch den Chefarchitekten und den CIO Bedarfe für Architekturfokusthemen abgeleitet. Diese Betrachtungen münden im gezielten Ausbau des Architektur-Kernteams (d. h. Vollzeit-Architekten, direkt dem CIO zugeordnet):
Systemarchitektur (funktionale und operative Anwendungslandschaft)
Datenarchitektur (Daten-Governance und Datenmanagement).
Maßnahme B: Übergreifende Leitlinien identifizieren und Verbindlichkeit schaffen
Es wird ein Austausch mit Technical Officers (TO) etabliert, da diese die IT-Unterstützung der strategischen Geschäftsziele innerhalb der PL sicherstellen. Die Ausrichtung auf strategisch relevante Themen erfolgt mittels folgender Vorgehensweise:
1.
Aufnehmen strategischer Bedarfe einer PL sowie relevanter Handlungsfelder
2.
Bestimmen der Reifegrade der Handlungsfelder (SOLL/IST-Abgleich)
3.
Aufzeigen von Entwicklungspotentialen und priorisieren der Handlungsfelder
4.
Ableiten des IT-Zielbildes und Schaffen eines Gesamtbildes über alle PL
5.
Identifizieren von Synergien und Festlegen gemeinsamer Maßnahmen
Beispielhaft genannt seien die beiden übergreifend priorisierten Handlungsfelder Datenmanagement und API-Management. Für beide Handlungsfelder können nach einer Evaluierungsphase die Bedarfe übergreifend mittels Standard-Lösungen aus dem Konzern bedient werden.
Der Architekt moderiert die Bestimmung des Zielbilds und die inhaltliche Gestaltung obliegt dem jeweiligen TO. Dadurch können objektiv die Bedarfe der PL offengelegt werden, was entscheidend dazu beiträgt, dass auch innerhalb der PL deren eigene Herausforderungen besser verstanden bzw. Potenziale erkannt werden können. Anhand bedarfsgetriebener und gehärteter Anforderungen entstehen Leitlinien, die den PL bei der Steuerung ihrer Ziel-Erreichung helfen und damit auch in ihrer Verbindlichkeit aus den PL heraus durch die TOs im IT-Management akzeptiert werden.
Maßnahme C: Management Support aufbauen
Das Domänenmodell des Konzerns bewegt sich auf hoher Abstraktionsebene und beschreibt die Geschäftsfähigkeiten der wichtigsten Geschäftsfelder. Auf Nischen spezialisierte Geschäftsfelder finden in diesem bisher keine Berücksichtigung. Es ist offen für inhaltliche Ergänzungen der einzelnen Geschäftsfelder, aber mit Vorgaben verbunden: Neben den marktüblichen Anforderungen an ein Domänenmodell, wie bspw. Eindeutigkeit und inhaltliche Überschneidungsfreiheit, müssen alle Ergänzungen unterhalb der zweiten Ebene eingeordnet und in der EAM-Software LeanIX dokumentiert werden.
Zunächst wird das Konzernmodell um Inhalte bereinigt, die keine Überschneidung mit dem Geschäftsmodell des Unternehmens aufweisen, wie bspw. der Ticketverkauf, die Planung und Disposition von Personaleinsätzen oder Energiewirtschaft. Beibehalten und mit Fachexperten abgestimmt werden Inhalte, die Übereinstimmung oder Ähnlichkeiten aufweisen (bspw. Management mobiler Assets) oder wenn eindeutig Lücken erkannt werden (bspw. Leasing oder Leihe von Mobilitätsmitteln).
Anschließend erfolgt die iterative Evaluation und Verfeinerung der Inhalte in Gesprächen mit Fachexperten. Externe Unterstützung erfolgt durch den Forschenden mittels inhaltlicher Moderation der Termine mit den Fachexperten sowie in Form von regelmäßigen Reviews. Als Ergebnis entsteht ein in Teilen vollständiges Domänenmodell über alle Produktlinien des Unternehmens unter Berücksichtigung der Sprache und Begrifflichkeiten der Fachbereiche. Unterstützt durch den CIO erfolgen auf Basis dieses gemeinsamen Bezugsrahmens aller Produktlinien gezielte strategische Betrachtungen der Anwendungslandschaft.
5.3.3 Reflektion
Die Maßnahmen haben teilweise zu den erhofften Effekten geführt, aber auch Einschränkungen aufgezeigt. Die beiden zusätzlich eingestellten Architekten stellen nach einer Einarbeitungsphase zusätzliche Kapazitäten für die direkte Projektunterstützung dar. Insbesondere mit dem Aufbau des virtuellen Teams, CoPA, ist eine direkte Kommunikation zwischen den Projekten zu beobachten – auch ohne aktives Mitwirken des Architekturteams. Gleichzeitig ist ein initial höherer Aufwand (bspw. Schulungen, Koordination der Austauschkanäle) seitens des Architekturteams entstanden.
Leitlinien als Basis für die einheitliche und projektübergreifende Lösungsfindung haben sich grundlegend als Blaupause für Standardprobleme etabliert, jedoch zwei Herausforderungen gezeigt. Viele Probleme in Projekten können nicht durch gemeinsame Leitlinien gelöst werden. Existierende Leitlinien müssen aufwändig an Projektspezifika angepasst werden (neue, relevante Leitlinien ergänzen; veraltete Leitlinien anpassen oder entfernen). Die Anwendung von Leitlinien erfordert Kenntnis der Architekturmethodik, weswegen Mitarbeitende in den Projekt-Teams gezielt geschult werden müssen.
Eine unternehmensweite Verbindlichkeit von Leitlinien ist auch am Ende der dritten Phase nur vereinzelt feststellbar. Zwar sind übergreifende Leitlinien für die Steuerung der Zielerreichung im Unternehmen gewünscht, allerdings können nur wenige Leitlinien verbindlich etabliert werden. Übergreifende Leitlinien sind i. d. R. wenig spezifisch und geben den Projekten damit eher eine Richtung vor. Details für die Lösung und deren Umsetzung müssen noch immer von den Projektteams erarbeitet werden.
Die Anpassung des konzernweiten Domänenmodells hat sich zeitlich über mehrere Monate gezogen. Da das Geschäftsmodell (individuelle Mobilität) stark vom klassischen Geschäftsmodell des Konzerns abweicht, mussten Anpassungen auch in der Terminologie vorgenommen werden (Zitat eines Fachexperten: „Das Ding spricht nicht mit mir!“). Das Verwalten von Fahrplänen ist bspw. nicht nötig, aber das individuelle Buchen und Freischalten eines Fahrzeugs. Die Einführung des angepassten Domänenmodells wird schließlich vom CIO gestützt und als planerische Basis für die Bündelung von Projektanforderungen etabliert. Vereinfacht wird die Einführung auch durch das frühzeitige Verwenden von Fachdomänen bereits in der ersten Phase.
6 Diskussion
6.1 Reflektion Projektergebnis
Das im vorliegenden Beitrag vorgestellte Vorgehen war mit deutlichen Aufwänden für das Architekturteam verbunden. Deswegen erstreckten sich die Phasen 1 und 2 über einen längeren Zeitraum als erwartet. Auch war das Vorgehen von Rückschlägen gezeichnet, wenn bspw. einzelne Projekte die Mitarbeitsangebote der Architektur nicht annehmen wollten. Durch den Auf- und Ausbau von Architekturkompetenz innerhalb der Projektteams wurde auch der personelle Ausbau des Architekturteams in den nachgefragten Themenfeldern vorangetrieben. Das Aufteilen der Architekturarbeit auf viele Ressourcen ermöglichte das Ausweiten der Architekturarbeit auf die Gesamtheit der Projekte. Allerdings entstand ein initialer Zusatzaufwand durch notwendige Anschubarbeiten seitens des Architektur-Teams.
Der Fokus auf Projekte limitierte allerdings den Blick auf allgemeine unternehmensweite Architektur-Themen und folglich auch auf allgemeingültige Architektur-Leitlinien. Als erfolgreich für die Akzeptanz von Leitlinien durch Projektverantwortliche zeigte sich das Vorgehen, Leitlinien aus realen Projektszenarien abzuleiten und zusammen mit Projektbeteiligten zu erarbeiten. Abstrakte Leitlinien wurden dagegen durch Projekte häufig abgelehnt (bspw. Leitlinien des Konzerns). Es zeigte sich erneut, wie bereits bei der Mitarbeit der Architektur in Projekten beobachtet, dass ohne Management-Unterstützung eine Verankerung der Architekturthemen häufig nur auf freiwilliger Basis möglich ist und damit eine geringe Verbindlichkeit aufweisen.
Möglicherweise sollte zunächst ein Top-down Kommittent durch den CIO und die Fachbereiche hergestellt werden und im Anschluss die Bedarfe aus den operativen Tätigkeitsfeldern Bottom-up gefüllt werden (bspw. in Projekten). Der aktive Widerstand einiger PL gegen die Mitarbeit von Architekten in Projekten hat in Phase 1 dazu beigetragen, dass die Architekturarbeit nur langsam vorankam. Dieser hat sich jedoch schrittweise mit vorzeigbaren Erfolgen in anderen Projekten aufgelöst. Wir erwarten mit einem derartigen Vorgehensmodell eine nachhaltige Entwicklung der Relevanz von Architektur in einer Organisation vom Helfer (Trusted Adviser) zum aktiv eingebundenen Mitgestalter.
Mehrere Monate nach Abschluss der dritten Phase wurde ein Interview mit dem Nachfolger des Chefarchitekten geführt. Dieser beschreibt die Mitarbeit der Architekten in Projekten der PL als etabliertes Vorgehen, wobei mittlerweile die System-Architektur für Lösungsfindung und Umsetzung der Zielarchitektur in die IT-Bereiche der PL integriert ist. Das architekturbasierte Management von ES wird in den folgenden Bereichen als Mehrwert eingeschätzt:
Bewertung von Lösungsoptionen und Nachvollziehbarkeit von Entscheidungen
Logische Strukturierung von Projekten und Vorhaben
Dokumentieren von Architektur-Änderungen
Beschreiben der Anwendungsarchitektur im Arc42-Format
Ein geringer Mehrwert beigemessen wird dagegen dem Einsatz des Domänenmodells. Eine Nutzung erfolgt nur vereinzelt und fallbezogen. Architektur-Themen im alltäglichen Projektgeschehen bewegen sich hauptsächlich im Bereich der Software- bzw. Technologiearchitektur. Zudem sind weite Teile des Konzern-Domänenmodells zur direkten Verwendung weiterhin fachlich ungeeignet und müssen bei Bedarf mit Aufwand erst in den Unternehmenskontext überführt werden.
Ein neu geschaffenes Austauschformat ist die „Architektur/CIO-Klausur“. Sie findet vierteljährlich statt, mit dem Teilnehmerkreis: CIO, EA und Systemarchitektur sowie themenspezifisch geladenen Gästen (z. B. Informationssicherheit). Inhaltlicher Fokus liegt auf der gemeinsamen mittel- und langfristigen Abstimmung und Planung laufender sowie strategisch relevanter Architektur-Themen.
6.2 Reflektion Forschungsmethode
Die Durchführung des Projekts hat sich über einen Zeitraum von 18 Monaten erstreckt. Für die einzelnen Phasen wurde vorab keine zeitliche Begrenzung festgelegt. Die Zusammenarbeit zwischen Forscher und Praktiker (Chefarchitekt) hat sich retrospektiv als erkenntnisreich erwiesen. Dabei muss man einige Randbedingungen beachten: Die Phasen hatten keine vorab definierte Dauer, sondern wurden unter Berücksichtigung der Auslastung des Praktikers durchgeführt. Zusätzlich ist seitens des Praktikers eine gewisse Disziplin notwendig, um den Fortschritt und den Erfolg der Maßnahmen zu dokumentieren und gemeinsam mit dem Forscher zu evaluieren. Zusätzlich muss die Vertraulichkeit von Informationen beachtet werden, was insbesondere für die Veröffentlichung eine Herausforderung darstellte. Aus diesem Grund wirkt die Beschreibung in dieser Publikation teilweise abstrakt, da auf die Nennung konkreter Produkte oder Namen verzichtet werden musste.
Die ursprüngliche Planung sah für das Forschungsprojekt vier Phasen vor. Nach Beendigung der dritten Phase hat der Praktiker den Unternehmensbereich gewechselt und das Projekt konnte in der vorliegenden Konfiguration nicht weitergeführt werden. Die gewonnenen Erkenntnisse können jedoch in die zukünftige Arbeit einfließen.
7 Zusammenfassung
Der vorliegende Beitrag dokumentiert die Einführung einer Organisationseinheit für das übergreifenden Management von ES in einem Unternehmen auf Basis von EAM. Die Durchführung des Projekts erfolgt mittels der Forschungsmethode Action Research, die einen strukturellen Rahmen für Planung, Umsetzung und Evaluierung von Änderungen in der Organisation bietet. Das Kernteam, bestehend aus einem Forschenden und dem Chefarchitekten als Praktiker, hat in mehreren Phasen auf Basis der jeweils aktuellen Situation Maßnahmen umgesetzt und diese anhand konkreter Ziele gemeinsam ausgewertet.
Aus den Projekterfahrungen lassen sich mehrere Empfehlungen für ähnlich gelagerte Vorhaben ableiten:
Die Unterstützung durch Architekten in Projekten fördert die Akzeptanz von Architekturarbeit, da der Nutzen unmittelbar sichtbar wird. Erfolge sollten frühzeitig im Unternehmen als positive Beispiele kommuniziert werden.
Der Nutzen von Architekturarbeit ist bei Eigenentwicklungen oder weiterentwickelten ES höher als beim Customizing einer Standardsoftware.
Architekturarbeit muss gleichzeitig top-down vom Management forciert werden, um auch projektübergreifend Nutzen zu erzielen. Das Ableiten gemeinsamer Standards aus einzelnen Projekten (bottom-up) hat sich im vorliegenden Fall als kaum durchführbar erwiesen.
Neben einem zentralen EA-Team sollte auch Architekturkompetenz in den Projektteams aufgebaut werden. Projektarchitekten vermitteln Wissen in die Projekte und können gleichzeitig beim Entwurf globaler Standards mitwirken.
Übergreifende Leitlinien können Architekturkompetenz in Projekten nicht ersetzen. Solche allgemeingültigen Leitlinien müssen i. d. R. an die spezifischen Projektbedürfnisse angepasst werden.
Einheitliche Vorlagen für die Dokumentation sollten frühzeitig eingeführt und erprobt werden, da sie für Projektarchitekten eine Empfehlung für relevante Inhalte darstellen.
Ein Domänenmodell wird als hilfreich erachtet, wenn es das Kerngeschäft in der Terminologie der Fachseite dokumentiert. Ein konzernweites Domänenmodell sollte nicht verpflichtend sein, wenn es dies nicht gewährleisten kann.
Es sollte ein Architekturboard als zentrales Gremium zur mandatierten Entscheidungsfindung übergreifender Architektur-Themen etabliert werden.
Open Access Dieser Artikel wird unter der Creative Commons Namensnennung 4.0 International Lizenz veröffentlicht, welche die Nutzung, Vervielfältigung, Bearbeitung, Verbreitung und Wiedergabe in jeglichem Medium und Format erlaubt, sofern Sie den/die ursprünglichen Autor(en) und die Quelle ordnungsgemäß nennen, einen Link zur Creative Commons Lizenz beifügen und angeben, ob Änderungen vorgenommen wurden.
Die in diesem Artikel enthaltenen Bilder und sonstiges Drittmaterial unterliegen ebenfalls der genannten Creative Commons Lizenz, sofern sich aus der Abbildungslegende nichts anderes ergibt. Sofern das betreffende Material nicht unter der genannten Creative Commons Lizenz steht und die betreffende Handlung nicht nach gesetzlichen Vorschriften erlaubt ist, ist für die oben aufgeführten Weiterverwendungen des Materials die Einwilligung des jeweiligen Rechteinhabers einzuholen.
Vorgehen bei der Einführung einer Organisation für das Management von Enterprise Systems
Action-Research-Projekt in einem deutschen Logistikunternehmen
Adikpe I, Garba A, Ali F (2024) The enterprise architecture (EA) practice—an analysis of EA models for different organisational contexts. Enterp Archit Pract J
Ajer AKS, Olsen DH (2018) Enterprise architecture challenges: a case study of three Norwegian public sectors. 26th European Conference on Information Systems: Beyond Digitization—Facets of Socio-Technical Change, ECIS 2018.MATH
Allweyer T (2020) IT-Management: Grundlagen und Perspektiven für den erfolgreichen Einsatz von IT im Unternehmen. BoD—Books on Demand, Norderstedt
Ansyori R, Qodarsih N, Soewito B (2018) A systematic literature review: critical success factors to implement enterprise architecture. Procedia Comput Sci 135:43–51. https://doi.org/10.1016/j.procs.2018.08.148CrossRef
Avison D, Lau F, Myers M, Nielsen PA (1999) Action research. Commun ACM 42:94–97CrossRef
Avison D, Baskerville R, Myers M (2001) Controlling action research projects. Inf Technol People 14:28–45CrossRef
Baskerville RL (1999) Investigating information systems with action research. Commun Ais 2:1–32MATH
Baskerville R, Wood-Harper AT (1998) Diversity in information systems action research methods. Eur J Inf Syst 7:90–107CrossRefMATH
Bente S, Bombosch U, Langade S (2012) Collaborative enterprise architecture: enriching EA with lean, agile and enterprise 2.0 practices. Morgan Kaufmann, AmsterdamCrossRefMATH
Buchgeher G, Schoberl S, Geist V et al (2023) Using architecture decision records in open source projects—an MSR study on github. IEEE Access 11:63725–63740. https://doi.org/10.1109/ACCESS.2023.3287654CrossRef
Burrows M (2019) Right to left: the digital leader’s guide to lean and agile. New Generation PublishingMATH
Cawsey TF, Deszca G, Ingols C (2016) Organiszational change: an action-oriented toolkit. SAGE
Greefhorst D, Proper E (2011) Architecture principles: the cornerstones of enterprise architecture. Springer, Berlin, HeidelbergCrossRefMATH
Greenwood DJ (2018) Action research. In: Ciesielska M, Jemielniak D (Hrsg) Qualitative methodologies in organization studies. Springer, S 75–98CrossRefMATH
Guo H, Li J, Gao S (2019) Understanding challenges of applying enterprise architecture in public sectors: a technology acceptance perspective. Proceedings—IEEE International Enterprise Distributed Object Computing Workshop, EDOCW 2019, S 38–43 https://doi.org/10.1109/EDOCW.2019.00020CrossRefMATH
Hanschke I (2012) Enterprise Architecture Management – einfach und effektiv: Ein praktischer Leitfaden für die Einführung von EAM. Hanser, MünchenMATH
Hohpe G (2020) 37 things one architect knows about IT transformation A chief architect’s journey. Leanpub
Hult M, Lennung S‑Å (1980) Towards a definition of action research: a note and bibliography. J Management Studies 17:241–250CrossRefMATH
Jung J (2019) Purpose of enterprise architecture management: Investigating tangible benefits in the German logistics industry. In: Proceedings—IEEE International Enterprise Distributed Object Computing Workshop, EDOCW
Kotter JP (2012) Leading change. Harvard Business Review Press
Kuehn W (2023) Strategy to reality: making the impossible possible for business architects, change makers and strategy execution leaders. Morgan James, New YorkMATH
Kurnia S, Kotusev S, Dilnutt R et al (2020) Artifacts, activities, benefits and blockers: exploring enterprise architecture practice in depth. Proc Annu Hawaii Int Conf Syst Sci 2020:5583–5592. https://doi.org/10.24251/hicss.2020.687CrossRefMATH
Lange M, Mendling J, Recker J (2016) An empirical analysis of the factors and measures of enterprise architecture management success. Eur J Inf Syst 25:411–431. https://doi.org/10.1057/ejis.2014.39CrossRefMATH
Lankhorst MM, Iacob M‑E, Jonkers H (2017) State of the art. In: (Hrsg) Enterprise architecture at work, 4. Aufl. Springer, Berlin, HeidelbergCrossRef
Op’t Land M, Proper E, Waage M et al (2008) Enterprise architecture: creating value by informed governance. Springer
Pfannenstiel W (2023) Business Capabilities: Geschäftsfähigkeiten als effektives Werkzeug für die Gestaltung von Unternehmens- und IT-Architekturen. dpunkt.MATH
Schwartz M (2019) War and Peace and IT: business leadership, technology, and success in the digital age. IT Revolution, Portland (USA)MATH
