Ursprünglich veröffentlicht am 19. September 2020 auf redblog

Von: Dr. Christoph Moser, Boris K.A. Reinhard

Wir zeigen im Folgenden einen Denkansatz auf, diese Herausforderung mit dem agilen Framework OKR und dem Enterprise Architecture Management (EAM) – Standard ArchiMate zu meistern. Wir demonstrieren damit, dass Agilität und Architektur zusammen passen.

Unser Case

Die fortschreitende Entwicklung von elektrischen Antriebstechnologien und Batteriesystemen hat für den fiktiven Energielieferanten GreenEnergy ein neues Geschäftsmodell eröffnet: eMobility. GreenEnergy plant in diesem Kontext eine Partnerschaft mit dem eRoaming-Spezialisten Plug & Charge.

Plug & Charge ermöglicht eFahrzeug-Lenkern eine nutzerfeundliche Ladung ihrer Fahrzeuge. Dieses erfolgt ohne administrative Aufwände, das heisst (Kabel) „Anstecken und Losladen“. Die Abrechnung erfolgt bequem über die Stromrechnung. Durch die automatische Authentifizierung und Autorisierung an der Ladestation ist eine vorgängige Registrierung (z.B. RFID-Karten-Systemen, Kreditkarten, Mobile Apps) obsolet. Die Customer Experience wird massiv erhöht und dadurch die Nachfrage angekurbelt.

Mit dem Entscheid zur Einführung des neuen Modells wird gleichzeitig ein Entscheid über die Zukunft der Architektur des Unternehmens getroffen. Bei Umsetzung und Bereitstellung der erforderlichen Capabilities werden Geschäftsprozesse von GreenEnergy adaptiert. Neue Systeme werden eingeführt. Informationsflüsse und Schnittstellen werden angepasst. Die „digitale“ Capability „Anstecken und Losladen“ wird bereitgestellt.

Ansatz OKR & ArchiMate

Die Einführung dieses neuen Verkaufskanals erfolgt im Rahmen eines agilen Ansatzes. Vorerst soll frühes Kundenfeedback im Fokus stehen. Erst in den späteren Phasen soll der Schwerpunkt auf die technische Infrastruktur gelenkt werden. Zentral für jeden Zyklus im Vorhaben sind die „Objectives & Key Results“ (OKR), durch deren Erreichen ein messbarer Mehrwert für GreenEnergy und seine Kunden generiert wird (Anm.: Grundlagen zu OKR werden hier nicht weiter erörtert, bitte nehmt hierzu Kontakt auf).

Am Ende eines OKR-Zyklus steht ein Zielzustand, in ArchiMate „Plateaus“. Die Objectives können in ArchiMate durch Goals, die Key Results durch Outcomes repräsentiert werden.

Der erste Zyklus (Plateau 1) wird im OKR-Planning ausformuliert. Für jedes OKR-Set müssen die zuständigen Teams jeweils ein Commitment abgeben. Unser erster Zyklus beinhaltet unter anderem nachfolgende OKRs.

Objective (Beispiel)

Testkunden können per Plug & Charge mit einem Prototyp laden

Key Results (Auszug)

  • Der Interimsprozess für den halbautomatischen Datentransfer der Abrechnungsdaten (Abrechnungsfile) ist eingeführt.
  • Ein Prototyp wird für 10 ausgewählte Stationen bereitgestellt.
  • Der Plug & Charge Prototyp steht für eine Anzahl von 30 Testkunden zur Verfügung.

Weitere Zyklen / Plateaus

Die OKR-Sets für die weiteren Plateaus werden jeweils zu Beginn des neuen Zyklus im Rahmen der Plannings definiert, wenn die Erkenntnisse aus dem vorgängigen Zyklus vorliegen (Stichworte „Review“, „Retro“ – in der Praxis überschneiden sich die Zyklen leicht).

Die Roadmap bildet in weiteren Plateaus erste grobe Vorstellungen ab, die nach jedem Zyklus justiert oder neu formuliert werden müssen.

