Was Enterprise-Architecture-Tools leisten – am praktischen Beispiel

Im vorangehenden Post zu diesem Thema wurden der Zweck und die Funktionalität von Enterprise-Architecture-Tools erläutert. Dieser zweite Teil illustriert die konkrete Nutzung am Beispiel des Systems „ADOIT:Community-Edition“.

ADOIT ist eine Enterprise-Architecture-Suite der Firma BOC Group. Neben der kostenpflichtigen Enterprise Edition wird auch eine kostenlose Community Edition angeboten. Im Gegensatz zu den Testzugängen der meisten Hersteller ist die Nutzungsdauer der ADOIT:Community Edition nicht eingeschränkt.

Im Vergleich zur Enterprise Edition muss auf die meisten Konfigurations- und Integrations­mög­lich­keiten verzichtet werden, und es ist keine Zusammenarbeit mehrerer Benutzer möglich. Dennoch ist der Funktions­umfang für eine kostenlose Version sehr beachtlich. Daher eignet sich dieses System sehr gut, um die Möglichkeiten und Features eines EAM-Tools zu erkunden.

Um einen Zugang zu der als Cloud-Anwendung bereitgestellten Plattform zu bekommen, muss man sich unter www.adoit-community.com registrieren. Die Bedienung erfolgt im Browser.

ADOIT organisiert die EA-Daten gemäß dem im vorigen Beitrag beschriebenen Prinzip: EA-Objekte – wie Geschäfts­prozesse, Anwendungen oder Hardwarekomponenten –  werden mit ihren Eigenschaften und Bezie­hungen unabhängig von Modellen verwaltet. Jedes Objekt kann in beliebig vielen Modellen enthalten sein.

Modellierung

Modelle werden in einem grafischen Editor erstellt. Als Notation wird ArchiMate verwendet. Da der ArchiMate-Standard sehr umfangreich ist, kann man ADOIT auf eine kleinere Auswahl von ArchiMate-Elementen einschränken, die für typische EA-Anwendungsszenarien ausreichen.

Abbildung 1 zeigt die Modellierungsoberfläche. Auf der linken Seite ist die Werkzeugleiste mit den zur Verfügung stehenden Objekttypen zu sehen. Rechts daneben befindet sich die Zeichenfläche, in der das grafische Modell erstellt wird. Für das in der Abbildung selektierte Anwendungssystem „CRM“ werden zwei gebogenen Paletten eingeblendet, über die weitere Objekte hinzugefügt oder der Eigenschaftsdialog dieses Anwendungssystems aufgerufen werden kann.

In Abbildung 2 ist ein weiteres, kleines Archimate-Modell zu sehen, in dem ebenfalls das Anwendungssystem „CRM“ enthalten ist. Es verfügt über zwei Schnittstellen, eine für den Austausch von Bestellungen, die andere für Kundendaten. Für die Anwendung wird die Systemsoftware JavaEE und mySQL1 genutzt. Sie ist auf dem Hardware-Knoten „Server X“ bzw. „Server Y“ installiert.

Um zu überprüfen, ob ein Modell sämtliche Modellierungsregeln erfüllt, kann man es validieren lassen. Abbildung 3 enthält eine Ansicht mit Validierungsergebnissen. Die Objekte, zu denen es Hinweise oder Warnungen gibt, sind im Modell markiert, und in der rechten Spalte lassen sich die zugehörigen Beschreibungen lesen. In dem Beispiel sind einige Pflichtattribute der Objekte nicht eingetragen, und es wurden Beziehungen verwendet, die nicht den Empfehlungen (der „Best Prac­tice“) entsprechen.

Detailinformationen zu Objekten

Zu jedem Objekt kann man einen Attribut-Dialog öffnen und darin eine ganze Reihe von DetailiInformationen erfassen. Abbildung 4 zeigt einen Ausschnitt aus dem Attribut-Dialog für das Anwendungssystem „Lagerverwaltung“, das unter anderem in dem Modell aus Abbildung 1 verwendet wird.

