Informationsbedarf der Enterprise Architektur – Teil 1

Dieser Beitrag beschäftigt sich mit den Informationen, welche beim Umgang mit der Unternehmensarchitektur einer Organisation anfallen.

Im ersten Teil des Beitrags geht es zuerst um die Definition von Enterprise Architektur und die spezifischen Herausforderungen. Die zweite Teile wird die Domänen und Detailebenen der Informationen näher beleuchten. Im dritten Teil gebe ich eine Übersicht über die Werkzeugunterstützung beim Umgang mit diesen Informationen.

Der ganze Beitrag ist in dem Buch „Erfolgsfaktor Informations Management“ (ISBN 978-3-00-053730-1) enthalten und kann hier bestellt werden.

Was ist eigentlich Enterprise Architektur?

Die Enterprise Architektur ist keine neue Disziplin. Die ersten Erkenntnisse und Praktiken stammen bereits aus den 70er Jahren. Ende der 80er begann die Ausprägung einer eignen Disziplin innerhalb der IT.

Im Folgenden beschreibe ich die Enterprise Architektur nach dem Verständnis des Architektur-Rahmenwerks namens „The Open Group Architecture Framework“ oder kurz TOGAF. Die Open Group ist ein unabhängiges Konsortium, welche offene IT-Standards entwickelt und fördert. TOGAF ist ein kompletter „Werkzeugkasten“ zum Umgang mit der Enterprise Architektur.

Die Aufgabe der Enterprise Architektur ist die Optimierung der Prozesse, Methodik und Struktur beim Umgang mit der Architektur einer Organization. Alle Architektur Lebenszyklen sind dabei berücksichtig. Also die Planung, die Umsetzung, der Betrieb sowie die Evolution der Architektur. Zusätzlich wird der Konsum von Architekturen adressiert. Konsum bedeutet hierbei, dass Architekturen in die Enterprise aufgenommen werden, zum Beispiel im Falle von Zusammenlegungen durch Akquise oder Verschmelzungen.

Die Aufgaben der Enterprise Architektur werden je nach Größe des Unternehmens und der System-Landschaft von Entwicklern, System Architekten oder vom CIO, mehr oder weniger, mit übernommen. Ab einer gewissen Größe ist der Einsatz einer speziellen Funktion innerhalb der Organization der effizienteste Weg die Evolution der System-Landschaft zu begleiten. In größeren IT-zentrischen Unternehmen sowie in fortschrittlichen Behörden sind schon seit Längerem Enterprise Architekten mit diesen Aufgaben betraut. Ein Teil dieser Aufgaben, der Teil der mit dem konkreten Informationsbedarf direkt in Verbindung steht, werden im weiteren Verlauf erörtert.

Ich möchte nun auf verschiedene Begriffe eingehen, bevor wir uns weiter der Enterprise Architektur und ihrem Bedarf an Informations-Management zuwenden.

Enterprise

„Ist die Menge von Organisationseinheiten welche ein gemeinsames Ziel verfolgen. So kann als Enterprise ein einzelner Unternehmensbereich, das gesamte Unternehmen, eine Behörde oder mehrere geografisch getrennte Unternehmen mit gemeinsamer Eigentümerschaft betrachtet werden.“

Architektur

„Ist die fundamentale Struktur eines IT-Systems, verkörpert durch seinen Komponenten, deren Beziehungen untereinander sowie den Beziehung mit der weiteren Unternehmens-Umgebung, sowie den Prinzipien welche die Entwicklung des Systems begleiten.“

Diese Definition von Architektur muss erweitert werden um den Bereich der Wahrnehmung von Architektur. Im Gegensatz zur Gebäude-Architektur ist bei System-Architektur das Konstrukt nicht direkt wahrnehmbar. Es bedarf einer Abstraktion und Repräsentation um das Konstrukt zu verkörpern. Schliessendlich ist die Architektur das was als gemeinsames Verständnis über das Konstrukt bezeichnet werden kann. In Konsequenz zu dieser erweiterten Definition von Architektur, hat ein System zwar eine Konstruktion aber keine Architektur, wenn nicht alle „Mitspieler“ das Konstrukt spezifisch wahrnehmen können.

