Tools für Enterprise-Architektur: So finden Sie die passende Lösung

Enterprise-Architecture-Tools helfen Ihnen, Fähigkeiten, Anwendungen, Daten und Prozesse abzubilden und ihre Zusammenhänge zu verstehen. Welches Tool das richtige ist, hängt davon ab, ob Sie ein Inventar, Standards und Roadmaps oder Belege dafür benötigen, wie die Arbeit tatsächlich abläuft.

Ein Repository zeigt, was vorhanden ist und wie die einzelnen Elemente zusammenpassen sollen. Es zeigt jedoch nicht unbedingt, was geschieht, wenn Mitarbeitende diese Systeme und Prozesse nutzen.

Diese Lücke ist kein Versäumnis der Personen, die die Architektur pflegen. Die Arbeit verändert sich, Dokumente veralten und operative Systeme erfassen Belege, die ein statisches Modell allein nicht liefern kann.

Wofür werden Enterprise-Architecture-Tools eingesetzt?

Enterprise-Architecture-Tools helfen Ihnen, eine Organisation und die Beziehungen zwischen ihren Bestandteilen zu beschreiben. Die meisten unterstützen drei übergeordnete Aufgaben.

• Bestand: Erfassen Sie Fähigkeiten, Prozesse, Anwendungen, Daten, Verantwortliche und Abhängigkeiten.
• Standards und Roadmaps: Verwenden Sie Frameworks wie TOGAF oder ArchiMate, um geplante Änderungen zu bewerten und den Übergang vom aktuellen zum angestrebten Zustand zu planen.
• Analyse: Verstehen Sie, wie die Organisation arbeitet und welche Auswirkungen eine Änderung haben könnte.

Ein Repository hilft Ihnen bei Fragen wie: Welche Anwendungen unterstützen eine bestimmte Fähigkeit? Welche Prozesse sind von einem System abhängig? Außerdem schafft es eine gemeinsame Begriffsbasis, auf der Teams über Veränderungen sprechen können.

Ein Architektur-Repository erklärt jedoch nicht automatisch, wie die Arbeit in der Praxis abläuft. Prozessname, Verantwortliche und Beschreibung zeigen weder, wie oft Cases einen Ausnahmeweg nehmen, noch wo sie warten oder wie viele Freigabeschleifen sie durchlaufen.

Dieser Unterschied prägt den weiteren Vergleich: Repository-Tools beschreiben, was vorhanden ist und geplant wird. ProcessMind hilft Ihnen zu untersuchen, was laut Ihren Systemen tatsächlich geschieht.

Worauf sollten Sie beim Vergleich von Enterprise-Architecture-Software achten?

Vergleichen Sie Enterprise-Architecture-Software danach, welche Aufgaben sie unterstützen muss, und nicht nur anhand der Funktionen auf der Website eines Anbieters.

1. Repository und Metamodell: Kann das Tool Ihre Fähigkeiten, Prozesse auf mehreren Ebenen, Anwendungen, Daten und Beziehungen ohne Umwege abbilden?
2. Framework-Unterstützung: Unterstützt das Produkt ArchiMate und TOGAF, oder stellt es vor allem Elemente für die Diagrammerstellung bereit?
3. Prozessdetails: Können Sie von einem übergeordneten Prozess zu Subprocesses, Aktivitäten, Gateways und Varianten wechseln? Lassen Sie sich einen Prozess auf mehreren Ebenen zeigen.
4. Datenverknüpfung: Lassen sich Teile der Architektur anhand operativer Daten aktualisieren oder überprüfen, statt sich vollständig auf manuelle Änderungen zu verlassen?
5. Zusammenarbeit und Berechtigungen: Können Teams Inhalte beitragen und prüfen? Können Mitarbeitende das Repository ansehen, ohne eine Bearbeitungslizenz zu benötigen?
6. Hosting und Datenresidenz: Wo werden Ihre Daten gespeichert, wer kann darauf zugreifen und erfüllt das Ihre Anforderungen?
7. Interoperabilität: Können Sie Ihre Architektur exportieren und APIs oder offene Formate verwenden? Sie sollten Ihre Arbeit mitnehmen können.
8. Lizenzierung: Wie werden Bearbeitende, Prüfende und Viewer mit Leserechten lizenziert? Vergleichen Sie die Gesamtkosten für alle Personen, die Zugriff benötigen, nicht nur für das Kernteam.