Möchte man ausgewählte Attribute mehrerer Elemente im Überblick sehen und bearbeiten, so bietet sich eine Tabellendarstellung an (Abbildung 5). Es ist unerheblich, ob ein Objekt und seine Beziehun­gen direkt in einem grafischen Modell, im Attributdialog oder in einer Tabelle geändert werden. Da es sich jeweils nur um unterschiedliche Darstellungen ein und desselben Objekts handelt, wirken sich die Änderungen überall aus, wo das Objekt angezeigt wird.

Modelle aus existierenden Inhalten erstellen

Legt man viele Modelle und Objekte an, so entsteht in der ADOIT-Datenbank ein komplexes Geflecht aus miteinander verknüpften EA-Objekten. Diese Inhalte können in den verschiedensten Modellen verwendet werden, wobei jeweils einzelne Ausschnitte und bestimmte Aspekte visualisiert werden. Möchte man beispielsweise darstellen, welche Anwendungssysteme mit welchen anderen Anwen­dungssystemen über Schnittstellen miteinander verbunden sind, so kann man ein leeres Modell erstellen, die gewünschten Anwendungssysteme und Schnittstellen per Drag-and-Drop in das Modell hineinziehen und die dazwischen existierenden Beziehungen einblenden lassen (Abbildung 6).

Mit welchen anderen Objekten ein Objekt direkt oder indirekt verbunden ist, kann man mit Hilfe einer Abhängigkeitsanalyse erkunden. Hierbei geht man von einem Objekt aus und lässt sich die damit verbundenen Objekte einblenden. Anschließend kann man eines dieser hinzugekommenen Objekte selektieren und wiederum dessen verbundene Objekte einblenden. Auf diese Weise lässt sich das Beziehungsgeflecht der Enterprise-Architecture durchforsten um interessante und wichtige Abhängigkeiten herauszufinden und darzustellen.

So kann man  Abbildung 7 unter anderem entneh­men, dass es Verbindungen zwischen den Servern X und Y einerseits und den Geschäftspro­zessen „Bestellung ausführen“ und „Reklamation bearbeiten“ andererseits gibt. Der Ausfall eines der beiden Server würde also unter anderem dazu führen, dass die beiden dargestellten Geschäftsprozesse nicht mehr durchgeführt werden könnten.

Objektbezogene Visualisierung und Analyse

Die Darstellung in Abbildung 8 „Object-Insights“ dient der Visualisierung verschiedener Informa­tionen zu einem bestimmten Objekt. Welche Informationen angezeigt werden, hängt vom Typ des Objekts ab. Im Beispiel handelt es sich um ein Objekt vom Typ „Anwendung“. Hier wird unter ande­rem gezeigt, welche anderen Anwendungen damit verbunden sind und dass sich die Anwendung in der Lebenszyklusphase „In Produktion“ befindet.

Zudem wird angezeigt, wie gut verschiedene Kriterien zur Bewertung der Anwendung erfüllt sind. Beispielsweise ist die IT-Fitness sehr gut. Dieses Kriterium umfasst unter anderem die Verfügbarkeit, die Wartbarkeit und die Stabilität der Anwendung. Die Kosten-Fitness ist etwas niedriger, d. h. das Kosten-Nutzen-Verhältnis der Anwendung ist relativ gut, aber nicht optimal.

Damit die Bewertung einheitlich erfolgt, muss im Vorfeld festgelegt werden, wer sie durchführt und was es konkret bedeutet, dass etwa die strategische Bedeutung als „niedrig“, „hoch“ oder „sehr hoch“ eingeschätzt wird.

