Was ist ein Enterprise Architecture Team?
Was ist ein Enterprise Architecture Team?
Wie ist ein Enterprise-Architecture-Team strukturiert?
- Auswirkungen der Organisationsgröße auf die EA-Teamstruktur
- Auswirkungen des Anwendungsfalls der Unternehmensarchitektur 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 leiten. Dies geschieht durch die Entwicklung eines Unternehmensstruktur das die organisatorischen Verbesserungen zeigt, die Ihre Stakeholder wünschen.
Umfragen der Association of Enterprise Architects, des Corporate Executive Board, von Forrester und anderen ergaben durchweg ein breites Spektrum positiver und negativer Eindrücke.
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 der Unternehmensarchitektur.
Merkmale eines starken EA-Teams
Erfolgreiche EA-Teams sind engagiert und helfen dabei, effektive Veränderungen herbeizuführen. Die effektivsten EA-Teams haben:
- konzentrieren sich auf ihre Anwendungsfall der Unternehmensarchitektur
- Fachpersonal für mehrere Architekturdomänen
- Effektiver Austausch mit den Entscheidungsträgern Ihrer Organisation.
- effektives Engagement bei der Umsetzung 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
Der Leitfaden für Enterprise-Architektur-Teams geht detailliert darauf ein, wie eine EA-Fähigkeit aufgebaut und entwickelt wird.
Der Referenzarchitektur für Unternehmensarchitekturfunktionen bietet eine umfassende Referenzarchitektur für eine Unternehmensarchitekturfähigkeit.
Gemeinsame Merkmale schwächelnder EA-Teams
Bei EA-Teams mit Problemen ist das ganz anders. Sie durchlaufen in der Regel einen Zyklus aus Neustart, Herunterfahren und Neustart. Bei EA-Teams mit Problemen ist das häufig der Fall:
- sind nicht auf die Entscheidungs- und Umsetzungsprozesse ihrer Organisation abgestimmt
- Erscheinen nach Portfolio- und Projekteinreichung
- versuchen, Entscheidungen zu treffen und Prioritäten zu setzen
- sind stark auf theoretische IT-orientierte Themen fokussiert
- habe keine optimiertes Enterprise-Architektur-Framework
- konzentrieren Sie sich auf die Implementierungsdetails
- keinen Gebrauch machen von:
- haben das Team ohne Rücksicht auf ihre Anwendungsfall der Unternehmensarchitektur
Wie ist ein Enterprise-Architecture-Team strukturiert?
Die Erfahrung zeigt, dass es nicht das eine richtige EA-Team gibt. Es gibt nicht die beste Struktur. Erfolgreiche Teams passen zu ihrer Organisation und sind so strukturiert, dass sie ihre Anwendungsfall der Unternehmensarchitektur.
Die Struktur Ihres EA-Teams basiert auf:
- Organisationsskala
- Anwendungsfälle der Unternehmensarchitektur
Auswirkungen der Organisationsgröße auf die EA-Teamstruktur
Ein globaler Fortune 50-Riese und ein spezialisiertes Unternehmen für Unternehmensdienstleistungen konkurrieren möglicherweise auf dem Spezialistenmarkt. Allerdings unterscheiden sie sich in ihrer Größe stark. Und was noch wichtiger ist: Sie unterscheiden sich in ihrer Struktur stark.
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 der Unternehmensarchitektur.
Auswirkungen des Anwendungsfalls der Unternehmensarchitektur 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 von Portfolio
- 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 Führer des Führers 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“ kann an den Hauptverbrauchern von Enterprise-Architecture-Services ausgerichtet werden. Die Hauptverbraucher werden dynamisch und treibend sein, wie etwa bei digitalen Produkten.
Im Extremfall wird das Betriebsmodell des Architekturteams koordiniert oder repliziert. In diesem Fall gibt es mehrere Architekturteams, die auf unterschiedliche Funktionen ausgerichtet sind. Diese Struktur wird dort üblich sein, wo es starke regionale Trennungen gibt.
IT-zentriert EA-Teams berichten an die IT-Funktion. Die Berichte gehen direkt an den CIO oder CTO. Die Führer des Führers Abbildung 7 auf Seite 34 zeigt einige IT-zentrierte Berichtsstrukturen.
Strategiezentriert EA-Teams berichten an den Geschäftsbetrieb. Wenn sie eine Strategiefunktion in der Organisation unterstützen, konzentrieren sie sich auf den Anwendungsfall Strategie oder Portfolio. Wenn sie eine Betriebsfunktion unterstützen, konzentrieren sie sich höchstwahrscheinlich auf den Anwendungsfall Portfolio.
Erfolgreicher Aufbau eines Enterprise Architecture Teams
Es gibt vier Ansätze für die Gestaltung der Struktur Ihres Enterprise-Architecture-Teams. Diese Ansätze basieren auf einem Standard Referenzarchitektur für BetriebsmodelleDiese 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 Ausmaß muss Ihre Organisation die Entwicklung ihrer Unternehmensarchitektur partitionieren?
Eine Partitionierung ist in folgenden Fällen angezeigt:
-
- 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 eine einheitliche Methode, einheitliche 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 Abstimmung 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 Startmodell verwendet wird, ist es für ein konsolidiertes EA-Team sehr schwierig, Prioritäten und Ziele zu ändern. 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 Interessengruppen. Es wird eine zentrale Aufsicht für eine einheitliche Methode, einheitliche Entscheidungen und ein wiederverwendbares EA-Repository geben.
Replizierte Enterprise Architecture Teams werden nicht ausreichend genutzt. Wir sehen sie am häufigsten in Organisationen mit starker regionaler Entscheidungsfindung und während der Integration von Akquisitionen. Sie gelten nicht automatisch für replizierte Geschäftsbetriebsmodelle. Replizierte Geschäftseinheiten benötigen kein eigenes EA-Team.
Kollaborative Enterprise-Architecture-Teams
Kollaborativ ist „nahtloser Zugriff auf gemeinsam genutzte Daten”
Separate EA-Teams arbeiten mit einer anderen Methode, aber einem gemeinsamen EA-Repository. Separate EA-Teams hätten wahrscheinlich unterschiedliche Architekturbereich Fokus und können unterschiedliche Anwendungsfälle haben. Kollaborative EA-Teams hätten Erweiterungen zu einem gemeinsamen optimiertes EA-Framework.
Stellt sicher, dass den unterschiedlichen Geschäftsprioritäten und Interessengruppen Rechnung getragen wird.
Verteilte EA-Teams bieten unterschiedliche Ansätze für verschiedene Interessengruppen. Es wird eine zentrale Aufsicht geben, um ein wiederverwendbares EA-Repository sicherzustellen.
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. Sie benötigen wahrscheinlich getrennte EA-Repositorien 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 Interessengruppen. Es wird keine zentrale Aufsicht oder ARB geben.
Verteilte Enterprise-Architecture-Teams sind eher selten.
Das Unification-Modell beschreibt ein zentralisiertes Organisationsdesign. Das Unternehmen verwendet standardisierte Prozesse und gemeinsam genutzte Daten, um Kosten zu senken und Zuverlässigkeit und Vorhersehbarkeit zu verbessern. Das EA-Team muss eine End-to-End-Ansicht der Betriebsabläufe 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 spezialisiertes Unternehmen für Unternehmensdienstleistungen konkurrieren möglicherweise auf demselben Markt. Sie unterscheiden sich jedoch in ihrer Größe erheblich. 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 darin, wofür die Unternehmensarchitektur verwendet wird. Sie hilft Unternehmensleitern, effektive Veränderungen herbeizuführen. Sie brauchen nicht Hunderte von Leuten, 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 der 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, jedes große Team, mit dem wir gearbeitet haben, hatte viele Leute mit dem Jobtitel Architekt, die die Rolle des Architekten - Unternehmensarchitekt, Sicherheitsarchitekt, Geschäftsarchitekt, Anwendungsarchitekt, Datenarchitekt oder Infrastrukturarchitekt.
Wir bilden schlanke, effiziente Teams. Operative Funktionen und technische Spezialisten lassen wir aus dem Architekturteam heraus.
Wie arbeitet das EA-Team mit dem Architecture Review Board zusammen?
Der Fünf Ziele für ein erfolgreiches ARB skizzieren Sie die Beziehung zwischen dem EA-Team und dem Prüfungsausschuss für Architektur.
Die fünf Ziele sind:
- Stellen Sie sicher, dass sich das Enterprise-Architecture-Team auf Ihr Anwendungsfall der 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
- Sicherstellen, dass die Architekturüberprüfungsprozess funktioniert effizient
Kurz gesagt, das ARB übernimmt eine Aufsichtsfunktion und gewährleistet den Best-Practice-Prozess für Architekturgenehmigung und Implementierungs-Governance. Der ARB hat zwei Engagements mit dem EA-Team.
Zuerst, Aufsicht. Sicherstellen, dass das Enterprise-Architektur-Team auf seinen Anwendungsfall ausgerichtet ist und diesen umsetzt.
Sekunde, Prozess. Sicherstellen, dass die Architektur-Genehmigungsprozess und Implementierungs-Governance-Prozess reibungslos ablaufen. Zur Unterstützung dieser Prozesse wird das ARB die Zielarchitektur-Governance-Checkliste und das 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. Außerdem können Sie die Architektur zur Steuerung und Verbesserung Ihres Unternehmens nutzen.
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 gebrauchen Referenzarchitektur für Unternehmensarchitekturfunktionen und fähigkeitsbasierte Planung zur Entwicklung einer Architekturfahrplan für ein EA-Team.
Welche Rollen benötigt ein EA-Team?
Ein Enterprise Architecture Team benötigt die Rollen, die die Unternehmensarchitektur unterstützen FähigkeitskarteDie Fähigkeitskarte sollte entwickelt werden, um die Anwendungsfall der 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
- Implementierungs-Governance
Grundlegende Rollen
- Architektenrollen
- Unternehmensarchitekt
- Domänenarchitekten
- Geschäftsarchitekt
- IT-Architekt
- Anwendungsarchitekt
- Datenarchitekt
- Digitaler Produktarchitekt
- Cloud-Infrastruktur-Architekt
- Integrationsarchitekt
- Sicherheitsarchitekt
- Rollen von Bibliothekaren
- Bibliothekar für Enterprise-Architektur-Modelle
- Bibliothekar für Arbeitsprodukte der Unternehmensarchitektur
- Bibliothekar für Enterprise-Architektur-Lieferobjekte
- Enterprise Architecture Repository-Bibliothekar
- 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
Du hast drei Wege zu einem besseren EA-Team