Visualisierung von Software-Architekturen in heterogenen IT-Systemlandschaften - Marktüberblick und Kriterien für die Softwareauswahl

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1. Einleitung
1.1. Problemstellung
1.2. Zielsetzung und Aufbau der Arbeit

2. Grundlagen
2.1. Architekturen im Rahmen des Informationsmanagements
2.1.1. Architekturbegriffe und -prinzipien
2.1.2. Architekturbeschreibungssprachen (ADLs)
2.1.3. Unternehmensarchitekturen und -rahmenwerke
2.1.4. Service-orientierte Architekturen
2.1.4.1. SOA-Definitionen und -Prinzipien
2.1.4.2. Zusammenhang zwischen SOA und Unternehmensarchitektur
2.1.4.3. SOA-Rollen
2.1.5. Software-Architekturen
2.1.5.1. Definitionen von Software-Architektur
2.1.5.2. Entstehung und Gestaltung von Software-Architektur
2.1.6. Herausforderungen für Software-Architekturen
2.1.6.1. Sichten und das Sichten-Dilemma
2.1.6.2. Komplexitätsproblem
2.2. Visualisierung
2.2.1. Überblick
2.2.2. Zweidimensionale Best-Practice-Visualisierungen für EA nach Hanschke
2.2.3. Zweidimensionale UML-Diagrammtypen nach OMG
2.2.4. Dreidimensionales Modell der generischen Sichten nach Spies
2.2.5. Zwischenfazit bzgl. Visualisierungsmöglichkeiten
2.3. Kennzeichen einer heterogenen IT-Systemlandschaft

3. Bewertungskatalog und Visualisierungsszenarien
3.1. Bewertungsvorgehen
3.2. Abgrenzung zwischen funktionalen und nicht-funktionalen Anforderungen
3.3. Beschreibung der Kriterien für den Bewertungskatalog
3.3.1. Überblick
3.3.2. Funktionale Kriterien für die Visualisierung
3.3.3. Nicht-funktionale Kriterien für die Visualisierung
3.4. Beispiel-Szenarien zur Ergänzung der Auswahlkriterien

4. Marktüberblick und Identifikation einer‚Short List‘
4.1. Übersicht zu Produkten und Hersteller der‚Long list‘
4.2.‚Short List‘
4.3. Kurzüberblick zu ADOit:CE von BOC

5. Zusammenfassung und Ausblick

6. Literaturverzeichnis

Abbildungsverzeichnis

Abb. 1: Kontext-orientiertes Kommunikationsmodell in Anlehnung an Schwittek und Eicker (2010, S. 457)

Abb. 2: Softwaremarkt der BPM-Werkzeuge aus Forrester Report BPM Software (Forrester, 2013, S. 7)

Abb. 3: Übersicht der EAM-Werkzeuge (Forrester_EA, 2013, S. 9)

Abb. 4: Softwarearchitektur-Domänen (Vogel, 2011, S. 405)

Abb. 5: Architekturarten (Schekkerman, 2004, S. 24)

Abb. 6: Architekturprinzipien (Vogel et al., 2011, S. 119)

Abb. 7: Hierarchie der Architekturausprägungen in Anlehnung an Matthes (2011, S. 11)

Abb. 8: Die Entstehung und Nutzung von Architekturfamilien (Masak, 2010, S. 153)

Abb. 9: Das Zachman EA-Framework – ergänzt durch Hanschke (2013, S. 47)

Abb. 10: TOGAF Architecture Development Cycle (The Open Group, 2009, S. 54)

Abb. 11: TOGAF Architecture Repository Structure (The Open Group. 2009, S. 14)

Abb. 12: Umfang einer Enterprise Architecture nach D. Matthes in Anlehnung an Zachman

Abb. 13: Entstehung von Architektur (Toth, 2010)

Abb. 14: Beziehung zwischen den Kernkonzepten von Software-Architektur (Rozanski, 2012, S. 27)

Abb. 15: Von der Unternehmensarchitektur zur IT-Konfiguration (Herden, 2013, S. 27)

Abb. 16: Herausforderungen für Software-Architekten (Hruschka und Starke, 2011, S. 10)

Abb. 17: Sichten in der Software-Architektur (Starke, 2011, S. 16)

Abb. 18: Übersicht des Generischen Sichtenmodells (Spies, 2011, S. 168)

Abb. 19: Konzeptionelle Abgrenzung zwischen Anwendungs-, Informations- und Organisationssystem (vom Brocke et al., 2009, S. 262 in Anlehnung an Teubner,1999, S. 26)

Abb. 20: Integriertes Referenzmodell für die Visualisierung (Schumann und Müller, 2000, S. 21)

Abb. 21: Übersicht EAM-Best-Practice-Visualisierung (eigene Darstellung in Anlehnung an Hanschke, 2013, S. 62 ff.)

Abb. 22: Mapping von Profilen und Daten/Metadaten (Spies, 2011, S. 181)

Abb. 23: 3-D-Entwurf eines Beispielprozesses, der Services und Komponenten (Spies, 2011, S. 195)

