Die Zukunft von Enterprise Architecture Management ist integrativ – Interview mit Dr. Udo Nink

Hallo Udo: Sprechen wir über Enterprise Architecture Management (EAM). Um unser Interview mit einem geteilten Begriffsverständnis zu starten: Was verstehst Du unter EAM und wo hilft Unternehmen diese Disziplin?

EAM ist die Architektur im Großen, vergleichbar mit der Stadt- und Umweltplanung. Dagegen ist die Architektur eines Einzelsystems konkreter, vergleichbar mit der Architektur eines Gebäudes oder einer Industrieanlage. Dazwischen liegen noch Initiativen und Projekte. Auf alle kann man gezielt EAM-Ansätze übertragen und sie miteinander verzahnen.

Aktuell beschäftigen sich viele Unternehmen mit der digitalen Transformation. Hauptfrage: „Wie kommen wir von unseren analogen Produkten zu digitalisierten Vertretern und was kostet mich das?“. Die strategische Ebene wird wieder wichtiger und damit auch EAM. Gleichzeitig möchten Unternehmen aber das Elfenbeinturmdenken vermeiden. Dazu braucht es integrative Ansätze: EAM und agil, EAM und Service-Architektur usw.

Eine zentrale Rolle im Management von Unternehmensarchitekturen ist die Modellierung. Seit über 15 Jahren modellierst Du in EAM Projekten. Nach all der Zeit: Was sind Deine wichtigsten Kernerkenntnisse?

Meine erste Erkenntnis ist, dass sich ein Miteinander von EAM und Service-Architekturen herauskristallisiert.

Folgendes wollen Organisationen erreichen:

1. Elfenbeinturmdenken und Papiertiger unbedingt vermeiden.
2. Service-Architektur zahlt in Portfolioarchitektur ein und Portfolioarchitektur passt sich an die von der Service-Architektur geschaffene Realität immer wieder an.
3. Unternehmensarchitektur und Service-Architekten arbeiten kollaborativ.
4. Portfolio- und Service-Dokumentation sind nachhaltig.

Meine zweite Erkenntnis ist: Architektur-Methodiken und Tools werden konvergieren.

Was ist das Problem heute?

1. Methodiken sind wichtig, aber uneinheitlich.
2. Rein dokumentenorientierte Ansätze sind out, data-driven ist die Zukunft.
3. EAM und Service-Architektur setzen verschiedene, wenig integrierte Tools ein.

Das erzeugt Blindleistung. Wie kam es dazu? Bei EAM ist das Zielpublikum eher wirtschaftlich strategisch geprägt, während Servicearchitektur ingenieurhaft ist mit Modellierung oder laienhaft mit Office-Tools. Deshalb sind EAM-Tools auch ERP-orientiert und Service-Architektur-Werkzeuge sind visuell getrieben.

Wir brauchen passende Metamodelle und Werkzeuge. Relevante Metamodelle sind z.B. ArchiMate als Teil des TOGAF-Standards, UAF (Unified Architecture Framework) der OMG (Object Management Group) oder NAF (NATO Architecture Framework). Sie unterstützen sowohl Portfolio als auch Service und sind die Grundlage für geeignete Werkzeuge.

Meine dritte Erkenntnis: Tool Chains werden integriert.

Derzeit entstehen Integrationsplattformen, die sich der Verknüpfung von Tools in der Entwicklungskette verschrieben haben. Sie bieten das für EAM, Service-Architektur, Requirements Management, Output Management usw. Beispiele dafür sind Sparx Prolaborate oder MID Smartfacts.

Tauchen wir noch etwas tiefer in die Welt der Unternehmensmodelle ein. Regelmäßig entwickelst Du für Kunden domänenspezifische Sprachen. Was ist das genau und wo hilft mir eine Domain Specific Language als Enterprise Architect?

Eine domänenspezifische Sprache (DSL = Domain Specific Language) ist wie ein Maßanzug, eine zugeschnittene Sprache, die den Wortschatz einer Domäne umfasst z.B. für einen Kunden oder eine Branche. Im Grunde sind es Fachmodelle, die maschinell verarbeitet werden können. Wieso hält man sich nicht einfach an verfügbare Standards?

Meiner Erfahrung nach sind wir in Deutschland im Gegensatz z.B. zu den Amerikanern viel weniger bereit, Prozesse und Anforderungen den verfügbaren Standards anzupassen. Standards sind generisch und berücksichtigen eher selten branchenspezifische und erst recht nicht unternehmensspezifische Bedürfnisse. Doch die meisten Unternehmen haben ihre Unternehmensstandards. Dadurch entstehen Lücken. Diese lassen sich mit DSLs schließen.

Schauen wir uns die Branchen Automobil, Gesundheit und Finanzen an. Wer über Steuergeräte im Fahrzeug redet, hat ein anders Vokabular als Jemand, der sich auf Medizinprodukte oder Credit Scoring spezialisiert. Sofort wird klar, dass Sprache auf allen Ebenen relevant ist. Vokabular unterscheidet sich umso deutlicher, je tiefer man in eine Materie eintaucht. Bis auf einzelne Felder hinunter.

Zu Deiner Frage, wieso mir eine DSL als Enterprise Architekt hilft. Ich formuliere die Frage um: „Wieso hilft sie meinen Kunden?“. Sie hilft meinen Kunden, weil sie ihre Architektur verständlicher und präziser mit ihrem eigenen Wortschatz beschreiben und vermitteln können. Sie hilft meinen Kunden, weil sie verfügbare Standards verwenden und an ihre bestehenden Wortschätze zuschneiden können.