Ein Beispiel soll helfen diesen Aspekt besser zu verstehen.

Wenn wir ein Gebäude planen wird zuerst ein Repräsentation erstellt. Dies sind zumeist Konstruktionszeichnung und Auflistungen. Einige dieser Repräsentationen sind notwendig um regulatorische Anforderungen zu erfüllen, um zum Beispiel eine Baugenehmigung zu bekommen. Wenn das Gebäude erstellt ist, kann man alleine durch augenscheinliche Wahrnehmung auf die Architektur schließen. Die Anzahl der Stockwerke, den Grundriss, die Lage der Eingänge und Zufahrten, das vorherrschende Baumaterial, auch Rückschlüsse auf den Verwendungszweck sind durch die Betrachtung möglich.

Einem IT-System fehlt diese augenscheinliche Wahrnehmbarkeit. Man kann nicht erkennen wie umfangreich es ist oder „woraus es gebaut ist“, aus wieviel Teilen es besteht und wie diese Teile verbunden sind. Auch der Verwendungszweck ist nicht immer offensichtlich. Natürlich gibt es Personen die im Umgang mit dem System eine spezifische Wahrnehmung haben. Betriebsmannschaften kennen die Plattform und Verteilung des Systems,
Business Analysten und Kunden kennen den Zweck und die Funktionalität, Entwickler kennen den Aufbau, usw.

Im Gegensatz zum Gebäude ist die Konstruktion nicht ohne die Repräsentation – oder zumindest die Beschreibung und Erläuterung eines jeweiligen Experten – wahrnehmbar.

Erschwert wird die Wahrnehmung auch dadurch, dass die Experten nur einen Teilaspekt der Konstruktion kennen. Die Wahrnehmbarkeit von Architektur bzw. der System-Konstruktion wird im weiteren Verlauf noch eine Rolle spielen.

Was ist „Optimal“?

Wie Eingangs definiert ist die Aufgabe der Enterprise Architektur die Optimierung. Die Frage „Was ist optimal?“ muss beantwortet werden im Kontext der unternehmerischen Ziele. Sollen primär Kosten reduziert werden, soll die Kundenzufriedenheit gesteigert werden, möchte man eine technologische Führerschaft anstreben, usw.

Prinzipien der Organisation und der Architektur unterstützen dabei die strategischen Ziele der Enterprise. Sie sollten verständlich, komplett, robust, konsistent und stabil sein und im Idealfall über mehrere Innovationszyklen hinweg gültig bleiben.

Informationsbedarf der Enterprise Architektur

Einleitend möchte ich darauf hinweisen, dass es sich bei den folgenden Betrachtungen um die vollständige, maximale Informationsmenge handelt, wie sie von TOGAF beschrieben ist. Diese Vollständigkeit ist oft unnötig und nicht trivial in ihrer Verwaltung. Welche Informationsbereiche, zu welchem Zeitpunkt, in welcher Form abgebildet und verwaltet werden, hängt von den spezifischen Anforderungen in der Organization ab und kann nicht allgemein beantwortet werden.

Prinzipien, Leitlinien, Referenzarchitekturen und -modelle

Schon die erwähnten Leitsätze, die sogenannte Unternehmensprinzipien, und die Unternehmensstrategie selbst sind Bestandteil der Information die verwaltet und kommuniziert werden müssen. Daraus abgeleitet werden die Architekturprinzipen, welche wiederum maßgebend sind für Referenzarchitekturen und Architekturleitlinien, sogenannte Guidelines.

Des weiteren muss sich die Architektur an bestimmte Unternehmens- oder Industrie-Standards halten und teilweise komplexe regulatorische Auflagen erfüllen.

Architekturbeschreibungen