Achten Sie besonders auf Prozessdetails und die Verknüpfung mit Daten. Eine Fähigkeitslandkarte kann bei der Planung helfen. Sie ist jedoch schwieriger in konkrete Maßnahmen umzusetzen, wenn Sie sie nicht mit den Prozessen verbinden können, die Mitarbeitende ausführen.

Bitten Sie Anbieter zu zeigen, wie ein Modell gepflegt wird, wie weit Sie die Prozesshierarchie hinabgehen können und ob sich Informationen anhand von Daten überprüfen lassen. An den Antworten erkennen Sie, ob das Tool die Prozessebene unterstützt oder lediglich dokumentiert.

Diese Prüfpunkte helfen Ihnen zu entscheiden, ob Sie ein Enterprise-Architecture-Repository, eine Prozessebene mit Datenbelegen oder beides benötigen.

Welches Enterprise-Architecture-Tool eignet sich für welche Aufgabe?

Enterprise-Architecture-Tools gibt es für unterschiedliche Anforderungen. Ein sinnvoller Vergleich beginnt bei der Aufgabe und nicht bei der Anzahl der Funktionen. Die folgende Matrix vergleicht die acht Prüfpunkte über verschiedene Kategorien hinweg. ProcessMind steht in der letzten Spalte.

EA-Suiten mit Repository-Schwerpunkt wie Software AG ARIS, Bizzdesign, MEGA HOPEX, Orbus iServer und Sparx EA sind für Architektur-Repositorys, Frameworks, Governance und Portfoliomanagement ausgelegt. Sie eignen sich für Organisationen, die den Auftrag und die Kapazitäten haben, ein formelles Architekturprogramm zu betreiben.

EA-Management-Plattformen wie SAP LeanIX bieten einen SaaS-Ansatz für Anwendungs- und Fähigkeitsinventare. Sie eignen sich für Organisationen, die einen Überblick über ihre Anwendungslandschaft und eine strukturierte Verwaltung der Enterprise Architecture anstreben.

Diagramm- und ArchiMate-Tools eignen sich, wenn Sie vor allem Modelle erstellen und teilen möchten. Archi ist eine kostenlose Open-Source-Lösung mit nativer ArchiMate-Unterstützung. Auch mit Visio lassen sich Architekturen dokumentieren. Prüfen Sie, ob Repository, Zusammenarbeit und Governance Ihren Anforderungen entsprechen.

ITSM- und Plattformmodule können sinnvoll sein, wenn Architekturansichten neben den Systemen verfügbar sein sollen, die Sie bereits verwenden. Prüfen Sie, ob Modellierungstiefe und Repository-Funktionen des Moduls zu Ihrer Architekturarbeit passen.

ProcessMind beantwortet eine andere Frage: Wie läuft die Arbeit ab und was zeigen die operativen Daten? Die Plattform verknüpft Value Streams und Prozessebenen mit den Ereignisdaten, die Ihre Systeme bereits erfassen. So lässt sich die Architektur bis zu den ausgeführten Aktivitäten nachvollziehen und mit dem tatsächlichen Ablauf abgleichen.

In diesen Kategorien gibt es keinen eindeutigen Gesamtsieger. Wählen Sie das Tool, das zu Ihrer vorrangigen Aufgabe passt. Geht es Ihnen vor allem um das Prozessverhalten, beginnen Sie mit Belegen aus der Prozessebene. Ergänzen Sie ein Repository, wenn Ihr Architekturprogramm es benötigt.

Warum weicht die Enterprise Architecture von der Realität ab?

Die Enterprise Architecture kann sich von der Realität entfernen, wenn das Repository von manuellen Aktualisierungen abhängt und das Modell zu weit über der Arbeitsebene liegt, die es beschreiben soll.

Drei strukturelle Faktoren begünstigen diese Abweichung:

• Mitarbeitende pflegen das Repository manuell. Änderungen an Prozessen, Anwendungen und Zuständigkeiten müssen eingetragen und geprüft werden.
• Der Nutzen zeigt sich möglicherweise erst später. Teams benötigen ein korrektes Inventar vielleicht erst bei einem künftigen Audit oder einer Auswirkungsanalyse, während die Aktualisierung sofort anfällt.
• Das Modell beschreibt die Absicht, nicht das Verhalten. Ein dokumentierter Prozess zeigt möglicherweise weder Nacharbeitsschleifen und Ausnahmen noch Übergaben oder Wartezeiten in realen Cases.

