Agile software development excels at building something that we have never had before and do not know how to build. It is hard enough to successfully build a complex system the second time. The first time probably won’t succeed. Agile reduces risk during implementation. It works in short increments. It ties fails, tries again. Then it succeeds.<\/p>\n
Der agile Ansatz reduziert das Risiko, indem er den Versuchszyklus verk\u00fcrzt.<\/p>\n
Die Rolle eines Enterprise-Architekt<\/a> ist es, Stakeholdern zu helfen, einen Weg nach vorne zu finden, wenn Sie nicht wissen, was zu tun ist. Enterprise Architecture reduziert das Risiko bei der Richtungsfindung und Planung. Enterprise Architectures blickt weiter voraus als Agile, um\u00a0 Vergleichen Sie m\u00f6gliche \u00c4nderungen<\/a> \u00fcber Architekturdom\u00e4nen<\/a>.<\/p>\n Die Unternehmensarchitektur soll die Entscheidungsfindung unterst\u00fctzen und die Kosten erfolgloser \u00c4nderungsbem\u00fchungen senken.<\/p>\n Unternehmensarchitektur und Agile reduzieren gemeinsam Risiken. Architektur dient dazu, Risiken und Kosten vor der Implementierung zu senken. Agile senkt Risiken und Kosten nach der Implementierung.<\/p>\n\t\t\t\n\t\t\t\t\t\t\tErfahren Sie mehr \u00fcber die TOGAF-Zertifizierung\n\t\t\t<\/a>\n\t Wie passen Unternehmensarchitektur und Agile zusammen?<\/a><\/p>\n Enterprise Architecture and Agile – Define the Agile Approach<\/a><\/p>\n Enterprise Architecture and Agile – Guide Backlog in Sprint<\/a><\/p>\n Unternehmensarchitektur und Agile \u2013 Sprints einschr\u00e4nken<\/a><\/p>\n Enterprise Architecture and Agile – Solve Dependency<\/a><\/p>\n Schlussfolgerung zu Unternehmensarchitektur und Agile<\/a><\/p>\n\t\t\t\t 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\u00e4gt sie zur Beschleunigung von Versandsoftware bei?<\/p>\n Enterprise-Architektur und Agile passen nicht innerhalb des Sprints zusammen. Sie passen au\u00dferhalb des Entwicklungszyklus zusammen. Sie passen zusammen, indem die Enterprise-Architekten und die agilen Entwickler ihre Arbeit erledigen. Erfolgreiche EA-Teams erf\u00fcllen ihre Anwendungsfall<\/a>. Sie liefern nichts anderes. Selbst wenn sie k\u00f6nnten.<\/p>\n Wir verf\u00fcgen \u00fcber eine einfache Unternehmensarchitektur und ein agiles Referenzmodell. Es gibt vier zentrale Einsatzmuster f\u00fcr die Unternehmensarchitektur:<\/p>\n In den letzten Jahren arbeitete ich an Digitale Transformation<\/a> Initiativen haben wir eine Reihe von Engagementmustern entwickelt.<\/p>\n\t\t\t\t <\/p>\n Betrachten Sie zun\u00e4chst 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.<\/p>\n Unser Architektur Muster Vorlage<\/a> hat zwei Schl\u00fcsselelemente: die vorhersehbares Problem<\/em> und die Ansatz<\/em> zur L\u00f6sung des Problems. Wir sammeln auch die harte Teile<\/em>. Wenn wir ein Muster in Betracht ziehen, achten wir darauf, wie gut es das Problem l\u00f6st und wie viel zus\u00e4tzliche Arbeit notwendig ist, um das Muster erfolgreich anzuwenden.<\/p>\n Let’s look at the engagement patterns. The problem they solve, the approach, and the hard bits.<\/p>\n Ich hatte ein am\u00fcsantes Gespr\u00e4ch mit der neu eingestellten Systems Reliability Engineer. Die SRE-Spezialistin war begeistert. Wir haben endlich moderne Methoden eingef\u00fchrt: CI\/CD und automatisiertes Testen. Sie fragte mich, was das EA-Team zur Unterst\u00fctzung t\u00e4te.<\/p>\n I had to smile when she asked, ‘was tut das EA-Team, um zu helfen?<\/em>‘ What she really meant was, ‘was tun Sie heute, um mich zu unterst\u00fctzen?<\/em>‘ Today, in terms of her immediate challenges, nothing. She was inside the implementation. She was looking about in terms of implementation.<\/p>\n She didn’t understand how the organization was developing. She was not aware of the Portfolio-Roadmap<\/a>. The roadmap had a transition point we had just reached. We had brought in containers, test data management, and a weak automated testing suite. She didn’t realize that old-fashioned top-down planning had created circumstances for her new job.<\/p>\n Sie dachte an die unmittelbare Entwicklung. Ich dachte an das Ganze digitale Transformation<\/a>. Ihre Aufgabe bestand darin, der Organisation bei der n\u00e4chsten Umstellung zu helfen. Sie entwickelte die kritische F\u00e4higkeiten<\/a>. Automatisierte Tests sollten den Nachweis erbringen, dass die Architekturbeschr\u00e4nkungen eingehalten wurden. Ich bewegte mich von Definition des agilen Ansatzes<\/a>. Ich brauchte Hilfe den R\u00fcckstand zu steuern<\/a>.<\/p>\n Zehn Br\u00fccken und Verbindungsstra\u00dfen sind wertvoller als 500 Halbbr\u00fccken ins Nirgendwo<\/em><\/strong><\/p>\n490 Br\u00fcckenbauer werden ungl\u00fccklich sein Agile ist eine Entscheidung. Sie hat Vor- und Nachteile. Die Einf\u00fchrung von Agile erfordert Entscheidungen \u00fcber Produkt, Plattform, Servicebereitstellungsstrategie und Top-Down-\u00dcbergangspunkte.<\/p>\n Ein EA-Team muss in der Lage sein, Strategie<\/a> und Portfolio<\/a> Zu Definieren Sie den agilen Ansatz.<\/em><\/strong><\/p>\n Vorhersehbares Problem<\/strong>: Wann verwenden Sie Agile?<\/p>\n 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\u00fcssen ermittelt werden.<\/p>\n Vorhersehbares Problem<\/strong>: Woher kommt das Produkt?<\/p>\n Ansatz<\/strong>Die Definition von \u2018L\u00f6sungen\u2019 zur Schlie\u00dfung von L\u00fccken und die Ergebnisse von Arbeitspaketen sollten an die in sich abgeschlossenen Produkte angepasst werden. Es sollte ein internes Produktportfolio und eine Reihe von Wertkennzahlen f\u00fcr interne Produkte entwickelt werden. Die Produkte sollten auf der folgenden Webseite erscheinen: Architektur-Roadmap<\/a>.<\/p>\n Platforms can improve development speed and sustainability. However a poorly selected platform will have the opposite result. It is not an agile team’s choice whether to use a platform, let alone which platform. We have used the term platform to cover SAP, M365, Facebook, Pega, or even Open Shift Containers.<\/p>\n Referenzarchitekturen<\/a>\u00a0spielen eine entscheidende Rolle bei der Definition, Auswahl und regieren<\/a>\u00a0die Nutzung von Plattformen.<\/p>\n Vorhersehbares Problem<\/strong>: Wann sollte eine Plattform verwendet werden und wann sollte das Produkt uneingeschr\u00e4nkt sein?<\/p>\n Ansatz<\/strong>: Mehrere Ans\u00e4tze<\/p>\n Harte Teile<\/strong>: Frage des Supports und der Nachhaltigkeit des Produkts und der Plattform.<\/p>\n Eine Servicebereitstellungsstrategie beschreibt den Ansatz, den Unternehmen zur Bereitstellung von Produkten oder Dienstleistungen verfolgen. Es ist nicht selbstverst\u00e4ndlich, dass Sie Ihren aktuellen Ansatz \u2013 intern, vertraglich oder durch Personalaufstockung \u2013 w\u00e4hlen.<\/p>\n Vorhersehbares Problem<\/strong>: Wie wird Ihr Unternehmen eine agile Entwicklung umsetzen?<\/p>\n Ansatz<\/strong>: Folgen Sie den Ans\u00e4tzen der Architektur zur Unterst\u00fctzung der Strategie. Stellen Sie die Frage, wie agile Entwicklung erm\u00f6glicht wird. Verwenden Sie eine Betriebsmodell<\/a> Wert zu definieren und eine Organisationsstruktur<\/a> um zu definieren, wie die verschiedenen Verbraucher, Entwickler und Betreiber eines Produkts zusammenarbeiten werden.<\/p>\n Agile Entwicklung ist genauso wahrscheinlich wie jeder andere Ansatz, den richtigen Zeitpunkt f\u00fcr eine Beendigung zu erkennen. Value Resting Points sind ein Synonym f\u00fcr Architektur\u00fcberg\u00e4nge. 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\u00fcnden:<\/p>\n Vorhersehbares Problem<\/strong>: Den Wert-Ruhepunkt kennen, um anzuhalten oder den Fokus zu \u00e4ndern<\/p>\n Ansatz<\/strong>: Verwenden Sie Architektur-Roadmaps, um alternative Wertbereitstellungspunkte zu erkunden. Erstellen Sie Berichte \u00fcber Aktivit\u00e4ten in Richtung \u00dcbergangszust\u00e4nde.<\/p>\n Harte Teile<\/strong>: Zu den \u00dcberlegungen geh\u00f6ren der relative Wert im Ruhezustand und der potenzielle Wert als Sprungbrett f\u00fcr andere Aktivit\u00e4ten. Implementierer verstehen diese Gespr\u00e4che selten. Sie versteifen sich emotional auf einen bestimmten Weg oder Ruhepunkt. Insbesondere, wenn es um die Existenz des Produkts oder die n\u00e4chste Version geht. F\u00fchrungskr\u00e4fte suchen immer nach dem besten Weg nach vorne, nicht nach dem h\u00f6chsten potenziellen Ertrag. Sie wollen den besten Weg.<\/p>\n Der erste Schritt besteht darin, die Wertruhepunkte zu erkunden. Entscheidungstr\u00e4ger m\u00fcssen die Optionen verstehen (Auswahl anhand verschiedener Kriterien und Aufschub unsicherer Entscheidungen). Anschlie\u00dfend m\u00fcssen sie ermitteln, was n\u00f6tig ist, um zu den ausgew\u00e4hlten Wertruhepunkten zu gelangen.<\/p>\n Bew\u00e4hrte Verfahren Unternehmensarchitektur<\/a> von Conexiam Navigieren<\/a><\/p>\n\t\t\t\n\t\t\t\t\t\t\tPlanen Sie ein individuelles Enterprise Architecture Training, um Ihr Team zu st\u00e4rken\n\t\t\t<\/a>\n\t Starke, agile Teams finden den effektivsten Weg nach vorne. L\u00e4ngerfristige Planung und Budgetierung sind aufgrund der Komplexit\u00e4t des \u00d6kosystems erforderlich. Die Herausforderung besteht darin, langfristige Planung und agile Kreativit\u00e4t zu verbinden. Verbinden Sie Top-down-Planung und Bottom-up-Ausf\u00fchrung.<\/p>\n Sie m\u00fcssen \u00fcber die organisatorischen Priorit\u00e4ten in einer Weise informiert werden, die in das R\u00fcckstandsmanagement einflie\u00dfen kann.<\/p>\n Agiles Vorgehen ist deshalb so wichtig, weil die Menschen, die der L\u00f6sung am n\u00e4chsten sind, den effektivsten Weg finden k\u00f6nnen. Erfolgreiche Organisationen setzen Priorit\u00e4ten und w\u00e4gen ab. Ohne das Erreichen der gew\u00fcnschten Zielvorgabe unter Ber\u00fccksichtigung der Zeit- und Ressourcenbeschr\u00e4nkungen sollte keine Arbeit begonnen werden.<\/p>\n Ein EA-Team muss in der Lage sein, Portfolio<\/a> und Projekt zu Backlog im Sprint leiten<\/em><\/strong>.<\/p>\n Vorhersehbares Problem<\/strong>: Sicherstellen, dass die Ver\u00f6ffentlichung und Produktentwicklung von den erwarteten Ergebnissen, dem Wert, den kaskadierten Leistungserwartungen und Einschr\u00e4nkungen bestimmt wird.<\/p>\n Hartes St\u00fcck<\/strong>: Zu viele Agile-Evangelisten sind \u00fcberrascht, dass Organisationen, die Agile einf\u00fchren, weiterhin stark der Planung und langfristigen Budgetierung verpflichtet bleiben. Wir m\u00fcssen oft den Mythos \u00fcberwinden, dass es eine kulturelle Pr\u00e4ferenz f\u00fcr den Wasserfall gibt.<\/p>\n Vorhersehbares Problem<\/strong>: Eine umfassende Produkt-Roadmap anstelle eines Feature-Release-Zyklus.<\/p>\n Ansatz<\/strong>: Mit einem Architektur-Roadmap-Technik<\/a> wo das Produkt oder die Produktfamilie an die Stelle des Portfolios tritt. Stellen Sie sicher, dass die normale Produktberichterstattung Aktivit\u00e4ten in Richtung \u00dcbergangszust\u00e4nde umfasst.<\/p>\n Harte Teile<\/strong>: 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\u00e4higkeiten der Produktorganisation einspringen oder auf andere L\u00f6sungen zur\u00fcckgreifen.<\/p>\n Zu viele Architekturteams tappen in die Falle k\u00fcnstlicher Pr\u00e4zision oder vermeintlicher Allwissenheit. Beides sind hochtrabende Ausdr\u00fccke f\u00fcr das Wasserfall-Denken. Eine klassische Architektur-Roadmap spricht von \u00dcberg\u00e4ngen, L\u00fccken und Arbeitspaketen. F\u00fcr ein Produktteam ist das unverst\u00e4ndlich. Wechseln Sie zur Produkt- und agilen Terminologie. Der Produktbesitzer muss die Einschr\u00e4nkungen verstehen, innerhalb derer er arbeitet.<\/p>\n Building the roadmap requires enough architecture. The only scalable approach is ‘gerade genug<\/em>.’ Just enough means enforcing organizational priority and dodging predictable problems. Just enough means staying out of the product design. Use architecture patterns that deliver across the portfolio. Just enough means ignoring potential synergy. Just enough means focusing on predictable problems. The value of dodging predictable problems is high. Just enough means not being afraid to use creative destruction.\u00a0 Use a concept of expected lifecycle to drive aggressive refactoring (greenfield and revolutionary approaches).<\/p>\n Die Verwendung der Techniken mit dem Produktbesitzer hilft dabei, organisatorische Priorit\u00e4ten und Einschr\u00e4nkungen in die Produkt-Roadmap einzubringen.<\/p>\n Vorhersehbares Problem<\/strong>: Verwenden von Epics zum Implementieren von Top-Down-Ergebnissen und Einschr\u00e4nkungen in das Produkt.<\/p>\n Ansatz<\/strong>: Durch die Verwendung gut konstruierter \u00dcbergangszust\u00e4nde in einem Architektur-Roadmap-Technik<\/a> wo das Produkt oder die Produktfamilie an die Stelle des Portfolios tritt. Stellen Sie sicher, dass die normale Produktberichterstattung Aktivit\u00e4ten in Richtung \u00dcbergangszust\u00e4nde umfasst.<\/p>\n Harte Teile<\/strong>: Erfordert eng integrierte oder stark eingeschr\u00e4nkte Produkte. Der Schwerpunkt muss auf der Integration oder den Einschr\u00e4nkungspunkten liegen. Ein einfaches Beispiel ist die Koexistenz mehrerer Produkte in einem \u00d6kosystem mit gemeinsamen Referenzdaten.<\/p>\n Es kommt h\u00e4ufig 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\u00e4t aufgrund von \u00d6kosystem- oder externen Anforderungen einschr\u00e4nken m\u00fcssen. Idealerweise sollte dies im Voraus geschehen und nicht als Reaktion auf technische Schulden.<\/p>\n Als uns dies gelungen ist, haben wir die Sprache von Methoden wie SaFE aktiv \u00fcbernommen und die Roadmap anhand strategischer Themen und Architektur-Start- und Landebahnen gestaltet.<\/p>\n Vorhersehbares Problem<\/strong>: Die Sicherstellung der in den \u00dcbergangs- und Zielzust\u00e4nden enthaltenen kritischen Erfolgsfaktoren dient als Leitfaden f\u00fcr die agile Backlog-Pflege und die Epic-Planung.<\/p>\n Ansatz<\/strong>: \u00dcbersetzen Sie Top-Down-Ma\u00dfnahmen und -Ziele in anwendbare Kriterien f\u00fcr die agile Backlog-Aufbereitung. Stellen Sie sicher, dass die normale Produktberichterstattung die Auswahl und Fertigstellung von Aktivit\u00e4ten in Richtung des angegebenen Werts umfasst.<\/p>\n Harte Teile<\/strong>: Die Top-Down-Ma\u00dfnahmen m\u00fcssen 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.<\/p>\n Jede \u00c4nderung der Top-Down-Ma\u00dfnahmen f\u00fchrt zu Verwirrung. Dies gilt insbesondere dann, wenn ein \u00dcbergangszustand erreicht wurde.<\/p>\n Bei internen Produkten stellen wir stets sicher, dass wir ein solides Kostenmodell f\u00fcr digitale Produkte haben, bevor wir Kostenma\u00dfnahmen einf\u00fchren. Ohne ein Kostenmodell gehen Betriebs- und Plattformkosten verloren, und alle Kosten werden durch die Implementierungskosten gerechtfertigt. Planen Sie, den internen Produktmanager zu unterst\u00fctzen bei ITFM verstehen<\/a>. Im Gegensatz dazu verf\u00fcgen Produktmanager externer digitaler Produkte normalerweise \u00fcber ein sehr ausgepr\u00e4gtes Kostenverst\u00e4ndnis.<\/p>\n Vorhersehbares Problem<\/strong>: Produktbesitzer betrachten das gesamte Unternehmen durch die Linse ihres Produkts und seiner direkten Benutzer.<\/p>\n Ansatz<\/strong>: Dokumentieren Sie Produkt und Rolle innerhalb des \u00d6kosystems. Dokumentieren Sie die f\u00fcr das Produkt geltenden Einschr\u00e4nkungen. Dokumentieren Sie Bewertungskriterien. Stellen Sie sicher, dass die normale Produktberichterstattung den Fortschritt in Richtung \u00dcbergangszust\u00e4nde und Aktivit\u00e4ten im Einklang mit dem Unternehmenswert umfasst.<\/p>\n Harte Teile<\/strong>: Produktbesitzer interner digitaler Produkte sind oft ein schwaches Glied. Zu den h\u00e4ufigsten Herausforderungen geh\u00f6rt das mangelnde Verst\u00e4ndnis f\u00fcr:<\/p>\n EA Teams supporting Portfolio and Project are most likely to need to constrain ‘bottom-up’ Product owners. It requires a deliberate effort and staff assignment.<\/p>\n Wir unterst\u00fctzen agile Teams nicht mehr nur bei der Verwaltung ihres R\u00fcckens, sondern greifen auch in den Sprint ein. Hier m\u00fcssen wir Architekturspezifikationen in die Software einbringen. Dies m\u00fcssen wir tun, ohne die Kreativit\u00e4t und Innovation des agilen Teams zu beeintr\u00e4chtigen.<\/p>\n Jede Architekturspezifikation schr\u00e4nkt einen gewissen Freiheitsgrad ein. Wenn wir ihre Freiheit einschr\u00e4nken, erschweren wir es dem agilen Team, den effizientesten Weg zu finden. Wenn Einschr\u00e4nkungen die Unternehmenspriorit\u00e4ten bestimmen, erleichtern wir die Suche nach dem besten Weg.<\/p>\n Vorhersehbares Problem<\/strong>: Sicherstellen, dass die f\u00fcr den agilen Erfolg entscheidenden Entscheidungen im Sprint die Priorit\u00e4ten, Pr\u00e4ferenzen und Einschr\u00e4nkungen der Organisation ber\u00fccksichtigen und von ihnen geleitet werden.<\/p>\n Harte Teile<\/strong>: Ein Gleichgewicht zwischen Unternehmensanforderungen und Eingriffen in die erforderliche Design- und Ansatzfreiheit finden. Dies gilt insbesondere f\u00fcr Architekten mit Entwicklungshintergrund. Fachkompetenz f\u00fchrt dazu, dass Unternehmensspezifikationen nicht mehr in das Design einflie\u00dfen. Dies f\u00fchrt zu einer schlechten Big-Up-Front-Architektur.<\/p>\n Enterprise-Architekten, die die Projekt- und L\u00f6sungsbereitstellung unterst\u00fctzen, m\u00fcssen mit eingeschr\u00e4nkten Sprints rechnen. Architekten, die sich auf ein Produkt\u00f6kosystem oder eine Plattform konzentrieren, m\u00fcssen ebenfalls mit der Zusammenarbeit mit agilen Teams rechnen.<\/p>\n Vorhersehbares Problem<\/strong>: Sicherstellen, dass die Software den Spezifikationen und Standards der Unternehmensarchitektur entspricht.<\/p>\n Ansatz<\/strong>: Bereitstellung verbindlicher Abnahmekriterien, die am Ende von Epics und vor der Ver\u00f6ffentlichung gelten. Wir haben oft Anwendungsarchitekturmuster<\/a> und Datenarchitekturmuster<\/a> um Akzeptanzkriterien zu erstellen. Nehmen Sie in alle Testberichte obligatorische Akzeptanzkriterien auf.<\/p>\n Harte Teile<\/strong>: Wissen, wann verbindliche Abnahmekriterien durchgesetzt werden m\u00fcssen. Zu fr\u00fch verzerrt die Entwicklung. Zu sp\u00e4t f\u00fchrt zu Druck f\u00fcr Release-Ausnahmen. Dies gilt insbesondere f\u00fcr interne digitale Produkte, die keine wirklich vorhersehbaren Release-Zyklen haben.<\/p>\n Wir klassifizieren unsere Architekturspezifikationen wie folgt:<\/p>\n Die meisten obligatorischen Akzeptanzkriterien m\u00fcssen Architekturmuster oder -standards sein.<\/p>\n Vergessen Sie nie, aus dem Weg zu gehen und die Kreativit\u00e4t zu ernten.<\/p>\n Vorhersehbares Problem<\/strong>: Verstehen, was gesch\u00e4tzt wird und wie der Wert gemessen wird.<\/p>\n Ansatz<\/strong>: Die Unternehmensarchitektur muss eindeutig festlegen, wie der Wert beschrieben und gemessen wird. Wertaussagen erfordern kritische Erfolgsfaktoren (CSF) und Effektivit\u00e4tsma\u00dfe (MoE). Stellen Sie sicher, dass Wertma\u00dfe in die Produkt-, Epic- und Release-Berichte einbezogen werden.<\/p>\n Harte Teile<\/strong>: Zu viele IT-Experten haben ein begrenztes Verst\u00e4ndnis von Wert. Sie verwenden eine schnelle Abk\u00fcrzung, die den Wert anhand der gelieferten Leistung ausdr\u00fcckt. Der Wert ergibt sich aus der Leistung selbst.<\/p>\n 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\u00f6ren. Oder wenn eine Arbeitseinheit Funktionen anfordert, die ihre Arbeit auf Kosten des Systems vereinfachen.<\/p>\n We strongly recommend basic Lean and Six-Sigma practices. Look into the definition and quantification of value. Look for local optimization. The Business Model Canvas’ concepts of Target Customer and Value Proposition are very helpful.<\/p>\n In TOGAF’s Phase E<\/a>, there is a cool step. Look at the work package and select an appropriate strategy-Greenfield, Evolutionary or Revolutionary. Are you expecting to preserve as much as possible, radically refactor, or start from scratch?<\/p>\n Dies geschieht im Rahmen der Produktportfolio- und \u00d6kosystemplanung. Es ist eine wichtige Orientierungshilfe und stellt eine starke Einschr\u00e4nkung f\u00fcr ein agiles Team dar. Sollen sie bei Null anfangen (Greenfield)? Die bestehenden Systeme schrittweise verbessern (Evolution)? Oder radikale Ver\u00e4nderungen durchf\u00fchren, die die bisherigen Reibungspunkte und Probleme beseitigen (Revolution)?<\/p>\n Vorhersehbares Problem<\/strong>: Sicherstellen, dass die Implementierungsstrategie befolgt wird.<\/p>\n Ansatz<\/strong>: Verwenden Sie Produkt-Roadmaps und Release-Zyklen, um radikale \u00c4nderungen im Ansatz durchzusetzen.<\/p>\n Hartes St\u00fcck<\/strong>: Ausrichtung der Top-Down-Architektur\u00e4nderungen an einer Produkt-Roadmap. Dies ist besonders schwierig, wenn Entscheidungen zur Unterst\u00fctzung der Strategie oder des Portfolios eine \u00c4nderung des Produktansatzes erfordern. Wir mussten viel Zeit darauf verwenden, den Eigent\u00fcmern digitaler Produkte und \u00fcber sie ihren Teams zu versichern, dass die bisherige Anstrengung nicht umsonst war.<\/p>\n Wenn ein Produkt in eine bestehende Unternehmensumgebung passen oder eine sich entwickelnde Unternehmensumgebung unterst\u00fctzen 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\u00e4nken die agile Entwicklung ein.<\/p>\n Bestehende Systeme werden nicht ver\u00e4ndert. Die Investitionen flie\u00dfen in neue Systeme. Das neue System muss sich integrieren. Selbst die F-22 Raptor musste \u00fcber in den 1970er Jahren entwickelte Schnittstellen mit Altsystemen verbunden werden. Nicht einmal ein so teures Flugzeug konnte mit Altsystemen modernisiert werden.<\/p>\n Vorhersehbares Problem<\/strong>: Erforderliche Schnittstellen identifizieren und deren Nutzung sicherstellen.<\/p>\n Ansatz<\/strong>: Fokussieren Sie die Top-Down-Arbeit auf Schnittstellen und gemeinsame Datenstrukturen. Geben Sie Anforderungen \u00fcber Epic- und Release-Zyklen ein. Verwenden Sie Akzeptanzkriterien. Wir haben oft verwendet Anwendungsarchitekturmuster<\/a> und Datenarchitekturmuster<\/a> bis hin zu leicht spezifischen Schnittstellen. F\u00fcgen Sie die Schnittstellenkonformit\u00e4t in alle Testberichte ein.<\/p>\n Hartes St\u00fcck<\/strong>: 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\u00f6ffentlichte APIs und Datenstrukturen f\u00fcr Stammdaten, Referenzdaten und Transaktionsdatens\u00e4tze vorhanden sind.<\/p>\n Schnelllebige Produktteams \u00fcbersehen oft die Gesetzgebung in mehreren Rechtsgebieten oder einen expandierenden Marktplan. In diesen F\u00e4llen 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\u00e4t und Schnittstellen durchgesetzt haben.<\/p>\n Agile Teams und die auf digitale Produkte fokussierte Entwicklung eignen sich nicht zur L\u00f6sung von Problemen innerhalb eines \u00d6kosystems oder Produktportfolios. Das grundlegende Konzept agiler Methoden besteht darin, dass ein einzelnes Team Probleme zerlegt und direkt l\u00f6st. Es gibt zwar Konzepte f\u00fcr Team-of-Teams, diese haben jedoch Schwierigkeiten, den \u00dcbergang aus der aktuellen Situation herauszuholen.<\/p>\n Jedes Architekturteam muss Verantwortung f\u00fcr die L\u00f6sung produkt\u00fcbergreifender Probleme \u00fcbernehmen. Agile Entwicklung und moderne Integration machen diesen Service wichtiger denn je.<\/p>\n Vorhersehbares Problem<\/strong>: Konflikte im gesamten digitalen Produktportfolio blockieren den Fortschritt mehrerer Produkte.<\/p>\n Ansatz<\/strong>: Verwenden Sie Techniken der Unternehmensarchitektur, um die minimalen \u00c4nderungen zu finden, die einen Fortschritt erm\u00f6glichen.<\/p>\n Harte Teile<\/strong>: Die gr\u00f6\u00dfte Herausforderung ist das Timing. Kreative, agile Entwicklungsteams arbeiten nach bew\u00e4hrten Methoden an der L\u00f6sung des Problems. Tritt das Problem jedoch auf, stellt es in der Regel einen kritischen Blocker dar, der mit vielen technischen Schulden verbunden ist.<\/p>\n Das EA-Team muss sich auf inkrementelle \u00dcbergangszust\u00e4nde konzentrieren, um Fortschritte im gesamten Produktportfolio zu erm\u00f6glichen.<\/p>\n Vorhersehbares Problem<\/strong>: Identifizierung des wahren Stakeholders, der f\u00fcr ein komplexes internes Produktportfolio Anleitung und Genehmigung geben kann.<\/p>\n Ansatz<\/strong>: Verwenden Sie Enterprise-Architektur-Techniken, um Stakeholder und Stakeholder-Agenten, Anliegen und Pr\u00e4ferenzen zu identifizieren. Verwenden Sie Enterprise-Architektur-Techniken von Alternativen<\/a> und Abtausch<\/a> die Stakeholder zu einer Entscheidung zu f\u00fchren, die das Produktportfolio lenkt. Sorgen Sie f\u00fcr eine effektive digitale Portfolio-Governance.<\/p>\n Harte Teile<\/strong>: Wir k\u00f6nnen davon ausgehen, dass digitale Produktteams \u00fcber lokale Autorit\u00e4tsquellen und ein vereinfachtes Entscheidungsmodell verf\u00fcgen. Dar\u00fcber hinaus werden ihre Kommunikation und Bewertung IT-orientiert und taktisch sein.<\/p>\n The EA Team will have to work to ensure effective governance crosses the digital portfolio and engage with the digital product authority structures. As well, EA Teams do not have a special ability to gain stakeholder engagement. They do have an ability to represent the stakeholders’ concerns through superior architecture.<\/p>\n Vorhersehbares Problem<\/strong>: Aus lokal optimierten taktischen Entscheidungen kann kein effektives und nachhaltiges digitales \u00d6kosystem entstehen.<\/p>\n Ansatz<\/strong>: Gerade genug beibehalten Anwendungsarchitektur<\/a> und Datenarchitektur<\/a>. Setzen Sie in dieser Architektur organisatorische Priorit\u00e4ten. 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 \u00d6kosystemansatz spezifizieren.<\/p>\n Harte Teile<\/strong>: Die Erweiterung des Portfolios erfordert die Vereinbarkeit zweier widerspr\u00fcchlicher Realit\u00e4ten. Erstens entstand der agile Ansatz aufgrund des beobachteten Versagens detaillierter Top-down-Unternehmenskonzepte. Zweitens k\u00f6nnen neu entstehende lokal optimierte L\u00f6sungen ohne starken Evolutionsdruck und Entwicklungszeit keine effizienten komplexen Systeme aufbauen.<\/p>\n The only scalable approach is ‘gerade genug<\/em>.’ Just enough means enforcing organizational priority and dodging predictable problems. For example, if your organizational priority is sustainability, your application architecture must enforce modularity and the use of isolation infrastructure like a API gateway.<\/p>\n \u201eGenug\u201c bedeutet, sich aus dem Produktdesign herauszuhalten. Stattdessen m\u00fcssen Sie Architekturmuster verwenden, die das gesamte Portfolio abdecken.<\/p>\n 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\u00fcr etwas bezahlt, um davon zu profitieren. Der Wert von Synergien ist gering, wenn Unsicherheit herrscht.<\/p>\n 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\u00f6sen Sie es fr\u00fchzeitig. Es lohnt sich, vorhersehbare Probleme zu vermeiden.<\/p>\n Gerade genug bedeutet, keine Angst vor Marktkr\u00e4ften und kreativer Zerst\u00f6rung zu haben. Wir verwenden das Konzept des erwarteten Lebenszyklus, um hervorzuheben, wo im \u00d6kosystem wir regelm\u00e4\u00dfig aggressives Refactoring (Greenfield- und revolution\u00e4re Ans\u00e4tze) durchf\u00fchren werden.<\/p>\n Vorhersehbares Problem<\/strong>: \u201eGenug Architektur\u201c bedeutet, dass nicht jede Eventualit\u00e4t, jede Einschr\u00e4nkung und jeder Konflikt vor der Ver\u00f6ffentlichung entdeckt wurde.<\/p>\n Ansatz<\/strong>: Stecken Sie die H\u00e4nde in die Taschen und warten Sie, bis Sie w\u00e4hrend der Probleml\u00f6sung angerufen werden. Warten Sie, bis Sie angerufen werden, mit der Einschaltung w\u00e4hrend der Vorfallspr\u00fcfung, um herauszufinden, wo Sie ein vorhersehbares Problem nicht erkannt, ein Risiko untersch\u00e4tzt oder eine Testanforderung \u00fcbersehen haben.<\/p>\n Harte Teile<\/strong>: There is one case when an architecture team might have an emergency. Those rare cases when implications extend past the product. If the end users are working around the defect, you don’t have an emergency. When they are creating vulnerability and liability, you have an emergency.<\/p>\nVerst\u00e4ndnis von Unternehmensarchitektur und Agile<\/h2>\n
\n
![\"Unternehmensarchitektur](\"https:\/\/conexiam.com\/wp-content\/uploads\/2023\/09\/AdobeStock_437654262.jpeg\" "\\"Unternehmensarchitektur")
\n\t\t\t\n\t\t\t\t\t\t\tKontaktieren Sie uns, damit wir Sie bei der Unternehmensarchitekturberatung unterst\u00fctzen k\u00f6nnen\n\t\t\t<\/a>\n\tWie passen Unternehmensarchitektur und Agile zusammen?<\/h2>\n
\n
![\"Unternehmensarchitektur](\"https:\/\/conexiam.com\/wp-content\/uploads\/2020\/05\/EA-supporting-Agile-Development-Work-Product-600x408.png\" "\\"Unternehmensarchitektur")
\n\tWie verwendet man diese Engagement-Muster?<\/h2>\n
\n
Praxisbeispiel: Agile Entwicklung auf der Enterprise Architecture Roadmap<\/strong><\/h3>\n
\n
\n<\/em><\/strong>490 Br\u00fcckenbauer, die glaubten, einen Mehrwert zu schaffen<\/em><\/strong>\n
\n\t\t\t\n\t\t\t\t\t\t\tMa\u00dfgeschneiderte Unternehmensarchitektur-Schulungen zur St\u00e4rkung Ihres Teams\n\t\t\t<\/a>\n\tUnternehmensarchitektur Downloads und Unternehmensarchitektur Beispiele<\/a><\/h2>\n\t
Enterprise Architecture and Agile – Define the Agile Approach<\/h2>\n
Produktmuster<\/h3>\n
Plattformmuster<\/h3>\n
\n
\n
Muster der Servicebereitstellungsstrategie<\/h3>\n
Ruhepunktmuster f\u00fcr Hauptwerte<\/h3>\n
\n
\n
\nDies ist ein ROI-Gespr\u00e4ch. ROI-Gespr\u00e4che f\u00fchren normalerweise zu einer \u00c4nderung der Priorit\u00e4ten.<\/li>\n\n
\n
Mehr erreichen mit Best-Practice-Unternehmensarchitektur-Prozess und -Methode<\/h2>\n
Enterprise Architecture and Agile – Guide Backlog in Sprint<\/h2>\n
Roadmap zur Anleitung des Produktmusters<\/h3>\n
\n
\n
Roadmap zur Anleitung des Epic-Musters<\/h3>\n
Unternehmenswertmuster<\/h3>\n
Constrain ‘bottom up’ Product Owner Pattern<\/h3>\n
\n
\n
![\"Unternehmensarchitektur](\"https:\/\/conexiam.com\/wp-content\/uploads\/2020\/05\/EA-supporting-Agile-Development-Work-Product.png\" "\\"Verst\u00e4ndnis")
<\/p>\n\t\t\t\n\t\t\t\t\t\t\tLaden Sie den Leitfaden f\u00fcr Praktiker zur Entwicklung einer Unternehmensarchitektur herunter\n\t\t\t<\/a>\n\tUnternehmensarchitektur-Schulung und TOGAF-Schulung<\/h2>\n\t
Unternehmensarchitektur und Agile \u2013 Sprints einschr\u00e4nken<\/h2>\n
\nEs gibt eine Grundregel<\/strong><\/em>: never remove a degree of freedom if you don’t have to
\nInnovations- und Gestaltungsfreiheit sind das Lebenselixier der agilen Softwareentwicklung<\/em>\nEs gibt eine erweiterte Regel<\/strong>: Scheuen Sie sich nie, einem agilen Team ein wirklich schwieriges Problem zu stellen
\nInnovation und Kreativit\u00e4t schaffen L\u00f6sungen, die Sie sich nicht vorstellen k\u00f6nnen<\/em>\n
\nAkzeptanzkriterienmuster<\/h3>\n
\n
\n
Wert (Ma\u00dfe und Ruhepunkte) Muster<\/h3>\n
Greenfield, Evolution oder Revolution<\/a><\/h3>\n
Schnittstellenmuster einschr\u00e4nken<\/h3>\n
<\/p>\n\t\t\t\n\t\t\t\t\t\t\tLaden Sie den Enterprise Architecture Governance Guide herunter\n\t\t\t<\/a>\n\tEnterprise Architecture and Agile – Solve Dependency<\/h2>\n
Entsperren Sie das Portfolio-Muster<\/h3>\n
Identifizieren Sie das echte Stakeholder-Muster<\/h3>\n
\u00dcberqueren Sie das Portfolio-Muster<\/h3>\n
Release-Auswirkungsmuster<\/h3>\n