Die nachstehende Sicht zeigt die Roadmap in einer im Architekturmanagement üblichen ArchiMate-View. Im Rahmen des OKR-Plannings werden die OKRs für das Unternehmen, die Bereiche und Teams für den jeweils aktuellen Zyklus abgestimmt. Die aktuellen OKRs zielen auf die Erreichnung des nächsten Plateaus ab.

Key Results können im OKR-Team je nach präferiertem Ansatz (z. B. Scrum, Kanban etc.) umgesetzt werden. OKR macht hierzu keine Vorgaben. Wir ordnen beispielhaft einem der Key Results Sprints (Workpackages) zu. Mit der Realisierung der Key Results respektive der Sprints werden Elemente der Unternehmensarchitektur eingeführt, modifiziert oder abgelöst:

  • Der Geschäftsprozess „eCharging-Services abrechnen“ wird im Rahmen des Sprints „eCharging-Abrechnungsprozesse“ definiert.
  • Die erforderlichen Anpassungen an der Abrechnungsplattform „Settlement-Plattform“ für den manuellen Import der Abrechnungsdaten erfolgen im Sprint „eCharging Enablement“ usw.

Aus der Teilautomatisierung und den Medienbrüchen ergeben sich Risiken: „Abrechnungsfehler aufgrund fehlerhafter Datenübernahme“ und „Verzögerte Abrechnung“. Diese werden in ArchiMate als Assessment abgebildet. Die Risiken werden für Plateau 1 akzeptiert. Vor Implementierung von Plateau 2 müssen diese nochmals in Hinblick auf ihre Auswirkungen bewertet werden.

Je nach Gewichtigkeit werden die Risiken entweder direkt in Plateau 2 oder in einem der nachfolgenden Plateaus adressiert.

Kleine Iterationen statt grosser Masterplan: Statt langfristige grosse Ziele festzulegen, konzentrieren wir uns auf kurze Planungs- und Umsetzungsintervalle. Plateau 2 wird noch nicht im Detail ausmodelliert. Somit kann flexibel auf die Erkenntnisse aus dem Vorgängerplateau reagiert werden. Key Results und Sprints sind ergo noch nicht definiert.

Outcome-driven Architecture: OKRs als zwingender Bestandteil der Transformations-Roadmap

Der aggregierte Fortschritt der Key Results reflektiert den Gesamtfortschritt bezogen auf das zugehörige Objective. Auch wird für jedes Key Result fortlaufend das „Confidence Level” eingeschätzt. Das Confidence Level spiegelt wider, wie wahrscheinlich es ist, dass ein Key Result tatsächlich im laufenden Zyklus erreicht werden kann.

Im nachfolgenden Transformations-Cockpit werden zusätzlich zu den OKRs die Architektur-relevanten Aspekte in einer für alle Stakeholdergruppen (Endkunde, Product Owner, Scrum Master, Enterprise Architect, etc.) Art und Weise kommuniziert.

Screenshot: ADOIT, <a href=“http://www.boc-group.com/adoit“>www.boc-group.com/adoit</a>

Fazit

Unser Denkansatz zeigt, wie die beiden Welten durch OKRs und ArchiMate integriert werden können.

Wir adressieren diese Herausforderung der Architektur, indem wir OKRs aus der agilen Welt Architektur-Plateaus allozieren, anhand derer die Roadmap Schritt für Schritt ausgestaltet wird.

Die Autoren

Boris K.A. Reinhard – Dipl.-Ing. & M.Sc.
Boris sieht seine Aufgabe darin, Organisationen beim Wandel zu befähigen. Er ist Unternehmer, Management-Coach, Dozent, Trainer und Mentor. (https://redminds.co).

Dr. Christoph Moser
Christoph ist Produktmanager von ADOIT, der von Analystenhäusern als Leader eingestuften EA-Suite.

Diesen Bericht teilen!

Jetzt für unseren kostenlosen Newsletter anmelden

Fachartikel zu brandaktuellen Themen, Informationen zu Webinaren und regionalen Events
sowie Ankündigungen neuer Produktversionen.