Fähigkeitslandkarten und Anwendungsinventare helfen dabei, die Organisation auf einer übergeordneten Ebene zu verstehen. Mitarbeitende erkennen ihre tägliche Arbeit jedoch möglicherweise nicht in einem Modell wieder, das auf der Ebene von Fähigkeiten oder Anwendungen endet.

Die Unterschiede zeigen sich oft in den Details: Prozessvarianten, Übergaben, wiederholte Freigaben und Wartezeiten. Ein Repository kann den geplanten Prozess dokumentieren. Ob diese Beschreibung noch dem operativen Ablauf entspricht, lässt sich jedoch nur mit einer zusätzlichen Datenquelle überprüfen.

Eine Architektur, in der sich niemand wiedererkennt, scheitert auf eine von zwei Arten. Entweder umgehen Mitarbeitende sie, weil das Modell eine Freigabe vorsieht, während das Team aus Erfahrung drei kennt. Dann wird das Modell nicht mehr konsultiert. Oder es bleibt als Compliance-Dokument bestehen, das vor einem Audit aktualisiert und dazwischen ignoriert wird. In beiden Fällen liegt es nicht am Tool, sondern an der Kluft zwischen Modell und Arbeit.

Eine bessere Governance kann dazu beitragen, ein Repository aktuell zu halten. Sie liefert jedoch für sich genommen keinen unabhängigen Beleg dafür, dass das Modell dem tatsächlichen Ablauf entspricht. Wenn Sie Prozessmodelle mit operativen Daten verknüpfen, können Sie diese Ebene überprüfen.

Wie lässt sich die Architektur mit der täglichen Arbeit verbinden?

Details aus dem Arbeitsalltag machen die Architektur für Teams greifbarer. Außerdem können Sie diese Angaben anhand operativer Daten überprüfen.

Eine Fähigkeitslandkarte beschreibt, was die Organisation leisten muss. Ein Prozessmodell zeigt, wie diese Arbeit ausgeführt wird, wer dafür verantwortlich ist und wie Subprocesses zusammenhängen. Je klarer Sie diese Ebenen verknüpfen, desto einfacher wechseln Sie zwischen einer Architekturansicht und der darin dargestellten Arbeit.

Ein Event Log liefert Belege zu abgeschlossenen Cases. Es zeigt, welche Aktivitäten in welcher Reihenfolge stattgefunden haben und wie lange die Cases dauerten. Wenn Sie diese Daten mit einem Prozessmodell vergleichen, erkennen Sie Abweichungen zwischen dem beobachteten Ablauf und dem dokumentierten Prozess.

Das bedeutet nicht, dass sich alle Teile einer Enterprise Architecture aus Ereignisdaten ableiten lassen. Portfolioentscheidungen, Standards und Entscheidungen zum Zielzustand erfordern weiterhin Architekturarbeit und Governance. Daten können eine belegbare Grundlage für die Prozessebene liefern, aber nicht das gesamte Repository ersetzen.

Prozessdetails aus dem Arbeitsalltag verhindern beide Arten des Scheiterns. Wenn die Architektur Aktivitäten, Übergaben und Wartezeiten abbildet, erkennen Teams ihre eigene Arbeit im Modell wieder. Verantwortliche sehen zugleich, für welche Entscheidungen sie zuständig sind. Ein EA-Tool kann das Portfolio verwalten. Die Verbindung zu den Menschen, die es umsetzen, entsteht durch die Arbeit selbst.

Datenbelege liefern ein überprüfbares Signal. Die im Modell angegebene Wartezeit sollte mit der Wartezeit im Event Log übereinstimmen. Ist das nicht der Fall, dreht sich das Gespräch um den Prozess statt um das Diagramm. Das ist hilfreicher als eine weitere Aktualisierungsrunde.

Auch die Reihenfolge der Arbeit ändert sich. Statt zuerst das Repository fertigzustellen und darauf zu hoffen, dass die Details später folgen, messen Sie einen Prozess und verknüpfen ihn mit der übergeordneten Ebene. So kann sich Vertrauen in das Modell dort entwickeln, wo es überprüfbar ist. Dieser erste Ausschnitt ist klein genug, um ihn abzuschließen. Zugleich erhält das Architekturprogramm ein funktionierendes Beispiel statt eines bloßen Plans.