Bei der Planung der Architektur werden verschiedene Architekturbeschreibungen erstellt, überarbeitet und abgenommen. Im Idealfall enthält die Architekturbeschreibung weniger „Prosa“ als Artefakten, wie Diagramme, Aufzählungen und Tabellen. Diagramme sind eine wertvolle, wenn nicht die wertvollste, Repräsentation der Architektur. Sie sind leichter zu verstehen und vereinfachen die Kommunikation wesentlich. Zusätzlich läßt sich die strukturierte, mit einem Datenmodell unterlegte, Architekturbeschreibung leichter elektronisch verarbeiten als unstrukturierte textuelle Erklärungen.

Für verschiedene Gruppen von Beteiligten bei der Planung, der Umsetzung und dem Betrieb der Architektur gibt es eigene Artefakte mit spezifischem Inhalt. Dieser spezifische Inhalt wird als Blickpunkt (Viewpoint) auf die Architektur bezeichnet. General hat ein Viewpoint einen Zweck, eine damit verbunden Nutzergruppe (Stakeholders) sowie eine Abstraktionsebene die mehr oder weniger  viele Details der Architektur beinhalten. Die Verwendung von Viewpoints erlaubt den Blick auf die für die Nutzergruppe wesentlichen Informationen. Zur Steigerung der Effizienz werden nicht benötigte Informationen und Detailierungsebenen ausgeblendet.

Die Open Group bietet mit ihrer offenen EA Modellierungssprache „ArchiMate“ einen Lösungsvorschlag zur Standardisierung der Viewpoints, inklusive ihres Zweckes, Detailierungsgrades, der damit verbundenen Nutzergruppe sowie dem Inhalt.

Dabei wird der Zweck grob in drei Kategorien eingeteilt:

1. Entwerfen (Designing)
   Unterstützt primär Architekten bei der Planung der Architektur, sowie Experten und Entwickler bei der Umsetzung.
2. Entscheiden (Deciding)
   Unterstützt Projekt- und Linien-Management beim Entscheidungsprozess durch Aufzeigen von abteilungsübergreifenden Beziehungen und spezifischen Auswirkungen. Oft werden dabei alternative Entwürfe verglichen um die jeweiligen Vor- und Nachteile sowie Risiken zu erörtern.
3. Informieren (Informing)
   Unterstützt jegliche Nutzergruppe beim Verständnis der System-Architektur und erhöht die Unterstützung aller Beteiligten sowie deren Verbundenheitsgefühl zur Architektur.

Der Detailierungsgrad wird in drei Ebenen unterteilt:

1. Details
   Unterstützt das tiefgreifende Verständnis von Geschäftsprozesse, Informationsflüssen sowie deren Einfluss auf die Anwendungs-, Daten- und Technologie-Architektur.
2. Zusammenhang (Coherence)
   Zeigt deutlich die Beziehungen der Geschäftsprozesse zu Akteuren, Ereignissen, Informationen, Anwendungen, Kommunikationswegen und der Infrastruktur.
3. Übersicht (Overview)
   Zeigt logische Gruppen von Geschäftsfunktionen (Services), den Austausch und die Verwaltung von Geschäftsobjekte (Business Objects) sowie die grundlegende Anwendungs- und Infrastruktur-Architektur.

Die folgende Tabelle zeigt die Relation der Detailierungsebene und dem damit verbundenen Informationsbedarf der jeweiligen Nutzergruppe.

Die Tabelle zeigt eine Vereinfachung der Nutzergruppen. Die System-Architektur wird heute üblicherweise in vier Domänen aufgeteilt. In Business-, Daten-, Applikation- und technische Architektur. Analystin bezieht sich auf die Business-Analyse zum Zwecke des Anforderungsmanagements. Das Management umfasst Projekt- und Linienfunktionen. Zur Exekutiv-Ebene gehören CIO (Chief Information Officer), CTO (Chief Technology Officer) sowie Lead- und Enterprise-Architekten. Enterprise Architekten sollten aber auch ein ausreichendes Verständnis auf Detailebene besitzen um CIO/CTO wesentlich bei der Architektur-Steuerung zu unterstützen.