Abb. 24: Phasen des Vorgehensmodells zur Softwareauswahl (in Anlehnung an Schütte et al., 2011, S. 62)

Abb. 25: Übersicht zu Aktivitäten, Ergebnistypen und Beteiligten im Softwareauswahlprozess (eigene Darstellung in Anlehnung an Schütte et al. sowie Teich et al.)

Abb. 26: Anforderungsaufnahme und –beschreibung nach Volere (Robertson, 2013, S. 14)

Abb. 27: Arten von nicht-funktionalen Anforderungen (Rupp, 2009, S. 248)

Abb. 28: Ausschnitt „Startseite Modelling Toolkit“ von ADOit

Abb. 29: Ausschnitt „Application Architecture Diagram“ aus Beispieldatenbank von ADOit

Abb. 30: Netzdiagramm zur Bewertung von ADOit (eigene Darstellung)

Tabellenverzeichnis

Tab. 1: Übersicht über Architekturbeschreibungssprachen (in Anlehnung an Vogel, 2011, S. 255 f., Zöller-Greer, 2010, S. 10 ff. und Groene, 2004, S. 17)

Tab. 2: SOA-Klassifizierung nach Heutschi (2007, S. 30 ff.)

Tab. 3: Übersicht zu Vor- und Nachteilen von SOAs (in Anlehnung an Krafzig et al., 2007, S. 251 f. und Martin, 2009, S. 16)

Tab. 4: Stand der SOA-Realisierung (Becker et al., 2011a, S. 191 f.)

Tab. 5: Das service-orientierte Paradigma im Zachman-Framework (Masak, 2007, S. 26)

Tab. 6: Historische Einordnung von SOA im Vergleich zu anderen Architekturen (Becker et al., 2011b, S. 18)

Tab. 7: Existierende Rollen mit SOA-spezifischen Verantwortlichkeiten (Bieberstein et al., 2005, S. 78 f.)

Tab. 8: Neue SOA-Rollen (Bieberstein et al., 2005, S. 80 f.)

Tab. 9: Überblick über wesentliche SWA-Definitionen (eigene Darstellung in Anlehnung an SEI, 2013)

Tab. 10: Auszug zu Begriffen und ihrer Verwendung im konzeptionellen Modell von Architekturbeschreibungen

Tab. 11: Lehman’s acht Gesetze der Softwareevolution (zitiert nach Spies, 2011, S. 125 f.)

Tab. 12: Visualisierungskategorien und ihre Inhalte (in Anlehnung an Diehl, 2007, S. 3 ff.)

Tab. 13: Begriffsabgrenzung bzgl. Visualisierungspipeline-Schritten (in Anlehnung an Diehl, 2007, S. 12 f. sowie Schumann und Müller, 2000, S. 20 ff.)

Tab. 14: Details zu den einzelnen Typen der EAM-Best-Practice-Visualisierungen (in Anlehnung an Hanschke, 2013, S. 66 ff. und Diehl, 2007, S. 5)

Tab. 15: Übersicht über UML-Diagrammtypen

Tab. 16: Bedeutung der Symbole aus 3-D-Entwurf (Spies, 2011, S. 195 f.)

Tab. 17: Mögliche Komponenten einer heterogenen IT-Systemlandschaft (in Anlehnung an Masak, 2010, S. 191 f.)

Tab. 18: Auswertungscluster für Kriterienkatalog (eigene Darstellung)

Tab. 19: Kriterien-Cluster inkl. Verteilung und Priorisierung der Anforderungen als Gesamtsicht (eigene Darstellung)

Tab. 20: Kriterien-Details der Kategorie „1_Funktionale Anforderungen“ (eigene Darstellung)

Tab. 21: Kriterien-Details zu den überwiegend nicht-funktionalen Anforderungen der Kategorien 3 bis einschl. 6 (eigene Darstellung)

Tab. 22: Übersicht Hersteller von Softwareprodukten basierend auf Analysen von Forrester und Gartner

Tab. 23: Übersicht Hersteller von UML-Werkzeugen (oose innovative informatik sowie Eichelberger et al.)

Tab. 24: Verdichtete Bewertungsergebnisse in den Clustern für ADOit

Tab. 25: Detaillierte Bewertungsergebnisse für ADOit

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

Die zunehmende Komplexität der heutigen IT-Systemlandschaften im betrieblichen Umfeld zieht die Notwendigkeit nach sich, durch Visualisierungswerkzeuge Transparenz zu schaffen und Verschlankungspotenziale in der Software-Architektur auch graphisch unterstützt zu generieren.

1.1. Problemstellung