Anhand der Dokumentation der Prozessarchitektur sehen Sie, wie Prozessebenen und ihre Beziehungen dargestellt werden. Informationen zur Datenseite finden Sie unter So erstellen Sie ein Process-Mining-Event-Log.

Warum verfolgt ProcessMind einen anderen Ansatz für Architektur?

ProcessMind setzt bei den Teilen der Architektur an, die sich mit Daten belegen lassen. Das ist eine bewusste Entscheidung für einen anderen Ansatz und keine kleinere Variante dessen, was ein Repository leistet.

Portfoliomanagement, der Lebenszyklus von Anwendungen und die Verwaltung von Standards gehören zum Kernbereich eines Repositorys. ARIS, SAP LeanIX, Bizzdesign, MEGA HOPEX, Orbus und Sparx eignen sich gut für diese Aufgaben. Die Prozessebene hat hier ihren eigenen Platz.

Wir konzentrieren uns auf die Prozessebene: Value Streams, konfigurierbare Prozessebenen, RACI-Verantwortlichkeiten, Governance-Workflows und ein Viewer-Portal, verknüpft mit Ereignisdaten. Für Fragen zu Prozessen funktioniert diese Ebene eigenständig. Wenn ein Architekturprogramm ein Repository benötigt, ergänzt sie es auf natürliche Weise.

Wie wählen Sie ein Enterprise-Architecture-Tool aus?

Richten Sie Ihre Wahl danach aus, welche Fragen Ihre Teams beantwortet haben müssen und welche Architekturarbeit Sie steuern möchten.

• Sie benötigen Portfoliomanagement, Standards und Roadmaps: Nehmen Sie eine umfassende EA-Suite in die engere Wahl und planen Sie die Mitarbeitenden und Prozesse ein, die für die Pflege des Repositorys erforderlich sind.
• Sie benötigen ein SaaS-Inventar für Anwendungen und Fähigkeiten: Bewerten Sie eine EA-Management-Plattform wie SAP LeanIX anhand Ihrer Anforderungen an Inventar und Governance.
• Sie benötigen Antworten zum Prozessverhalten: Beginnen Sie mit Prozessmodellen und operativen Daten. Entscheiden Sie anschließend, ob Sie zusätzlich ein umfassenderes Repository benötigen.
• Sie sind noch unentschieden: Ermitteln Sie, welche Fragen Teams am häufigsten stellen. So können Sie entscheiden, ob Sie mit einem Repository, Datenbelegen zu Prozessen oder beidem beginnen.

Wenn Sie Repository-Tools vergleichen, lesen Sie unseren Vergleich von ARIS-Alternativen. Wenn Sie untersuchen, wie Modelle und Daten zusammenspielen, lesen Sie Wie Prozessmodellierung und Process Mining einander ergänzen.

Beginnen Sie dort, wo Sie Datenbelege erhalten. Ergänzen Sie das Repository, wenn Ihr Architekturprogramm dessen umfassendere Governance- und Portfoliomanagement-Funktionen benötigt.

Welche Rolle spielt ProcessMind?

ProcessMind ergänzt die Architektur um eine Prozess- und Value-Stream-Ebene, die sie mit Belegen zum tatsächlichen Arbeitsablauf verknüpft.

Ein Repository verwaltet das Portfolio und die Standards. ProcessMind bildet die Prozessebene und die zugehörigen Datenbelege ab. Wer beides einsetzt, kann die Prozessdetails der Architektur überprüfen. Wer nur die Prozessebene benötigt, kann ProcessMind auch eigenständig verwenden.

Sie können Prozesse auf konfigurierbaren Ebenen organisieren, in BPMN 2.0 modellieren, RACI-Verantwortlichkeiten zuweisen und Governance-Workflows sowie ein Viewer-Portal einsetzen. Außerdem lassen sich Prozessmodelle mit Ereignisdaten verknüpfen, um dokumentierte Prozesse mit dem beobachteten Ablauf zu vergleichen. Mit der Prozesssimulation können Sie Änderungen im Modell untersuchen, bevor jemand den Prozess in der Produktion verändert.

Weitere Informationen zu den Funktionen von ProcessMind für Enterprise Process Architecture finden Sie auf der Seite Enterprise Process Architecture. Lesen Sie auch über Prozess-Governance und Was ist Process Mining?.