Wir halten also fest, dass eine Menge von Architektur-Informationen in unterschiedlicher Detailebenen und Versionen, einzeln oder in Beziehung zu einander, erstellt, überarbeitet und verwaltet werden müssen.
Ausserdem muss die Architektur-Information zumindest allen Stakeholdern gegenüber veröffentlicht werden. Hierbei ist zu Beachten, dass die Detailebene nicht über den Bedarf hinausgeht.
Frederic Vester, deutscher Systemforscher und Pionier des „Vernetzen Denkens“, zeigte mittels des nebenstehenden Bildes, dass eine grobe Detailebene in der Übersicht hilfreich ist. Vester gibt zu bedenken, dass auch wenn alle Details der Kästchen, wie Farbwert, Größe und Beschaffenheit, bekannt und korreliert sind, kann der gezeigten Staatenlenker nicht erkannt werden. Nur durch die Übersicht und einen gewissen Abstand ist hier das Konterfei von Abraham Lincoln zu erkennen.

 

 

 

Architektur-Steuerung (Governance)

Aufgabe der Governance ist die Begleitung der Implementierung. Dies erfolgt anfänglich mit dem vermitteln der grundlegenden Prinzipien, Richtlinien und Standards und setzt sich fort mit der Untersuchung der Konformität der Umsetzung zu den Entwurfsmustern. Auch die Qualitätssicherung der Planung und Implementierung sind typische Aufgaben der Architektur-Steuerung.

Die Erkenntnisse zur Konformität und Qualität der Implementierung werden regelmäßig in Zusammenfassung an den CIO/CTO, bzw. an ein Architektur-Gremium (Architecture Board)  unter deren Vorsitz, berichtet. Dabei werden Maßnahmen zur Unterstützung positiver und zur Gegensteuerung negativer Einflussgrößen diskutiert, beschlossen und begleitet.

Je nach Reife der Architektur-Funktion im Unternehmen, ist die Governance-Funktion objektivierbar. Im Idealfall basiert die Governance ganz auf den gleichen Prinzipen, Richtlinien und Standards, welche dem Planungs- und Implementierungs-Team zur Verfügung stehen. Es wird aber auch immer ein gewisses Maß an Ad-Hoc Goverance notwendig sein. Wichtig ist hierbei, dass auch die Ad-Hoc Governance ihre Entscheidungen veröffentlicht muss. Dies fördert die Nachvollziehbarkeit und erhöht die Wahrscheinlichkeit, dass Organizationsweit eine frühere Konformität zu den Ad-Hoc Entscheidungen entsteht, auch ohne eine Richtlinie, beziehungsweise vor deren Veröffentlichung. Ebenfalls Teil der zu publizierten Informationen aus der Governance sind die Ausnahmegenehmigungen oder Aufschübe für die Umsetzung der Konformität.

Je nach Größer der System-Landschaft und der Anzahl von Planungs- und Implementierung-Projekten, benötigt man einen „Fahrplan“ um die Governance-Funktion zur rechten Zeit am rechten Ort zur Verfügung stellen zu können.

Architektur-Funktion

Eine Architektur entsteht und verändert sich durch das Zusammenspiel verschiedener Tätigkeiten. Im (theoretischem) Idealfall ist das Resultat der Architektur-Funktion deterministisch. Gleiche Anforderungen und Rahmenbedingungen führen zur gleichen Architektur und Implementierung.  Dies setzt Prozesse, Rollen und Organization voraus. Die Architektur-Funktion einer Enterprise läßt sich, wie jeder andere Verbindung aus Prozessen, Akteuren und Organization, als eigenständige Architektur entwerfen, dokumentieren und publizieren. Dabei fallen die oben beschriebenen Architektur-Artefakte an.

Zusätzlich gibt es Informationen zur Ontologie der Fachbegriffe der Architektur-Funktion, Vorlagen für die Architekturbeschreibungen (View Point Library) und Beschreibungen der Rollen inklusive der Definition benötigen Kompetenzen.

Auch das verwendete Architektur-Rahmenwerk (Framework) sowie deren Zuschnitt auf die individuellen Gegebenheiten der Organization können als Information verwaltet und veröffentlicht werden.

Das „Architecture Repository“

