Enterprise Architecture – das ist doch sowas von 90’er
Auf der einen Seite haben Enterprise Architekten im Augenblick keinen guten Ruf. Da gibt es Kosenamen wie: „Architekten im Elfenbeinturm“, „UML Junkies“, „Besserwisser“ oder „Nacheilende Dokumentatoren“. Und dann gibt es auch noch den Traum aller Enterprise Architekten, einmal alle Systeme, deren Use Cases, Interfaces und implementierten Prozesse richtig abzubilden. Am Besten noch in einer lebenden Dokumentation mit einem Tool, das unglaublich teuer ist und zu dem nur eingeweihte einen Zugang haben.
Product Driven Development – der heiße Scheiß
Auf der anderen Seite gibt es die Digitale Transformation. Hier tummeln sich ganz andere Schlagwörter oder eben Buzzwords: Microservices, You build it You run it, Scrum, agile Fehlerkultur, Brownbag Sessions, Fuckup Nights, Error Budgets, etc.. Dahinter steht der feste Glaube der Verantwortlichen, wenn wir nur mal durch die Digitale Transformation durch sind, wird alles, was wir anfassen zum Erfolg. Wir sind dann „Easy as Apple“ und alles geht dann auf Einmal ganz schnell. Heute haben wir eine Idee und morgen probieren wir sie schon in Produktion an unseren Kunden aus.
Ein Schwein und ein Huhn – das Geheimnis dahinter
Es ist richtig, dass die klassische Enterprise Architektur in digitalisierten Unternehmen keinen Platz mehr haben darf, da sie die Produktteams in ihrer Arbeit negativ beeinflussen. Der Grund hierfür ist das Verhältnis zwischen Betroffenen und Beteiligten. Das wird sehr anschaulich mit dem sogenannten Huhn/Schwein-Pattern illustriert:
Ein Huhn und ein Schwein eröffnen ein Frühstücksrestaurant, bei dem ausschließlich Rührei mit Speck serviert werden soll. Dadurch nimmt das Schwein die Rolle des Betroffenen ein und das Huhn ist lediglich beteiligt. Man kann sich vorstellen, dass das Schwein die Entscheidungen über den „Lieferprozess“ der Lebensmittel haben sollte und das Huhn damit eher die Rolle des Zuhörers einnimmt. Bei agilen Entscheidungsprozessen nennt man das den „silent Chicken Mode“.
Klassische Unternehmen haben aufgrund ihrer ganzheitlichen, effizienzoptimierten Prozesse viele Beteiligte und wenige Betroffene bei jeder Entscheidungsfindung. Dadurch kommt es, dass wenige Betroffene die über viele Meetings hinweg gefällten Entscheidungen „ausbaden“ müssen. Zum einen lähmt das die Entwicklungsgeschwindigkeit der jeweiligen Komponenten. Zum anderen fehlt bei den Betroffenen dadurch oft das nötige emotionale „Commitment“.
Kennen Sie aus Ihrem Umfeld Sätze, die mit „Man müsste das eigentlich, …“, „Ich verstehe gar nicht, warum …“ oder „Es ist doch klar, dass das nicht funktioniert …“ beginnen? Hier sprechen Betroffene, die von Beteiligten überstimmt wurden.
Die digitale Transformation justiert dieses Verhältnis neu: Viele Betroffene und nur sehr wenige Beteiligte. Also stark gekapselte Produktteams, die mit maximaler Unabhängigkeit ihre Produkte weiterentwickeln.
Was für eine Rolle spielt aber in diesem Ansatz die Enterprise Architektur? Sie ist ja ein klassisches Huhn. Kann sie also weg?
Die Antwort versteckt sich hinter zwei neuen Fragen:
- Wie macht man aus einem Huhn ein Schwein?
- Was für einen Mehrwert stiftet die Enterprise Architektur?
Digitale Produkte – wie ist ein Schwein gebaut?
Erfolgreiche digitale Produkte leben nach einem einzigen eisernen Grundsatz:
Hohe Kohäsion und lose Kopplung.
Die Kohäsion zielt dabei auf das innere eines Produktes ab. Das Aufgabengebiet, das von dem Produkt exklusiv behandelt werden soll, muss möglichst eng und hermetisch sein. Es macht zum Beispiel wenig Sinn, wenn sich ein Produkt um den Bestellprozess und gleichzeitig über die Bestandsführung im Lager Gedanken macht, weil beide Themen nicht eng genug zusammenhängen.
Die lose Kopplung fordert, auf welche Art und Weise die Produkte (und deren Teams) miteinander kommunizieren: über Services, die unabhängig genutzt werden können. Dabei müssen die Services so beschrieben und zur Verfügung gestellt werden, dass man sie ohne weitere zusätzliche Information nutzen kann. Im Beispiel des Produktes für Bestellungen wäre das: „Bitte löse für diesen Kunden mit der ID 123 die Bestellung der Waren mit folgenden ID’s aus: 4711, 4712 und 4713“. Das Bestell–Produkt holt sich dann mit der Kunden-ID vom Kunden-Produkt alle relevanten Informationen und mit den Produkt-IDs vom Produkt Service alle nötigen Produktinformationen. Danach erzeugt es einen Bestellauftrag für das Lager und so weiter.
Mit dieser Definition (Hohe Kohäsion und lose Kopplung), könnte man die Enterprise Architektur eines Unternehmens ebenfalls als ein digitales Produkt anbieten. Dadurch würden alle vormals nur beteiligten Architekten zu Betroffenen.
Somit bleibt noch zu klären, welchen Mehrwert die Enterprise Architektur in einem digitalisierten Unternehmen stiftet.
Enterprise Architektur – ein sinnvolles digitales Produkt!
Die Kohäsion und damit der Sinn des Themas „Enterprise Architektur“ liegt auf der Hand: „Sorge dafür, dass alle technische unternehmenskritische Aspekte umgesetzt werden.“ Das sind im Wesentlichen zwei:
Homogenität: Im Deployment und Delivery (CI/CD), im Betrieb (z.B.: Cloud first), beim Logging und Monitoring, bei der Security (z.B.: zentrale Authentifizierung und Autorisierung, https only, …), bei den Verwendeten Produkten („Wie viele CMS Produkte haben wir eigentlich derzeit im Betrieb?“). Dadurch erzeugt man eine gleichförmige Art und Weise, wie entwickelt wird und verhindert local Heroes und schwer zu skalierenden Ressourcen. Zudem fördert man einen sicheren und verfügbaren Betrieb der Gesamtlösung.
Lose Kopplung: Alle Produkte dürfen nur noch über einen gehärteten API Layer miteinander kommunizieren. Dort werden alle Services konform angemeldet und zur Verfügung gestellt. Dadurch erzeugt man die Austauschbarkeit einzelner Lösungen und minimiert unnötige Abstimmungsmeetings zwischen den Produkten (wenige Hühner).
Die lose Kopplung des Produktes „Enterprise Architektur“ kann man durch drei angebotene Services erreichen.
- „Was-Service“: Die Enterprise Architektur (EA) übernimmt Make–Buy–Use Assessments, führt eine Entscheidung herbei und kümmert sich um die Umsetzung des beschlossenen Ansatzes. Wenn also ein Software Produkt gekauft oder genutzt (SAAS) werden soll, überprüft die EA die Gebrauchstauglichkeit im Unternehmenskontext, ob es dafür nicht schon eine Lösung im Unternehmen gibt oder ob man die Software nicht selbst bauen sollte.
- „Wie–Service“: Die Enterprise Architektur gibt Auskunft, wie andere Produkte ein spezifisches Problem lösen. „Wie machen wir CI/CD?“, „Wie machen wir Pull over Push?“. Wenn es für die Anfrage im Moment noch keine Lösung gibt, organisiert die EA ein Gilden Treffen und moderiert die Community zu einem Guiding Principle, an dass sich dann alle Produkte halten, um in homogener Art und Weise entwickeln zu können. Die gefundenen Guiding Principles werden ebenfalls von EA in alle Produkt Teams getragen und stellt sicher, dass die Prinzipien verstanden und akzeptiert wurden.
- „KPI–Service“: Die EA sorgen dafür, dass vom API Layer und der Infrastruktur permanent Metriken abgegriffen werden können, von denen die Organisation ableiten kann, ob die Prinzipien, die sich alle gegeben haben, auch entsprechend eingehalten werden.
Das sind natürlich keine REST Services, sondern ein Ticketsystem, eine Telefonnummer, eine Mailadresse und eine aufgeräumte adressatengerechte Confluence Seite, über die man die Services anfragen kann.
Durch diesen Ansatz erreicht man, dass sich die Enterprise Architektur komplett aus dem Produktkontext heraushält. Alles, was im Produkt geschieht, bleibt Sache des Produktteams und kann von diesem eigenständig entschieden und verantwortet werden. Auf der anderen Seite ist der Raum zwischen den einzelnen Produkten und der Raum zwischen den Produkten und der Infrastruktur das Hoheitsgebiet der Enterprise Architektur. Hier ist sie betroffen und entscheidet somit auch.
Eine Erfahrung aus der Praxis
Derzeit habe ich die Möglichkeit dieses Konzept bei einer sehr großen europaweiten Einzelhandelskette in die gelebte Wirklichkeit mit umzusetzen. Stück für Stück kann ich bei diesem Change Prozess feststellen, wie die Enterprise Architekten immer stärker als Service Provider wahrgenommen werden, die sich ganzheitlich um Probleme kümmern und den einzelnen Produktteams lose gekoppelt Arbeit abnehmen.
So entsteht unternehmensweit eine homogene und sichere Softwarelandschaft, in der sich die einzelnen Produktteams im hohen Maße unabhängig und eigenständig um ihre Produkte kümmern.
Eine vormals streng hierarchische Organisation, die ihre gesamte Historie Top–Down und hochgradig prozessoptimiert agiert hat, ändert sich in ein digitalisiertes Unternehmen, das seine Entscheidungen Botton-Up in Community Prozessen trifft. Dadurch entsteht ein hohes Maß an effektiver Schlagkraft, die nötig sein wird, um im digitalisierten Markt überleben zu können.
Wenn Ihnen der Artikel gefallen hat, könnte Sie auch mein Blog über unseren KillerBot gefallen: