Verständnis von Unternehmensarchitektur und Agile
Wie passen Unternehmensarchitektur und Agile zusammen?
Unternehmensarchitektur und Agile – Definieren Sie den Agile-Ansatz
Unternehmensarchitektur und Agile – Backlog im Sprint leiten
Unternehmensarchitektur und Agile – Sprints einschränken
Wie passen Unternehmensarchitektur und Agile zusammen?
Unternehmensarchitektur und Agile passen auf unerwartete Weise zusammen. Die agile Methode konzentriert sich auf das Jetzt. Die Schritte zur Erstellung praktikabler Versandsoftware. Aus dieser Perspektive stellt sich die Frage: Was leistet Unternehmensarchitektur heute? Wie trägt sie zur Beschleunigung von Versandsoftware bei?
Enterprise-Architektur und Agile passen nicht innerhalb des Sprints zusammen. Sie passen außerhalb des Entwicklungszyklus zusammen. Sie passen zusammen, indem die Enterprise-Architekten und die agilen Entwickler ihre Arbeit erledigen. Erfolgreiche EA-Teams erfüllen ihre Anwendungsfall. Sie liefern nichts anderes. Selbst wenn sie könnten.
Wir verfügen über eine einfache Unternehmensarchitektur und ein agiles Referenzmodell. Es gibt vier zentrale Einsatzmuster für die Unternehmensarchitektur:
- Definition des agilen Ansatzes
- Steuerung des Backlogs im Sprint
- Einschränkung der agilen Sprints
- Lösen der produktübergreifenden Abhängigkeit
In den letzten Jahren arbeitete ich an Digitale Transformation Initiativen haben wir eine Reihe von Engagementmustern entwickelt.
Wie verwendet man diese Engagement-Muster?
Betrachten Sie zunächst Ihren EA-Anwendungsfall. Welche Beratung wird von Ihnen erwartet? Wem dienen Sie? Betrachten Sie dann die Engagement-Muster, die Ihren beruflichen Herausforderungen gerecht werden. Beziehen Sie diese in Ihr Engagement ein.
Unser Architektur Muster Vorlage hat zwei Schlüsselelemente: die vorhersehbares Problem und die Ansatz zur Lösung des Problems. Wir sammeln auch die harte Teile. Wenn wir ein Muster in Betracht ziehen, achten wir darauf, wie gut es das Problem löst und wie viel zusätzliche Arbeit notwendig ist, um das Muster erfolgreich anzuwenden.
Schauen wir uns die Engagement-Muster an: das Problem, das sie lösen, den Ansatz und die schwierigen Aspekte.
- Definition des agilen Ansatzes
- Steuerung des Backlogs im Sprint
- Einschränkung der agilen Sprints
- Lösen der produktübergreifenden Abhängigkeit
Praxisbeispiel: Agile Entwicklung auf der Enterprise Architecture Roadmap
Ich hatte ein amüsantes Gespräch mit der neu eingestellten Systems Reliability Engineer. Die SRE-Spezialistin war begeistert. Wir haben endlich moderne Methoden eingeführt: CI/CD und automatisiertes Testen. Sie fragte mich, was das EA-Team zur Unterstützung täte.
Ich musste lächeln, als sie fragte: ‘was tut das EA-Team, um zu helfen?’Was sie wirklich meinte, war:‘was tun Sie heute, um mich zu unterstützen?’Heute gab es hinsichtlich ihrer unmittelbaren Herausforderungen nichts. Sie war mitten in der Umsetzung. Sie hat sich in Bezug auf die Umsetzung umgesehen.“.
Sie verstand nicht, wie sich die Organisation entwickelte. Sie war sich nicht bewusst über die Portfolio-Roadmap. Die Roadmap enthielt einen Wendepunkt, den wir gerade erreicht hatten. Wir hatten Container, Testdatenmanagement und eine schwache automatisierte Testsuite eingeführt. Ihr war nicht klar, dass die altmodische Top-Down-Planung die Voraussetzungen für ihren neuen Job geschaffen hatte.
Sie dachte an die unmittelbare Entwicklung. Ich dachte an das Ganze digitale Transformation. Ihre Aufgabe bestand darin, der Organisation bei der nächsten Umstellung zu helfen. Sie entwickelte die kritische Fähigkeiten. Automatisierte Tests sollten den Nachweis erbringen, dass die Architekturbeschränkungen eingehalten wurden. Ich bewegte mich von Definition des agilen Ansatzes. Ich brauchte Hilfe den Rückstand zu steuern.
Zehn Brücken und Verbindungsstraßen sind wertvoller als 500 Halbbrücken ins Nirgendwo
490 Brückenbauer werden unglücklich sein
490 Brückenbauer, die glaubten, einen Mehrwert zu schaffen
Agentische KI-Playbook-Konversationen
Agentic AI Playbook-Gespräche Wir haben uns intensiv mit der sich wandelnden Landschaft der KI-Einführung auseinandergesetzt und eine Reise unternommen, die sowohl technische Feinheiten als auch die umfassendere digitale Transformation beinhaltet. Wir haben den Leitfaden für Führungskräfte entwickelt […]
Laden Sie die Referenzarchitektur für kritische Fähigkeiten zur KI-Einführung herunter
Laden Sie die Referenzarchitektur für kritische Fähigkeiten zur KI-Einführung herunter. Die Einführung von KI erfordert innovatives Denken. Derzeit verfügen wir nicht über bewährte Best Practices für eine flächendeckende KI-Einführung, die unsere Organisationen nachhaltig verbessern. Wir benötigen die Fähigkeit, unsere Vorgehensweise neu zu denken. […]
Leitfaden für Unternehmensleiter zu AI herunterladen
Download Business Leader's Guide to Artificial Intelligence Unternehmen, die innovative Technologien erfolgreich einsetzen, haben einen Wettbewerbsvorteil. Innovative Technologie ist nicht mit etablierten Erfolgsmustern und bewährten Verfahren verbunden. Innovative Technologie ist neu und [...]
Download der Einführung in den TOGAF-Standard, 10. Ausgabe
Download Einführung in den TOGAF®-Standard, 10. Auflage Der TOGAF-Standard, 10. Auflage erleichtert die Einführung von Best Practices für Unternehmensarchitektur. Er trennt die universellen Konzepte von bewährten Best Practices. Der Standard unterstreicht, wo man [...]
Leitfaden zur fähigkeitsbasierten Planung herunterladen
Download Leitfaden für die fähigkeitsbasierte Planung Immer auf die Realisierung von Werten hinarbeiten. Eine halbe Verbesserung ist 100% Verschwendung! Niemand bringt einem Adler das Krabbeln, Gehen oder Laufen bei. Eagles Fly! Download Bringen Sie Ihren Adlern das Fliegen bei: Capability-based Planning [...]
Leitfaden zur Bewertung der Geschäftsarchitekturfähigkeit herunterladen
Leitfaden zur Bewertung der Geschäftsarchitektur herunterladen Laden Sie einen Leitfaden zur Bewertung der Geschäftsarchitektur herunter. Die fähigkeitsbasierte Planung ist eine der leistungsfähigsten Techniken zur Verbesserung der Unternehmensarchitektur. Die bewährte Praxis der fähigkeitsbasierten Planung verwendet die Fähigkeit als Managementinstrument [...]
Muster für Unternehmensarchitekturprinzipien herunterladen
Download von Beispielen für Architekturprinzipien Laden Sie ein Beispiel für die Prinzipien der Unternehmensarchitektur herunter. Die Grundsätze der Unternehmensarchitektur zeigen auf, wie man an ein Problem oder eine Entscheidung herangeht. Der Ansatz führt Sie immer zu Ihren dauerhaften Prioritäten. Muster für Unternehmensarchitekturprinzipien herunterladen [...]
Leitfaden zur Unternehmensarchitektur-Governance herunterladen
Download Enterprise Architecture Governance Guide Laden Sie den Enterprise Architecture Governance Guide herunter und erfahren Sie mehr über bewährte Verfahren zur Steuerung und Kontrolle der Architekturentwicklung und -änderung, um die erwarteten Ergebnisse zu erzielen. Leitfaden zur Unternehmensarchitektur-Governance herunterladen [...]
TOGAF und SABSA Integration herunterladen
Download TOGAF und SABSA Integration Bringen Sie SABSA, das weltweit beste Framework für Sicherheitsarchitekturen, und TOGAF, das branchenübliche Framework für Unternehmensarchitekturen, zusammen. Download TOGAF und SABSA-Integration TOGAF und SABSA-Integration Enthält SABSA verwendet ein [...]
Referenzarchitektur für die Unternehmensarchitektur herunterladen
Download Enterprise Architecture Capability Reference Architecture Die Enterprise Architecture Capability Reference Architecture wird den Aufbau und die Verbesserung Ihres EA-Teams beschleunigen. Gestalten Sie Ihr Enterprise Architecture Team für den Erfolg. Identifizieren und verbessern Sie Ihre Unternehmensarchitektur [...]
Unternehmensarchitektur und Agile – Definieren Sie den Agile-Ansatz
Agile ist eine Entscheidung. Sie hat Vor- und Nachteile. Die Einführung von Agile erfordert Entscheidungen über Produkt, Plattform, Servicebereitstellungsstrategie und Top-Down-Übergangspunkte.
Ein EA-Team muss in der Lage sein, Strategie und Portfolio Zu Definieren Sie den agilen Ansatz.
Vorhersehbares Problem: Wann verwenden Sie Agile?
Produktmuster
Externe Produkte sind einfacher als interne. Kurz gesagt: Es gibt einen Markt. Intern wird das interne System durch agiles Arbeiten in digitale Produkte umgewandelt. Existenz, Umfang und Entwicklungsansatz interner Systeme müssen ermittelt werden.
Vorhersehbares Problem: Woher kommt das Produkt?
Ansatz: Passen Sie die Definition von ‘Lösungen’ an, die zum Schließen von Lücken und Arbeitspaketergebnissen verwendet werden, um sie an eigenständige Produkte anzupassen. Entwickeln Sie ein internes Produktportfolio und einen Satz von Wertmaßstäben für interne Produkte. Produkte sollten auf der Architektur-Roadmap.
Plattformmuster
Plattformen können die Entwicklungsgeschwindigkeit und Nachhaltigkeit verbessern. Eine schlecht gewählte Plattform kann jedoch das Gegenteil bewirken. Es ist nicht die Entscheidung eines agilen Teams, ob und erst recht nicht welche Plattform verwendet wird. Wir haben den Begriff Plattform für SAP, M365, Facebook, Pega oder sogar Open Shift Containers verwendet.
Referenzarchitekturen spielen eine entscheidende Rolle bei der Definition, Auswahl und regieren die Nutzung von Plattformen.
Vorhersehbares Problem: Wann sollte eine Plattform verwendet werden und wann sollte das Produkt uneingeschränkt sein?
Ansatz: Mehrere Ansätze
-
- Wählen Sie eine Architekturalternative aus. Die wichtigsten Aspekte sind Vertrauen, Nachhaltigkeit, Markteinführungszeit und Geschäftskontinuität.
- Plattform verwenden Referenzarchitektur um die Vollständigkeit des Produktdesigns sicherzustellen und das Schließen aller Lücken zu bewerten
Harte Teile: Frage des Supports und der Nachhaltigkeit des Produkts und der Plattform.
Muster der Servicebereitstellungsstrategie
Eine Servicebereitstellungsstrategie beschreibt den Ansatz, den Unternehmen zur Bereitstellung von Produkten oder Dienstleistungen verfolgen. Es ist nicht selbstverständlich, dass Sie Ihren aktuellen Ansatz – intern, vertraglich oder durch Personalaufstockung – wählen.
Vorhersehbares Problem: Wie wird Ihr Unternehmen eine agile Entwicklung umsetzen?
Ansatz: Folgen Sie den Ansätzen der Architektur zur Unterstützung der Strategie. Stellen Sie die Frage, wie agile Entwicklung ermöglicht wird. Verwenden Sie eine Betriebsmodell Wert zu definieren und eine Organisationsstruktur um zu definieren, wie die verschiedenen Verbraucher, Entwickler und Betreiber eines Produkts zusammenarbeiten werden.
Ruhepunktmuster für Hauptwerte
Agile Entwicklung ist genauso wahrscheinlich wie jeder andere Ansatz, den richtigen Zeitpunkt für eine Beendigung zu erkennen. Value Resting Points sind ein Synonym für Architekturübergänge. Wir verwenden diesen Begriff, um zu verdeutlichen, dass der Stakeholder einen Ausweg hat und seine Investitionen einstellen kann. Stakeholder nutzen diese Auswege aus mehreren Gründen:
-
- Wenn die Anstrengung, den nächsten Ruhepunkt zu erreichen, den inkrementellen Wert überschreitet.
Dies ist ein ROI-Gespräch. ROI-Gespräche führen normalerweise zu einer Änderung der Prioritäten. - Wenn mit dem gleichen Aufwand ein wertvolleres Ergebnis erreicht werden kann
- Wenn sich die organisatorischen Prioritäten geändert haben (Verwaltung)
- Wenn eine unerwartete Bedrohung oder Chance besteht (Unternehmensagilität)
- Wenn die Anstrengung, den nächsten Ruhepunkt zu erreichen, den inkrementellen Wert überschreitet.
Vorhersehbares Problem: Den Wert-Ruhepunkt kennen, um anzuhalten oder den Fokus zu ändern
Ansatz: Verwenden Sie Architektur-Roadmaps, um alternative Wertbereitstellungspunkte zu erkunden. Erstellen Sie Berichte über Aktivitäten in Richtung Übergangszustände.
Harte Teile: Zu den Überlegungen gehören der relative Wert im Ruhezustand und der potenzielle Wert als Sprungbrett für andere Aktivitäten. Implementierer verstehen diese Gespräche selten. Sie versteifen sich emotional auf einen bestimmten Weg oder Ruhepunkt. Insbesondere, wenn es um die Existenz des Produkts oder die nächste Version geht. Führungskräfte suchen immer nach dem besten Weg nach vorne, nicht nach dem höchsten potenziellen Ertrag. Sie wollen den besten Weg.
Der erste Schritt besteht darin, die Wertruhepunkte zu erkunden. Entscheidungsträger müssen die Optionen verstehen (Auswahl anhand verschiedener Kriterien und Aufschub unsicherer Entscheidungen). Anschließend müssen sie ermitteln, was nötig ist, um zu den ausgewählten Wertruhepunkten zu gelangen.
-
- Welche Änderung ist angesichts verschiedener Kriterien anzustreben –Architektur-Roadmap Typ 4: Szenarien
- Welche Arbeit wird einen Mehrwert bringen, und die Kosten und Unsicherheiten –Architektur-Roadmap Typ 1: Heatmap
- Welche Entscheidungen werden aufgeschoben –Architektur-Roadmap Typ 4: Szenarien
- Wann wird der Wert geliefert –Übergangszustände
Mehr erreichen mit Best-Practice-Unternehmensarchitektur-Prozess und -Methode
Bewährte Verfahren Unternehmensarchitektur von Conexiam Navigieren
Entwicklung einer Architekturansicht
Entwicklung einer Architekturansicht Die Unternehmensarchitektur ist ein wichtiger Kompass. Sie hilft Unternehmen, die Komplexität von Technologie, Strategie und Betrieb zu meistern. Der Kern der Unternehmensarchitektur ist ein systematischer Ansatz. Ziel ist es, sicherzustellen, dass […]
Bewährte Praktiken zur Implementierung von Tools für das Management der Unternehmensarchitektur
Best Practices für die Implementierung von Enterprise Architecture Management Tools Enterprise Architecture Management Tools wurden entwickelt, um die Planung, den Entwurf, die Analyse und die Ausführung der Unternehmensarchitektur zu unterstützen. Sie versetzen Unternehmensarchitekten in die Lage, die Notwendigkeit von Änderungen zu untersuchen [...]
Verwendung der Szenarioanalyse für die Unternehmensarchitektur
Verwendung der Szenarioanalyse für die Unternehmensarchitektur Ein Szenario ist einfach eine plausible Zukunft. Die Szenarioanalyse untersucht, wie wir zu einer plausiblen Zukunft gelangen und wie sich verschiedene Szenarien auf unsere aktuellen Entscheidungen auswirken. Szenarien helfen Führungskräften [...]
Entdecken Sie die Leistungsfähigkeit von Enterprise Architecture Patterns
Entdecken Sie die Leistungsfähigkeit von Enterprise-Architektur-Mustern: Ein umfassender Leitfaden. Jedes Unternehmen möchte sich verbessern. Seine Abläufe rationalisieren. Seine Unternehmensagilität steigern. Veränderungen an seinen Strategien ausrichten. Die digitale Transformation erfolgreich meistern. Enterprise Architecture, eine Disziplin […]
Alles, was Sie über die Verwendung von Architekturalternativen wissen müssen
Alles, was Sie über den Einsatz von Architekturalternativen wissen müssen Architekturalternativen sind für eine gute Unternehmensarchitekturentwicklung erforderlich. Wenn Sie mit der Architekturentwicklung beginnen, weist Ihr Unternehmen Mängel auf. Es gibt Bereiche, die verbessert werden müssen. Sie müssen [...]
Einrichtung eines Fachausschusses für moderne Architektur
Einrichtung eines modernen Architekturprüfungsausschusses Die Einrichtung eines modernen Architekturprüfungsausschusses erfordert die Schaffung eines dynamischen Governance-Prozesses und die Einrichtung eines Entscheidungsgremiums auf höchster Ebene, das als Backstop fungiert. Ziel ist es, eine effektive Architektur-Governance ohne Bürokratie zu etablieren. [...]
Entwicklung einer Unternehmensarchitektur-Strategie
Entwicklung einer Enterprise-Architektur-Strategie: Strategischer Plan für Veränderungen. Eine Enterprise-Architektur-Strategie ist Handeln. Maßnahmen, die Ihr Unternehmen ergreifen wird, und Veränderungen, die Sie vornehmen werden, um Ihre strategischen Ziele zu erreichen. Bei der Strategieentwicklung geht es vor allem um Entscheidungen. […]
Entfesseln Sie Ihr Unternehmenspotenzial: Wie Sie eine effektive Capability Map erstellen
Das Potenzial Ihres Unternehmens freisetzen: Wie Sie eine effektive Capability Map erstellen Haben Sie Schwierigkeiten, die Fähigkeiten zu ermitteln, die Sie benötigen, um Ihr Unternehmen auf die nächste Stufe zu heben? Finden Sie es schwierig, die Ressourcen auf die [...]
Die Macht der fähigkeitsbasierten Planung freisetzen: Eine Kurzanleitung
Die Leistungsfähigkeit der fähigkeitsbasierten Planung nutzen: Eine Kurzanleitung Suchen Sie nach einer effektiveren Methode zur Planung und Umsetzung Ihrer Unternehmensstrategie? Dann sind Sie bei der fähigkeitsbasierten Planung an der richtigen Adresse. Die Identifizierung und Nutzung der Fähigkeiten Ihres Unternehmens [...]
Sicherstellung von Ausrichtung und Verantwortlichkeit: Die entscheidende Rolle von Enterprise Architecture Governance Checklisten
Sicherstellung von Ausrichtung und Verantwortlichkeit: Die entscheidende Rolle von Governance-Checklisten für Unternehmensarchitekturen Governance-Checklisten für Unternehmensarchitekturen vereinfachen die Governance-Prozesse für Unternehmensarchitekturen. Der Governance-Prozess muss die Zielarchitektur genehmigen und die Umsetzung steuern. Ein robustes Unternehmen [...]
Unternehmensarchitektur und Agile – Backlog im Sprint leiten
Starke, agile Teams finden den effektivsten Weg nach vorne. Längerfristige Planung und Budgetierung sind aufgrund der Komplexität des Ökosystems erforderlich. Die Herausforderung besteht darin, langfristige Planung und agile Kreativität zu verbinden. Verbinden Sie Top-down-Planung und Bottom-up-Ausführung.
Sie müssen über die organisatorischen Prioritäten in einer Weise informiert werden, die in das Rückstandsmanagement einfließen kann.
Agiles Vorgehen ist deshalb so wichtig, weil die Menschen, die der Lösung am nächsten sind, den effektivsten Weg finden können. Erfolgreiche Organisationen setzen Prioritäten und wägen ab. Ohne das Erreichen der gewünschten Zielvorgabe unter Berücksichtigung der Zeit- und Ressourcenbeschränkungen sollte keine Arbeit begonnen werden.
Ein EA-Team muss in der Lage sein, Portfolio und Projekt zu Backlog im Sprint leiten.
Vorhersehbares Problem: Sicherstellen, dass die Veröffentlichung und Produktentwicklung von den erwarteten Ergebnissen, dem Wert, den kaskadierten Leistungserwartungen und Einschränkungen bestimmt wird.
Hartes Stück: Zu viele Agile-Evangelisten sind überrascht, dass Organisationen, die Agile einführen, weiterhin stark der Planung und langfristigen Budgetierung verpflichtet bleiben. Wir müssen oft den Mythos überwinden, dass es eine kulturelle Präferenz für den Wasserfall gibt.
Roadmap zur Anleitung des Produktmusters
Vorhersehbares Problem: Eine umfassende Produkt-Roadmap anstelle eines Feature-Release-Zyklus.
Ansatz: Mit einem Architektur-Roadmap-Technik wo das Produkt oder die Produktfamilie an die Stelle des Portfolios tritt. Stellen Sie sicher, dass die normale Produktberichterstattung Aktivitäten in Richtung Übergangszustände umfasst.
Harte Teile: Exzellentes Produktmanagement liefert eine umfassende Produkt-Roadmap. Zu viele Bottom-up-Produktbesitzer haben keine Erfahrung mit der Verwaltung des Lebenszyklus oder der Integration einer integrierten Produktsuite. Das EA-Team muss je nach den Fähigkeiten der Produktorganisation einspringen oder auf andere Lösungen zurückgreifen.
Zu viele Architekturteams tappen in die Falle künstlicher Präzision oder vermeintlicher Allwissenheit. Beides sind hochtrabende Ausdrücke für das Wasserfall-Denken. Eine klassische Architektur-Roadmap spricht von Übergängen, Lücken und Arbeitspaketen. Für ein Produktteam ist das unverständlich. Wechseln Sie zur Produkt- und agilen Terminologie. Der Produktbesitzer muss die Einschränkungen verstehen, innerhalb derer er arbeitet.
Der Aufbau der Roadmap erfordert eine ausreichende Architektur. Der einzige skalierbare Ansatz ist ‘gerade genug.’ „Gerade genug“ bedeutet, organisatorische Prioritäten durchzusetzen und vorhersehbaren Problemen auszuweichen. „Gerade genug“ bedeutet, sich aus dem Produktdesign herauszuhalten. Verwenden Sie Architekturmuster, die im gesamten Portfolio überzeugen. „Gerade genug“ bedeutet, potenzielle Synergien zu ignorieren. „Gerade genug“ bedeutet, sich auf vorhersehbare Probleme zu konzentrieren. Das Ausweichen vor vorhersehbaren Problemen ist sehr wertvoll. „Gerade genug“ bedeutet, keine Angst vor kreativer Zerstörung zu haben. Verwenden Sie ein Konzept des erwarteten Lebenszyklus, um aggressives Refactoring voranzutreiben (Greenfield- und revolutionäre Ansätze).
Die Verwendung der Techniken mit dem Produktbesitzer hilft dabei, organisatorische Prioritäten und Einschränkungen in die Produkt-Roadmap einzubringen.
-
- Welches Produkt oder welche Hauptmerkmale sollten unter Berücksichtigung verschiedener Kriterien angestrebt werden? Architektur-Roadmap Typ 4: Szenarien
- Welche Produkte oder Funktionen bieten einen Mehrwert (Nutzen, Arbeit und Unsicherheit – Architektur-Roadmap Typ 1: Heatmap
- Wann sind Produkt- und Plattformänderungen erforderlich – Architektur-Roadmap Typ 2: Lebenszyklus
- Welche Abhängigkeit und Auswirkung haben Arbeit und Veränderung – Architektur-Roadmap Typ 3: Auswirkungen und Abhängigkeiten
Roadmap zur Anleitung des Epic-Musters
Vorhersehbares Problem: Verwenden von Epics zum Implementieren von Top-Down-Ergebnissen und Einschränkungen in das Produkt.
Ansatz: Durch die Verwendung gut konstruierter Übergangszustände in einem Architektur-Roadmap-Technik wo das Produkt oder die Produktfamilie an die Stelle des Portfolios tritt. Stellen Sie sicher, dass die normale Produktberichterstattung Aktivitäten in Richtung Übergangszustände umfasst.
Harte Teile: Erfordert eng integrierte oder stark eingeschränkte Produkte. Der Schwerpunkt muss auf der Integration oder den Einschränkungspunkten liegen. Ein einfaches Beispiel ist die Koexistenz mehrerer Produkte in einem Ökosystem mit gemeinsamen Referenzdaten.
Es kommt häufig vor, dass man in die Falle tappt, die Softwareentwicklung im Voraus zu planen. Der Fokus sollte auf den Bereichen liegen, in denen Ihre Softwareentwickler ihre Kreativität aufgrund von Ökosystem- oder externen Anforderungen einschränken müssen. Idealerweise sollte dies im Voraus geschehen und nicht als Reaktion auf technische Schulden.
Als uns dies gelungen ist, haben wir die Sprache von Methoden wie SaFE aktiv übernommen und die Roadmap anhand strategischer Themen und Architektur-Start- und Landebahnen gestaltet.
Unternehmenswertmuster
Vorhersehbares Problem: Die Sicherstellung der in den Übergangs- und Zielzuständen enthaltenen kritischen Erfolgsfaktoren dient als Leitfaden für die agile Backlog-Pflege und die Epic-Planung.
Ansatz: Übersetzen Sie Top-Down-Maßnahmen und -Ziele in anwendbare Kriterien für die agile Backlog-Aufbereitung. Stellen Sie sicher, dass die normale Produktberichterstattung die Auswahl und Fertigstellung von Aktivitäten in Richtung des angegebenen Werts umfasst.
Harte Teile: Die Top-Down-Maßnahmen müssen eindeutig und leicht bewertbar sein. Beispielsweise kann vom agilen Team nicht verlangt werden, eine differenzierte Balance zwischen Time-to-Market und Resilienz zu entwickeln. Eine eindeutige Terminologie ist erforderlich.
Jede Änderung der Top-Down-Maßnahmen führt zu Verwirrung. Dies gilt insbesondere dann, wenn ein Übergangszustand erreicht wurde.
Bei internen Produkten stellen wir stets sicher, dass wir ein solides Kostenmodell für digitale Produkte haben, bevor wir Kostenmaßnahmen einführen. Ohne ein Kostenmodell gehen Betriebs- und Plattformkosten verloren, und alle Kosten werden durch die Implementierungskosten gerechtfertigt. Planen Sie, den internen Produktmanager zu unterstützen bei ITFM verstehen. Im Gegensatz dazu verfügen Produktmanager externer digitaler Produkte normalerweise über ein sehr ausgeprägtes Kostenverständnis.
Beschränken Sie das Bottom-up-Product-Owner-Muster
Vorhersehbares Problem: Produktbesitzer betrachten das gesamte Unternehmen durch die Linse ihres Produkts und seiner direkten Benutzer.
Ansatz: Dokumentieren Sie Produkt und Rolle innerhalb des Ökosystems. Dokumentieren Sie die für das Produkt geltenden Einschränkungen. Dokumentieren Sie Bewertungskriterien. Stellen Sie sicher, dass die normale Produktberichterstattung den Fortschritt in Richtung Übergangszustände und Aktivitäten im Einklang mit dem Unternehmenswert umfasst.
Harte Teile: Produktbesitzer interner digitaler Produkte sind oft ein schwaches Glied. Zu den häufigsten Herausforderungen gehört das mangelnde Verständnis für:
-
- warum ihr Produkt existiert
- Rolle des Produkts im Ökosystem
- Kritikalität von Unternehmensbeschränkungen
- Wer sind die Entscheidungsträger (Geldgeber)?
- So erhalten Sie Orientierungshilfen zu Unternehmensprioritäten und Wertmaßstäben
EA-Teams, die Portfolio und Projekte unterstützen, müssen höchstwahrscheinlich die Bottom-up-Produktbesitzer einschränken. Dies erfordert gezielte Anstrengungen und Personaleinsatz.
Unternehmensarchitektur-Schulung und TOGAF-Schulung
Avolution ABACUS-Schulungskurs
Avolution ABACUS Training Effektive Unternehmensarchitektur beruht auf formaler Modellierung und Analyse. Wir bieten eine Avolution ABACUS-Schulung von Unternehmensarchitekten aus der Praxis an. Die Teilnehmer erwerben Fähigkeiten und Kenntnisse, um integrierte Unternehmens- und Domänenarchitekturen in diesem [...]
Effektive Online-Bildung
Effektive Online-Bildung Effektive Online-Bildung funktioniert. Die Schüler haben Zugang zu den besten verfügbaren Lehrkräften. Die Studierenden bestimmen ihr Lerntempo selbst. Die Lehrkräfte können umfangreiches Zusatzmaterial zur Verfügung stellen, ohne vom Hauptthema abzulenken. Effektiver Fernunterricht [...]
Kickstart für Unternehmensarchitekten
Enterprise Architect's Kickstart Wir müssen unsere Fähigkeiten auf dem neuesten Stand halten. Jetzt mehr denn je. Nutzen Sie den Enterprise Architecture Kickstart, um Ihre Fähigkeit zu verbessern, transformative Unternehmensarchitektur zu liefern. Dieser 90-Tage-Kickstart ist die Art und Weise, wie Conexiam Consulting [...]
Maßgeschneiderte Schulungen zur Unternehmensarchitektur
Maßgeschneiderte Schulungen für Unternehmensarchitektur Maßgeschneiderte Schulungen für Unternehmensarchitektur sind auf die professionelle Entwicklung Ihres EA-Teams ausgerichtet. Gute Unternehmensarchitekten nutzen ein breites Spektrum an Fähigkeiten, Methoden und spezialisiertem Fachwissen zur Entwicklung von [...]
Schulungskurs Geschäftsarchitektur
Business Architecture Training Eine effektive Unternehmensarchitektur beruht auf der Geschäftsarchitektur. Der Kurs vermittelt den Teilnehmern die Fähigkeiten und das Wissen, um eine Geschäftsarchitektur im Rahmen einer Unternehmensarchitektur zu entwickeln. Die Unternehmensarchitektur umfasst die Beschreibung der Struktur des [...]
TOGAF-Schulung zur Unternehmensarchitektur
Sie möchten eine Schulung für die TOGAF-Zertifizierung? Beweisen Sie Ihr Wissen über Unternehmensarchitektur mit der TOGAF-Zertifizierung TOGAF® Enterprise Architecture Training Course Machen Sie einen großen Schritt, um ein besserer Unternehmensarchitekt zu werden mit TOGAF Standard, 10.
Unternehmensarchitektur und Agile – Sprints einschränken
Wir unterstützen agile Teams nicht mehr nur bei der Verwaltung ihres Rückens, sondern greifen auch in den Sprint ein. Hier müssen wir Architekturspezifikationen in die Software einbringen. Dies müssen wir tun, ohne die Kreativität und Innovation des agilen Teams zu beeinträchtigen.
Jede Architekturspezifikation schränkt einen gewissen Freiheitsgrad ein. Wenn wir ihre Freiheit einschränken, erschweren wir es dem agilen Team, den effizientesten Weg zu finden. Wenn Einschränkungen die Unternehmensprioritäten bestimmen, erleichtern wir die Suche nach dem besten Weg.
Es gibt eine Grundregel: Entfernen Sie niemals einen Freiheitsgrad, wenn es nicht unbedingt nötig ist
Innovations- und Gestaltungsfreiheit sind das Lebenselixier der agilen Softwareentwicklung
Es gibt eine erweiterte Regel: Scheuen Sie sich nie, einem agilen Team ein wirklich schwieriges Problem zu stellen
Innovation und Kreativität schaffen Lösungen, die Sie sich nicht vorstellen können
Vorhersehbares Problem: Sicherstellen, dass die für den agilen Erfolg entscheidenden Entscheidungen im Sprint die Prioritäten, Präferenzen und Einschränkungen der Organisation berücksichtigen und von ihnen geleitet werden.
Harte Teile: Ein Gleichgewicht zwischen Unternehmensanforderungen und Eingriffen in die erforderliche Design- und Ansatzfreiheit finden. Dies gilt insbesondere für Architekten mit Entwicklungshintergrund. Fachkompetenz führt dazu, dass Unternehmensspezifikationen nicht mehr in das Design einfließen. Dies führt zu einer schlechten Big-Up-Front-Architektur.
Enterprise-Architekten, die die Projekt- und Lösungsbereitstellung unterstützen, müssen mit eingeschränkten Sprints rechnen. Architekten, die sich auf ein Produktökosystem oder eine Plattform konzentrieren, müssen ebenfalls mit der Zusammenarbeit mit agilen Teams rechnen.
Akzeptanzkriterienmuster
Vorhersehbares Problem: Sicherstellen, dass die Software den Spezifikationen und Standards der Unternehmensarchitektur entspricht.
Ansatz: Bereitstellung verbindlicher Abnahmekriterien, die am Ende von Epics und vor der Veröffentlichung gelten. Wir haben oft Anwendungsarchitekturmuster und Datenarchitekturmuster um Akzeptanzkriterien zu erstellen. Nehmen Sie in alle Testberichte obligatorische Akzeptanzkriterien auf.
Harte Teile: Wissen, wann verbindliche Abnahmekriterien durchgesetzt werden müssen. Zu früh verzerrt die Entwicklung. Zu spät führt zu Druck für Release-Ausnahmen. Dies gilt insbesondere für interne digitale Produkte, die keine wirklich vorhersehbaren Release-Zyklen haben.
Wir klassifizieren unsere Architekturspezifikationen wie folgt:
-
- Architekturprinzip
- Architekturmuster
- Standard
- Regel
Die meisten obligatorischen Akzeptanzkriterien müssen Architekturmuster oder -standards sein.
Vergessen Sie nie, aus dem Weg zu gehen und die Kreativität zu ernten.
Wert (Maße und Ruhepunkte) Muster
Vorhersehbares Problem: Verstehen, was geschätzt wird und wie der Wert gemessen wird.
Ansatz: Die Unternehmensarchitektur muss eindeutig festlegen, wie der Wert beschrieben und gemessen wird. Wertaussagen erfordern kritische Erfolgsfaktoren (CSF) und Effektivitätsmaße (MoE). Stellen Sie sicher, dass Wertmaße in die Produkt-, Epic- und Release-Berichte einbezogen werden.
Harte Teile: Zu viele IT-Experten haben ein begrenztes Verständnis von Wert. Sie verwenden eine schnelle Abkürzung, die den Wert anhand der gelieferten Leistung ausdrückt. Der Wert ergibt sich aus der Leistung selbst.
In einer komplexen Welt kann jede einzelne Lieferung den Wert mindern. Ein einfaches Beispiel sind Funktionen, die sich an Benutzer richten, die nicht zur Zielgruppe gehören. Oder wenn eine Arbeitseinheit Funktionen anfordert, die ihre Arbeit auf Kosten des Systems vereinfachen.
Wir empfehlen dringend grundlegende Lean- und Six-Sigma-Praktiken. Berücksichtigen Sie die Definition und Quantifizierung von Werten. Achten Sie auf lokale Optimierungsmöglichkeiten. Die Konzepte ’Zielkunde“ und „Wertversprechen“ des Business Model Canvas sind sehr hilfreich.
Greenfield, Evolution oder Revolution
In Phase E von TOGAF, gibt es einen coolen Schritt. Schauen Sie sich das Arbeitspaket an und wählen Sie eine geeignete Strategie – Greenfield, Evolutionär oder Revolutionär. Wollen Sie so viel wie möglich erhalten, radikal umgestalten oder von vorne beginnen?
Dies geschieht im Rahmen der Produktportfolio- und Ökosystemplanung. Es ist eine wichtige Orientierungshilfe und stellt eine starke Einschränkung für ein agiles Team dar. Sollen sie bei Null anfangen (Greenfield)? Die bestehenden Systeme schrittweise verbessern (Evolution)? Oder radikale Veränderungen durchführen, die die bisherigen Reibungspunkte und Probleme beseitigen (Revolution)?
Vorhersehbares Problem: Sicherstellen, dass die Implementierungsstrategie befolgt wird.
Ansatz: Verwenden Sie Produkt-Roadmaps und Release-Zyklen, um radikale Änderungen im Ansatz durchzusetzen.
Hartes Stück: Ausrichtung der Top-Down-Architekturänderungen an einer Produkt-Roadmap. Dies ist besonders schwierig, wenn Entscheidungen zur Unterstützung der Strategie oder des Portfolios eine Änderung des Produktansatzes erfordern. Wir mussten viel Zeit darauf verwenden, den Eigentümern digitaler Produkte und über sie ihren Teams zu versichern, dass die bisherige Anstrengung nicht umsonst war.
Schnittstellenmuster einschränken
Wenn ein Produkt in eine bestehende Unternehmensumgebung passen oder eine sich entwickelnde Unternehmensumgebung unterstützen muss, sind Schnittstellen entscheidend. Schnittstellen werden durch Daten und Methoden gesteuert. In einer komplexen Welt wird selbst bei neu entstehenden Produkten die Freiheit zur Entwicklung von Datenstrukturen und Schnittstellen nicht gegeben sein. Stammdaten, Referenzdaten und bestehende Systeme schränken die agile Entwicklung ein.
Bestehende Systeme werden nicht verändert. Die Investitionen fließen in neue Systeme. Das neue System muss sich integrieren. Selbst die F-22 Raptor musste über in den 1970er Jahren entwickelte Schnittstellen mit Altsystemen verbunden werden. Nicht einmal ein so teures Flugzeug konnte mit Altsystemen modernisiert werden.
Vorhersehbares Problem: Erforderliche Schnittstellen identifizieren und deren Nutzung sicherstellen.
Ansatz: Fokussieren Sie die Top-Down-Arbeit auf Schnittstellen und gemeinsame Datenstrukturen. Geben Sie Anforderungen über Epic- und Release-Zyklen ein. Verwenden Sie Akzeptanzkriterien. Wir haben oft verwendet Anwendungsarchitekturmuster und Datenarchitekturmuster bis hin zu leicht spezifischen Schnittstellen. Fügen Sie die Schnittstellenkonformität in alle Testberichte ein.
Hartes Stück: Schnittstellen sind einer der Punkte, an denen in der Regel eine Top-Down-Vorausplanung erforderlich ist. Es muss sichergestellt werden, dass eine solide API-Infrastruktur, veröffentlichte APIs und Datenstrukturen für Stammdaten, Referenzdaten und Transaktionsdatensätze vorhanden sind.
Schnelllebige Produktteams übersehen oft die Gesetzgebung in mehreren Rechtsgebieten oder einen expandierenden Marktplan. In diesen Fällen ist das EA-Team verpflichtet, vorausschauend zu denken. In der Regel sind wir mit radikalem Refactoring zufriedener als mit vorausschauender Planung. Insbesondere, wenn wir Modularität und Schnittstellen durchgesetzt haben.
Unternehmensarchitektur und Agile – Abhängigkeiten lösen
Agile Teams und die auf digitale Produkte fokussierte Entwicklung eignen sich nicht zur Lösung von Problemen innerhalb eines Ökosystems oder Produktportfolios. Das grundlegende Konzept agiler Methoden besteht darin, dass ein einzelnes Team Probleme zerlegt und direkt löst. Es gibt zwar Konzepte für Team-of-Teams, diese haben jedoch Schwierigkeiten, den Übergang aus der aktuellen Situation herauszuholen.
Jedes Architekturteam muss Verantwortung für die Lösung produktübergreifender Probleme übernehmen. Agile Entwicklung und moderne Integration machen diesen Service wichtiger denn je.
Entsperren Sie das Portfolio-Muster
Vorhersehbares Problem: Konflikte im gesamten digitalen Produktportfolio blockieren den Fortschritt mehrerer Produkte.
Ansatz: Verwenden Sie Techniken der Unternehmensarchitektur, um die minimalen Änderungen zu finden, die einen Fortschritt ermöglichen.
Harte Teile: Die größte Herausforderung ist das Timing. Kreative, agile Entwicklungsteams arbeiten nach bewährten Methoden an der Lösung des Problems. Tritt das Problem jedoch auf, stellt es in der Regel einen kritischen Blocker dar, der mit vielen technischen Schulden verbunden ist.
Das EA-Team muss sich auf inkrementelle Übergangszustände konzentrieren, um Fortschritte im gesamten Produktportfolio zu ermöglichen.
Identifizieren Sie das echte Stakeholder-Muster
Vorhersehbares Problem: Identifizierung des wahren Stakeholders, der für ein komplexes internes Produktportfolio Anleitung und Genehmigung geben kann.
Ansatz: Verwenden Sie Enterprise-Architektur-Techniken, um Stakeholder und Stakeholder-Agenten, Anliegen und Präferenzen zu identifizieren. Verwenden Sie Enterprise-Architektur-Techniken von Alternativen und Abtausch die Stakeholder zu einer Entscheidung zu führen, die das Produktportfolio lenkt. Sorgen Sie für eine effektive digitale Portfolio-Governance.
Harte Teile: Wir können davon ausgehen, dass digitale Produktteams über lokale Autoritätsquellen und ein vereinfachtes Entscheidungsmodell verfügen. Darüber hinaus werden ihre Kommunikation und Bewertung IT-orientiert und taktisch sein.
Das EA-Team muss eine effektive Governance im gesamten digitalen Portfolio sicherstellen und sich mit den Autoritätsstrukturen für digitale Produkte auseinandersetzen. EA-Teams verfügen nicht über die besondere Fähigkeit, Stakeholder einzubinden. Sie sind jedoch in der Lage, die Anliegen der Stakeholder durch eine überlegene Architektur zu vertreten.
Überqueren Sie das Portfolio-Muster
Vorhersehbares Problem: Aus lokal optimierten taktischen Entscheidungen kann kein effektives und nachhaltiges digitales Ökosystem entstehen.
Ansatz: Gerade genug beibehalten Anwendungsarchitektur und Datenarchitektur. Setzen Sie in dieser Architektur organisatorische Prioritäten. Die Anwendungsarchitektur muss sich auf gemeinsam genutzte Dienste und Schnittstellen konzentrieren. Die Datenarchitektur muss sich auf Stammdaten, Referenzdaten und Daten mit hoher Sicherheitsklassifizierung konzentrieren. Metadatenbeschreibungen sind erforderlich. Verwenden Sie Architekturmuster, die den Ökosystemansatz spezifizieren.
Harte Teile: Die Erweiterung des Portfolios erfordert die Vereinbarkeit zweier widersprüchlicher Realitäten. Erstens entstand der agile Ansatz aufgrund des beobachteten Versagens detaillierter Top-down-Unternehmenskonzepte. Zweitens können neu entstehende lokal optimierte Lösungen ohne starken Evolutionsdruck und Entwicklungszeit keine effizienten komplexen Systeme aufbauen.
Der einzige skalierbare Ansatz ist ‘gerade genug.’Gerade genug“ bedeutet, die organisatorische Priorität durchzusetzen und vorhersehbare Probleme zu vermeiden. Wenn Ihre organisatorische Priorität beispielsweise auf Nachhaltigkeit liegt, muss Ihre Anwendungsarchitektur Modularität und die Verwendung einer isolierten Infrastruktur wie einem API-Gateway erzwingen.
„Genug“ bedeutet, sich aus dem Produktdesign herauszuhalten. Stattdessen müssen Sie Architekturmuster verwenden, die das gesamte Portfolio abdecken.
Gerade genug bedeutet, potenzielle Synergien zu ignorieren. Versuche, sich eine komplexe Zukunft vorzustellen, geraten oft zur Farce. Synergien sind am schwierigsten zu finden. Unsere gesamte Arbeit an Architektur-Roadmaps beweist, dass man immer die Rechnung für etwas bezahlt, um davon zu profitieren. Der Wert von Synergien ist gering, wenn Unsicherheit herrscht.
Gerade genug bedeutet, sich auf vorhersehbare Probleme zu konzentrieren. Niemand hat jemals einen verteilten Kundenstamm ohne Referenzdaten erstellt. Niemals. Das ist ein Problem vorhersehbarer Daten. Lösen Sie es frühzeitig. Es lohnt sich, vorhersehbare Probleme zu vermeiden.
Gerade genug bedeutet, keine Angst vor Marktkräften und kreativer Zerstörung zu haben. Wir verwenden das Konzept des erwarteten Lebenszyklus, um hervorzuheben, wo im Ökosystem wir regelmäßig aggressives Refactoring (Greenfield- und revolutionäre Ansätze) durchführen werden.
Release-Auswirkungsmuster
Vorhersehbares Problem: „Genug Architektur“ bedeutet, dass nicht jede Eventualität, jede Einschränkung und jeder Konflikt vor der Veröffentlichung entdeckt wurde.
Ansatz: Stecken Sie die Hände in die Taschen und warten Sie, bis Sie während der Problemlösung angerufen werden. Warten Sie, bis Sie angerufen werden, mit der Einschaltung während der Vorfallsprüfung, um herauszufinden, wo Sie ein vorhersehbares Problem nicht erkannt, ein Risiko unterschätzt oder eine Testanforderung übersehen haben.
Harte Teile: Es gibt einen Fall, in dem ein Architekturteam in einen Notfall geraten kann. Diese seltenen Fälle, in denen die Auswirkungen über das Produkt hinausgehen. Wenn die Endbenutzer den Fehler umgehen, liegt kein Notfall vor. Wenn sie jedoch Schwachstellen und Haftungsrisiken schaffen, liegt ein Notfall vor.
Nutzen Sie eine gute Lücken-, Arbeitspaket- und Wert-Ruhepunkt-Technik. Suchen Sie nach der kleinsten Veränderung, die einen nutzbaren Wert bietet. In diesem Fall bedeutet Wert, Bedrohungen und Risiken zu beseitigen.
Fazit zu Enterprise Architecture und Agile
Sowohl Enterprise-Architektur als auch Agile leiden unter chronischer Fehlanwendung. Zu oft gleichzeitig. Passen Sie Ihren Ansatz so an, dass Ihre agilen und Unternehmensarchitektur Bemühungen verringern die Erfolgsunsicherheit.
Suchen Sie als Unternehmensarchitekt nach Möglichkeiten, mit einem inkrementellen Ansatz die Wahrscheinlichkeit und die Kosten von Fehlern zu senken. Wenn Sie die Kosten fehlgeschlagener Änderungsbemühungen senken, vermeiden Sie Verschwendung. 100% Ihrer vergeblichen Änderungsbemühungen mindern den Wert der Änderung.
Die Rechnung ist einfach: Der Nutzen ist gleich geblieben, der Aufwand hat zugenommen. Unter dem Strich bleibt der Wert geringer.
Die einfache Antwort lautet: Nutzen Sie Ihre Stärken. Und erwarten Sie, dass das agile Team seine Stärken ausspielt.
Unternehmensarchitektur und Agile weisen vier Engagementmuster auf oberster Ebene auf:
- Definition des agilen Ansatzes
- Steuerung des Backlogs im Sprint
- Einschränkung der agilen Sprints
- Lösen der produktübergreifenden Abhängigkeit
Die Auswahl des Musters wird durch Ihre Anwendungsfall für Unternehmensarchitektur Die Design Ihres EA-Teams.
Mit Unternehmensarchitektur und Agilität weiterkommen
Weiter gehen Beweglichkeit unterscheidet sich von der agilen Softwareentwicklung. Enterprise Architecture und Agile passen in drei Bereichen zusammen:
- Entwerfen Sie ein agiles Unternehmen
- agile Arbeitspraktiken zur Entwicklung einer Best-Practice-Unternehmensarchitektur
- Agile Softwareentwicklung & Unternehmensarchitektur