Es werden verschiedenste Informationen bei der Planung, der Implementierung, dem Betrieb und der Evolution von Software-Architekturen benötigt und erzeugt. Wenn diese Informationen auf einem Daten- bzw. Meta-Modell basieren, kann man sie leichter elektronisch verwalten und und in Beziehung setzen.

Das folgende Diagramm zeigt das „Architecture Repository“ und dessen Umgebung, wie es von TOGAF vorgeschlagen wird:

Architecture Landscape

Hier wird ist die Beschreibung der gesamten Enterprise Architektur verwaltet.

Dies sind Architektur-Beschreibungen, welche eine Architektur einzeln und im Bezug zu anderen Architekturen in der Enterprise repräsentieren.

Beispiele sind:

• Zuordnung von Geschäfts-Funktionen, -Objekten und Akteuren zu Anwendungen
• Informations- und Datenflüsse zwischen Anwendungen
• Integration der Anwendungen (Schnittstellen, Protokolle, Technologien)
• Technische Infrastruktur für den Betrieb der Applikationen
• Meta Informationen wie Phase im Lebenszyklus oder Eigentümerschaft

Dabei wird auch die Historie bzw. die Veränderung der Enterprise Architektur verwaltet und repräsentiert. Auch zukünftige Versionen einer Enterprise Architektur lassen sich hier modellieren zum Zwecke der Planung und Simulation.

Die drei Detailierungsebenen im Architecture Repository, „Strategic“, „Segment“ und „Capability“, können den Detailierungsebenen der ArchiMate View Point Library zugeordnet werden.

Reference Library und Standards Information Base

Hier sollten alle Prinzipien, Standards, Leitlinien Referenz-Modelle und -Architekturen enthalten sein, welche für eine Architektur-Planung maßgeblich sind.

Dazu zählen beispielsweise:

• Auflagen des Gesetzgebers und der Aufsichtsorganen
• Industrieweite Kommunikationsmodelle (z.B. SWIFT und EDIFACT)
• Organizations- und Industrie-Richtlinien (Best Practices)
• Technologie Kataloge (Standard Technology-Stack)
• Vorlagen für die Architektur-Beschreibungen
• View-Point-Library

Die Reference Library und die Standards Information Base erlauben es den Architekturbeteiligten schon im Vorfeld für sie verpflichtende sowie hilfreiche Informationen zu identifizieren. Weiterhin ist die Governance-Funktion gut zu objektivieren, da zur Bestimmung der Konformität die gleichen Informationen herangezogen werden können wie bei der Planung.

Governance Log

Das Governance Log enthält Informationen welche bei der Steuerung der Architektur benötigt werden, beziehungsweise anfallen. Überwiegend ist die Governance-Funktion begleitend zur Implementierung aktiv um sicherzustellen, dass sie der Planung entspricht.

Dazu benötig man zuerst die Information über das Projekt selbst. Name und Umfang des Projekts sowie die verantwortlichen Ansprechpartner in ihren jeweiligen Rollen (Projektleitung, Architekt, Betrieb usw.).

Die getroffenen Entscheidungen bei Lösungsalternativen sowie die Abweichungen vom Standard sind wesentliche Informationen um die Architektur-Evolution nachvollziehbar zu machen und Verantwortlichkeiten zu dokumentieren.

Bei Erreichung bestimmter Meilensteine im Projektverlauf kann eine Bewertung der Konformität zu den geltenden Standards und Richtlinien zum Zwecke der Qualitätssicherung durchgeführt werden. Diese wohldefinierten Kontaktpunkte zwischen Projekt und Governance-Funktion werden durch einen Kalender planbar.

Bei der Einführung oder Änderung von Unternehmensarchitekturen kann es vorkommen, dass neue Fähigkeiten im Unternehmen benötigt werden. Seien es nun geschäftliche, technische oder planerische Fähigkeiten. Bei der Umsetzung der Architektur ist es Aufgabe der Governance-Funktion den Status der Einführung neuer Fähigkeiten regelmäßig zu erfassen und an die Führungsebene rückzumelden.