Einer Studie aus dem Jahr 2011 zufolge, die von Becker^[1] und anderen bzgl. Umsetzung und Bewertung des SOA-Konzepts durchgeführt wurde, sind erst eine oder wenige Anwendung(en) durch einen Großteil der Nutzer auf SOA-Basis im produktiven Betrieb implementiert worden. Hinzu kommt, dass der Anteil der Services an der gesamten IT-Landschaft seinerzeit durchschnittlich bei ca. 10 % lag. Neben zunehmenden Agilitätsanforderungen werden vor allem Performanz- und Sicherheitsaspekte als Herausforderungen angesehen. Auch Spies stellt in seiner Dissertation aus 2011 fest, dass „auch bei service-orientierten Architekturen die Komplexität nicht zuletzt durch den Zugewinn an Flexibilität in der Regel noch steigt. Insbesondere auf organisatorischer Ebene und beim Management von service-orientierten Architekturen tragen Charakteristika wie z. B. die geographische Verteilung, Dezentralisierung, emergentes Verhalten, der Mensch als Teil des Systems, ein hoher Integrationsgrad und die kontinuierliche Evolution zu einer erhöhten Komplexität bei.“^[2]

In den sog. „Achsenzeiten“, die laut Jaspers – hier zitiert nach Hüther– „dadurch gekennzeichnet sind, dass die bisher vorherrschende analytische und spaltende Sichtweise durch eine synthetische, das bisher Getrennte nun wieder zusammenfügende Sichtweise, abgelöst wird“^[3], findet ein Wandel der Betrachtungsperspektive statt. Auch in Spies‘ Dissertation zum Modell der generischen Sichten, welches u. a. darauf abzielt, unterschiedliche Stakeholder-Bedürfnisse zusammenzufassen und zu verdichten sowie – nach entsprechender Bearbeitung der Daten und Metadaten - automatisiert in dreidimensionalen Darstellungen kontextspezifisch zu visualisieren, findet sich der Wandel der Betrachtungsperspektive.^[4] Van Buuren et al. haben 2004 aufgezeigt, dass Architekten die Flexibilität benötigen, domänenübergreifende Sichten oder Modelle zu erzeugen. Sie entwickeln dazu ein Modell, indem sie aus bereits existierenden Modellbeziehungen neue explizite Beziehungen komponieren, mit dem Ziel indirekte Beziehungen zwischen den Konzepten formell abzuleiten.^[5] Den Aspekt des Nutzens von Architekturbeschreibungen für Zwecke des Wissenstransfers wird von Dingsøyr und van Vliet^[6] herausgehoben und durch Schwittek und Eicker wie folgt zusammengefasst: „Architecting is a communication intensive task in which the architecture serves as a vehicle for communication among stakeholders. … This shift underlines that communicating a software architecture is a knowledge intensive process, which occurs often during the development of a software architecture and therefore should be considered adequately.”^[7] In Anlehnung an Kienles Dissertation aus dem Jahre 2003 haben Schwittek und Eicker– wie in Abbildung 1 dargestellt - ein kontextorientiertes Kommunikationsmodell abgeleitet, welches in modifizierter Form auch in der Dissertation von Spies Berücksichtigung gefunden hat:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Kontext-orientiertes Kommunikationsmodell in Anlehnung an Schwittek und Eicker (2010, S. 457)

Mit Blick auf die Softwarewerkzeuge, die neben anderen Funktionalitäten auch die Visualisierung der Software-Architektur unterstützen, lässt sich festhalten, dass der Softwaremarkt weiterhin stark umkämpft ist und sich nicht nur durch ein umfangreiches Produktangebot auszeichnet, sondern auch dem Wandel der Funktionalitätsschwerpunkte unterworfen ist – wie Abbildung 2 exemplarisch zu entnehmen ist:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: Softwaremarkt der BPM-Werkzeuge aus Forrester Report BPM Software (Forrester, 2013, S. 7)

Allerdings ist in diesem Zusammenhang zu beachten, dass die Werkzeuge zur Unterstützung des Business Process Management (BPM) nur bedingt für das Management von Enterprise sowie service-orientierten Architekturen geeignet sind, da der funktionale Schwerpunkt von BPM-Suite die Unterstützung und das Management von Geschäftsprozessen beinhaltet.

Abbildung 3 zeigt das aktuelle Ergebnis der Forrester-Untersuchung für EAM-Produkte, deren funktionaler Fokus auf dem Management von Unternehmensarchitekturen liegt:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: Übersicht der EAM-Werkzeuge (Forrester_EA, 2013, S. 9)

Im Einführungshandbuch von Vogel et al. werden die wesentlichen Aspekte von Software-Architektur-Management dargestellt. Aus den Details lässt sich u. a. ableiten, dass die Auswahl des bzw. der Werkzeuge, um Software-Architektur zu visualisieren, vor allem anhand des geplanten Einsatzfeldes bestimmt wird:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4: Softwarearchitektur-Domänen (Vogel, 2011, S. 405)

Der Schnitt des Einsatzfeldes bzw. der Einsatzfelder resultiert aus den jeweiligen Anforderungen und lässt sich jeweils zusätzlich nach den Zielgruppen in geschäfts- bzw. prozessorientierte sowie in technologieorientierte Aspekte zerlegen. Es ist davon auszugehen, dass die technologieorientierte Zielgruppe das Instrument bspw. ITIL-nah für die Administration von Infrastruktur- und Anwendungskomponenten einsetzt.

