Was ist ein Enterprise Architecture Team?
Was ist ein Enterprise Architecture Team?
Wie ist ein Enterprise-Architecture-Team aufgebaut?
- Auswirkungen der Organisationsgröße auf die EA-Teamstruktur
- Auswirkungen des Enterprise Architecture Use Case auf die EA-Teamstruktur
- Für wen arbeitet ein Enterprise-Architecture-Team?
- Erfolgreicher Aufbau eines Enterprise Architecture Teams
Was ist die optimale Größe für ein EA-Team?
Wie arbeitet das EA-Team mit dem Architecture Review Board zusammen?
Was ist die Enterprise Architecture-Fähigkeit?
Welche Rollen benötigt ein EA-Team?
Welche Fähigkeiten benötigt ein EA-Team?
Warum benötigt Ihr EA-Team ein optimiertes Enterprise-Architektur-Framework?
Was ist ein Enterprise Architecture Team?
Was ist ein Enterprise-Architecture-Team? Ein EA-Team ist dafür verantwortlich, effektive Veränderungen zu begleiten. Dies geschieht durch die Entwicklung eines Unternehmensarchitektur das die organisatorischen Verbesserungen zeigt, die Ihre Stakeholder wünschen.
Umfragen der Association of Enterprise Architects, des Corporate Executive Board, von Forrester und anderen haben durchweg ein breites Spektrum positiver und negativer Eindrücke ergeben.
Es gibt Beispiele für starke EA-Teams mit langer Lebensdauer und für Teams mit Zyklen kontinuierlicher Initiierung und Schließung. Die Kernaussage ist, dass jedes erfolgreiche EA-Team auf den Kontext seiner Organisation ausgerichtet ist und Anwendungsfall für Unternehmensarchitektur.
Merkmale eines starken EA-Teams
Erfolgreiche EA-Teams sind engagiert und unterstützen effektive Veränderungen. Die effektivsten EA-Teams verfügen über:
- konzentrieren sich auf ihre Anwendungsfall für Unternehmensarchitektur
- Fachpersonal für mehrere Architekturdomänen
- effektive Zusammenarbeit mit den Entscheidungsträgern Ihrer Organisation.
- effektives Engagement bei Ihrer Implementierung und agile Entwicklungsteams
- ein optimiertes Enterprise-Architektur-Framework
- eine dynamische Architekturprüfungsausschuss
- Prozesse zu nutzen
- dynamisches Arbeitsmanagement und Bewusstsein für wichtige Geschäftszyklen
- die Fähigkeit, sich kontinuierlich zu verbessern
- die richtigen Fähigkeiten
Die Leitfaden für Enterprise-Architektur-Teams geht detailliert darauf ein, wie eine EA-Fähigkeit aufgebaut und entwickelt wird.
Die Referenzarchitektur für Unternehmensarchitekturfähigkeiten bietet eine umfassende Referenzarchitektur für eine Unternehmensarchitekturfähigkeit.
Gemeinsame Merkmale von EA-Teams mit Schwierigkeiten
EA-Teams in Schwierigkeiten sind ganz anders. Sie neigen zu einem Zyklus aus Neustart, Herunterfahren und Neustart. EA-Teams in Schwierigkeiten erleben häufig:
- sind nicht auf die Entscheidungs- und Umsetzungsprozesse ihrer Organisation abgestimmt
- Erscheinen nach Portfolio- und Projektentscheidung
- versuchen, Entscheidungen zu treffen und Prioritäten zu setzen
- sind stark auf theoretische IT-orientierte Fragestellungen fokussiert
- habe kein optimiertes Enterprise-Architektur-Framework
- konzentrieren Sie sich auf Implementierungsdetails
- Verwenden Sie nicht:
- haben das Team ohne Bezug auf ihre Anwendungsfall für Unternehmensarchitektur
Wie ist ein Enterprise-Architecture-Team aufgebaut?
Die Erfahrung zeigt, dass es nicht das eine richtige EA-Team gibt. Es gibt keine optimale Struktur. Erfolgreiche Teams passen zu ihrer Organisation und sind so strukturiert, dass sie ihre Anwendungsfall für Unternehmensarchitektur.
Die Struktur Ihres EA-Teams basiert auf:
- Organisationsskala
- Anwendungsfälle für Unternehmensarchitektur
Auswirkungen der Organisationsgröße auf die EA-Teamstruktur
Ein globaler Fortune 50-Riese und ein spezialisierter Unternehmensdienstleister konkurrieren möglicherweise auf dem Spezialistenmarkt. Sie unterscheiden sich jedoch stark in ihrer Größe und vor allem in ihrer Struktur.
Größere, spezialisiertere Organisationen erfordern spezialisiertere EA-Teamstrukturen.
Das Grundmodell eines zentralisierten EA-Teams versagt in komplexen digitalen Unternehmen. Verschiedene Teile einer komplexen digitalen Organisation können unterschiedliche Anwendungsfälle für Unternehmensarchitektur.
Auswirkungen des Enterprise Architecture Use Case auf die EA-Teamstruktur
In verschiedenen Organisationen wird von EA-Teams erwartet, dass sie unterschiedliche Anwendungsfälle unterstützen. Es gibt vier Standardanwendungsfälle:
- Unternehmensarchitektur zur Unterstützung der Strategie
- Unternehmensarchitektur zur Unterstützung des Portfolios
- Unternehmensarchitektur zur Unterstützung von Projekten
- Unternehmensarchitektur zur Unterstützung der Lösungsbereitstellung
Jeder Anwendungsfall erfordert eine andere Struktur.
Für wen arbeitet ein Enterprise-Architecture-Team?
Die meisten EA-Teams sind in der IT-Organisation angesiedelt. Die richtige Berichtsstruktur wird jedoch vom Fokus des EA-Teams bestimmt.
Als Ausgangspunkt dient die Leitfaden identifiziert:
- Funktionszentriert
- IT-zentriert
- Strategiezentriert
Funktionszentriert EA-Teams berichten an verschiedene Geschäftsfunktionen. Dies erfordert häufig Matrixberichte mit einer Berichtsstruktur mit durchgezogenen und gepunkteten Linien.
Die 'durchgezogene Linie' lässt sich an den Hauptkonsumenten von Enterprise-Architektur-Services ausrichten. Die Hauptkonsumenten werden dynamisch und treibend sein, wie beispielsweise bei digitalen Produkten.
Im Extremfall wird das Betriebsmodell des Architekturteams koordiniert oder repliziert. Dabei gibt es mehrere Architekturteams, die auf unterschiedliche Funktionen ausgerichtet sind. Diese Struktur ist bei starker regionaler Trennung üblich.
IT-zentriert EA-Teams berichten an die IT-Abteilung. Die Berichte gehen direkt an den CIO oder CTO. Die Leitfaden Abbildung 7 auf Seite 34 zeigt einige IT-zentrierte Berichtsstrukturen.
Strategiezentriert EA-Teams berichten an den Geschäftsbetrieb. Wenn sie eine Strategiefunktion im Unternehmen unterstützen, konzentrieren sie sich auf den Strategie- oder Portfolio-Anwendungsfall. Wenn sie eine Betriebsfunktion unterstützen, konzentrieren sie sich höchstwahrscheinlich auf den Portfolio-Anwendungsfall.
Erfolgreicher Aufbau eines Enterprise Architecture Teams
Es gibt vier Ansätze für die Gestaltung der Struktur Ihres Enterprise-Architektur-Teams. Diese Ansätze basieren auf einem Standard Referenzarchitektur für Betriebsmodelle. Diese Betriebsmodelle sind ein Ausgangspunkt für die Gestaltung der Struktur Ihres EA-Teams:
- Konsolidiertes Enterprise-Architektur-Team
- Repliziertes Enterprise-Architektur-Team
- Kollaboratives Enterprise-Architektur-Team
- Verteilte Enterprise-Architektur-Teams
Die Auswahl des besten Betriebsmodells für ein EA-Team wird von einer Frage bestimmt:
In welchem Umfang muss Ihre Organisation die Entwicklung ihrer Unternehmensarchitektur partitionieren?
Eine Partitionierung ist angezeigt, wenn:
-
- Es gibt ein koordiniertes oder diversifiziertes Geschäftsmodell
- Es gibt ein hohes Maß an regionaler Kontrolle und Operationen
Konsolidiertes Enterprise-Architektur-Team
Konsolidierung ist “standardisierte, integrierte Prozesse”
Einzelne EA-Teams arbeiten mit einer gemeinsamen Methode, einem EA-Repository und einem optimiertes EA-Framework
Stellt sicher, dass die gemeinsame Geschäftsstrategie, der aktuelle Status, die Prioritäten und die Interessengruppen berücksichtigt werden.
Konsolidierte EA-Teams bieten einer einzigen Gruppe von Stakeholdern gemeinsame Ansätze. Es wird eine zentrale Aufsicht für konsistente Methoden, konsistente Entscheidungen und ein wiederverwendbares EA-Repository geben.
Konsolidierte Enterprise Architecture Teams werden übermäßig eingesetzt. Wir sehen sie sogar dann, wenn das Geschäftsbetriebsmodell und die Struktur nicht vereinheitlicht oder repliziert sind.
Wenn keine starke Übereinstimmung zwischen dem Betriebsmodell des EA-Teams und dem Geschäftsbetriebsmodell besteht, arbeitet das EA-Team häufig als Enterprise Architecture-as-a-Service.
Bei der Bereitstellung von Enterprise Architecture-as-a-Service reichen externe Teams in der Organisation eine Anfrage ein, die das EA-Team bearbeiten soll.
Obwohl Enterprise Architecture-as-a-Service häufig als Start-up-Modell verwendet wird, ist es für ein konsolidiertes EA-Team sehr schwierig, Prioritäten und Ziele zu verschieben. Eine fehlende Ausrichtung auf Ziel und Priorität führt zum Scheitern und Neustart.
Repliziertes Enterprise-Architektur-Team
Replikation ist “standardisierte Unabhängigkeit”
Separate EA-Teams arbeiten mit einer gemeinsamen Methode, optimiertes EA-Framework, und separates EA-Repository.
Stellt sicher, dass eine gemeinsame Geschäftsstrategie mit unterschiedlichem aktuellen Status, unterschiedlichen Prioritäten und unterschiedlichen Interessengruppen umgesetzt wird.
Replizierte EA-Teams bieten gemeinsame Ansätze für unterschiedliche Stakeholdergruppen. Es gibt eine zentrale Aufsicht für einheitliche Methoden, einheitliche Entscheidungen und ein wiederverwendbares EA-Repository.
Replizierte Enterprise Architecture Teams werden nicht ausreichend genutzt. Wir sehen sie am häufigsten in Organisationen mit starker regionaler Entscheidungsfindung und bei der Integration von Akquisitionen. Sie gelten nicht automatisch für replizierte Geschäftsmodelle. Replizierte Geschäftseinheiten benötigen kein eigenes EA-Team.
Kollaborative Enterprise-Architektur-Teams
Kollaborativ ist “nahtloser Zugriff auf gemeinsam genutzte Daten”
Separate EA-Teams arbeiten mit unterschiedlichen Methoden, aber einem gemeinsamen EA-Repository. Separate EA-Teams hätten wahrscheinlich unterschiedliche Architekturdomäne Fokus und können unterschiedliche Anwendungsfälle haben. Kollaborative EA-Teams hätten Erweiterungen zu einem gemeinsamen optimiertes EA-Framework.
Stellt sicher, dass unterschiedliche Geschäftsprioritäten und Stakeholder berücksichtigt werden.
Verteilte EA-Teams bieten unterschiedliche Ansätze für unterschiedliche Stakeholdergruppen. Eine zentrale Aufsicht gewährleistet die Wiederverwendbarkeit des EA-Repositorys.
Kollaborative Enterprise Architecture-Teams sind sehr selten.
Verteilte Enterprise-Architektur-Teams
Verteilt ist “Unabhängigkeit durch Shared Services”
Separate EA-Teams arbeiten mit einem hohen Maß an Autonomie. Wahrscheinlich sind getrennte EA-Repositories erforderlich und möglicherweise separate optimierte EA-Frameworks.
Stellt sicher, dass unterschiedliche Geschäftsstrategien, Prioritäten und Interessengruppen berücksichtigt werden.
Verteilte EA-Teams bieten unterschiedliche Ansätze für unterschiedliche Stakeholdergruppen. Es wird keine zentrale Aufsicht oder ARB geben.
Teams für verteilte Unternehmensarchitektur sind ziemlich selten.
Das Unification-Modell beschreibt ein zentralisiertes Organisationsdesign. Das Unternehmen nutzt standardisierte Prozesse und gemeinsame Daten, um Kosten zu senken und Zuverlässigkeit und Vorhersehbarkeit zu verbessern. Das EA-Team muss eine durchgängige Betriebsübersicht und einen einheitlichen Kundenkontakt schaffen. Das standardisierte globale Geschäft von Delta Air Lines ist ein Beispiel für Unification.
Was ist die optimale Größe eines Enterprise-Architecture-Teams?
Ein globaler Fortune 50-Riese und ein spezialisierter Business-Service-Anbieter konkurrieren möglicherweise auf demselben Markt. Ihre Größenordnung ist jedoch sehr unterschiedlich. Das größte EA-Team, mit dem wir zusammengearbeitet haben, bestand aus über 2.500 Mitarbeitern. Das kleinste bestand aus einer Einzelperson. Die effektivsten Teams hatten alle weniger als 40 Mitarbeiter.
Ja, die effektivsten Mitarbeiter waren immer weniger als 40. Unabhängig von der Größe ihrer Organisation. Ja, sogar bei einem globalen Riesen.
Der Grund für die Größe liegt im Zweck der Unternehmensarchitektur. Sie hilft Unternehmensleitern, effektive Veränderungen zu steuern. Man braucht nicht Hunderte von Mitarbeitern, um die Change-Leader einer Organisation zu beraten. Es gibt nicht genug Change-Leader.
Große EA-Teams verlieren zwangsläufig den Fokus auf ihre Anwendungsfall für Unternehmensarchitektur. Große EA-Teams konzentrieren sich von der Architektur auf die Implementierung und den Betrieb. Große EA-Teams beschäftigen sich mit mehreren Anwendungsfällen.
Ehrlich gesagt, gab es in jedem großen Team, mit dem wir zusammengearbeitet haben, viele Leute mit der Berufsbezeichnung Architekt, die die Rolle des Architekten - Enterprise-Architekt, Sicherheitsarchitekt, Geschäftsarchitekt, Anwendungsarchitekt, Datenarchitekt oder Infrastrukturarchitekt.
Wir bilden schlanke, effiziente Teams. Betriebsfunktionen und technische Spezialisten lassen wir aus dem Architekturteam heraus.
Wie arbeitet das EA-Team mit dem Architecture Review Board zusammen?
Die Fünf Ziele für ein erfolgreiches ARB skizzieren Sie die Beziehung zwischen dem EA-Team und dem Architekturprüfungsausschuss.
Die fünf Ziele sind:
- Stellen Sie sicher, dass sich das Enterprise-Architecture-Team auf Ihre Anwendungsfall für Unternehmensarchitektur
- Stellen Sie sicher, dass die Zielarchitektur Ihre organisatorischen Defizite behebt
- Sicherstellung der richtigen Entscheidungsträger die Zielarchitektur anhand der Zielarchitektur-Checkliste genehmigt
- Sicherstellen, dass die Implementierungsteams die erwarteten Nutzen und blieben innerhalb ihrer Beschränkungen mithilfe der Checkliste zur Implementierungs-Governance
- Stellen Sie sicher, dass Architekturüberprüfungsprozess funktioniert effizient
Kurz gesagt, das ARB übernimmt eine Aufsichtsfunktion und gewährleistet den Best-Practice-Prozess für Architekturgenehmigung und Umsetzungs-Governance. Der ARB hat zwei Engagements mit dem EA-Team.
Erste, Aufsicht. Sicherstellen, dass das Enterprise-Architekturteam auf seinen Anwendungsfall ausgerichtet ist und diesen umsetzt.
Zweite, Prozess. Stellen Sie sicher, dass die Architekturgenehmigungsprozess und Implementierungs-Governance-Prozess reibungslos ablaufen. Zur Unterstützung dieser Prozesse nutzt das ARB die Checkliste für die Governance der Zielarchitektur und die Checkliste für die Implementierungs-Governance.
Was ist die Enterprise Architecture-Fähigkeit?
Die Enterprise Architecture Capability ist die geschäftliche Fähigkeit zur Entwicklung und Pflege einer Unternehmensarchitektur. Darüber hinaus nutzt sie die Architektur zur Steuerung und Verbesserung Ihres Unternehmens.
Ihr EA Geschäftsfähigkeitskarte wird für Ihren EA-Anwendungsfall entwickelt. Sie entwickeln und stellen die grundlegenden Fähigkeiten zusammen, um Ihre Zweckfähigkeiten zu unterstützen.
Wir verwenden Referenzarchitektur für Unternehmensarchitekturfähigkeiten und fähigkeitsbasierte Planung zur Entwicklung eines Architektur-Roadmap für ein EA-Team.
Welche Rollen benötigt ein EA-Team?
Ein Enterprise Architecture Team benötigt die Rollen, die die Enterprise Architecture unterstützen Fähigkeitskarte. Die Fähigkeitskarte sollte entwickelt werden, um die Anwendungsfall für Unternehmensarchitektur.
Allgemeine Geschäftsrollen
- EA-Teamleiter
- Leitung des EA-Teams
- Leistungsmanagement
- Berufliche Entwicklung des EA-Teams
- EA Team-Design
- EA-Teamarbeitsmanagement
- Personalwesen
EA-Anwendungsfallrollen
- Strategie
- Strategieberatung
- Portfolio
- Portfolioberatung
- Roadmap-Entwicklung
- Roadmap-Implementierung Governance
- Projekt- und Lösungslieferung
- Beschaffungsberatung
- Umsetzung Governance
Grundlegende Rollen
- Architektenrollen
- Unternehmensarchitekt
- Domänenarchitekten
- Business-Architekt
- IT-Architekt
- Anwendungsarchitekt
- Datenarchitekt
- Digitaler Produktarchitekt
- Cloud-Infrastruktur-Architekt
- Integrationsarchitekt
- Sicherheitsarchitekt
- Bibliothekarrollen
- Bibliothekar für Enterprise-Architekturmodelle
- Bibliothekar für Arbeitsprodukte der Unternehmensarchitektur
- Bibliothekar für Enterprise-Architektur-Liefergegenstände
- Bibliothekar für Enterprise-Architektur-Repository
- Governance-Rollen
- ARB-Moderator
- Technik
- Modellierung und Analyse
- Wissensmanagement
Welche Fähigkeiten benötigt ein EA-Team?
Warum benötigt Ihr EA-Team ein optimiertes Enterprise-Architektur-Framework?
Abschluss
Sie haben drei Wege zu einem besseren EA-Team