Ebenfalls regelmäßig wird die Leistungsfähigkeit und Vitalität der Architektur-Funktion innerhalb der Organization überwacht. So kann das „Architecture Charter“ die Leistungen und Reaktionszeiten der Architektur-Funktion selbst vorgeben. Die Erhebung von Soll- und Ist-Werten erlaubt es organisatorische Flaschenhälse früh zu erkennen und diesen Gegenzusteuern.

Architecture Capability und Metamodel

Die Fähigkeiten der Architektur- und Governance-Funktion ist ebenfalls im „Architecture Repository“ beschrieben. Hier werden die Strukturen und Prozesse hinterlegt, welche bei der Planung und der Umsetzung von Architekturen benötigt werden. Besonders Augenmerk liegt dabei auf der Zuordnung von Fähigkeiten zu Rollen. Um eine Rolle innerhalb der Architektur-Funktion zu erfüllen, wie zum Beispiel die Rolle des Daten-Architekten, wird ein spezifisches Wissen vorausgesetzt. Diese Zuordnung kann auch gezielt eingesetzt werden um das spezifische Wissen im Unternehmen oder in einer Behörde durch Schulungen aufzubauen.

Das im vorherigen Abschnitt erwähnte „Architecture Charter“, zu deutsch „Architektur-Vereinbarung“, ist ebenfalls Bestandteil der Dokumentation der Architektur-Funktion. Hier werden die Sponsoren (meist CIO), der Nutzen, die Ziele, sowie Beschränkungen und wichtige Anforderungen an die Architektur-Funktion dokumentiert.

Schließendlich befindet sich im „Architecture Repository“ auch das Meta-Model, welche die Datenstrukturen und ihre Beziehungen für den Inhalt des Repository selbst beschreibt.

Wechselwirkungen

Die oben aufgezeigten Elemente des „Architecture Repository“ stehen miteinander in Beziehung. Einige davon wurden bereits erwähnt, etwa die Wechselwirkung zwischen „Reference Library“ und „Standards Information Base“ mit der Architektur- und Governance-Funktion. Daraus ist ersichtlich welchen Verpflichtungen die Architektur erfüllt bzw. erfüllen muss.

Im weiteren gibt es auch Beziehungen zu Elementen ausserhalb des „Architecture Repository“.

Diese sind:

• Solution Repository
  Hier wird eine Beziehung zwischen der Architektur und der Software-Lösung hergestellt in einer Weise, dass feststellbar ist welcher Software-Baustein durch welchen Architektur-Baustein repräsentiert ist. Dies fördert die Wiederverwendung von Lösungen bei gleicher oder ähnlicher Architektur.
• Requirements Repository
  Anforderungs-Management wird in jeder Phase der Architektur-Funktion benötigt. Änderungen in den Anforderungen führen meist zu Änderungen der Architektur, deshalb gibt es eine starke Wechselwirkung zwischen Anforderungs-Management und „Architecture Repository“. Die Governance-Funktion überprüft die Konformität zu bestimmten Anforderungen oder formuliert eigene Anforderungen (Auflagen).
• Externe Quellen
  Standards und Referenzen von externen Quellen haben einen hohen Stellenwert, da sie den industrieweiten Datenaustausch begünstigen sowie bewährte Praktiken beschreiben. Auch Auflagen, zum Beispiel des Gesetzgebers, sind den externen Quellen zuzuordnen.
• Architecture Board
  Dieses Gremium übernimmt die Exekutive bei der Architektur-Steuerung und benötigt dabei Informationen aus dem „Architecture Repository“. Im Besonderen die strategische Perspektive der „Architecture Landscape“ und das „Governance Log“.

Werkzeuge

Für die Verwaltung der Informationen im „Architecture Repository“ hat sich eine eigene Gattung von Software herausgebildet, „Enterprise Application Management Tools“ oder auch allgemeiner „Enterprise Architecture Tool“. Das Spektrum geht dabei von der reinen Verwaltung der „Architecture Landscape“ bis hin zu modular aufgebauten Frameworks von erheblicher Komplexität.

