Enterprise Architecture Management Frameworks – Teil 1

In dieser zweiten Serie zum Thema Enterprise Architecture Management geht es um Frameworks für Enterprise Architecture Management (EAM). Die erste EAM-Serie hat sich in drei Teilen ausführlich den Definitionen der Begriffe Architektur, Unternehmensarchitektur (Enterprise Architecture) und Unternehmensarchitekturmanagement (Enterprise Architecture Management) gewidmet.

Im ersten Teil der aktuellen Serie will ich zunächst eine Definition für Enterprise Architecture Frameworks, hier abgekürzt mit EAF, herleiten. Quellenangaben zu dieser Serie finden sich gesammelt an zentraler Stelle.

Enterprise Architecture Management Frameworks

Allein in der Informatik gibt es eine Vielzahl unterschiedlicher Frameworks. Exemplarisch seien hier drei genannt, die Programmierern die Arbeit durch vorgefertigte Bausteine erleichtern sollen. So liefern Frameworks für ContentManagement-Systeme wie TYPO3 beispielsweise Module für Datenbankzugriffe mit. Im bekannten Webframework JSF (Java Server Faces) wird das Model-View-Controller Konzept umgesetzt. View-Komponenten werden häufig durch JSP (Java Server Pages) realisiert, während der Controller in Java geschrieben werden kann und Java-Beans für das Modell vorgesehen sind. Diese bei weitem unvollständige Liste soll durch das Test-Framework JUnit abgeschlossen werden, welches dabei hilft, Java-Programme automatisiert auf Fehler zu überprüfen.

„Enterprise Architecture Management Frameworks – Teil 1“ weiterlesen

Eine EAM Visualization entsteht …

… oder wie man von einer (konkreten) Fragestellung zu einer EAM Visualization kommt.

Kennen Sie das? Der allgemeine Druck wächst zunehmend grafisch zu kommunizieren. In diesem Beitrag möchte ich zwei Varianten vorstellen, wie Sie, ohne Druck, den grafischen Kommunikationsbedarf decken können.

Variante 1: Eine fertige EAM Visualization verwenden

Man kann uns fragen und wir greifen auf unsere Erfahrung und über 100 Fragen und deren mögliche grafische Beantwortung zurück, siehe z.B. diese typische Fragestellung.

Dieser Fundus existierte jedoch nicht „schon immer“, und nicht immer finden wir dort etwas Passendes. In beiden Fällen gehen wir nach Variante 2 vor.
Das Vorgehen hinter Variante 2 beschreiben wir in diesem Beitrag an einem Beispiel, für das wir so tun, als wenn wir die Frage Wer nutzt was wofür noch nicht grafisch beantwortet hätten.
„Eine EAM Visualization entsteht …“ weiterlesen

EAM Visualisierung für die Kaffeeküche

EAM Visualisierung am Ort der Begegnung

Ich habe vor einiger Zeit ein Projekt begleitet, in dem unter anderem zwei IT-Landschaften zusammengelegt werden sollten. Die am Projekt beteiligten IT-Architekten hatten eine sehr gute Übersicht entwickelt. Sie zeigte den aktuellen Stand der Systemmigration aus den existierenden „alten“ Teillandschaften in die „neue“ gemeinsamte IT-Landschaft. Jeden Monat wurde diese Übersicht aktualisiert und in die Kaffeeküche auf einem DIN-A0-Ausdruck gehängt.

„EAM Visualisierung für die Kaffeeküche“ weiterlesen

Visualisierung für IT-Merger: Die Konsolidierungskarte

Eine komplexe – aber generierte – Visualisierung von vGen

Die Motivation für diese EAM Visualisierung stammt aus einem Projekt, dass ich mal begleitet habe. Das Konzept für die Visualisierung, wie sie in unserer Software implementiert ist, ist von Thomas Hellkamp 2014 in seiner Bachelor-Arbeit entwickelt worden. Die Arbeit trug den Titel „Zeitorientierte Visualisierungen von Unternehmensarchitekturen: Konzept einer Konsolidierungskarte“.

Das Ergebnis ist eine der Problemstellung eines IT-Mergers in Komplexität, Inhalt, Lesbarkeit und Konfigurierbarkeit angemessene Visualisierung. Ein weiterer Vorteil ist die Generierbarkeit. Man muss sie nicht mehr per Hand malen!

IT-Merger: Bedarf nach einer eigenen Visualisierung

Die Konsolidierungskarte wurde entwickelt, um Fragestellungen im Kontext von Unternehmensübernahmen zu beantworten. Der in der Bachelor-Arbeit entwickelte Kartentyp wird im Folgenden anhand des dort beschriebenen, motivierenden EAM-Szenarios vorgestellt.

„Visualisierung für IT-Merger: Die Konsolidierungskarte“ weiterlesen

Definition EAM – ein ausführlicher Versuch, Teil 3

In den Teilen eins und zwei dieser dreiteiligen Beitragsreihe habe ich an die Begriffe Architektur und Unternehmensarchitektur herangeführt. Der Spannungsbogen findet hier nun mit der Definition EAM, als des Enterprise Architecture Managements seinen Höhepunkt und gleichzeitg seinen Abschluss.

Unternehmensarchitektur als Disziplin