1.2. Zielsetzung und Aufbau der Arbeit

Im Fokus dieser Masterarbeit steht zunächst ein kurzer Überblick über die begrifflichen Grundlagen. Daran schließt sich die Skizzierung von wesentlichen Vorgehensmodellen zur Darstellung von Software-Architekturen – hier: Zachman und TOGAF an. Darauf aufbauend wird im Hauptteil zunächst das Vorgehen bei einer Softwareauswahl skizziert. Daran schließt sich die Ableitung der Auswahl- und Bewertungskriterien für die Softwareauswahl (hier: aus Sicht eines fiktiven mittelständischen, nicht globalisierten, deutschen Unternehmens) an. Es werden auch Aspekte wie die Möglichkeiten zur Integration in bestehende BPM- bzw. Prozessvisualisierungs- und/oder EAM-Werkzeuge (ARIS, Adonis, iteraplan, etc.) berücksichtigt. Ob und in welchem Umfang Anbieter in der Lage sind, dreidimensionale Software-Architekturen zu visualisieren, wie dies dem Modell der generischen Sichten nach Spies entspricht, wird ebenso in den Bewertungskatalog eingehen. Der Marktüberblick wird anhand von eigenen Recherchen erzeugt und gliedert sich zum einen in EAM-nahe zum anderen in UML-Werkzeuge. Am Ende des Hauptteils wird ein Softwareprodukt (hier: ADOit:CE) exemplarisch in Relation zum Kriterienkatalog gesetzt und einer subjektiven Bewertung unterzogen.

Im abschließenden Fazit werden die erarbeiteten Ergebnisse verdichtet und in Bezug zu den bekannten Forschungsarbeiten gesetzt. Des Weiteren wird Bilanz gezogen zum derzeitigen Stand der Integrationsmöglichkeiten und es werden die Grenzen der Visualisierung im Hinblick auf deren Einsatz in heterogenen IT-Systemlandschaften aufgezeigt.

2. Grundlagen

Im folgenden Abschnitt geht es um die Einordnung und inhaltliche Skizzierung wesentlicher Grundbegriffe, die im Kontext der Betrachtung von Visualisierungsmöglichkeiten heterogener IT-Systemlandschaften von Bedeutung sind.

Ausgehend von der Meta-Sicht der Unternehmensarchitektur (engl.‚enterprise architecture‘) wird der Begriff der Softwarearchitektur in den entsprechenden Zusammenhang gebracht und von anderen Architekturarten wie Geschäfts-, System-, Lösungs-, Datenarchitektur wie auch Infrastruktur abgegrenzt.

Ergänzend wird auf wesentliche Frameworks eingegangen, um den Gesamtzusammenhang und die Abgrenzung zwischen Enterprise und Software-Architekturen sowie die sich daraus ergebenden Betrachtungsperspektiven herauszuarbeiten.

Des Weiteren werden homogene und heterogene Systemlandschaften hinsichtlich ihrer wesentlichen Merkmale skizziert, da dies für die Zusammensetzung des Bewertungskatalogs von Relevanz ist. Ungeachtet dessen sollte ein Bewertungskatalog unternehmens- wie auch projektspezifisch definiert werden, damit die jeweilige Anwendungslandschaft des Unternehmens angemessen berücksichtigt werden kann.

2.1. Architekturen im Rahmen des Informationsmanagements

Um Architekturen im Rahmen des Informationsmanagements näher einordnen zu können, wird zunächst der Architekturbegriff näher beschrieben. Informationsmanagement wird hier im Sinne von Krcmar^[8] als Teilbereich der Unternehmensführung und damit sowohl als Technik- wie auch als Managementdisziplin verstanden.

Daran schließen sich Betrachtungen der Begriffe Unternehmens- und service-orientierte Architektur wie auch Softwarearchitektur an. In diesem Zusammenhang werden Herausforderungen wie das Komplexitätsproblem und das Sichten-Dilemma skizziert.

2.1.1. Architekturbegriffe und -prinzipien