Unter den Anbietern zu finden sind  Troux mit dem gleichnamigen Produkt, „Rational System Architect“, welches IBM Ende 2015 an Unicom Systems verkauft hat, die Software AG mit „Aris“ und „Alfabet“, der derzeitige Marktführer Mega mit seinem gleichnamigen Produkt sowie Iteraplan mit „iteratec“, welche als Open Source Software in einer sogenannten „Community“ (kostenlos) und „Enterprise“ Edition angeboten wird.

Manche der Lösungen verarbeiten mehr als die oben beschriebenen Informationen des „Architecture Repository“. Die meisten der angebotenen Produkte haben einen Suite-Charakter und umfassen auch das Anforderungs-Management,  das modellieren von Geschäftsprozessen (Business Process Models), budgetäre Informationen sowie Komponenten zur Projektplanung und -steuerung.

Bei Auswahl von umfangreichen Lösungen sollte man eine angemessene Einarbeitungszeit sowie zusätzlichen Beratungsleitungen des Herstellers einplanen. Der Vorteil von modular aufgebauten Suiten ist das „mitwachsen“ der Lösung. Dies erlaubt die stufenweise Erweiterung um neuen, höheren Anforderungen an das Enterprise Architektur-Management gerecht zu werden.  Einige Produkte erlauben ebenfalls eine Partitionierung der Informationen und mehrfache Installation, um den föderalen Aufbau größerer, IT-zentrischer Organisationen zu unterstützen.

Das Lizenzmodell der Anbieter sollte vor einer Produktauswahl genauer Untersucht werden. Bei einige Anbietern, wie der Software AG, reicht die Produktpalette von kostenlosen Einsteigerversionen bis hin zu komplexen Installationen, welche Investitionen im Millionen Euro Bereich entsprechen. Die meisten Hersteller bieten flexible Modelle bei den Lizenzen an. So gibt es benutzerbezogen (named user) Lizenzen, sogenannte „floating licenses“, Lizenzen per Installation und globale, Multi-Installationen Lizenzen.

Es besteht auch die Möglichkeit sich ein Informationsmanagement-System für die Enterprise Architektur durch das Kombinieren verschiedener, eventuell schon vorhandener, Werkzeuge selbst aufzubauen.  Nicht unüblich, zum Beispiel, ist die Kombination aus Microsoft SharePoint, Visio und einem Wiki. SharePoint dient hierbei als Content-Management Plattform, Visio der Erstellung von Diagrammen und das Wiki als Benutzerschnittstelle.

Das Werkzeug sollte der Größe der System-Landschaft und dem Reifegrad der Architektur-Funktion angemessen sein. Die reichhaltigen Möglichkeiten von umfangreichen Suiten gehen ohne die eigene Anforderungen zu kennen, unter Umständen über den Bedarf hinaus.

Bei der Werkzeugauswahl entsteht leicht eine Henne-Ei-Situation: Nehme ich zuerst ein Werkzeug und lege meine Architektur-Funktion danach aus, oder lege ich zuerst meine Architektur-Funktion fest und suche mir das dazu passende Werkzeug aus?

Die Werkzeug-getrieben Enterprise Architektur ist empfehlenswert, wenn der Reifegrad der Architektur-Funktion nicht hoch ist, hat aber den Nachteil, dass über die vom Werkzeug geführten Fähigkeiten hinaus, eine eigene Vision nur schwer zu verwirklichen ist. Auch gibt es Hinweise, dass „Conway’s Law“ ebenfalls für die Verbindung von Enterprise Architecture Tool und den Entwürfen gilt. „Conway’s Law“ besagt: „Organisationen, die Systeme entwerfen, […] sind auf Entwürfe festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden.“

Andererseits ist die Konzeption einer Enterprise Architektur-Disziplin unter Umständen ein ressourcen-intensives Unterfangen. Die Unterstützung der Führungsebene könnte bröckeln, wenn nicht auch schnell Ergebnisse geliefert werden. Allerdings ist eine eigenständige und gute Vision, mit der entsprechenden Konzeption und  Werkzeugunterstützung, durchaus ein Wettbewerbsvorteil für IT-intensive Organisationen.

