Projekte zur Umgestaltung komplexer Anwendungslandschaften erweisen sich in der Praxis als Herausforderung für Unternehmen. Die laufende Anpassung an sich ändernde fachliche und technische Gegebenheiten ist für die Zukunftssicherheit einer Anwendungslandschaft unverzichtbar. Dieser Artikel schlägt einen Modellierungsansatz vor, der Anwendungslandschaften zum Gegenstand eines von allen Beteiligten gestalteten Veränderungsprozesses macht. Durch die ineinandergreifende Modellierung von technischer Architektur und Geschäftsprozessen wird Verständnis für jene Zusammenhänge geschaffen, welche die Umgestaltung so herausfordernd machen.
nalität als externe Dienstleistung zugekauft wird. Für die Umsetzung dieser Änderungen muss die Anwendungslandschaft im Kontext ihrer Verwendung betrachtet und verstanden werden, da sonst viele relevante Fragen unbeantwortet bleiben. Bezogen auf die Veränderungen im Wertpapierhandel sind dies beispielsweise:
Welcher Ausschnitt der Anwendungslandschaft ist von den Veränderungen im Wertpapierhandel betroffen? Kommt es durch die neue Anwendung zu Redundanzen in der Datenhaltung, so dass Daten aus mehreren Beständen synchronisiert werden müssen? Wie wirken die komplexen IT-gestützten und manuellen Arbeitsprozesse zusammen, die den Geschäftsprozess „Wertpapierhandel“ ausmachen? Welche dieser Arbeitsprozesse müssen angestoßen werden, um die neuen und geänderten Schnittstellen in der Anwendungslandschaft testen zu können? In diesem Artikel wird untersucht, wie die gemeinsame Betrachtung von Anwendungslandschaften und ihrer Verwendung Umgestaltungsprojekte unterstützen kann (siehe Abschnitt 2). Als Grundlage für diese Analyse dienen Projekte der C1 WPS GmbH, in welcher der Autor als Berater tätig ist. Mit der an der Universität Hamburg entwickelten exemplarischen Geschäftsprozessmodellierung (eGPM, siehe Abschnitt 3) steht ein praxiserprobter Ansatz zur Verfügung, um Anwendungslandschaften und ihre Verwendung ineinandergreifend zu modellieren. In mehreren Projekten der C1 WPS wurden positive Erfahrungen mit eGPM gemacht. In einem Abgleich mit bestehenden Modellierungsansätzen für Anwendungslandschaften und Geschäftsprozesse (siehe Abschnitt 4) zeigt der Artikel, dass die vorgeschlagene Sichtweise auf Anwendungslandschaften bisher wenig beachtete Themen beleuchtet. Abschließend fasst Abschnitt 5 die bisherigen Erkenntnisse zusammen und zeigt weiteren Forschungsbedarf auf. 2
2.1
Unternehmen betreiben nicht länger einzelne, isolierte Softwaresysteme, sondern eine große Zahl teilweise von einander abhängiger Anwendungen. Die Gesamtheit dieser Anwendungen wird zusammen mit ihren Abhängigkeiten als Anwendungslandschaft eines Unternehmens bezeichnet [Der03]. Änderungen im Geschäft und technische Gründe wie schlecht zu wartende IT-Systeme erfordern die laufende Anpassung von Anwendungslandschaften. Um sie umgestalten zu können, ist die Kenntnis ihrer Architektur genauso wichtig wie die Abstimmung mit den von ihr zu unterstützenden Arbeits- und Geschäftsprozessen. Dieser Artikel folgt der Definition der ANSI und versteht unter Architektur den Aufbau einer Anwendungslandschaft, verkörpert durch ihre Bestandteile und deren Beziehungen untereinander, sowie die Grundsätze ihres Entwurfs und ihrer Evolution [ANS00]. Als Geschäftsprozesse fasst man koordinierte Aktivitäten zur Erreichung von Geschäftszielen zusammen [Wes07]. Umgesetzt werden diese abstrakten Aktivitäten durch konkrete manuelle und IT-gestützte Arbeitsprozesse.
Ohne ein Verständnis der Architektur können die Auswirkungen der Anpassung einer Anwendungslandschaft nicht eingeschätzt werden, während eine fehlende Abstimmung mit den Prozessen den Sinn der Änderungen in Frage stellt. Zu einer ähnlichen Einschätzung kommen Conrad et al., die für das Gebiet der Enterprise Application Integration (EAI) die beiden Problembereiche „technische Realisierung“ und „organisatorische/soziale Integration“ identifizieren [CHKT06, S. 5]. EAI kann als Teilbereich der Umgestaltung von Anwendungslandschaften aufgefasst werden, weil das Einführen neuer Anwendungen, die Anpassung von Schnittstellen zwischen Anwendungen und das Abschalten von Anwendungen die wesentlichen Möglichkeiten darstellen, um eine Anwendungslandschaft zu verändern. Die in diesem Artikel vorgeschlagene Unterstützung für die Umgestaltung von Anwendungslandschaften basiert daher auf der Unterstützung dieser Veränderungsmöglichkeiten. 2.2
Dieser Abschnitt fasst die Erfahrungen zusammen, welche die C1 WPS GmbH in Umgestaltungsprojekten gesammelt hat. Neben Beratung zur IT-Strategie der Kunden und der Modellierung von Ist- und Soll-Anwendungslandschaften unterstützte sie die Umsetzung der erarbeiteten Pläne. Dabei traten immer wieder zwei grundlegende Fragen auf, deren Beantwortung die gemeinsame Betrachtung der Architektur der Anwendungslandschaften und der von ihnen unterstützten Prozesse erforderte:
Was muss man über die Anwendungslandschaft und ihre Verwendung wissen, um sie umgestalten zu können? Welche Auswirkung hat die Umgestaltung auf die Anwendungslandschaft und ihre Verwendung? Anhand eines fiktiven, aber realistischen Beispiels aus der Versicherungsbranche werden im Folgenden drei Kontexte vorgestellt, in denen diese Fragen auftauchen: Eine Versicherung verwendet Vorgangsmappen, um die arbeitsteilige Abarbeitung von Schadensfällen zu koordinieren und den Bearbeitungsstatus eines Falls nachvollziehen zu können. Die einzelnen Arbeitsschritte der Sachbearbeiter werden bereits durch IT-Systeme unterstützt. Hingegen ist die Vorgangsmappe eine nicht formal festgelegte, lose Kombinaton von E-Mails, Dateien und Papierdokumenten. Um die Bearbeitungsgeschwindigkeit zu erhöhen, sollen die Vorgangsmappen durch ein Workflow-Management-System (WfMS, vgl. [zM04]) umgesetzt werden.
Nur mit Detailwissen über die IT-Unterstützung der betroffenen Akteure können Schnittstellen zwischen Anwendungen auf technischer und fachlicher Ebene ermittelt und eine sinnvolle Integration erreicht werden. Im Beispiel: Um herauszufinden, wie das WfMS und die bestehenden Anwendungen sinnvoll integriert werden können, müssen die Arbeitsprozesse der Sachbearbeiter und die vorhandene ITUnterstützung modelliert werden.
Welche Arbeitsgegenstände (eingescannte Dokumente, Anträge auf Papier etc.) verwenden die Sachbearbeiter? Welche Arbeitsschritte erledigen sie IT-gestützt und mit welchen Anwendungen? Tauschen diese untereinander Daten aus? Wie wird die Kommunikation angestoßen?
Unternehmen setzen große Änderungen in ihren Anwendungslandschaften oft in kleinen Schritten um, sodass die Landschaft und die von ihr unterstützten Prozesse auf dem Weg vom Ausgangs- zum Zielzustand mehrere produktive Zwischenzustände durchlaufen. In jedem dieser Schritte müssen die Veränderungen in der Landschaft gut abgestimmt und von Fachabteilung und IT verstanden werden, um den reibungslosen Betrieb aufrecht erhalten zu können. Im Beispiel:
In welcher Reihenfolge sollen die Arbeitsprozesse der Sachbearbeiter im WfMS abgebildet werden? Wie verändern sich die Prozesse in der Abteilung für Schadensfälle und die Schnittstellen in der Anwendungslandschaft durch das WfMS? Wie sehen sie nach dem ersten, zweiten, dritten etc. Migrationsschritt aus?
Anwendungsübergreifende Tests entlang fachlicher Prozesse mindern das Risiko, das neue und geänderte Schnittstellen für die Verwendung einer Anwendungslandschaft darstellen. Passende Testszenarien zu identifizieren und konkrete Testfälle aufzustellen erfordert die detaillierte Kenntnis der Zusammenhänge zwischen technischer Architektur der Anwendungslandschaft und den von ihr unterstützten Arbeitsprozessen. Im Beispiel: Welche anwendungsübergreifenden Arbeitsprozesse führt ein Sachbearbeiter aus? Gibt es manuelle Schritte in diesen Arbeitsprozessen, die Kommunikation zwischen Anwendungen auslösen? Welche Abhängigkeiten zwischen Anwendungen sind rein fachlich und nicht technisch (z.B. Nachbearbeitung von eingescannten Dokumenten)? 3
Dieser Abschnitt stellt einen Ansatz zur Geschäftsprozessmodellierung vor, der sich in der Praxis als Hilfsmittel zur Beantwortung der oben genannten Fragestellungen erwiesen hat. Da eine ausführliche Beschreibung des Ansatzes den Umfang dieses Artikels sprengen würde, wird er nur im Überblick dargestellt. 3.1
Ursprung der exemplarischen Geschäftsprozessmodellierung (vgl. [BKS06, Bre03]) ist die Analyse der Unterstützung kooperativer Arbeit durch Software – speziell der Aspekte Kommunikation, Kooperation und Koordination (vgl. [TSMB95]). Die Modellierung findet in diesem Ansatz typischerweise in Workshops statt, in denen z.B. Vertreter aus Fachabteilung und IT ihr Wissen und ihre unterschiedlichen Sichten in gemeinsame Modelle einbringen. Das ermöglicht unmittelbare Rückkopplung, ob die Darstellung des modellierten Gegenstandsbereichs zutreffend ist. Da eine Werkzeugunterstützung für diese Vorgehensweise sehr nützlich ist, wurde eGPM in Zusammenarbeit mit der BOC Group1 als Modellierungsmethode für das Geschäftsprozessmanagement-Werkzeug ADONIS implementiert. eGPM besteht aus mehreren Modelltypen, die in ein gemeinsames Metamodell eingebettet sind. Durch die Werkzeugunterstützung können Modelle verschiedener Typen auf Ebene von Modellelementen verknüpft werden, was eine konsistente Modellierung erleichtert. Zusätzlich stehen Überblicks- und Begriffsmodelltypen zu Verfügung, die einen Überblick über zusammengehörige Modelle verschaffen bzw. Begriffe und Konzepte des modellierten Gegenstandsbereichs zueinander in Beziehung setzen. Nur die beiden für diesen Artikel wichtigsten Modelltypen werden im Folgenden näher beschrieben.
Das Kooperationsbild ist der zentrale Modelltyp der eGPM und baut auf den Arbeiten von Krabbel, Wetzel et al. (siehe u.a. [KWR96a, KWR96b]) auf. Kooperationsbilder stellen Kommunikation, Kooperation und Koordination zwischen Akteuren graphisch dar. Sowohl Menschen als auch IT-Systeme können als Akteure eine aktive Rolle übernehmen. Dadurch machen Kooperationsbilder die IT-Unterstützung von Geschäftsprozessen auf der Ebene einzelner Arbeitsschritte sichtbar. Akteure sind durch typisierte Pfeile mit anderen Akteuren und Gegenständen (z.B. „Geschäftsobjekte"wie in [BELM08]) verbunden. Diese Relationen beschreiben folgende Aktivitäten:
(a) Akteur bearbeitet Gegenstand
(b) Akteur gibt Gegenstand weiter (c) Akteur informiert mit Medium
Abbildung 1: Relationen zwischen Akteuren und Gegenständen im Kooperationsbild Den Kooperationsbildern liegt keine ablaufsteuernde, algorithmische Denkweise zu Grunde. Stattdessen zeigen sie einen konkreten Ablauf eines Prozesses aus der Sicht der beteiligten Akteure. Die einzelnen Aktivitäten des Prozesses werden dazu in eine exemplarische Reihenfolge gebracht. Auf die Darstellung von Fallunterscheidungen wird verzichtet – Kooperationsbilder „erzählen“ Szenarios (vgl. [Car00]).
Wie sich im Praxiseinsatz gezeigt hat, ist eGPM durch die grafische Darstellung der Kooperationsbilder und den Verzicht auf Fallunterscheidungen so verständlich, dass die an den Workshops teilnehmenden Personen auch selbst Modelle erstellen können, während ein geschulter Modellierer die Rolle des Moderators annimmt. Dieser achtet unter anderem darauf, dass das gewählte Szenario durch klare Randbedingungen von anderen Fällen abgegrenzt wird (z.B. Schadensfall Privathaftpflichtversicherung ohne Zusatzdeckungen, Schadenssumme unter 10.000AC, Schaden wird vollständig gedeckt). Abbildung 2 stellt den fiktiven Geschäftsprozess „Bearbeitung eines Schadensfalls“ mit den beschriebenen Rahmenbedingungen als Kooperationsbild dar. Dieses Beispiel ist im Vergleich zu realen Prozessen stark vereinfacht und verwendet nicht alle graphischen Elemente des Modelltyps. Anhand der Nummern kann der Ablauf des Szenarios nachvollzogen werden.
Der Modelltyp IT-Landschaft2 stellt die Zusammenhänge mehrerer IT-gestützter Prozesse dar. Es handelt sich dabei um ein Begriffsmodell, das IT-Systeme zueinander in Beziehung setzt. Ein geschulter Modellierer erstellt auf Basis der aus den Kooperationsbildern gewonnenen Informationen über die IT-Unterstützung ein Modell des relevanten Teils der Anwendungslandschaft. Dieses Modell wird gegebenenfalls in Workshops mit der ITAbteilung um technische Aspekte ergänzt und von Widersprüchen bereinigt. Kooperationsbilder können auf IT-Landschaften Bezug nehmen, in dem die Anwendungen mit denen der IT-Landschaft verknüpft werden. Das Modell der IT-Landschaft dient dem mit der Auswahl der Szenarien verbundenen Zweck – etwa der Herausarbeitung von technischen, fachlichen und organisatorischen Berührungspunkten einer Anwendungslandschaft zu einem neu einzuführenden Workflow-Management-System. Abbildung 3 zeigt den für die Schadensbearbeitung relevanten Teil der IT-Landschaft vor der Einführung des WfMS. Ein solches Modell führt die technikbezogenen Informationen mehrerer Kooperationsbilder (u.a. dem in Abbildung 2) zusammen. Auch diese Abbildung ist im Vergleich zu 2„IT-Landschaft“ ist in eGPM ein Oberbegriff für „Anwendungslandschaft“, der zusätzlich Hardware- und Software-Infrastruktur mit einschließt. echten IT-Landschaften stark vereinfacht und enthält nur einige wenige der möglichen Darstellungsmittel. Zu sehen sind ausgewählte IT-Systeme, für welche Daten sie führend zuständig sind und welche Daten von ihnen aus anderen Anwendungen importiert (grauer Pfeil), an andere Anwendungen gesendet (schwarzer Pfeil) und mit anderen Anwendungen synchronisiert (schwarzer Doppelpfeil) werden.
3.2
Dieser Abschnitt beschreibt unsere Erfahrungen beim Einsatz der eGPM in Umgestaltungsprojekten. Er zeigt, mit welchen Eigenschaften eGPM den in Abschnitt 2.2 aufgelisteten Herausforderungen begegnet.
Die Umgestaltung einer Anwendungslandschaft involviert viele Personen mit unterschiedlichen Fähigkeiten und Hintergründen, beispielsweise Mitarbeiter aus Fachbereichen und IT sowie externe Dienstleister. Diese Personen haben direkt mit der Umgestaltung zu tun, verfügen aber über verschiedene Sichten auf die Anwendungslandschaft. Selbst wenn bereits Informationen zu den einzelnen Anwendungen vorliegen und in ein Modell verdichtet wurden, heißt das nicht, dass die Beteiligten über ein gemeinsames Verständnis verfügen. Dieses ist aber wegen der nötigen Abstimmung in solchen Projekten (siehe z.B. die Frage nach der Planung produktiver Zwischenschritte im Abschnitt 2.2) von großer Bedeutung. Die eGPM leistet mit ihren für alle Beteiligte verständlichen Darstellungsformen einen Beitrag zur Schaffung eines gemeinsamen Verständnisses einer Anwendungslandschaft. Beim Erstellen der Modelle erarbeiten sich die Beteiligten außerdem ein gemeinsames Begriffsmodell. Daher kann der Modellierungsprozess der eGPM als „Verständnisprozess“ aufgefasst werden, in dessen Verlauf die Beteiligten explizit Informationen einbringen und unterschiedliche Sichten verbinden.
Viele der Fragen aus Abschnitt 2.2 beschäftigen sich mit Kommunikation, Koordination und Kooperation. Im Kontext von Anwendungslandschaften spielen diese Aspekte sowohl in der Zusammenarbeit von IT-Systemen untereinander als auch zwischen Anwendungen und ihren Benutzern eine Rolle. Daher greifen rein technisch motivierte Modelle zu kurz. Die Kooperationsbilder der eGPM stellen unter anderem dar, wer - was - womit - wozu bearbeitet und wer - wen - mit welchen Mitteln informiert. Dadurch fordert sie von den Modellierern, explizit Fragen zur IT-Unterstützung von Kommunikation, Koordination und Kooperation zu stellen. Die Antworten zu diesen Fragen gehen in das Modell der Anwendungslandschaft ein.
In der Praxis kann kaum eine vollständige Modellierung einer Anwendungsanlandschaft erreicht werden: Zum einen wären die zu erhebenden Daten extrem umfangreich und nicht aktuell zu halten. Zum andern verfügen viele Unternehmen nicht über die Möglichkeit, die Vollständigkeit der Modellierung z.B. anhand der vom Lizenzmanagement erfassten Anwendungen zu überprüfen.
Eines der Kernkonzepte der eGPM ist die Fokussierung auf Szenarios. Diese auszuwählen und dabei Wesentliches von Unwesentlichem zu trennen bedeutet, die Unvollständigkeit von Modellen zu thematisieren und einen konstruktiven Umgang damit zu suchen. Die Szenarios werden anhand des konkreten Ziels (vgl. „Pragmatisches Merkmal“ in [Sta73]) eines Umgestaltungsprojekts (z.B. Einführung eines Workflow-Management-Systems) gewählt. Die bisherigen Erfahrungen beim Einsatz der eGPM zeigen, dass dadurch genügend Informationen für die Modellierung der betroffenen Teile der Anwendungslandschaft erhoben werden können. 4
Dieser Abschnitt stellt andere Ansätze vor, die sich mit der Modellierung von Anwendungslandschaften und ihrer Einordnung in einen unternehmensweiten Kontext befassen. 4.1
Als Unternehmensarchitektur werden unternehmensweite, integrierte Modelle von Geschäftsstrategie, Geschäftsprozessen, Anwendungen und Infrastruktur verstanden [Kel07]. Es handelt sich also um die Beschreibung der existierenden Strukturen von Unternehmen. Das Modell einer Anwendungslandschaft ist Teil einer Unternehmensarchitektur. Unternehmensarchitekturen sind nicht als Hilfsmittel für die detaillierte Planung und Durchführung von Änderungen in Anwendungslandschaften gedacht. So wird in [ARW08] und [WF06] gefordert, Unternehmensarchitekturen auf aggregierten Informationen aufzubauen und sie strategisch auszurichten. D.h. Unternehmensarchitekturen bestehen aus grobgranularen Informationen über alle Aspekte eines Unternehmens hinweg statt vertiefender Detailinformationen zu den einzelnen Aspekten. Winter und Fischer empfehlen, spezialisierte Architekturansätze für die operativen Aufgaben in Teilbereichen des Unternehmens einzusetzen [WF06]. Die eGPM ist ein solcher spezialisierter Ansatz. 4.2
Dieser Ansatz stellt Anwendungslandschaften in Form von Softwarekarten [LMW05] dar. In [BELM08] werden die Darstellungskonzepte (beispielsweise verschiedene Kartentypen) und die damit verbundenen Einsatzmöglichkeiten in Form von Mustern zusammengefasst. Ziel dieses Musterkatalogs ist, bestehende Ansätze zur Beschreibung von Unternehmensarchitekturen (siehe Abschnitt 4.1) zu ergänzen. Dazu wurden in der Praxis häufig auftretende Fragestellungen gesammelt und passende Lösungsansätze beschrieben, die aus Handlungsanweisungen, dafür benötigten Informationen und geeigneten Darstellungsformen für diese Informationen bestehen.
Der Großteil dieser Fragestellungen (Concerns) betrifft strategische Themen wie die langfristige Planung von Anwendungslandschaften. Zwar gibt es zwischen den Fragen und den Einsatzzwecken der eGPM einige Überschneidungen (etwa „Concern C-51: Which business objects are used or exchanged by which business applications or services?“ [BELM08, S. 34]), doch unterscheiden sich die Modelle für deren Beantwortung. Sofwarekarten basieren auf der Visualisierung von im Vorfeld (z.B. per Fragebogen) erhobenen Daten und sind nicht das Resultat eines Modellierungsprozesses im Sinne der eGPM. Die eGPM bindet die betroffenen Akteure in den Prozess mit ein und macht ihre Aufgaben zum Bestandteil von Kooperationsbildern, wodurch die Zusammenhänge zwischen Anwendungslandschaft und Geschäftsprozessen auf Ebene von Arbeitsprozessen (siehe Abschnitt 2.1) dargestellt werden. Softwarekarten zeigen diese Zusammenhänge auf Ebene von Geschäftsobjekten (siehe z.B. Viewpoint 48 im Katalog) oder direkt auf Geschäftsprozessebene (siehe z.B. Viewpoint 17). Ein weiterer Unterschied besteht im Umgang mit der (Un-)Vollständigkeit von Modellen (siehe Abschnitt 3.2). Im Gebiet der Geschäftsprozessmodellierung dominieren Ansätze, die Prozesse als Kontrollflüsse [KNS92] beschreiben. Als Vertreter dieses Konzepts führt Weske unter anderem die Business Process Modeling Notation und ereignisgesteuerte Prozessketten auf (vgl. [Wes07]). „Anwendungen“ spielen in diesen Ansätzen eine untergeordnete Rolle. Beispielsweise bietet der verbreitete Ansatz der ereignisgesteuerten Prozessketten [KNS92] lediglich die Möglichkeit, Informationsobjekte im Sinne von Datenquellen oder Speicherorten in einem Geschäftsprozessmodell zu verwenden. 5
Anwendungslandschaften rücken immer mehr in den Blickwinkel von Unternehmen und stehen aus fachlichen und technischen Gründen unter ständigem Änderungsdruck. Zukunftssicher können Anwendungslandschaften daher nur sein, wenn sie immer wieder durch Umgestaltungsprojekte an neue Gegebenheiten angepasst werden. In solchen Projekten werden Modelle von Anwendungslandschaften für die Planung und Umsetzung verwendet, jedoch stellt dabei die Verknüpfung von technischer Architektur und Arbeitsprozessen eine von der Informatik noch wenig beachtete Herausforderung dar. Eine solche Sicht auf Anwendungslandschaften ist aber für viele Aufgaben in Umgestaltungsprojekten hilfreich, etwas für die Konzeption fachlich und technisch passender Schnittstellen, für die detaillierte Migrationsplanung und für die Erarbeitung von Testszenarios. Mit der exemplarischen Geschäftsprozessmodellierung steht ein vielversprechender und praxiserprobter Ansatz zur Verfügung, um Anwendungslandschaften und die von ihnen unterstützten Prozesse ineinandergreifend zu modellieren. Er bildet die Grundlage für das Promotionsvorhaben des Autors, in dessen Verlauf die eGPM weiter für den Einsatz in Umgestaltungsprojekten optimiert werden soll. Dazu werden die Darstellungsmittel der eGPM weiter verbessert und eine passende Modellierungsmethode ausgearbeitet. Ergänzend werden Muster für die Anwendung der Methode bereitgestellt.
Ein weiterer, noch zu erforschender Aspekt ist die Einordnung der eGPM in eine Unternehmensarchitektur. Die Verbindung des Metamodells der eGPM mit dem Metamodell eines Ansatzes für die Modellierung von Unternehmensarchitekturen könnte eine Brücke zwischen strategisch ausgerichteten, stark aggregierten Darstellungen von Anwendungslandschaften und operativ ausgerichteten, detaillierten Darstellungen schlagen.
[ANS00]
ANSI/IEEE Computer Society. ANSI/IEEE-Standard-1471. IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, 2000. [ARW08] Stephan Aier, Christian Riege und Robert Winter. Unternehmensarchitektur. Literaturüberblick und Stand der Praxis. Wirtschaftsinformatik, 4:292–304, 2008.
Florian Matthes und André Wittenburg. Softwarekarten zur Visualisierung von Anwendungslandschaften und ihren Aspekten - Eine Bestandsaufnahme. Technical report, Technische Universität München, sebis, 2004. [Sta73]
Herbert Stachowiak. Allgemeine Modelltheorie. Springer, 1973.
Robert Winter und Ronny Fischer. Essential Layers, Artifacts, and Dependencies of Enterprise Architecture. In EDOC Workshop on Trends in Enterprise Architecture Research, Seiten 30–38. IEEE Computer Society, 2006.