Spies zufolge hat sich aufgrund zahlreicher unterschiedlicher Sichtweisen bis heute noch kein disziplinübergreifendes und einheitliches Begriffsverständnis hinsichtlich des Architekturbegriffs herauskristallisiert.^[9] Nach Abwägen verschiedener Architekturbegriffsauslegungen legt er in seiner Dissertation die Definition des Architekturbegriffs der ISO/IEC (ISO/IEC 42010 IEEE Std 1471-2000 (ISO/IEC und IEEE 2007) zugrunde, die wie folgt lautet: „The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.“^[10] Dieses Begriffsverständnis wird auch dieser Masterarbeit zugrunde gelegt. Weitere Sichtweisen zu Architekturbegriffen werden im Folgenden dargestellt: Schon 2003 grenzte Schekkerman die Architekturarten („types“) wie folgt voneinander ab: „An Enterprise Architecture relates organisational mission, goals, and objectives to business tasks, activities and relations and to the technology or IT infrastructure required to execute them. A System or Solution Architecture relates requirements and the external world to system / solution structures, including both hardware and software, so that the effectiveness of a system design concept can be communicated. A Software Architecture relates requirements, fixed system hardware, and infrastructure (i. e., COTS or GOTS) to software structures in order to demonstrate software effectiveness”.^[11]

Abbildung in dieser Leseprobe nicht enthalten

Abb. 5: Architekturarten (Schekkerman, 2004, S. 24)

Vogel et al. fasst Architekturprinzipien, zu denen u. a. lose Kopplung, Nachverfolgbarkeit, Abstraktion und Modularität zählen, wie folgt zusammen:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 6: Architekturprinzipien (Vogel et al., 2011, S. 119)

Ergänzend zu den obigen Ausführungen stellt Matthes in seinem Werk „EAM Kompendium“ heraus, dass „eine Ordnung und damit die Darstellung bzw. Bildung von Architekturausprägungen durch folgende Aspekte gekennzeichnet“ ist:^[12]

„(a) Eine Zuordnung oder Ordnung hin zu Schichten, Hierarchien oder Modulen kann durch Berücksichtigung des Objekttyps (Daten, Technologien usw.) erfolgen.
(b) Architekturausprägungen können nebeneinander, aufbauend oder auch unabhängig
zueinander angeordnet werden. Dies ergibt sich durch den kontextspezifischen Zusammenhang der erkenntnisrelevanten Objekte ... Horizontale Gliederungen beschreiben dabei meist technische Abhängigkeiten. Vertikale Beziehungen beschreiben die Beeinflussung von geordneten Objekten auf einer Ebene...
(c) Die Ordnung der erkenntnisrelevanten Objekte kann einer bestimmten Betrachtungsintention (Zielsetzung des Betrachters) entsprechen. Im Interesse eines Betrachters werden wesentliche Aspekte hervorgehoben und minder wichtige verkürzt bzw. sogar ausgeblendet.“^[13]

Er zieht die Schlussfolgerung, dass sich alle von ihm untersuchten Architekturbegriffsausprägungen in der folgenden Dreiteilung einig sind, die darin besteht, zwischen „fachlicher, logischer und physischer Schicht“ zu differenzieren.^[14] Um die Abhängigkeiten zwischen den Schichten herauszustellen, führt Matthes zusätzlich eine Darstellung von Krüger und Seelmann-Eggebrecht (2003, S. 28) an, die insbesondere für die Beschreibung der Sicherheitsschicht (=Security Architecture, hier grau hinterlegt) Interdependenzen zur Plattform-, Middleware-Kommunikations-, Integrations-, System- und Komponentenarchitektur aufzeigt und in Abbildung 7 dargestellt ist:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 7: Hierarchie der Architekturausprägungen in Anlehnung an Matthes (2011, S. 11)

Die Interdependenzen zwischen den Schichten stellen nicht nur bei der zweidimensionalen Visualisierung von Sichten, sondern vor allem bei der dreidimensionalen Visualisierung, die von Spies im Modell der generischen Architektursichten entwickelt und beschrieben werden, einen wesentlichen Aspekt für die Abgrenzung der Stakeholder-Bedürfnisse dar.^[15]

Masak stellt die Entstehung von Architekturfamilien als interdependenten Zusammenhang zwischen Referenzarchitektur, Referenzmodell wie auch Architekturstil, Architekturfamilie, Applikations- und Systemarchitektur dar. Er hält fest, dass die Konzepte „alle direkt oder indirekt die entstehende oder vorhandene Architektur (beeinflussen), obwohl die Einflüsse manchmal nicht offensichtlich sind – denn in den meisten Fällen werden die abstrakten Konzepte durch Betrachtung der konkreten Architektur und einer anschließenden Abstraktion abgeleitet“.^[16]

-Architekturstil oder –pattern:
„Eine Beschreibung der Komponententypen und des Musters für ihre Laufzeitkontrolle bzw. des genutzten Datentransfers, in manchen Fällen werden auch Topologien oder Rollen vorgegeben. Ein bekanntes Beispiel eines Architekturstils in der Software ist die Client-Server-Architektur. ... Üblicherweise ist der Architekturstil die höchste Form der Abstraktion des Layouts einer Architektur“.^[17]

- Referenzmodell:
„Unter einem Referenzmodell versteht man die Aufteilung der Funktionalität und der Datenflüsse zwischen den einzelnen Subsystemen. Das Referenzmodell stellt eine „Standardlösung“ zu bekannten Problemen dar, bei dem ein großes Problem in kontrollierbare Teilprobleme (meist identifizierbar mit Subsystemen) zerlegt wird“.^[18]

-Referenzarchitektur:
„Eine Referenzarchitektur ist ein Referenzmodell, welches in Subsysteme abgebildet wird, die kooperativ eine gegebene Funktionalität implementieren. Das Referenzmodell stellt somit die funktionale Dekomposition einer Problemdomäne dar, wohingegen die Referenzarchitektur sich auf die Abbildung dieser Dekomposition auf eine verallgemeinerte Systemdekomposition bezieht. Typische Beispiele für eine Referenzarchitektur in der Softwareentwicklung sind J2EE oder .NET“.^[19]

-Architekturfamilie:
„Die meisten Systeme entstehen nicht als Unikate, sondern freiwillig oder unfreiwillig als Teil einer Produktlinie. Die Produktlinien verfolgen die Idee der strategischen Wiederverwendung von Produkten in einem Marktsegment, entweder innerhalb eines Unternehmens oder in sehr eng verwandten Organisationsformen“.^[20]

-Systemarchitektur:
„Ein System im Sinne der Systemarchitektur ist eine Kollektion von Maschinen, Netzwerken, Kabeln usw. Die Systemarchitektur gibt dieser losen Kollektion eine Struktur und zeigt auf, wie diese mit den Geschäftszielen des Unternehmens verknüpft ist. Die so definierte Systemarchitektur beschäftigt sich ausschließlich mit der Infrastruktur eines Unternehmens“.^[21]

-Applikationsarchitektur:
„Diese wird in den meisten Fällen als Softwarearchitektur bezeichnet und in diversen Büchern ausführlich behandelt. Das Gebiet der Applikationsarchitektur umfasst alle Informationssysteme, welche die Geschäftsprozesse bei ihrer Ausführung unterstützen. Daneben werden technische Prinzipien definiert, die bei der Realisierung der Applikationslandschaft zugrunde zu legen sind. Dazu gehören insbesondere Anforderungen an die Hardware, die Betriebssysteme und die Entwicklungsumgebungen“.^[22]

Abbildung in dieser Leseprobe nicht enthalten

Abb. 8: Die Entstehung und Nutzung von Architekturfamilien (Masak, 2010, S. 153)

Zur Beschreibung von Software-Architekturen können textuelle und/oder graphische Notationen verwendet werden, die über den gesamten Lebenszyklus zur Verwendung kommen können. Aus diesem Grund befasst sich der folgende Abschnitt mit einem kurzen Überblick über Architekturbeschreibungssprachen.

2.1.2. Architekturbeschreibungssprachen (ADLs)

Ergänzend soll an dieser Stelle noch kurz auf Architekturbeschreibungssprachen (engl. architecture description langugages, ADL) eingegangen werden, die vor allem der Beschreibung von Architekturen für bestimmte Zielgruppen wie auch der Dokumentation der Gesamtheit des geplanten Softwareprojekts dienen sollen.^[23]

Zöller-Greer teilt die Architekturbeschreibungssprachen grob in zwei Gruppen auf und zwar in „formale Beschreibungssprachen“ und in „eher grafisch orientierte Spezifizierungen wie sie z. B. durch UML-Diagramme oder ähnliches geleistet wird“.^[24] Da es in dieser Masterarbeit um die Visualisierung von Software-Architektur in heterogenen IT-Systemlandschaften geht, werden demzufolge formale ADL kurz skizziert, aber aus der Betrachtung der Bewertungskriterien ausgeklammert. Auf dreizehn Diagrammtypen des UML, die als Visualisierungskriterien im zweidimensionalen Raum herangezogen werden können, wird in Abschnitt 2.2.3 eingegangen.

Nach Vogel und Zöller-Greer lassen sich neben UML u. a. folgende ADL unterscheiden:

Abbildung in dieser Leseprobe nicht enthalten^[25]

Tab. 1: Übersicht über Architekturbeschreibungssprachen (in Anlehnung an Vogel, 2011, S. 255 f., Zöller-Greer, 2010, S. 10 ff. und Groene, 2004, S. 17)

Bzgl. FMC liegt laut Groene die Vorstellung zugrunde, „zuerst die Struktur des gewollten Systems mittels Aufbaumodellen darzustellen, und danach die Implementierung, also die Umsetzung in Hardware, Software und Infrastruktur zu betrachten“^[26], was „die Aufbaumodelle dadurch abstrakter, da weiter von der Implementierung entfernt“^[27], gestaltet. Hruschka und Starke vertreten bezüglich FMC die Auffassung, dass „FMC die Grundidee unterschiedlicher Sichten“^[28] enthält, allerdings ist die „Kombination der FMC-Notationen mangels passender Werkzeuge für praktisch schwer einsetzbar“^[29].

2.1.3. Unternehmensarchitekturen und -rahmenwerke

Spies^[30] zeigt in seiner Dissertation auf, dass der Begriff Unternehmensarchitektur (engl.‚enterprise architecture‘) „in Wissenschaft und Praxis weiter verbreitet“ ist und zählt dazu unter anderem Ferstl und Sinz^[31], Lankhorst^[32] wie auch Dern^[33], Keller^[34] und Zachman^[35] auf. Des Weiteren verweist Spies auf Aier et al.^[36], die 2008 einen Literaturüberblick geschaffen haben, der u. a. auch „die Unterschiede und Gemeinsamkeiten in Literatur und Praxis“ aufzeigen.^[37] In Anlehnung an die Ausführungen von Spies und unter Zugrundelegung der Begriffsauffassung von Lankhorst aus 2009 soll auch in dieser Arbeit unter Unternehmensarchitektur „a coherent whole of principles, methods, and models that are used in the design and realisation of an enterprise’s organisational structure, business processes, information systems, and infrastructure“ verstanden werden.^[38]

Ergänzend – zwecks Überleitung zum Visualisierungsaspekt – wird auf die Begriffsauffassung von Goikoetxea verwiesen, der unter Unternehmensarchitektur die folgenden Gesichtspunkte zusammenfasst: “An Enterprise Architecture (EA) is a set of business and engineering artefacts, including text and graphical documentation, that describes and guides the operation of an enterprise-wide system, including instructions for its life cycle operation, management, evolution, and maintenance. [...]”^[39]

Hanschke dahingegen bezieht sich bei der Abgrenzung des Begriffs Unternehmensarchitektur auf eine praxisorientierte Begriffsauslegung und grenzt die Inhalte wie folgt ab: „Enterprise Architecture Management (EAM) liefert das inhaltliche Fundament für das operative und strategische Management der IT. In der Unternehmensarchitektur werden die wesentlichen fachlichen und IT-Strukturen eines Unternehmens grobgranular gesammelt und miteinander in Beziehung gesetzt. Auf dieser Basis kann das vielfältige Informationsbedürfnis der verschiedenen Stakeholder-Gruppen befriedigt und fundierter Input für Entscheidungen und die strategische Planung und Steuerung der IT bereitgestellt werden“.^[40] Angemessene Granularität wie auch eine adäquate Wahl der Visualisierungsinstrumente unterstützen somit bei einer zielgerichteten Beantwortung der Fragestellungen der verschiedenen Stakeholder.

Mit Blick auf die historische Bedeutung von Zachman’s EA-Framework^[41] aus dem Jahr 1987, welches sich als grundlegendes Rahmenwerk für‚Enterprise Architectures‘ versteht und dessen elementarer Bestandteil die Zachman-Matrix^[42] ist, die John A. Zachman 1992 zusammen mit John F. Sowa erweiterte^[43], hat sich der Begriff „Unternehmensarchitektur“ bzw. Enterprise Architecture etabliert. Ziel des Rahmenwerkes war „die Bereitstellung von Beschreibungskonzepten, die geeignet sind, die vielfältigen Schnittstellen von Komponenten eines Informationssystems sowie deren Integration in die Organisation darzustellen“.^[44] Die Übersicht von Hanschke zeigt auf, mit welchen zweidimensionalen Visualisierungselementen– hier: eingebettet in die Zachman-Matrix - Unternehmensarchitekturen dargestellt werden können:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 9: Das Zachman EA-Framework – ergänzt durch Hanschke (2013, S. 47)

Ausgehend von Zachman, der bereits Mitte der 1980er Jahre erkannte, „dass die verschiedenen Beteiligten individuelle Anforderungen an die Art der Arbeitsmittel stellen, um so das Vorhaben effektiv zu unterstützen...“^[45] und damit „das Prinzip der unterschiedlichen Sichtweisen auf ein System“^[46] einführte, entwickelten sich im Laufe der Zeit verschiedene Rahmenwerke mit unterschiedlichen Zielsetzungen, da sie teilweise militärischen teilweise betriebswirtschaftlichen Ursprungs gewesen sind, um verschiedene Zielgruppen zur Beschreibungen von Unternehmensarchitekturen zu erreichen.

In seinem EA Kompendium gibt Matthes dazu einen weit gefassten Überblick und stellt jeweils eine kurze Beschreibung zu den aus seiner Sicht wichtigsten Rahmenwerken, ohne allerdings auf Aspekte der Visualisierung von Software-Architekturen näher einzugehen. Im Folgenden sind einige der beschriebenen und bekannten Modelle in alphabetischer Reihenfolge aufgelistet:^[47]

- ARIS von IDS Scheer/Software AG
- ArchiMate von OMG
- ATAM
- E2AF
- EAF von Gartner
- IAF von CapGemini
- ISO42070-2007/IEEE1471-2000
- MDA
- TOGAF
- Zachman

Im Folgenden wird im Rahmen dieser Masterarbeit nur auf TOGAF eingegangen, da dieses laut Hanschke^[48] inzwischen eines der bekanntesten und am weitesten verbreitete EA-Framework ist und Anfang 2009 in Form der Version 9 aktualisiert wurde. Des Weiteren stellt Hanschke diesen als „einen methodischen Rahmen und einen Werkzeugkasten für die Entwicklung unterschiedlicher Unternehmensarchitekturen“ vor.^[49]

Dabei wird „die Erstellung einer konkreten Unternehmensarchitektur auf der Basis einer Beschreibung von vordefinierten Komponenten (‚Building Blocks‘) und mithilfe eines Vorgehensmodells unterstützt, die sich in die vier „Teilarchitekturen“ Business Architecture, Technology Architecture sowie Data und Application Architecture zerlegen lässt, wobei sich die beiden Letztgenannten zur Information System Architecture zusammenfassen lassen.^[50] Hanschke folgend kann TOGAF „den gesamten Lebenszyklus einer Unternehmensarchitektur“ abbilden, denn es unterstützt eine gute Dokumentation des Entwicklungsprozesses für Unternehmensarchitekturen, in dem „Referenzbeschreibungen und der Beschreibungen von Komponenten“ gesammelt werden, die in Version 9 zwar durch SOA- und Sicherheitsaspekte ergänzt werden, allerdings keine konkreten Anleitungen für Visualisierungen oder den Bebauungsplan liefern.^[51]

Dennoch lässt sich festhalten, dass insbesondere die folgenden Elemente haben einen deutlichen Bezug zu Software-Architektur und deren Gestaltung aufweisen:

-PART IV: Architecture Content Framework
-PART V: Enterprise Continuum & Tools
-PART VI: TOGAF Reference Models
-PART VII: Architecture Capability Framework

Das Architecture Content Framework (PART IV) zeichnet sich durch „ein detailliertes Modell der Ergebnistypen für die (Weiter-)Entwicklung der Unternehmensarchitektur“ aus und „liefert ein detailliertes Meta-Modell und eine klare Definition und Beschreibung“^[52], denn es besteht aus „einem Core Content Metamodel (...) und Erweiterungen für Governance-Aspekte, Services, Prozessmodellierung, Datenmodellierung, Infrastrukturkonsolidierung und Motivationsaspekten“.^[53]

Demgegenüber ist PART V (Enterprise Continuum & Tools) „eine Sammlung von Referenzbeschreibungen in Form von grafischen Modellen und Textdokumenten“, da es „aus dem Architecture Continuum und Solution Continuum” besteht, welche wiederum “Hilfsmittel für die Strukturierung der Unternehmensarchitektur, ein Architecture Repository sowie Tools für die Entwicklung der Unternehmensarchitektur“^[54] beinhalten und für die Ablagen von verschiedenartigen Architekturergebnissen geeignet sind.

„Das Architecture Repository beinhaltet neben dem Architecture Metamodel und der Architecture Capability insbesondere die Architecture Landscape, die Standards Information Base (SIB), die Reference Library und den Governance Log“.^[55]

[...]

---

^[1] Becker et al., 2011a, S. 187 ff.

^[2] Spies, 2011, S. 2

^[3] Hüther, 2013, S. 10

^[4] In Anlehnung an Spies, 2011, S. 224

^[5] Van Buuren et al., 2004, S. 40

^[6] Dingsøyr et al., 2009, S. 1-7

^[7] Schwittek et al., 2010, S. 457

^[8] Krcmar, 2009, S. 26

^[9] Spies, 2011, S. 21 ff.

^[10] ISO/IEC, 2007, S. 3

^[11] Schekkerman, 2003, S. 23 f.

^[12] Matthes, 2011, S. 10

^[13] Matthes, 2011, S. 10

^[14] Matthes, 2011, S. 10

^[15] Spies, 2011, S. 21 ff.

^[16] Masak, 2010, S. 151 ff.

^[17] Masak, 2010, S. 151

^[18] Masak, 2010, S. 151

^[19] Masak, 2010, S. 152

^[20] Masak, 2010, S. 152

^[21] Masak, 2010, S. 153 f.

^[22] Masak, 2010, S. 154

^[23] Zöller-Greer, 2010, S. 10 f.

^[24] Zöller-Greer, 2010, S. 10

^[25] Groene, 2004, S. 17

^[26] Groene, 2004, S. 18

^[27] Groene, 2004, S. 18

^[28] Hruschka /Starke, 2011, S. 91

^[29] Hruschka/Starke, 2011, S. 91

^[30] Spies, 2011, S. 23

^[31] Ferstl/Sinz, 2013, S. 419 ff.

^[32] Lankhorst, 2009, S. 3

^[33] Dern, 2009, S. 32

^[34] Keller, 2012, S, 19 ff.

^[35] Zachman, 1987, S. 276 ff.

^[36] Aier et al., 2008, S. 292 ff.

^[37] Spies, 2011, S. 23 f.

^[38] Lankhorst, 2009, S 3

^[39] Goikoetxea, 2007 S. 2

^[40] Hanschke, 2012, S. 45 f.

^[41] Zachman, 1987, S. 276 ff.

^[42] Spies, 2011, S. 24

^[43] Sowa, 1992, S. 590 ff.

^[44] Hanschke, 2013, S. 47

^[45] MatthesD, 2011, S. 17

^[46] MatthesD, 2011, S. 17

^[47] MatthesD, 2011, S. 37 ff.

^[48] Hanschke, 2012, S. 48

^[49] Hanschke, 2012, S. 48

^[50] Hanschke, 2012, S. 48

^[51] Hanschke, 2012, S. 51

^[52] Hanschke, 2012, S. 49 f.

^[53] Hanschke, 2012, S. 49 f.

^[54] Hanschke, 2012, S. 50

^[55] Hanschke, 2012, S. 50