Unser Blogpost zu EA ( http://itmc.ch/post/enterprise-architektur-braucht-einen-neuen-ansatz ) ist schon eine Weile her – aber die These noch sehr aktuell: Ein neuer Ansatz im Enterprise Architektur Management wurde gefordert – agiler, konkreter, kommunikativer. Ausserdem die These, dass „Synergie“ in den Hintergrund tritt, und dass der zeitliche Faktor bzw. die zeitliche Entwicklung von Architektur explizit werden muss.
Passt in diese neue Welt noch EA-Modellierung? Braucht es noch die vielen schönen Tools, die Analysen, die Reports?
Auf den ersten Blick könnte man zum Schluss kommen, dass die EA-Modellierung zum alten Eisen bzw. in den Elfenbeinturm gehört. Wenn EA schnell sein muss, wer hat dann monatelang Zeit, auf die Fertigstellung von Modellen zu warten? Ist nicht alles schon in dem Moment veraltet, in dem es fertig modelliert ist?
Klingt überzeugend, oder? Auf der anderen Seite: Was macht ein EA, wenn nun eine konkrete Anfrage kommt – etwa vom Betrieb (Problem Management!) oder vom Auditor? Wie können aktuelle, korrekte Informationen zur Unternehmens-IT geliefert werden? Wo, um ein scheinbar triviales Beispiel zu nennen, ist die definitive und aktuelle Liste aller IT-Applikationen?
Jetzt jedesmal mit primärer Forschung zu beginnen und Herumzufragen, das kann ja auch nicht die Lösung sein – und es wäre ganz bestimmt nicht agil.
Jedes Unternehmen braucht eine Übersicht über den Status der IT. Eine Darstellung, die aktuell ist und die wichtige (aber nicht alle) Informationen abbildet. Eine solche Darstellung kann man nicht anders nennen als, ja, als ein „Modell“. Ein Abbild der Realität, für Analysezwecke, zur Entscheidungsunterstützung.
Wenn einem das Wort „Modell“ zu altmodisch ist, dann kann man auch sagen „digital twin“ – und schon ist man wieder am Puls der Zeit.
Was ist nun an dem einen Modell schlecht, und an dem anderen Modell („digitaler Zwilling“) gut?
Ich bemühe mich auch noch, das genau herauszufinden. Aber meine Gedanken gehen zur Zeit in diese Richtung:
1) Das Modell muss komplett sein. Nicht „allumfassend“ – aber die Objekte, die man modelliert, sollten auch vollständig abgebildet sein. Beispiel: Werden Applikationen modelliert, dann darf es keine geben die nicht im Modell sind – der Scope wäre sonst immer unklar.
2) Qualitäten wie Aktualität und Korrektheit sind entscheidend – Details sind weniger wichtig. Simpel und dafür korrekt und aktuell, besser als ausgefeilt und unvollständig.
3) Die Pflege von Modellen ist viel wichtiger als die initiale Erstellung. Es braucht Mechanismen zur ständigen Aktualisierung – die akzeptiert und genutzt werden.
4) Modellierung mit dem Blick auf die Auswertungen. Die „Reports“ sind kein Abfallprodukt, sondern die Essenz. Die Modellierung sollten den Informationsbedürfnissen der Nutzer folgen, nicht umgekehrt.
Es entsteht ein Bild, bei dem das „Modell“ weniger ein „Kunstwerk“ eines Architekten ist, sondern eine Art minimalen Konsens darstellt für eine Sicht auf die Unternehmens-IT. Simpel und für alle verständlich. Der Aufwand geht zu 80% in Mechanismen der laufenden Pflege und Qualitätssicherung, und nur zur 20% in die initiale Modellierung.
Was ergeben sich daraus für Folgerungen?
Initialer Aufwand: Die Forderung nach Vollständigkeit führt zu einem gewissen initialen Aufwand – hier wieder das Beispiel mit dem Modell (aller) Applikationen. Den muss man im Rahmen halten – etwa durch geeignete Zusammenfassung (z.B. „alle Tools“, „alle lokal installierten Applikationen“). Auch ein schrittweises Vorgehen ist sinnvoll – und das simple Inventory der Applikationen (ohne weitere Relationen) kann durchaus ein guter Start sein.
Technische Schnittstellen zum / vom Modell: Technische Schnittstellen zwischen Modell und anderen Systemen – etwa zu CI/CD pipelines und zur CMDB – können eine grosse Rolle spielen, um die Qualität und Vollständigkeit zu erhöhen. Man bezahlt den Preis einer (stark) erhöhten Komplexität, aber den muss man bezahlen wenn man eine wirklich konsistente Sicht auf die „Wahrheit“ will – also ein allgemein akzeptiertes „Modell“ der Realität.
Meiner Ansicht nach sind die Tool-Hersteller hier gefordert, und neue Toolkategorien – die die Brücke schlagen zwischen Modellierung / Inventory, ECM, CMBD, … könnten in Zukunft entstehen. Es könnte durchaus auch sein, dass das führende Modell nicht mehr in einem der klassischen EA-Tools geführt wird, sondern in der CMDB.
Wer von den Lesern des ITMC-Blogs hat hier Erfahrungen, hat eine Meinung, und möchte das Thema diskutieren?
Gibt es zum Beispiel Erfahrungen mit der Modellierung physikalischer Assets – und gelten dort ähnliche Regeln?
Wir freuen uns auf einen Austausch!