Die für die Unternehmensarchitektur verantwortliche Rolle ist der Unternehmensarchitekt. Um den aktiven Anteil im Umgang mit Unternehmensarchitekturen explizit zu berücksichtigen, definiert [EHH+08] die Architekturdisziplin, die die Menge von Prinzipien und Methoden umfasst, um die Architektur eines Systems zu erstellen. Die Definition der Architekturdisziplin ist nicht so weitreichend, wie die Beschreibung der Tätigkeit architecting aus ISO/IEC/IEEE 42010. Auch in [Kel12] wird die Trennung der zwei Aspekte betont. So werden das Substantiv „Unternehmensarchitektur als Struktur“ und die Tätigkeit „Unternehmensarchitektur als Management“ unterschieden. Die Tätigkeit im Wortsinne findet sich auch in der Definition der „EA-Function“ in [vdRBSvV10].

„Definition EAM – ein ausführlicher Versuch, Teil 3“ weiterlesen

Definition EAM – ein ausführlicher Versuch, Teil 2

Definition EAM – Begriff Unternehmensarchitektur

Im vorherigen teil der dreiteiligen Beitragsreihe „Definition EAM“ wurden im Wesentlichen der Begriff „Architektur“ und als wesentlicher Namensbestandteil von „Unternehmensarchitektur“ definiert. In diesem Beitrag geht es nun um die Definition Unternehmensarchitektur bevor wir uns im nächsten Teil an die Definition des Enterprise Architecture Managements begeben.

„Definition EAM – ein ausführlicher Versuch, Teil 2“ weiterlesen

Definition EAM – ein ausführlicher Versuch, Teil 1

Definition EAM – erster Teil

In dieser Beitragsserie will ich den Versuch unternehmen, die Begriffe Enterprise Architecture (Unternehmensarchitektur) und Enterprise Architecture Management zunächst zu definieren und danach einen Einblick in die typischen Aufgaben dieser Disziplinen zu geben. Die anderen Beiträge sind die hier: Teil 2, Teil 3.

Den Text habe ich erstmals in [Gri15] veröffentlicht. Die darin verwendeten Quellen werden an dieser Stelle gesondert aufgeführt. Die Liste wächst mit jedem Beitrag dieser Serie.

Architektur und Unternehmensarchitektur

In einem Artikel von 1987 wurden Analogien zwischen „klassischer“ Architektur im Sinne der Baukunst, und der Architektur von Informationssystemen verwendet, um ein Framework zu motivieren, das Informationssysteme und deren Umwelt als Modelle erfasst ([Zac87]). Das Zachman Framework wird allgemein als Grundstein der Disziplin der Unternehmensarchitektur betrachtet.

„Definition EAM – ein ausführlicher Versuch, Teil 1“ weiterlesen

Tabelle vs. Bild: Systeme tauschen Daten über Schnittstellen aus

Visualisierung von Schnittstellen

Sind Sie für Systeme verantwortlich, die Daten speichern und diese Daten über Schnittstellen mit anderen Systemen austauschen? Und ändern sich diese Systemschnittstellen auch manchmal, z.B. durch Versionswechsel oder Formatanpassungen? Welches System ist für Ihre Daten jeweils das führende System?

Beantworten Sie diese Fragen mit „ja“? Dann erfahren Sie in diesem Beitrag wie Sie all diese Fragen auf einen Blick beantworten können. Zusätzlich haben wir eine Excel-Tabelle für Sie, die die notwendigen Daten für die Beantwortung der Fragen speichern kann.

Falls Sie diese Fragen mit „nein“ beantworten, dann können Sie in diesem Artikel erfahren, welche Fragen sich viele andere beim alltäglichen Management ihrer IT-Systeme stellen.

„Tabelle vs. Bild: Systeme tauschen Daten über Schnittstellen aus“ weiterlesen

Best-Practice EAM Visualisierungen

In den letzten Jahren haben wir viele EAM Visualisierungen erstellt. Dieser Beitrag bündelt die Visualisierungen, die wir als Best-Practices identifiziert und in unserer Software implementiert haben. Das Beitragsbild gibt einen Überblick über diese zwölf Visualisierungstypen, die jeweils als Skizzen dargestellt werden.

„Best-Practice EAM Visualisierungen“ weiterlesen

Typische EAM-Fragestellung: Wer nutzt was wofür?

Welche Systeme werden für welche Aufgaben genutzt?

Fragen Sie sich auch, welche Anwendungssysteme ihre Mitarbeiter und Kollegen bei ihrer täglichen Arbeit nutzen? Und wofür nutzen Sie diese?

Warum ist das eine typische EAM-Fragestellung?

Gehen wir einen Schritt zurück und überlegen kurz, warum man sich diese Fragen stellen sollte. Allein im Falle eines Systemabsturzes einzelner Anwendungsysteme ergeben sich folgende Vorteile wenn diese Frage transparent benatwortet werden kann:

Es ist offensichtlich welche geschäftskritischen Abläufe an welchen Systemen hängen und welche daher evtl. redundant auszulegen sind.
Wenn ein Anwendungssystem ausfällt, sind sämtliche Geschäftsprozesse (nicht nur die „üblichen Verdächtigen“) identifiziert, die vom Ausfall betroffen sind.
Die betroffenen Mitarbeiter können gezielt informiert werden, es muss keine E-Mail mehr an alle geschickt werden.
Die für das System verantwortlichen Kollegen können unmittelbar informiert werden.

„Typische EAM-Fragestellung: Wer nutzt was wofür?“ weiterlesen