In Abbildung 8 ist außerdem eine „Redundanzanalyse“ zu sehen. Hier werden andere Anwendungen angezeigt, deren Funktionalität sich mit der betrachteten Anwendung überschneiden. Daher sollte geprüft werden, ob möglicherweise eine der beiden Anwendungen durch die andere ersetzt werden kann. Für die Redundanzanalyse überprüft das Tool, welche Anwendungen dieselben Service anbieten oder dieselben Geschäftsfähigkeiten unterstützen.

Übergreifende Auswertungen und Analysen

Die Redundanzanalyse ist ein Beispiel für eine der zahlreichen Möglichkeiten, die im EA-Tool erfassten Daten automatisiert auszuwerten. Mit Hilfe leistungsfähiger Such- und Filterfunktionen lassen sich zahlreiche weitere Auswertungen erstellen. Z. B. kann man alle Systeme ermitteln, in denen bestimmte Datenobjekte verarbeitet werden. Oder man lässt sich alle Anwendungen auflisten, deren Sicherheits-Fitness einen bestimmten Wert unterschreitet.

Zudem gibt es viele vordefinierte Analysen, mit denen Diagramme erzeugt werden. So zeigt Abbildung 9 ein automatisch generiertes Portfoliodiagramm, in dem ausgewählte Anwendungs­systeme entsprechend ihrer Geschäfts-Fitness und ihrer Kosten-Fitness angeordnet sind. Die Größe der Kreise gibt die strategische Bedeutung des jeweiligen Systems an. Mit Hilfe solcher Diagramme lassen sich Systeme vergleichen. Sie helfen z. B. bei der Entscheidung, welche Weiterentwicklungen und Maßnahmen für die einzelnen Systeme durchgeführt werden sollten.

Auch der Bebauungsplan in Abbildung 10 wurde automatisch generiert. Hieraus lässt sich entnehmen, welche Anwendungssysteme für welche Geschäftsprozesse eingesetzt werden. Dabei wird zudem nach Organisationseinheiten unterschieden. So wird im Privatkundenvertrieb das System „CRM“ für den Prozess „Bestellung ausführen“ eingesetzt, im Großkundenvertrieb hingegen das System „KUNO“.

Die Farbe einer Anwendung gibt ihre Lebenszyklusphase an. Im Beispiel sind die meisten Anwendungen in Produktion, lediglich das System „CRM 2.0“ befindet sich erst in Entwicklung. Die Pfeilsymbole symbolisieren die Investitionsstrategie. So wird aktuell in das System „CRM 2.0“ investiert. Das Shopsystem soll hingegen abgeschafft werden.

Anhand eines solchen Bebauungsplans lässt sich gut erkennen, durch welche Systeme die Prozesse unterstützt werden, wo es ggf. Abdeckungslücken gibt, oder in welchen Prozessen möglicherweise zu viele unterschiedliche Systeme eingesetzt werden. Gibt es beispielsweise Abteilungen, die für einen bestimmten Prozess andere Systeme einsetzen als der Rest, so sollte geprüft werden, warum dies so ist, und ob es nicht möglich ist, ein gemeinsames System einzusetzen.

Die Capability-Map in Abbildung 11 enthält einen Überblick über die im Unternehmen vorhandenen Geschäftsfähigkeiten. Im Sinne einer „Heatmap“ sind die Geschäftsfähigkeiten markiert, bei denen aktuell Handlungs­bedarf besteht. Ein Grund dafür könnte sein, dass die IT-Unterstützung für diese Geschäftsfähigkeiten unzulänglich ist.

Zeitliche Entwicklungen und Planungen

Die zeitliche Entwicklung von Systemen und Anwendungen kann in einer Roadmap dargestellt werden, wie sie in Abbildung 12 gezeigt ist. Hier sind für jede Anwendung die bisherigen und die geplanten Zeiträume für die einzelnen Lebenszyklusphasen eingetragen. So soll die Entwicklung für das System „CRM 2.0“ im dritten und vierten Quartal des Jahres 2021 stattfinden. Anschließend soll die Produktiv-Phase beginnen.

