Unternehmensarchitektur und Agilität verstehen
Wie passen Unternehmensarchitektur und Agile zusammen?
Unternehmensarchitektur und Agile – Definieren Sie den agilen Ansatz
Unternehmensarchitektur und Agile – Leitfaden Backlog in Sprint
Unternehmensarchitektur und Agilität – Sprints einschränken
Wie passen Unternehmensarchitektur und Agile zusammen?
Unternehmensarchitektur und Agilität passen auf unerwartete Weise zusammen. Die agile Methode steht jetzt im Fokus. Die Schritte zur Erstellung einer funktionsfähigen Versandsoftware. Aus dieser Perspektive stellt sich die Frage: Was leistet Unternehmensarchitektur heute? Was beschleunigt es, um den Versand von Software zu beschleunigen?
Unternehmensarchitektur und Agilität passen im Sprint nicht zusammen. Sie passen außerhalb des Entwicklungszyklus zusammen. Sie fügen sich zusammen, indem die Unternehmensarchitekten und die agilen Entwickler ihre Arbeit erledigen. Erfolgreiche EA-Teams erfüllen ihre Ziele Anwendungsfall. Sie liefern nichts anderes. Auch wenn sie es könnten.
Wir verfügen über eine einfache Unternehmensarchitektur und ein agiles Referenzmodell. Es gibt vier Kernmuster für das Engagement in der Unternehmensarchitektur:
- Definieren des agilen Vorgehens
- Führen des Rückstands im Sprint
- Einschränkung der agilen Sprints
- Lösung für produktübergreifende Abhängigkeiten
In den letzten Jahren wurde daran gearbeitet Digitale Transformation Für unsere Initiativen haben wir eine Reihe von Engagement-Mustern entwickelt.
Wie nutzt man diese Engagement-Muster?
Schauen Sie sich zunächst Ihren EA-Anwendungsfall an. Welche Beratung wird von Ihnen erwartet? Wem dienen Sie? Schauen Sie sich dann die Engagementmuster an, die Ihren beruflichen Herausforderungen gerecht werden. Beziehen Sie sie in Ihr Engagement ein.
Unsere Architekturmustervorlage hat zwei Schlüsselelemente: die vorhersehbares Problem und das Ansatz zur Lösung des Problems. Wir sammeln auch die harte Teile. Wenn wir über ein Muster nachdenken, achten wir darauf, wie gut es das Problem löst und wie viel zusätzliche Arbeit erforderlich ist, um das Muster erfolgreich anzuwenden.
Schauen wir uns die Engagement-Muster an. Das Problem, das sie lösen, der Ansatz und die schwierigen Aspekte.
- Definieren des agilen Vorgehens
- Führen des Rückstands im Sprint
- Einschränkung der agilen Sprints
- Lösung für produktübergreifende Abhängigkeiten
Praxisbeispiel: Agile Entwicklung auf der Enterprise Architecture Roadmap
Ich hatte ein amüsantes Gespräch mit dem neu eingestellten Systems Reliability Engineer. Der SRE-Spezialist war begeistert. Endlich haben wir mit modernen Praktiken begonnen: CI/CD und automatisiertes Testen. Sie fragte mich, was das EA-Team tat, um zu helfen?
Ich musste lächeln, als sie fragte: „Was unternimmt das EA-Team, um zu helfen?„Was sie wirklich meinte war:“Was tust du heute, um mich zu unterstützen?„Heute, was ihre unmittelbaren Herausforderungen betrifft, nichts.“ Sie war bei der Umsetzung dabei. Sie war auf der Suche nach einer Umsetzung.
Sie verstand nicht, wie sich die Organisation entwickelte. Sie war sich dessen nicht bewusst Portfolio-Roadmap. Die Roadmap enthielt einen Übergangspunkt, den wir gerade erreicht hatten. Wir hatten Container, Testdatenmanagement und eine schwache automatisierte Testsuite eingeführt. Sie war sich nicht darüber im Klaren, dass die altmodische Top-Down-Planung die Umstände für ihren neuen Job geschaffen hatte.
Sie dachte an die unmittelbare Entwicklung. Ich dachte an das Ganze digitale Transformation. Ihre Rolle 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 werden. Ich bewegte mich von Definieren des agilen Vorgehens. Ich brauchte Hilfe um 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 dachten, sie würden einen Mehrwert liefern
Laden Sie den KI-Leitfaden für Führungskräfte herunter
Laden Sie den Leitfaden für Führungskräfte zur künstlichen Intelligenz herunter. Organisationen, die innovative Technologie erfolgreich anwenden, haben einen Wettbewerbsvorteil. Innovative Technologie geht nicht mit etablierten Erfolgsmustern und Best Practices einher. Innovative Technologie ist neuartig und […]
Laden Sie die Einführung in den TOGAF-Standard, 10. Ausgabe, herunter
Herunterladen Einführung in den TOGAF®-Standard, 10. Ausgabe Der TOGAF-Standard, 10. Ausgabe, erleichtert die Einführung von Best Practices für Unternehmensarchitekturen. Es trennt die universellen Konzepte von bewährten Best Practices. Der Standard-Unterstrich wo […]
Laden Sie den Leitfaden zur fähigkeitsbasierten Planung herunter
Laden Sie den Leitfaden zur fähigkeitsbasierten Planung herunter. Streben Sie stets danach, Werte zu realisieren. Eine halbe Verbesserung ist 100% Verschwendung! Niemand bringt einem Adler das Krabbeln, Gehen oder Laufen bei. Adler fliegen! Laden Sie „Teach your Eagles to Fly: Capability-based Planning“ herunter […]
Laden Sie den Leitfaden zur Bewertung der Geschäftsarchitektur herunter
Leitfaden zur Bewertung der Geschäftsarchitektur herunterladen Laden Sie einen Leitfaden zur Bewertung der Geschäftsarchitektur herunter. Die fähigkeitsbasierte Planung ist eine der leistungsstärksten Techniken zur Verbesserung der Geschäftsarchitektur. Best Practice der fähigkeitsbasierten Planung nutzt Fähigkeit als Management […]
Laden Sie Beispiele für Prinzipien der Unternehmensarchitektur herunter
Beispielprinzipien für die Architektur herunterladen Laden Sie ein Beispiel für Prinzipien der Unternehmensarchitektur herunter. Die Prinzipien der Unternehmensarchitektur legen fest, wie man ein Problem oder eine Entscheidung angeht. Der Ansatz treibt Sie immer zu Ihren dauerhaften Prioritäten. Beispielprinzipien der Unternehmensarchitektur herunterladen […]
Laden Sie den Governance-Leitfaden für Unternehmensarchitekturen herunter
Leitfaden zur Unternehmensarchitektur-Governance herunterladen Laden Sie den Leitfaden zur Unternehmensarchitektur-Governance herunter, um Best Practices zur Lenkung und Kontrolle der Entwicklung von Architekturen und Änderungen zu verstehen, um die erwarteten Ergebnisse zu erzielen. Governance-Leitfaden für Unternehmensarchitektur herunterladen […]
Laden Sie die TOGAF- und SABSA-Integration herunter
TOGAF- und SABSA-Integration herunterladen Bringen Sie SABSA, das weltweit beste Sicherheitsarchitektur-Framework, und TOGAF, das Industriestandard-Unternehmensarchitektur-Framework, zusammen. TOGAF- und SABSA-Integration herunterladen TOGAF- und SABSA-Integration Beinhaltet SABSA verwendet ein […]
Laden Sie die Enterprise Architecture Capability Reference Architecture herunter
Laden Sie die Referenzarchitektur „Enterprise Architecture Capability“ herunter. Die Referenzarchitektur „Enterprise Architecture Capability“ beschleunigt den Aufbau und die Weiterentwicklung Ihres EA-Teams. Gestalten Sie Ihr Enterprise-Architecture-Team für den Erfolg. Identifizieren und verbessern Sie die Architektur Ihres Unternehmens […]
Laden Sie den Agile Enterprise Architecture Report herunter
Laden Sie den Agile Enterprise Architecture Report herunter Der Agile Enterprise Architecture Report deckt unsere Erfahrung ab – Agile Enterprise Architecture ist real, praktisch und wertvoll. Wir tun es jeden Tag. Erfahrungsberichte überbrücken die theoretischen Konzepte und […]
Fallstudie zur agilen Unternehmensarchitektur herunterladen
Laden Sie die Fallstudie „Agile Unternehmensarchitektur“ herunter Laden Sie die Fallstudie „Agile Unternehmensarchitektur“ herunter, um ein Beispiel für die gleichzeitige Entwicklung einer EA-Fähigkeit und einer nützlichen Architektur zu sehen. Wir decken alle sechs Anwendungsfälle ab […]
Unternehmensarchitektur und Agile – Definieren Sie den agilen Ansatz
Agilität ist eine Wahl. Es hat Vor- und Nachteile. Die Einführung von Agile erfordert Entscheidungen über Produkt, Plattform, Servicebereitstellungsstrategie und Top-Down-Übergangspunkte.
Ein EA-Team braucht die Fähigkeit zu unterstützen Strategie und Portfolio Zu Definieren Sie den agilen Ansatz.
Vorhersehbares Problem: Wann verwenden Sie Agile?
Produktmuster
Externe Produkte sind einfacher als interne Produkte. Kurz gesagt, es gibt einen Markt. Intern treibt der Einsatz von Agile das interne System in digitale Produkte voran. Die Existenz, der Umfang und der 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 eine Reihe von Wertkennzahlen für interne Produkte. Produkte sollten auf der angezeigt werden Architekturfahrplan.
Plattformmuster
Plattformen können die Entwicklungsgeschwindigkeit und Nachhaltigkeit verbessern. Eine schlecht ausgewählte Plattform führt jedoch zum gegenteiligen Ergebnis. Es ist nicht die Entscheidung eines agilen Teams, ob es eine Plattform nutzt, geschweige denn welche Plattform. Wir haben den Begriff Plattform verwendet, um SAP, M365, Facebook, Pega oder sogar Open Shift Containers abzudecken.
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
-
- Verwenden Sie zur Auswahl eine Architekturalternative. Die wichtigsten Anliegen werden Vertrauen, Nachhaltigkeit, Markteinführungszeit und Geschäftskontinuität sein
- Plattform nutzen Referenzarchitektur um die Vollständigkeit des Produktdesigns sicherzustellen und das Schließen aller Lücken zu beurteilen
Harte Teile: Frage der Unterstützung und Nachhaltigkeit des Produkts und der Plattform.
Muster der Servicebereitstellungsstrategie
Eine Servicebereitstellungsstrategie bezieht sich auf den Ansatz, den Organisationen zur Bereitstellung von Produkten oder Dienstleistungen verwenden. Es ist nicht selbstverständlich, dass Sie Ihren aktuellen Ansatz wählen – intern, vertraglich, Personalaufstockung.
Vorhersehbares Problem: Wie wird Ihre Organisation eine agile Entwicklung durchführen?
Ansatz: Befolgen Sie die Ansätze der Architektur zur Unterstützung der Strategie. Stellen Sie die Frage, wie eine agile Entwicklung ermöglicht werden soll. Benutze ein Betriebsmodell Wert und einen definieren Organisationskarte um zu definieren, wie die verschiedenen Verbraucher, Entwickler und Betreiber eines Produkts zusammenarbeiten.
Hauptwert-Ruhepunktmuster
Bei der agilen Entwicklung ist die Wahrscheinlichkeit nicht geringer als bei jedem anderen Ansatz, dass man weiß, wann man aufhören muss. Value Resting Points sind ein Synonym für Architekturübergänge. Wir verwenden diesen Begriff, um hervorzuheben, dass der Stakeholder einen Ausweg hat und mit der Investition aufhören kann. Stakeholder werden die Ausfahrten aus mehreren Gründen nutzen:
-
- Wenn die Anstrengung zum Erreichen des nächsten Ruhepunkts den inkrementellen Wert überschreitet.
Dies ist ein ROI-Gespräch. ROI-Gespräche führen in der Regel zu einer Änderung der Priorität. - Wenn der gleiche Aufwand genutzt werden kann, um ein wertvolleres Ergebnis zu erzielen
- Wenn sich organisatorische Prioritäten geändert haben (Führung)
- Wenn es eine unerwartete Bedrohung oder Chance gibt (Unternehmensagilität)
- Wenn die Anstrengung zum Erreichen des nächsten Ruhepunkts den inkrementellen Wert überschreitet.
Vorhersehbares Problem: Den Ruhepunkt kennen, um anzuhalten oder den Fokus zu ändern
Ansatz: Nutzen Sie Architektur-Roadmaps, um alternative Wertschöpfungspunkte zu erkunden. Erstellen Sie Berichte über Aktivitäten in Richtung Übergangsstaaten.
Harte Teile: Zu berücksichtigen sind der Vergleichswert im Ruhezustand und der potenzielle Wert als Sprungbrett für andere Aktivitäten. Implementierer verstehen diese Gespräche selten. Sie werden emotional an einen Weg oder Ruhepunkt gebunden. Vor allem, wenn es um die Existenz des Produkts oder die nächste Veröffentlichung geht. Führungskräfte sind immer auf der Suche nach dem besten Weg nach vorn und nicht nach der höchsten potenziellen Rendite. 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 Aufschieben unsicherer Entscheidungen). Identifizieren Sie dann, was erforderlich ist, um zu verschiedenen ausgewählten Wertruhepunkten zu gelangen.
-
- Welche Änderung sollte angesichts unterschiedlicher Kriterien angestrebt werden?Architektur-Roadmap Typ 4: Szenarien
- Welche Arbeit wird einen Mehrwert liefern, welche Kosten und welche Unsicherheit entstehen?Architektur-Roadmap Typ 1: Heatmap
- Welche Entscheidungen werden aufgeschoben –Architektur-Roadmap Typ 4: Szenarien
- Wann wird der Wert geliefert?Übergangsstaaten
Gehen Sie noch einen Schritt weiter mit Best Practice-Prozessen und -Methoden für die Unternehmensarchitektur
Beste Übung Unternehmensstruktur aus Conexiam navigieren
Einrichten eines Prüfungsgremiums für moderne Architektur
Einrichten eines modernen Architekturprüfungsgremiums Um ein modernes Architekturprüfungsgremium einzurichten, ist die Schaffung eines dynamischen Governance-Prozesses und die Einrichtung eines Entscheidungsgremiums auf höchster Ebene erforderlich, das als Rückhalt fungiert. Ziel ist die Einrichtung einer effektiven Architektur-Governance ohne Bürokratie. […]
Erschließen Sie Ihr Geschäftspotenzial: So erstellen Sie eine effektive Fähigkeitskarte
Erschließen Sie Ihr Geschäftspotenzial: So erstellen Sie eine effektive Fähigkeitskarte. Fällt es Ihnen schwer, die Fähigkeiten zu identifizieren, die Sie benötigen, um Ihr Unternehmen auf die nächste Stufe zu bringen? Finden Sie es schwierig, Ressourcen aufeinander abzustimmen?
Enterprise Architecture Framework Vergleich: Welches ist das Richtige für Sie?
Vergleich von Enterprise-Architektur-Frameworks: Welches ist das Richtige für Sie? In der Wirtschaft gibt es keine Einheitslösung. Auch nicht bei Enterprise-Architektur-Frameworks. Vergleichen Sie die Vorzüge beliebter Frameworks, um herauszufinden, welches optimierte Framework das Richtige für Sie ist. Während […]
Intelligentere Entscheidungen treffen: Warum Ihr Unternehmen architektonische Entscheidungen benötigt
Intelligentere Entscheidungen treffen: Warum Ihr Unternehmen architektonische Entscheidungen braucht Unternehmen stehen ständig vor der Herausforderung, wichtige Entscheidungen zu treffen. Jeden Tag haben Entscheidungen, einschließlich betrieblicher Praktiken und Technologieauswahl, erhebliche Auswirkungen auf ein […]
Best Practices zur Implementierung von Enterprise Architecture Management Tools
Best Practices für die Implementierung von Enterprise-Architecture-Management-Tools Enterprise-Architecture-Management-Tools sollen die Planung, den Entwurf, die Analyse und die Ausführung von Unternehmensarchitektur unterstützen. Sie ermöglichen es Unternehmensarchitekten, den Änderungsbedarf zu untersuchen […]
Alles, was Sie über die Verwendung von Architekturalternativen wissen müssen
Alles, was Sie über die Verwendung von Architekturalternativen wissen müssen Architekturalternativen sind für eine gute Entwicklung von Unternehmensarchitekturen erforderlich. Wenn Sie mit der Architekturentwicklung beginnen, weist Ihr Unternehmen Mängel auf. Es gibt Bereiche für Verbesserungen. Du musst […]
Szenarioanalyse für die Unternehmensarchitektur nutzen
Szenarioanalyse für die Unternehmensarchitektur verwenden Ein Szenario ist einfach eine plausible Zukunft. Die Szenarioanalyse untersucht, wie wir zu einer plausiblen Zukunft gelangen und wie sich unterschiedliche Szenarien auf unsere aktuellen Entscheidungen auswirken. Szenarien helfen Führungskräften […]
Unternehmensarchitektur-Roadmap als Design
Enterprise Architecture Roadmap als Entwurf Eine Architecture Roadmap ist ein Planungstool, das den Entscheidungsträgern einer Organisation hilft. Eine dynamische Architecture Roadmap soll ihnen dabei helfen, den besten Weg nach vorne zu entwickeln und zu beschreiten. Sie […]
Entwicklung einer Strategie für die Unternehmensarchitektur
Entwicklung einer Strategie für die Unternehmensarchitektur: Strategischer Plan für Veränderungen Eine Strategie für die Unternehmensarchitektur ist eine Aktion. Die Maßnahmen, die Ihr Unternehmen ergreifen wird, und die Veränderungen, die Sie vornehmen werden, um Ihre strategischen Ziele zu erreichen. Bei der Strategieentwicklung geht es vor allem um Entscheidungen. […]
Unternehmensarchitektur und Agilität verstehen
Unternehmensarchitektur und Agile verstehen Sowohl agile als auch Unternehmensarchitektur sind darauf ausgelegt, Risiken zu reduzieren. Agile Softwareentwicklung zeichnet sich dadurch aus, dass sie etwas schafft, das wir noch nie zuvor hatten und von dem wir nicht wissen, wie man es baut. […]
Unternehmensarchitektur und Agile – Leitfaden Backlog in Sprint
Starke agile Teams finden den effektivsten Weg nach vorne. Aufgrund der Komplexität des Ökosystems sind längerfristige Planung und Budgetierung erforderlich. Die Herausforderung besteht darin, längerfristige Planung und agile Kreativität zu verbinden. Überbrücken Sie Top-Down-Planung und Bottom-Up-Ausführung.
Sie müssen über organisatorische Prioritäten informiert werden, die in das Backlog-Management einfließen können.
Agilität existiert, weil die Menschen, die der Lösung am nächsten stehen, den effektivsten Weg finden können. Erfolgreiche Organisationen führen Priorisierung und Kompromisse durch. Ohne die gewünschte Zukunft unter Zeit- und Ressourcenbeschränkungen zu erreichen, sollte keine Arbeit beginnen.
Ein EA-Team braucht die Fähigkeit zu unterstützen Portfolio und Projekt zu Guide-Rückstand im Sprint.
Vorhersehbares Problem: Sicherstellen, dass erwartete Ergebnisse, Werte, kaskadierte Leistungserwartungen und Einschränkungen die Veröffentlichung und Produktentwicklung leiten.
Schwieriges Stück: Zu viele Agile-Evangelisten sind überrascht, dass Organisationen, die Agile einführen, sich weiterhin stark für die Planung und längerfristige Budgetierung engagieren. Wir müssen oft die Mythologie überwinden, dass es kulturelle Vorlieben für Wasserfälle gibt.
Roadmap zur Anleitung des Produktmusters
Vorhersehbares Problem: Eine umfassende Produkt-Roadmap anstelle eines Feature-Release-Zyklus.
Ansatz: Mit einem Architektur-Roadmap-Technik wobei das Produkt oder die Produktfamilie das Portfolio ersetzt. Stellen Sie sicher, dass die normale Produktberichterstattung Aktivitäten in Bezug auf Ü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 ausweichen.
Zu viele Architekturteams tappen in die Falle künstlicher Präzision oder eingebildeter Allwissenheit. Beides sind ausgefallene Arten, Wasserfalldenken auszudrücken. Eine klassische Architektur-Roadmap wird von Übergängen, Lücken und Arbeitspaketen sprechen. Dies wird für ein Produktteam unverständlich sein. Ändern Sie die Sprache auf Produkt- und agile Terminologie. Der Produktbesitzer muss die Einschränkungen verstehen, denen er unterliegt.
Für die Erstellung der Roadmap ist ausreichend Architektur erforderlich. Der einzig 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 für das gesamte Portfolio geeignet sind. Gerade genug bedeutet, potenzielle Synergien zu ignorieren. Gerade genug bedeutet, sich auf vorhersehbare Probleme zu konzentrieren. Der Wert, vorhersehbaren Problemen auszuweichen, ist hoch. 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).
Der Einsatz der Techniken mit dem Product Owner hilft dabei, organisatorische Prioritäten und Einschränkungen in die Produkt-Roadmap einzubringen.
-
- Welches Produkt oder welche Schlüsselfunktionen sollten angesichts unterschiedlicher Kriterien angestrebt werden? Architektur-Roadmap Typ 4: Szenarien
- Welche Produkte oder Funktionen bieten einen Mehrwert (Nutzen, Arbeit usw.) Unsicherheit – Architektur-Roadmap Typ 1: Heatmap
- Wann sind Produkt- und Plattformänderungen erforderlich – Architektur-Roadmap Typ 2: Lebenszyklus
- Was ist die Abhängigkeit und Auswirkung von Arbeit und Veränderung – Architektur-Roadmap Typ 3: Auswirkung und Abhängigkeit
Roadmap zur Führung des epischen Musters
Vorhersehbares Problem: Verwendung von Epics zur Implementierung von Top-Down-Ergebnissen und Einschränkungen in das Produkt.
Ansatz: Verwendung gut konstruierter Übergangszustände in einem Architektur-Roadmap-Technik wobei das Produkt oder die Produktfamilie das Portfolio ersetzt. Stellen Sie sicher, dass die normale Produktberichterstattung Aktivitäten in Bezug auf Übergangszustände umfasst.
Harte Teile: Erfordert eng integrierte oder eng begrenzte Produkte. Der Schwerpunkt muss auf der Integration oder den Einschränkungspunkten liegen. Ein einfaches Beispiel ist die Koexistenz mehrerer Produkte innerhalb eines Ökosystems und die gemeinsame Nutzung von Referenzdaten.
Es kommt häufig vor, dass man in die Falle des voreiligen Designs tappt. 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 erfolgen und nicht als Reaktion auf technische Schulden.
Wenn uns dies gelungen ist, haben wir die Sprache von Methoden wie SaFE aktiv übernommen und die Roadmap in Bezug auf strategische Themen und Architekturpisten umrahmt.
Unternehmenswertmuster
Vorhersehbares Problem: Sicherstellen, dass die kritischen Erfolgsfaktoren, die in Übergangs- und Zielzuständen enthalten sind, als Leitfaden für agiles Backlog-Grooming und epische Planung dienen.
Ansatz: Übersetzen Sie Top-Down-Maßnahmen und -Ziele in umsetzbare Kriterien für das agile Backlog-Grooming. Stellen Sie sicher, dass die normale Produktberichterstattung die Auswahl und den Abschluss von Aktivitäten im Hinblick auf den angegebenen Wert umfasst.
Harte Teile: Die Top-Down-Maßnahmen müssen eindeutig und leicht zu beurteilen sein. Beispielsweise kann von einem agilen Team nicht verlangt werden, ein differenziertes Gleichgewicht zwischen Markteinführungszeit und Ausfallsicherheit zu entwickeln. Es ist eine eindeutige Terminologie erforderlich.
Jede Änderung der Top-down-Maßnahmen wird Verwirrung stiften. Dies gilt insbesondere dann, wenn ein Übergangszustand erreicht wurde.
Bei internen Produkten stellen wir stets sicher, dass wir über ein solides Kostenmodell für digitale Produkte verfügen, bevor wir Kostenmaßnahmen einführen. Ohne ein Kostenmodell gehen Betriebs- und Plattformkosten verloren und alle Kosten werden durch die Implementierungskosten gerechtfertigt. Planen Sie, dem internen Produktmanager dabei zu helfen ITFM verstehen. Im Gegensatz dazu verfügen Produktmanager externer digitaler Produkte normalerweise über ein sehr ausgeprägtes Kostenverständnis.
Beschränken Sie das Product Owner-Muster „von unten nach oben“.
Vorhersehbares Problem: Produktbesitzer, die das gesamte Unternehmen durch die Linse ihres Produkts und seiner direkten Benutzer betrachten.
Ansatz: Produkt und Rolle innerhalb des Ökosystems dokumentieren. Dokumentieren Sie Einschränkungen, die für das Produkt gelten. Kriterien für die Dokumentenbewertung. Stellen Sie sicher, dass die normale Produktberichterstattung Fortschritte in Richtung Übergangszustände und Aktivitäten umfasst, die auf den Unternehmenswert abgestimmt sind.
Harte Teile: Produktbesitzer interner digitaler Produkte sind oft ein schwaches Glied. Zu den häufigsten Herausforderungen gehört es, Folgendes nicht zu verstehen:
-
- 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 -wertkennzahlen
EA-Teams, die Portfolio und Projekte unterstützen, müssen höchstwahrscheinlich „Bottom-up“-Produktbesitzer einschränken. Es erfordert einen bewussten Einsatz und Personaleinsatz.
Enterprise Architecture Training und TOGAF Training
TOGAF-Schulungskurs für Unternehmensarchitektur
Möchten Sie eine Schulung zur TOGAF-Zertifizierung? Demonstrieren Sie Ihr Wissen über Unternehmensarchitektur mit der TOGAF-Zertifizierung. TOGAF® Enterprise Architecture-Schulungskurs Machen Sie einen großen Schritt, um ein besserer Unternehmensarchitekt zu werden mit TOGAF Standard, 10. […]
Avolution ABACUS-Schulungskurs
Avolution ABACUS Training Effektive Unternehmensarchitektur basiert auf formaler Modellierung und Analyse. Wir bieten Avolution ABACUS-Schulungen von praxisorientierten Unternehmensarchitekten an. Die Studierenden erwerben Fähigkeiten und Kenntnisse zur Erstellung integrierter Unternehmens- und Domänenarchitekturen in diesem […]
Schulungskurs für Unternehmensarchitektur
Business-Architektur-Schulung Effektive Unternehmensarchitektur basiert auf der Geschäftsarchitektur. Der Kurs vermittelt den Studierenden die Fähigkeiten und das Wissen, um eine Geschäftsarchitektur in einer Unternehmensarchitekturumgebung zu entwickeln. Bei der Geschäftsarchitektur geht es um die Beschreibung der Struktur des […]
Kickstart für Enterprise-Architekten
Kickstart für Enterprise-Architekten 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 bereitzustellen. Dieser 90-tägige Kickstart ist der Weg, den Conexiam Consulting […]
Benutzerdefinierte Schulung für Unternehmensarchitektur
Maßgeschneiderte Schulungen zu Unternehmensarchitekturen Maßgeschneiderte Schulungen zu Unternehmensarchitekturen zielen auf die berufliche Weiterentwicklung ab, die Ihr EA-Team benötigt. Gute Unternehmensarchitekten verwenden ein breites Spektrum an Fähigkeiten und Methoden sowie spezialisiertes Domänenwissen, um Unternehmen zu entwickeln […]
Effektive Online-Bildung
Effektive Online-Bildung Effektive Online-Bildung funktioniert. Studenten haben Zugang zum besten verfügbaren Lehrer. Studenten bestimmen ihr Lerntempo. Lehrer können reichhaltiges Zusatzmaterial bereitstellen, ohne vom Hauptthema abzulenken. Effektive Distanz […]
Unternehmensarchitektur und Agilität – Sprints einschränken
Wir gehen von der Unterstützung eines agilen Teams bei der Bewältigung des Problems zum Sprint über. Hier müssen wir Architekturspezifikationen in die Software einarbeiten. Wir müssen dies tun, ohne die Kreativität und Innovation des agilen Teams zu beeinträchtigen.
Jede Architekturspezifikation entfernt einen Freiheitsgrad. Wenn wir ihre Freiheit einschränken, erschweren wir es dem agilen Team, den effizientesten Weg zu finden. Wenn Einschränkungen die Prioritäten eines Unternehmens bestimmen, machen wir es einfacher, den besten Weg zu finden.
Es gibt eine Grundregel: Entfernen Sie niemals einen Freiheitsgrad, wenn dies nicht erforderlich ist
Innovations- und Gestaltungsfreiheit sind das Lebenselixier der agilen Softwareentwicklung
Es gibt eine erweiterte Regel: Haben Sie niemals Angst davor, 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 In-Sprint-Entscheidungen die Prioritäten, Präferenzen und Einschränkungen der Organisation kennen und von ihnen gesteuert werden.
Harte Teile: Finden eines Gleichgewichts zwischen Unternehmensanforderungen und Eingriffen in die erforderliche Design- und Ansatzfreiheit. Dies gilt insbesondere für Architekten mit Entwicklungshintergrund. Fachliche Fachkompetenz schafft einen schlüpfrigen Weg, der sich über die Unternehmensspezifikation hinaus in das Design einschleicht. Dies führt zu einer schlechten Big-Up-Front-Architektur.
Unternehmensarchitekten, die die Projekt- und Lösungsbereitstellung unterstützen, müssen damit rechnen, Sprints einzuschränken. Architekten, die sich auf ein Produktökosystem oder eine Produktplattform konzentrieren, sollten auch damit rechnen, mit den agilen Teams hier zusammenzuarbeiten.
Akzeptanzkriterienmuster
Vorhersehbares Problem: Sicherstellen, dass die Software den Spezifikationen und Standards der Unternehmensarchitektur entspricht.
Ansatz: Geben Sie verbindliche Akzeptanzkriterien an, die am Ende von Epics und vor der Veröffentlichung gelten. Wir haben es oft genutzt Anwendungsarchitekturmuster und Datenarchitekturmuster Akzeptanzkriterien zu schaffen. Nehmen Sie in allen Prüfberichten verbindliche Abnahmekriterien auf.
Harte Teile: Wissen, wann verbindliche Akzeptanzkriterien durchgesetzt werden müssen. Zu früh verzerrt die Entwicklung. Zu spät führt zu Druck auf Freigabeausnahmen. Dies gilt insbesondere für interne digitale Produkte, die keine wirklich vorhersehbaren Veröffentlichungszyklen haben.
Wir klassifizieren unsere Architekturspezifikationen als:
-
- 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 nutzen.
Wertmuster (Maße und Ruhepunkte).
Vorhersehbares Problem: Verstehen, was geschätzt wird und wie Wert gemessen wird.
Ansatz: Die Unternehmensarchitektur muss verbindlich sein, wie der Wert beschrieben und gemessen wird. Wertaussagen erfordern kritische Erfolgsfaktoren (CSF) und Wirksamkeitsmaßstäbe (MoE). Stellen Sie sicher, dass Wertkennzahlen in die Produkt-, Epic- und Release-Berichterstattung einbezogen werden.
Harte Teile: Für viele IT-Experten ist das Verständnis von Werten begrenzt. Sie verwenden eine kurze Abkürzung, die den Wert im Sinne einer Lieferung ausdrückt. Der Wert ist in der Lieferung selbstverständlich.
In einer komplexen Welt kann jede gelieferte Sache ihren Wert mindern. Ein einfaches Beispiel sind Funktionen, die sich an Benutzer richten, die keine Zielkunden sind. Oder wenn eine Arbeitseinheit nach Funktionen fragt, die ihre Tätigkeit auf Kosten des Systems vereinfachen.
Wir empfehlen dringend grundlegende Lean- und Six-Sigma-Praktiken. Schauen Sie sich die Definition und Quantifizierung von Wert an. Suchen Sie nach lokaler Optimierung. Die Konzepte Zielkunde und Wertversprechen des Business Model Canvas sind sehr hilfreich.
Greenfield, Evolution oder Revolution
In TOGAFs Phase E, es gibt einen coolen Schritt. Schauen Sie sich das Arbeitspaket an und wählen Sie eine geeignete Strategie aus – Greenfield, Evolutionary oder Revolutionary. Erwarten Sie, so viel wie möglich beizubehalten, radikal umzugestalten oder ganz von vorne zu beginnen?
Dies geschieht in der Produktportfolio- und Ökosystemplanung. Es ist eine entscheidende Orientierungshilfe und eine starke Einschränkung für ein agiles Team. Weisen Sie sie an, bei Null anzufangen (Greenfield)? Die bestehenden Systeme schrittweise verbessern (Evolution)? Oder radikale Veränderungen durchführen, von denen erwartet wird, dass sie die Reibungen und Probleme beseitigen, mit denen wir gelebt haben (revolutionär)?
Vorhersehbares Problem: Sicherstellen, dass die Umsetzungsstrategie eingehalten wird.
Ansatz: Nutzen 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 am schwierigsten, 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 durch sie und ihre Teams zu versichern, dass die vorherige 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 von entscheidender Bedeutung. Schnittstellen werden durch Daten und Methoden gesteuert. In einer komplexen Welt wird selbst ein neu entstehendes Produkt nicht die Freiheit haben, Datenstrukturen und Schnittstellen zu entwickeln. Stammdaten, Referenzdaten und bestehende Systeme werden die agile Entwicklung einschränken.
Bestehende Systeme werden sich nicht ändern. Die Investition erfolgt in neue Systeme. Es ist das neue System, das passen muss. Selbst der F-22 Raptor musste über in den 1970er Jahren entwickelte Schnittstellen eine Verbindung zu Altsystemen herstellen. Nicht einmal ein so teures Flugzeug wäre in der Lage, veraltete Systeme umzurüsten.
Vorhersehbares Problem: Erforderliche Schnittstellen identifizieren und deren Nutzung sicherstellen.
Ansatz: Konzentrieren Sie sich bei der Top-Down-Arbeit auf Schnittstellen und gemeinsame Datenstrukturen. Füttere Anforderungen über Epic- und Release-Zyklen. Verwenden Sie Akzeptanzkriterien. Wir haben es oft genutzt Anwendungsarchitekturmuster und Datenarchitekturmuster zu leicht spezifischen Schnittstellen. Beziehen Sie die Schnittstellenkonformität in alle Testberichte ein.
Hartes Stück: Schnittstellen gehören zu den Punkten, an denen in der Regel top-down vorausschauende Planung notwendig ist. Wir bemühen uns sicherzustellen, dass eine solide API-Infrastruktur, veröffentlichte APIs und Datenstrukturen für Stammdaten, Referenzdaten und Transaktionsdatensätze vorhanden sind.
Schnell agierende Produktteams übersehen oft die Gesetzgebung mehrerer Gerichtsbarkeiten oder einen Geschäftsplan für einen expandierenden Markt. In diesen Fällen hat das EA-Team die Pflicht, nach vorne zu schauen. In der Regel sind wir mit einer radikalen Umgestaltung zufriedener als mit einer vorausschauenden Planung. Insbesondere haben wir auf Modularität und Schnittstellen geachtet.
Unternehmensarchitektur und Agilität – Abhängigkeiten lösen
Agile Teams und eine auf digitale Produkte ausgerichtete Entwicklung sind nicht geeignet, Probleme in einem Ökosystem oder Produktportfolio zu lösen. Das grundlegende Konzept von Agile besteht darin, dass ein einzelnes Team Probleme aufschlüsselt und direkt löst. Es gibt Konzepte von Team-of-Teams, aber es fällt ihnen schwer, aus dem aktuellen Moment herauszukommen.
Jedes Architekturteam muss die Verantwortung für die Lösung produktübergreifender Probleme übernehmen. Agile Entwicklung und moderne Integration machen diesen Bedarfsservice wichtiger denn je.
Entsperren Sie das Portfolio-Muster
Vorhersehbares Problem: Konflikte im 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 Best-Practice-Agile-Entwicklungsteams werden daran arbeiten, das Problem zu lösen. Wenn das Problem auftaucht, handelt es sich in der Regel um einen kritischen Blocker mit mehreren technischen Schulden.
Das EA-Team muss sich auf inkrementelle Übergangszustände konzentrieren, um Fortschritte im gesamten Produktportfolio zu ermöglichen.
Identifizieren Sie das tatsächliche Stakeholder-Muster
Vorhersehbares Problem: Identifizieren des echten Stakeholders, der in einem komplexen internen Produktportfolio Orientierung und Zustimmung geben kann.
Ansatz: Verwenden Sie Techniken der Unternehmensarchitektur, um Stakeholder und Stakeholder-Agenten, Anliegen und Präferenzen zu identifizieren. Verwenden Sie Techniken der Unternehmensarchitektur von Alternativen und Abtausch um 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 Modell der Entscheidungsfindung und Entscheidungsbefugnis verfügen. Darüber hinaus erfolgt die Kommunikation und Beurteilung IT-orientiert und taktisch.
Das EA-Team muss daran arbeiten, eine effektive Governance über das gesamte digitale Portfolio hinweg sicherzustellen und mit den Autoritätsstrukturen für digitale Produkte zusammenzuarbeiten. Außerdem verfügen EA-Teams nicht über die besondere Fähigkeit, die Einbindung von Stakeholdern zu erreichen. Sie haben die Fähigkeit, die Anliegen der Stakeholder durch eine überlegene Architektur zu vertreten.
Überqueren Sie das Portfoliomuster
Vorhersehbares Problem: Lokal optimierte taktische Entscheidungen können nicht zu einem effektiven und nachhaltigen digitalen Ökosystem werden.
Ansatz: Behalten Sie gerade genug bei Anwendungsarchitektur und Datenarchitektur. Fördern Sie die organisatorische Priorität in dieser Architektur. Die Anwendungsarchitektur muss sich auf gemeinsam genutzte Dienste und Schnittstellen konzentrieren. Die Datenarchitektur muss sich auf Stammdaten, Referenzdaten und Daten mit hoher Sicherheitsklassifizierung konzentrieren. Erforderliche Metadatenbeschreibungen. Verwenden Sie Architekturmuster, die den Ökosystemansatz spezifizieren.
Harte Teile: Um das Portfolio zu kreuzen, müssen zwei widersprüchliche Realitäten in Einklang gebracht werden. Erstens entstand der agile Ansatz aufgrund des beobachteten Scheiterns eines detaillierten Top-Down-Unternehmensdesigns. Zweitens können neu entstehende lokal optimierte Lösungen ohne starken Evolutionsdruck und Zeit zur Weiterentwicklung keine effizienten komplexen Systeme aufbauen.
Der einzig skalierbare Ansatz ist „gerade genug.' Gerade genug bedeutet, organisatorische Prioritäten durchzusetzen und vorhersehbaren Problemen auszuweichen. Wenn Ihre organisatorische Priorität beispielsweise auf Nachhaltigkeit liegt, muss Ihre Anwendungsarchitektur Modularität und den Einsatz einer Isolationsinfrastruktur wie eines API-Gateways erzwingen.
Gerade genug bedeutet, sich aus dem Produktdesign herauszuhalten. Stattdessen müssen Sie Architekturmuster verwenden, die für das gesamte Portfolio geeignet sind.
Gerade genug bedeutet, potenzielle Synergien zu ignorieren. Es kommt häufig vor, dass Versuche, sich eine komplexe Zukunft vorzustellen, zur Farce werden. Synergien sind am schwierigsten zu finden. Unsere gesamte Architektur-Roadmap-Arbeit beweist, dass Sie immer die Rechnung für etwas bezahlen und möglicherweise auch davon profitieren. Der Wert der Synergie ist gering, wenn Unsicherheit angewendet wird.
Gerade genug bedeutet, sich auf vorhersehbare Probleme zu konzentrieren. Niemand hat jemals einen verteilten Kundenstamm ohne Referenzdaten erstellt. Immer. Das ist ein vorhersehbares Datenproblem. Lösen Sie es frühzeitig. Der Wert, vorhersehbaren Problemen auszuweichen, ist hoch.
Gerade genug bedeutet, keine Angst vor Marktkräften und kreativer Zerstörung zu haben. Wir verwenden ein Konzept des erwarteten Lebenszyklus, um hervorzuheben, wo im Ökosystem wir voraussichtlich regelmäßig aggressives Refactoring durchführen werden (Greenfield- und revolutionäre Ansätze).
Release-Impact-Muster
Vorhersehbares Problem: Gerade genug Architektur bedeutet, dass nicht jede Eventualität, jede Einschränkung, jeder Konflikt vor der Veröffentlichung entdeckt wurde.
Ansatz: Stecken Sie Ihre Hände in die Taschen und warten Sie, bis Sie während der Lösung aufgerufen werden. Sofern Sie nicht dazu aufgefordert werden, sollten Sie während der Vorfallüberprüfung warten, bis Sie eingreifen, um herauszufinden, wo Sie ein vorhersehbares Problem nicht erkannt, ein Risiko unterschätzt oder eine Testanforderung verpasst haben.
Harte Teile: Es gibt einen Fall, in dem ein Architekturteam einen Notfall haben könnte. Diese seltenen Fälle, in denen die Auswirkungen über das Produkt hinausgehen. Wenn die Endbenutzer den Fehler umgehen, liegt kein Notfall vor. Wenn sie Verwundbarkeit und Haftung schaffen, liegt ein Notfall vor.
Verwenden Sie eine gute Gap-, Arbeitspaket- und Value-Ruhe-Point-Technik. Suchen Sie nach der kleinsten Veränderung, die einen ertragbaren Wert bietet. In diesem Fall besteht der Wert darin, Bedrohung und Haftung zu beseitigen.
Fazit von Enterprise Architecture und Agile
Sowohl Unternehmensarchitektur als auch Agilität leiden unter chronischer Fehlanwendung. Zu oft gleichzeitig. Passen Sie Ihren Ansatz so an, dass Sie agil und flexibel sind Unternehmensstruktur Bemühungen reduzieren die Erfolgsunsicherheit.
Suchen Sie als Unternehmensarchitekt nach Möglichkeiten, mit einem schrittweisen Ansatz die Wahrscheinlichkeit und Kosten von Fehlern zu senken. Wenn Sie die Kosten fehlgeschlagener Änderungsbemühungen senken, vermeiden Sie Verschwendung. 100% Ihrer vergeblichen Veränderungsbemühungen mindern den Wert der Veränderung.
Die Rechnung ist einfach: Der Nutzen blieb gleich, die Arbeit nahm zu. Das Netto ist weniger wert.
Die einfache Antwort lautet: Spielen Sie Ihre Stärke aus. Und erwarten Sie, dass das agile Team seine Stärken ausspielt.
Unternehmensarchitektur und Agilität weisen vier Interaktionsmuster auf oberster Ebene auf:
- Definieren des agilen Vorgehens
- Führen des Rückstands im Sprint
- Einschränkung der agilen Sprints
- Lösung für produktübergreifende Abhängigkeiten
Die Auswahl des Musters wird von Ihnen bestimmt Anwendungsfall der Unternehmensarchitektur das Design Ihres EA-Teams.
Mit Unternehmensarchitektur und Agilität einen Schritt weiter gehen
Weitergehen Beweglichkeit unterscheidet sich von der agilen Softwareentwicklung. Enterprise Architecture und Agile passen in drei Bereichen zusammen:
- Architekt eines agilen Unternehmens
- agile Arbeitspraktiken zur Entwicklung einer Best-Practice-Unternehmensarchitektur
- Agile Softwareentwicklung & Unternehmensarchitektur
