Agile Entwicklung und Unternehmensarchitektur verstehen
Agile und Enterprise Architecture passen wunderbar zusammen. Beide lösen unterschiedliche Teile des Problems.
Agile Softwareentwicklung zeichnet sich dadurch aus, etwas zu bauen, das wir noch nie zuvor hatten und nicht wissen, wie. Unternehmensarchitektur glänzt vor Entscheidungen, wenn Sie nicht wissen, was zu tun ist.
- Architekt eines agilen Unternehmens
- agile Arbeitspraktiken zur Entwicklung einer Best-Practice-Unternehmensarchitektur
- Agile Softwareentwicklung & Unternehmensarchitektur
Die meisten Architekten springen zum letzten. Sie versuchen, zwei völlig divergierende Welten zusammenzufügen, normalerweise ohne innezuhalten, um beides zu verstehen.
Ich hatte ein amüsantes Gespräch mit dem neu eingestellten Systems Reliability Engineer. Der SRE-Spezialist war begeistert. Wir haben endlich mit modernen Praxen CI/CD-Praxen begonnen. Sie fragte mich, was das EA-Team tat, um zu helfen?
Ich musste lächeln, als sie fragte, 'Was tut das EA-Team, um zu helfen?' Was sie wirklich meinte, war: 'Was tust du, um mich heute zu unterstützen??' Heute, gegen ihre unmittelbaren Herausforderungen, könnte es sein – nichts. Sie erfuhr, wie das EA-Team ihre tägliche Arbeit unterstützte.
Sie hat nie die Portfolio-Roadmap gesehen, die Container, Testdatenmanagement und ehrlich gesagt eine lächerlich unzureichende automatisierte Testsuite brachte. Ihr war nicht bewusst, dass dieselbe alte Roadmap einen Übergangspunkt identifizierte, der ihren Job finanzierte.
Erfolgreiche EA-Teams ihren Zweck erfüllen. Sie liefern nichts anderes. Auch wenn sie könnten.
Sechs Anwendungsfälle decken alle Aspekte der Agile- und Unternehmensarchitektur ab
Ein einfacher Rahmen, um über Unternehmensarchitekturen nachzudenken, ist die Frage, was sie unterstützen.
- Strategie unterstützen
- Support-Portfolio
- Projekt unterstützen
- Lösungsbereitstellung unterstützen
Agile Entwicklung und Unternehmensarchitektur
Bei der Verknüpfung mit agiler Softwareentwicklung stellt sich die gleiche Frage, was sie dem Team bei der Beantwortung unterstützen sollen. Ein Teil der Ausrichtung wird davon bestimmt, was das Unternehmensarchitekturteam unterstützen soll.
- Definieren des agilen Vorgehens
- Führen des Rückstands im Sprint
- die Sprints einschränken
- Lösung für produktübergreifende Abhängigkeiten
Agile und Unternehmensarchitektur: Definieren Sie den agilen Ansatz
In der Regel wird dies ein EA-Team tun, das für Strategie und Portfolio zuständig ist Definieren Sie den agilen Ansatz.
Produkt
Produkte erscheinen auf einer Roadmap als Lücken oder Arbeitspakete. Das EA-Team kann über Fähigkeiten oder Geschäftsservice sprechen. Erwarten Sie in diesem Fall die neuen oder überarbeiteten Produkte.
Plattformen
Schwächere Praktiker werden sich darauf konzentrieren, Begriffe wie „Plattform“ zu definieren. Eine scharfe, allzu genaue Definition ist eine Falle. Nehmen Sie sich ein paar Sekunden Zeit, um über SAP, 0365, Facebook, Pega oder sogar Angular und Container als Plattformen zu sprechen. Der Begriff braucht einen Kontext für eine enge Definition. Alles, was Sie brauchen, ist, dass sich der Verbraucher und der Betreiber einigen. Ich bin der Versuchung erlegen, ein Produkt zu spezifizieren, das eine von anderen konsumierte Plattform war. Die Pedanten versuchten festzustellen, ob es sich um ein Produkt oder eine Plattform handelte.
Strategie der Servicebereitstellung
Roadmaps auf oberster Ebene sollten besser klarstellen, wie die Transformation umgesetzt werden soll. Beispiele beinhalten.
- Bauen Sie eine robuste interne Kapazität auf oder nutzen Sie Drittanbieter?
- Langlebige nachhaltige Systeme sicherstellen oder einige oder alle Produkte als Einwegkleenex behandeln?
Wichtige Ruhepunkte
Wir verwenden Value Resting Points routinemäßig als Synonym für Architekturübergänge. Stellen Sie Ihren Stakeholdern immer eine Ausfahrt zur Verfügung. Wir verwenden Abfahrten aus zwei Gründen:
- 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 die Anstrengung, einen Rastpunkt zu erreichen, eine aufregendere oder lohnendere Rast erreichen könnte.
Trade-Off-Gespräche sind eines der wertvollsten Ergebnisse einer Strategie- oder Portfolio-Roadmap-Übung. Ressourcen sind endlich. Leitende Führungskräfte sind immer auf der Suche nach dem besten Weg nach vorne, nicht nach dem höchsten potenziellen Gewinn. Der beste Weg. 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 Pfad oder Ruhepunkt gebunden. Vor allem, wenn über die Existenz des Produkts oder die nächste Version nachgedacht wird.
Agile und Unternehmensarchitektur: Guide Backlog in Sprint
EA-Praktiker, die Portfolios und Projekte unterstützen, arbeiten oft mit agilen Teams zusammen, indem sie den Rückstand im Sprint leiten.
Ich habe beobachtet, dass es zu viele agile Evangelisten überrascht, dass Organisationen, die sich zutiefst den Vorteilen der agilen Softwareentwicklung verschrieben haben, sich weiterhin zutiefst der Planung und längerfristigen Budgetierung verschrieben haben. Normalerweise verwirrt das Gespräch eine mythische kulturelle Vorliebe für einen Wasserfall.
Denken Sie stattdessen über das Problem nach. Aufgrund der Komplexität des Ökosystems gibt es eine längerfristige Planung und Budgetierung. Jede Organisation hat mehrere Wege nach vorne und unterschiedliche Einschränkungen. Erfolgreiche Organisationen führen Priorisierung und Kompromisse durch. Ohne die bevorzugte Zukunft in den Zeit- und Ressourcenbeschränkungen zu erreichen, sollte keine Arbeit beginnen.
Unternehmensarchitektur läuft auf Einschränkungen hinaus. Jede Einschränkung schränkt die Kreativität eines agilen Softwareentwicklungsteams ein. Ohne ein übergeordnetes Bedürfnis nach Zwängen nicht. Einfach nicht.
Roadmap zum Leitprodukt
Roadmap to guide product gehört zu den schwierigsten Ergebnissen für ein talentiertes EA-Team. Die grundlegende Spannung, zu wissen, wohin man geht, ohne zu wissen, wie man dorthin kommt, ist ein Hot Spot.
Zu viele Architekturteams tappen in die Falle künstlicher Präzision oder eingebildeter Allwissenheit. Beides ist eine ausgefallene Art, Wasserfalldenken zu sagen.
Agile Entwicklung liefert erstaunliche Ergebnisse, wenn das Team alle Freiheitsgrade hat. Denken Sie nur an den optimalen Punkt eines eigenständigen Greenfield-Produkts.
Oft läuft eine gute Architektur darauf hinaus, die Mindestbeschränkungen bereitzustellen, um sicherzustellen, dass Entscheidungen einen Test nicht bestehen, der für den Entscheidungsträger nicht offensichtlich ist. Wenn der Entscheidungsträger den Test sehen kann, brauchen Sie keine Architektur, um ihn einzuschränken. Architektur existiert, um die Wahl zu lenken oder einzuschränken, wenn der Faktor außerhalb des Sichtfelds des Architekten liegt.
Eine klassische EA-Roadmap spricht Übergänge, Lücken und Arbeitspakete an. Es wird für ein Produktteam unverständlich sein. Überführen Sie die Roadmap mit dem Product Owner in die richtigen Bedingungen. Der Product Owner muss die Einschränkungen verstehen, innerhalb derer er arbeitet.
Spannung erwarten
Roadmap zum Leiten von Epic
Roadmap to guide epic ist die schwierigste Aufgabe für ein talentiertes EA-Team. Ich denke immer daran, während eines Bombenangriffs in einem Minenfeld festzusitzen. Es gibt keinen sicheren Ort.
Timeline-Erwartungen machen die übliche Falle des Wasserfall-Denkens noch schlimmer. Die Entdeckungsreise eines agilen Teams mit künstlicher Präzision & imaginärer Allwissenheit voranzutreiben, untergräbt alles in der agilen Entwicklung. Tu es einfach nicht!
Ohne eng integrierte oder streng eingeschränkte Produkte sind Roadmaps für Epic zum Scheitern verurteilt. Beispiele, wo dies erforderlich ist, umfassen mehrere Produkte, die innerhalb eines Ökosystems koexistieren, und den Austausch von Referenzdaten. Das Konsumieren der Datenausbeute des anderen erfordert oft verbundene Epen oder komplexe Strafvorschriften.
Führen Sie diese Tätigkeit nicht ohne äußeren Druck aus. Überspezifikation und Überdesign durch selbsternannte allwissende Praktiker sind eine Sache, die wir erfunden haben, um darauf zu verzichten. Wenn Sie gezwungen sind, Roadmaps zu Epics zu machen, stellen Sie sicher, dass Sie genau verstehen, warum es notwendig ist, die Kreativität Ihrer Softwareentwickler einzuschränken. Jede Einschränkung, die ihre Freiheit und Kreativität einschränkt, sollte besser dazu dienen, die Wertschöpfung aufzuheben, die sich aus ungezügelter Kreativität ergibt
Erwarten Sie einen Misserfolg.
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.
Unternehmenswert
Eine überlegene Architektur wird sich immer mit den Anliegen der gemeinsamen Stakeholder befassen. Es sollte einen intern konsistenten Satz von Prinzipien bieten, die die Definition von Werten einschränken. Hier sorgt die Architektur dafür, dass Schlampereien in der Wertermittlung keine nachgelagerten Kosten verursachen.
Eine schlampige Wertermittlung ist das häufigste Problem, das von guter Architektur angegangen wird. Vorübergehende Erwägungen herrschen. Eine klassische Dichotomie ist die Unterscheidung zwischen taktischer Time-to-Market und Sicherheit, Resilienz oder Stabilität. Wenn Ihre Organisation Imperative hat, müssen Produktmanager und Scrum-Teams darüber informiert werden. Andernfalls können sie den Rückstand nicht angemessen mit wirklich wichtigen Kennzahlen vergleichen.
Beschränken Sie Product Owner von unten nach oben
Zu viele Product Owner haben keinen Einblick, warum ihr Produkt existiert oder Zu viele Product Owner haben keinen Einblick, warum ihr Produkt existiert oder welche Rolle das Ökosystem spielt. Schränken Sie die Freiheit eines Bottom-up-Produktbesitzers ein, indem Sie entweder die Auswahl verbieten oder die Bewertung und Bewertung erzwingen.
Agile und Unternehmensarchitektur: Sprints einschränken
EA-Praktiker, die eine Architektur zur Unterstützung der Projekt- und Lösungsbereitstellung entwickeln, sollten damit rechnen, Sprints einzuschränken. Auch Portfolio-orientierte Praktiker, die ein Ökosystem oder eine Plattform entwickeln, sollten damit rechnen, hier mit den agilen Teams zusammenzuarbeiten.
Einengende Sprints können für neue Architekten, die früher in der Entwicklung aktiv waren, emotional schwierig sein. Es ist schwer, seinen alten Job hinter sich zu lassen. Fachliche Expertise führt oft zu schleichender Überspezifikation und Überdesign. Jede Einschränkung, die ihre Freiheit und Kreativität einschränkt, muss zeigen, dass sie die Wertlieferung außer Kraft setzt, die sich aus ungezügelter Kreativität ergibt.
Die Schwierigkeit, Ihren alten Job aufzugeben, ist der Grund, warum wir jeden, der neu in der Unternehmensarchitektur ist, als einen behandeln neugeb. Der neue Absolvent und die Person mit 30-jähriger Erfahrung, die etwas anderes als Unternehmensarchitektur macht, sind neue Architekten.
Ich beobachte neue Architekten mit Jahren andere näher erleben. Sie haben viele schlechte Angewohnheiten, die sie davon abhalten, hochfunktionale Architekten zu sein.
Nathan und Sam sprechen darüber Entwicklung neuer Unternehmensarchitekten. Es ist sehr wichtig, dass alle Unternehmensarchitekten Entscheidungsrechte verstehen und Stakeholdern dienen.
Akzeptanzkriterium
Eine sehr einfache Einbindung in einen Sprint sind extern definierte Abnahmekriterien. Wenn die Architektur etwas erfordert, formulieren Sie es als Akzeptanzkriterium. Wenn der Detaillierungsgrad nicht sehr nahe daran ist, die agile Kreativität zu beeinträchtigen, wird die Einschränkung etwas Konsistentes sein. Es wird eine Nachfrage aus der Geschäftsarchitektur, der Datenarchitektur, der Anwendungsarchitektur oder der Infrastrukturarchitektur geben. Die Architekturspezifikation ist ein Prinzipal, ein Muster oder ein Standard. Geben Sie die Einschränkung als Akzeptanzkriterium an. Entweder an einem Sprint ausrichten oder freigeben. Dann gehen Sie aus dem Weg und beobachten Sie die Kreativität
Haben sie die Anleitung und Einschränkung der Zielarchitektur vernünftig interpretiert?
- Wenn ja, sollte ihre Interpretation als Konformität akzeptiert werden. Dies ist ein wichtiger Punkt. Eine gute Architektur kann mehrere Implementierungsmöglichkeiten haben. Der Implementierer ist nicht verpflichtet, sich an Meinungen zu halten. Wenn die Wahl der Implementierung eine vernünftige Interpretation ist, ist sie konform.
Wert (Maßnahmen und Ruhepunkte)
Ein immer wiederkehrender Konfliktpunkt ist das Verständnis von Wert.
Best Practice agile Softwareentwicklung ist wertorientiert. Leider haben die meisten Praktiker ein begrenztes Verständnis von Wert. Die schnelle Abkürzung ist, dass der Wert in Bezug auf etwas ausgedrückt wird, das geliefert wurde. Der Wert ist bei der Lieferung selbstverständlich.
In einer komplexen Welt könnte die gelieferte Sache leicht wertmindernd sein. Ein einfaches Beispiel sind Funktionen, die von Zielkunden abgewandt sind, oder die Verlagerung von Arbeit zwischen Arbeitseinheiten. Dies ist üblich, wenn eine Gruppe von dem Produkt bedient wird. Wir empfehlen dringend, grundlegende Lean- und Six-Sigma-Praktiken über lokale Optimierung und Wert zu lernen. Auch die Business Model Canvas-Konzepte von Target Customer und Value Proposition sind hilfreich.
Um diesen Herausforderungen zu begegnen, erwarten wir, dass die Geschäftsarchitektur maßgeblich dafür ist, wie der Wert bewertet wird. Die Architektur muss den Entwicklungsteams Wertbewertungskriterien liefern.
Greenfield, Evolution oder Revolution
In TOGAFs Phase E, gibt es einen coolen Schritt. Sehen Sie sich das Arbeitspaket an und wählen Sie eine geeignete Strategie aus.
Wird die Arbeit Greenfield, Evolutionary oder Revolutionary sein? Wollen wir so viel wie möglich erhalten, radikal umgestalten oder ganz von vorne anfangen? Dies ist eine wichtige Anleitung und eine starke Einschränkung für ein agiles Team. Sollen sie bei null anfangen (Greenfield)? Bestehende Systeme schrittweise verbessern (Evolution)? Oder radikale Veränderungen durchführen, um die Reibung und die Probleme zu beseitigen, mit denen wir gelebt haben (revolutionär)?
Die Wahl des Ansatzes liegt möglicherweise nicht bei ihnen. Wenn sie keine Wahl haben, wird sie immer von Entscheidungen bestimmt, die über ihrer Gehaltsstufe liegen.
Schnittstellen einschränken
Wenn ein Produkt in eine bestehende Unternehmensumgebung passen oder eine sich entwickelnde Unternehmensumgebung unterstützen muss, sind Schnittstellen entscheidend. Schnittstellen werden von Daten und Methoden gesteuert. Selbst wenn das Produkt entsteht, wird es in einer komplexen Welt keine Freiheit geben, Datenstrukturen oder Schnittstellen entstehen zu lassen. Stammdaten, Referenzdaten und bestehende Systeme werden die agile Entwicklung einschränken.
Bestehende Systeme werden nicht verändert. Sogar der F-22 Raptor musste über Schnittstellen, die in den 1970er Jahren entwickelt wurden, mit Altsystemen verbunden werden. Selbst ein Flugzeug, das so teuer ist, könnte alte Systeme nicht umgestalten lassen. Der Raptor passte in die vorhandene Schnittstelle und Datenstruktur.
Eine häufige Einschränkung, die von schnelllebigen Teams übersehen wird, ist, wie sich länderübergreifende Gesetze oder ein Geschäftsplan auf das Produkt auswirken. In diesen Fällen hat das EA-Team die Pflicht, sich einzugraben und die minimal notwendigen Einschränkungen zu entwickeln, um zu verhindern, dass das Produkt in einem ungünstigen Moment radikal umgestaltet werden muss. Wie alle Einschränkungen der Kreativität verstehen gute EA-Praktizierende die Bedeutung von gerade genug.
Enterprise Architecture & Agile: Abhängigkeiten lösen
Wir können davon ausgehen, dass eA-Praktiker, die in einem Unternehmen arbeiten, eingreifen und Abhängigkeiten und Konflikte lösen müssen, die zwischen Produkten, Lösungen und Systemen entstehen. Schauen Sie sich einfach TOGAF Phase G an, sie unterstreicht die Notwendigkeit von Anleitungen und Architekturänderungen. Agile Entwicklung und moderne Integration machen diesen langlebigen Bedarfsservice wichtiger denn je.
Entsperren Sie das Portfolio
Auch wenn Sie nicht durch Altlasten eingeschränkt sind, wird es mehrere Produkte geben, die in die Zukunft gehen. Kreative Best-Practice-Teams für agile Entwicklung werden verschiedene Wege finden, um Probleme anzugehen. Es ist töricht zu erwarten, dass Kreativität keine Konflikte hervorruft. Von einem guten EA-Team, das in Phase G arbeitet, wo die gesamte agile Softwareentwicklung stattfindet, kann erwartet werden, dass es den Konflikt im gesamten Unternehmensportfolio löst.
Identifizieren Sie echte Stakeholder
Echte Stakeholder sind oft schwer zu finden. Viele taktische Entscheidungen werden delegiert. Wenn die Delegation formell ist, kann das agile Team davon ausgehen, angemessenen Zugriff zu haben. Wo die Delegation informell ist, kann erwartet werden, dass lokale Fachexperten und Benutzer eine nicht abgestimmte Agenda vorantreiben.
Das Enterprise-Architecture-Team hat keine besondere Fähigkeit, Engagement zu gewinnen. Sie haben die Fähigkeit, die Anliegen der Stakeholder durch eine überlegene Architektur zu vertreten.
Überqueren Sie das Portfolio
Product Owner und andere Mitglieder eines Entwicklungsteams sind bestrebt, ein Produkt schrittweise bereitzustellen. Minimal Viable Product und Incremental Delivery bilden den Kern des agilen Wertversprechens.
Der gesamte agile Ansatz beruht auf dem beobachteten Versagen, sich jede Interaktion in einem komplexen Portfolio vorzustellen, das ist der Fehlerpfad. Ein detailliertes Top-Down-Enterprise-Design kann für isolierte Systeme funktionieren. Innerhalb eines Ökosystems, das sich verändert, versagt Top-Down-Design immer. Dieser Fehlerpfad ist der Grund, warum Agilität existiert und warum Agilität bevorzugt wird.
Es ist fast unmöglich, sich eine komplexe Zukunft vorzustellen, der Versuch, dies zu tun, endet oft in einer Farce. Aber wir müssen gerade genug tun. Wenn mehrere Produkte entstehen, entstehen neue Konflikte und Synergien. Ein gutes EA-Team mit umfassendem Verständnis für die Änderungen der Prioritäten ihres Unternehmens hilft bei der Bewältigung von Synergien und Konflikten.
Wenn das EA-Team Überschneidungen entdeckt, muss es seine Erkenntnisse und sein Engagement nutzen, um die beste Antwort zu erhalten. Häufig handelt es sich dabei um einen risikogesteuerten Ansatz. Der erste Schritt ist eine rasche Bewertung des Konflikts, um festzustellen, ob die Lösung verschoben werden kann. Die Nutzung von Synergien und die Vermeidung von Konflikten sind teuer. Teuer und zeitaufwändig. Sie wirken sich direkt auf die Time-to-Market aus.
Wir sprechen von Marktkräften und kreativer Zerstörung, wenn wir das Portfolio überqueren müssen.
Wirkung freigeben
Gerade genug Architektur bedeutet, dass nicht jede Eventualität, jede Einschränkung, jeder Konflikt vor der Veröffentlichung entdeckt wurde.
Es gibt einen Fall, in dem ein Architekturteam einen Notfall hat. Es ist eine Post-Release-Krise. Diese seltenen Fälle, in denen Auswirkungen über das Produkt hinausgehen. Produkt ist in freier Wildbahn. Endbenutzer innerhalb und außerhalb unserer Organisation verwenden es. Sie haben es entweder mit einem Defekt zu tun oder, schlimmer noch, sie schaffen unvorhergesehene Risiken und Haftungen für unser Unternehmen.
Fazit von Agile und Enterprise Architecture
Sowohl agile Entwicklung als auch Unternehmensstruktur unter chronischer Fehlanwendung leiden. Zu oft gleichzeitig.
Sechs Anwendungsfälle decken alle Aspekte der Agile- und Unternehmensarchitektur ab. Die Unternehmensarchitektur leitet und schränkt die agile Softwareentwicklung ein.
Bei der Verknüpfung mit agiler Softwareentwicklung müssen die Unternehmensarchitekten:
- Definieren des agilen Vorgehens
- Führen des Rückstands im Sprint
- die Sprints einschränken
- Lösung für produktübergreifende Abhängigkeiten
Unternehmensarchitektur läuft auf Grenzen hinaus – tun Sie dies, tun Sie das nicht. Jede Grenze schränkt die Kreativität eines agilen Softwareentwicklungsteams ein. Ohne ein übergeordnetes Bedürfnis nach Zwängen nicht. Einfach nicht.
Der TOGAF-Wissensbestand unterstützt die Entwicklung eines effektiven Governance-Ansatzes.
Nehmen Sie am Enterprise Architecture Kickstart teil
Kostenloses 12-wöchiges Programm, um ein besserer Unternehmensarchitekt zu werden