Fazit

Die anfallende Informationsmenge und der Informationsbedarf in der Enterprise Architektur ist von der Unternehmensgröße, der Anzahl der Systeme und vom Reifegrad der Organization abhängig.

Eine zu schwaches Informations-Management kann zu einer Vernachläßigung der Architektur-Führung führen, mit der Folge erhöhter Gesamtkomplexität der Architektur-Landschaft durch großer Heterogenität der Lösung und funktionalen Redundanzen.

Ein zu starkes Informations-Management kann über das Ziel hinausschiessen und verursacht einen erheblichen administrativen Aufwand. Anpassungen der Architektur-Funktion ziehen unter Umständen Aufwände im Bereich des Informations-Management nach sich. Eine größere Homogenität der Architekturen und Reduktion der funktionalen Redundanzen sind allerdings möglich. Es muss dabei auch berücksichtigt werden, dass sich Standardisierung und Innovation diametral gegenüberstehen. Eine permanente Innovation verhindert eine wirkungsvolle Standardisierung und eine starke Standardisierung erlaubt keine Innovation. Diese Aspekte gehören ausbalanciert.

Das Angebot an Werkzeugen unterstützen verschiedene Ausprägungen. Die Marktführer haben allerdings den Fokus auf ein starkes, umfängliches Informations-Management, welches im Bedarfsfall durch Reduktion auf den entsprechenden Anwendungsfall angepasst wird.

Bei der Produktauswahl sollte ein Mindestmaß an Konzeption der Architektur-Funktion  in der Organization vorhanden sein. Die Konzeption muß aber keineswegs vollumfänglich sein bevor ein Werkzeug ausgewählt wird. Dabei sollte man allerdings berücksichtigen das der Umfang der Investition dem Umfang der Konzeption angemessen ist. Also schwache Konzeption, schwache Investition und starke Konzeption, starke Investition.

Die Verbindung zwischen dem Enterprise-Architektur-Tool und des Entwurfs der Enterprise Architektur (Conway’s Law) bedingt, dass das Werkzeug ebenfalls den gleichen Anforderungen an Flexibilität und Agilität entspricht. Es muss sich schnell den Veränderungen der Architektur-Funktion anpassen lassen.

Entwicklung im Bereich der Open Source Software versprechen neue, flexiblere Ansätze. So erlauben Graphdatenbanken nicht nur das effiziente Verwalten von Diagrammen, sondern erlaubt auch Informationen zu Verbinden, ohne vorherige relationale Abbildungsanweisungen zu formulieren. Gleichsam wie auf einer Landkarte kann man zwischen „Informations-Siedlungen“ über ihre Verbindungen traversieren, um z.b. alle „Nachbar-Siedlungen“ auszumachen. Die Entkopplung von Funktionsgruppen (Services) in der Verarbeitung der Informationen, sowie HTTP-basierte Protokolle erlauben einen modularen Aufbau mit guter Integration und guter Änderbarkeit.

Man kann auf die Evolution der Enterprise-Architcture-Tools in naher Zukunft gespannt sein. Werkzeug-Hersteller die ein Lizenzmodell auf Nutzerbasis oder komplexe Bedienoberflächen anbieten, verpassen womöglich den Zeitgeist und bekommen in Zukunft weniger „likes“. Die Open Source Communities und die sozialen Netzwerke zeigen das verteilte Zusammenarbeit und der Informationsaustausch Spaß machen kann.

Quellen

Blind Men and an elephant – https://en.wikipedia.org/wiki/Blind_men_and_an_elephant

Open Group TOGAF 9 – https://www.opengroup.org/togaf/

Open Group ArchiMate – https://www.opengroup.org/archimate/

Frederic Vester, Neuland des Denkens – Vom technokratischen zum kybernetischen Zeitalter, dtv, München 1984 / 2002, ISBN 3-423-33001-5

Gartner, Magic Quadrant for Enterprise Architecture Tools 2015