Ich kann mich noch an meine Studienzeit um 2004 erinnern. Damals verfolgten Universitäten und Tool-Hersteller das Ziel aus Modellen direkt Programmcode zu generieren. Ist der Traum heute – über 16 Jahre später – Realität geworden?

Ingenieurbereiche wie die Fahrzeugentwicklung sind viel weiter als die klassische IT. Meiner Meinung nach liegt das an den vorhandenen Skills bzw. der Ausbildung. In der Fahrzeugentwicklung generiert man mehr. Das Ergebnis, gegen das man generiert, ist mächtiger.

Der Trick lautet Abstraktion und Kapselung, Kernkonzepte der Informatik. Wir reden von Plattformen, die mächtige Funktionen auf low-level Details kapseln. Mit der Codegenerierung muss man praktisch nur deren Aufruf orchestrieren. Das ist einfacher.

In der klassischen IT ist Codegenerierung häufig auf wenige Aspekten fokussiert wie z.B. Datenbank- oder XML-Schemata. Den überwiegend prozeduralen Anwendungscode programmieren die meisten Entwickler heute im Grunde noch immer mit der Hand am Arm wie vor 30 Jahren, nur mit besseren IDEs (Integrated Development Environment). Was man im übertragenen Sinne braucht, ist, ein Legokasten. Die Legosteine können dann modellhaft zusammengestöpselt werden. Ein Codegenerator muss also nicht in der Lage sein, einzelne Lego-Steine zu fabrizieren. Er muss sie nur kennen!

Mit dieser Erkenntnis haben es einige Anbieter zu einer gewissen Akzeptanz und Verbreitung gebracht, wie z.B. Appian oder kissflow. Deren Produkte fallen unter die Rubrik BPM-Plattformen, die ausführbare Modelle unterstützen (BPM = Business Process Management). D.h., man formuliert grafisch seine Prozesse mit Prozessschritten. Schritte sind ihrerseits ausführbare Einheiten. Sie können ebenfalls Prozesse sein oder vorgefertigte Funktionen, die der Hersteller mitliefert, oder auch eigene von Hand programmierte Funktionen. Es muss in diesem Fall noch nicht mal Code generiert werden. Es genügt, wenn die Modellbausteine ausführbar sind und die Orchestrierung im Modell auf einer Workflow-Engine ablaufen kann.

Ein weiteres Beispiel. Bei der Entwicklung autonomer Fahrzeuge verursacht Funktionssicherheit Unsummen an Testaufwand. Je mehr man modellbasiert simulieren kann, desto weniger echte Fahrzeuge muss man in der Realität testen – eine Kosten-/Nutzenrechnung. Diese Entwicklung wird vom Trend der Digital Twins weiter beflügelt. Digitale Abbilder physischer Produkte ermöglichen die Analyse von Änderungen. Erst dann entscheidet man, ob man diese in die Realität umsetzt oder anders oder gar nicht.

Lass uns mit der letzten Frage das Vorgehen und die Werkzeuge im EAM beleuchten. Was ist wichtiger: die Methodik oder das Tooling?

Häufig herrscht im EAM das Credo: „Methodik ist wichtiger als das Tooling“. Dazu stelle ich gerne eine Testfrage: „Wieso ist das bei der Code-Programmierung nicht so?“

Bei der Programmierung ist es vielmehr so, dass Methodik und Tooling Hand in Hand gehen. Jede Programmiersprache braucht eine Grammatik. Aber ohne geeignete IDE bzw. ohne auf Machbarkeit Rücksicht zu nehmen, entstehen Papiertiger. Schaut man sich die erfolgreichsten Programmiersprachen an, dann sind das die, für die es auch die besten Tools gibt. Daraus können Unternehmensarchitekten lernen.

Meine feste Überzeugung auch für EAM als auch Modellierung ist, dass die geschickte Kombination von Methodik und Tool zum Erfolg führt. Es gibt kein ‚wichtiger‘. Es passt auch besser zu einer agilen Arbeitsweise mit iterativem Fortschritt.

Einführungsprojekte, die sich zunächst und ausschließlich langen Phasen der methodischen Vorbereitung gewidmet und dabei das Tooling verdrängt haben, scheitern gerne. Das hat dem Thema EAM in der Vergangenheit sehr geschadet. Daher auch die große Angst vor dem sogenannten Elfenbeinturm.

Umgekehrt setzen manche Unternehmen von Beginn an auf Tool-Evaluierung und dann oder auch sofort auf ein auserkorenes Tool. Häufig ist man dann auch mit einer proprietären herstellerspezifischen Methodik verheirate. Das muss nicht schlecht sein, es wird höchstens teurer bei einer Scheidung. Auch Anpassungen sind meist nur in Grenzen möglich und werden schnell sehr kostspielig.

Die Zukunft lautet also: „Methodik mit Tooling“ in einem kontinuierlichen Verbesserungsprozess. Ein Schritt in Richtung Methodik, ein Schritt in Richtung Tool – wiederhole! Ich denke nicht erst ein Jahr lang über die perfekte theoretische Methodik nach. Nein, ich gehe Schritt für Schritt vor. Jeder Schritt erweitert mein stetig wachsendes Ökosystem. Verifikation inklusive. So erzielt man eine Rückkopplungsschleife, die sonst eher abstrakte Vorgehensmodelle verständlicher und praktikabler macht.

Zur Person Dr. Udo Nink