Die gestrichelten gelben Verbindungen geben an, welche Systeme einander ablösen. So soll „CRM 2.0“ zu Beginn des Jahres 2022 die Anwendung „CRM“ ersetzen. Mitte 2022 übernimmt „CRM 2.0“ auch noch die Aufgaben der bisherigen Shop-Anwendung, die dann ebenfalls abgeschaltet wird.

Damit derartige Auswertungen möglich sind, ist es erforderlich, dass die entsprechenden Zeiten bei den betrachteten Objekten gepflegt sind. Ist das der Fall, dann kann man nicht nur solche Roadmap-Darstellungen erzeugen, sondern auch z. B. einen Zeitfilter auf ein grafisches Modell anwenden und sich den tatsächlichen oder geplanten Zustand der Enterprise-Architecture zu unterschiedlichen Zeitpunkten anzeigen zu lassen (vgl. Abbildung 13 und Abbildung 14).

Regelmäßige Überprüfung der Aktualität

Da sich die Enterprise-Architecture laufend ändert, müssen die Inhalte im EAM-Tool regelmäßig aktualisiert werden. Im Idealfall kümmert man sich in den Projekten, in denen Systeme und andere EA-Objekte weiterentwickelt werden, auch darum, die entsprechenden Inhalte sofort zu aktualisieren.

Zusätzlich enthält ADOIT aber auch eine Erinnerungsfunktion. Objekte, deren Einträge seit längerer Zeit nicht mehr geändert wurde, werden in einer Erinnerungs­liste angezeigt (Abbildung 15). Der Benutzer sollte dann die Einträge zu diesen Objekten prüfen und sie bei Bedarf aktualisieren.

Abschließende Bemerkungen

• Das Thema Enterprise-Architecture ist sehr umfassend und vielfältig. Zwangsläufig konnte in dem vorliegenden Überblick nur ein Ausschnitt aller möglichen Darstellungsformen und Analysen vorgestellt werden.
• Auch wenn sich die am Markt verfügbaren EA-Tools zum Teil deutlich unterscheiden, gibt es doch einen gemeinsamen Kern an typischen Funktionalitäten. Insofern findet sich ein Großteil der am Beispiel von ADOIT:Community-Edition demonstrierten Features in den meisten Tools wieder.
• Vor der Auswahl und Einführung eines EA-Tools sollte sorgfältig analysiert werden, welche Ziele mit dem Enterprise-Architecture-Management erreicht werden sollen, welche Inhalte dafür abgebildet werden müssen und welche Auswertungsmöglichkeiten erforderlich sind.
• Da sich die konkrete Ausgestaltung des EAM und der EA-Dokumentation von Unternehmen zu Unternehmen stark unterscheiden kann, ist es insbesondere wichtig, das verwendete Tool stark konfigurieren zu können. Beispielsweise sollte es möglich sein, die genutzten Typen von EA-Objekten und Beziehungen selbst festzulegen.
• Es ist nützlich, wenn das Tool bereits viele Arten von vordefinierten Analysen enthält. Diese sollten ebenfalls stark konfigurierbar sein. Z. B. ist es hilfreich, wenn man für Portfolio­diagramme frei auswählen kann, welche Attribute als Dimensionen verwendet werden.
• Zudem sollte es möglich sein, eigene Analysen zu definieren, z. B. mit Hilfe einer einfachen Abfrage- oder Programmiersprache. Wenn der entsprechende Code der vordefinierten Analysen mitgeliefert wird, dann kann dieser als Grundlage für die Entwicklung eigener Analysen dienen.
• Es wurde bereits darauf hingewiesen, wie wichtig zudem leistungsfähige und intuitiv nutzbare Kolla­bora­tionsmöglichkeiten sind.

---

Mehr zum Thema Enterprise-Architecture-Management – und ganz allgemein zum IT-Management: