Dokumentation, Methoden und Prozesse von Softwarearchitekturen in agilen Projekten

Inhaltsverzeichnis

1 Einleitung
1.1 Problemstellung und Motivation
1.2 Aufbau der Arbeit

2 Unternehmen und Projektumfeld
2.1 Die Daimler AG
2.2 Die Abteilung ITS/GR
2.3 Die Abteilung GSP/ORP
2.4 Technische Pakete: Projekt „TecPac“

3 Grundlagen
3.1 Klassische Softwareentwicklung
3.1.1 Wasserfallmodell
3.1.2 V-Modell
3.2 Agile Software-Entwicklung
3.2.1 Allgemeines zum agilen Vorgehen
3.2.2 Scrum
3.2.3 Anpassungen im Projekt „Technische Pakete“
3.3 Software-Architektur
3.3.1 Begriff der Architektur
3.3.2 Der Software-Architekt
3.3.3 Enterprise Architecture (Management)
3.4 Grundlagen zur Dokumentation
3.4.1 Anforderungen an die Dokumentation
3.4.2 Sichten
3.4.3 Einheitliche Notation mit UML 2.0
3.5 Bewertung von Architekturen
3.5.1 Allgemeines zu Bewertungsmodellen
3.5.2 Architecture Tradeoff Analysis Method
3.6 Architekturframework und -Standards
3.6.1 Zachmann-Framework
3.6.2 IEEE Std 1471-2000
3.6.3 TOGAF
3.6.4 Arc42
3.7 Standards der Daimler AG
3.7.1 HoustonIT und das HBSG+B
3.7.2 Daimler Architektur-Standard: PAI

4 Dokumentation der Architektur im Projekt „TecPac“
4.1 Eine Roadmap über die Vorgehensschritte der Arbeit
4.2 Die Tools und Plattformen der Architekturdokumentation
4.2.1 Rational DOORS als Standardtool für die Dokumentation
4.2.2 Microsoft SharePoint 2010 als Projektplattform
4.3 Anforderungen an die Architekturdokumentation in „TecPac“
4.4 Erstellung einer Matrix für die Stakeholder der Architektur
4.4.1 Identifizierung der Stakeholder
4.4.2 Bereiche der Architektur
4.4.3 Nutzen und Verwendung der Architektur-Dokumentation
4.4.4 Unterscheidung von Detaillierungsstufen
4.4.5 Bestimmung des Dokumentationsangebots
4.4.6 Ableiten der spezifischen Dokumente
4.5 Integration von HoustonIT in das arc42-Template
4.6 Der Umgang mit redundanten oder fehlenden Informationen
4.7 Architekturdokumentation anhand eines Beispiels in DOORS
4.7.1 Erstellung eines Print-Moduls
4.7.2 Anlegen von speziellen Views durch Attribute und Filter
4.7.3 Konfiguration des Druck-Moduls
4.8 Die Prozesssicht der Architekturdokumentation

5 Fazit und Schlussbetrachtung

Verzeichnis der Anlagen

Literaturverzeichnis

Danksagung

An dieser Stelle möchte ich meine Danksagung an alle Personen meines Umfelds richten, die mich wesentlich und bedeutend bei der Ausfertigung dieser Arbeit unterstützt haben.

Ein besonderer Dank gilt meinem unternehmensseitigen Betreuer Dr. Harald Gurres für die Bereitstellung und Konkretisierung des Themas sowie der tatkräftigen Unterstützung und kritischen Würdigung bei der Ausarbeitung.

Des Weiteren möchte ich mich bei meinem Hochschulbetreuer Prof. Dr. Frank Morelli für die umfangreiche Beantwortung zahlreicher inhaltlicher und formaler Fragen bedanken.

Meinem Vater Heinz Kreuz möchte ich ebenfalls in ganz besonderem Maße danken. Seine liebevolle, moralische und finanzielle Unterstützung ermöglichte mir das Studium an der Hochschule Pforzheim und damit auch die vorliegende Abschlussarbeit.

Eine letzte Danksagung möchte ich meinem besten Freund und Seelenverwandten Sedat Bizik aussprechen, der mich privat und beruflich jederzeit mit allen Mitteln motiviert und unterstützt.

Abbildungsverzeichnis

Abbildung 1: Aufbau der Abteilung ITS/GR

Abbildung 2: Zusammenspiel der Systeme im Projekt „TecPac“

Abbildung 3: Schematischer Ablauf des Wasserfallmodells

Abbildung 4: Schematischer Ablauf des V-Modells

Abbildung 5: Der Scrum-Zyklus im Überblick

Abbildung 6: Übersicht über die vier wichtigsten Sichten

Abbildung 7: Strukturelle Darstellung von UML

Abbildung 8: Ablauf des ATAM-Verfahrens

Abbildung 9: Aufbau eines 'Utility Trees'

Abbildung 10: Das Zachmann Enterprise Architecture Framework

Abbildung 11: Konzeptionelles Modell der Architekturbeschreibung

Abbildung 12: Struktur von TOGAF

Abbildung 13: Struktur der arc42-Vorlage in der Version 6.0

Abbildung 14: Übersicht über die neun Knowledge Areas von Houston

Abbildung 15: Architektur einer integrierten Anwendungsplattform

Abbildung 16: Übersicht über die Schritte der Arbeit

Abbildung 17: Übersicht der Anforderungen an die Dokumentation im Projekt

Abbildung 18: Struktur und Navigation in DOORS

Abbildung 19: Filterung der Inhalte

Abbildung 20: Ansicht des Druckmoduls mit Parametern

Abbildung 21: Darstellung eines Hilfsmoduls mit Inhalt

Abbildung 22: Der Oberprozess der Architekturdokumentation

Abbildung 23: Der Teilprozess ‚Anforderungen & Randbedingungen klären‘

Abbildung 24: Der Teilprozess 'Strukturen entwerfen' und 'Technische Konzepte entwerfen'

Abbildung 25: Der Teilprozess 'Architektur kommunizieren' und ‚Umsetzung begleiten‘

Abbildung 26: Der Teilprozess 'Architektur bewerten'

Tabellenverzeichnis

Tabelle 1: Die vier Prinzipien des agilen Manifests

Tabelle 2: Beispielhafter Ausschnitt aus der Stakeholderliste

Tabelle 3: Erweiterung der Stakeholder-Matrix um die Architekturbereiche

Tabelle 4: Erweiterung der Stakeholder-Matrix um die Nutzung

Tabelle 5: Erweiterung der Stakeholder-Matrix um die Granularität

Tabelle 6: Abdeckung zwischen Dokumenttypen und Architekturbereiche

Tabelle 7: Ableitung spezifischer Dokumente

Tabelle 8: Gesamtergebnis der Auswertung aller Stakeholder

Tabelle 9: Analyse der inhaltlichen Abdeckung des LGG: ‚AW-Architektur‘

Tabelle 10: Analyse der inhaltlichen Abdeckung des LGG: ‚Systemarchitektur‘

Tabelle 11: Ergebnis verschiedener Ablageorte von Architekturdokumentation

Tabelle 12: Einordnung der Verwendungsarten in den Prozess

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

1.1 Problemstellung und Motivation

Die Softwareentwicklung^[1] im Allgemeinen ist alles andere als ein abgeschlossenes Handwerk, welches sich mit dem sturen Befolgen festgelegter Strukturen und Vorgehensweisen beschäftigt. Das Gegenteil ist der Fall. Mit der zunehmenden Globalisierung und dem damit einhergehenden Druck in Sachen Qualität und Effizienzsteigerung gewinnt die Entwicklung neuer Technologien, Methoden und Werkzeugen mehr denn je an Bedeutung. Hinzu kommt, dass unternehmens- und branchenübergreifende Wertschöpfungsketten zunehmend komplexer werden, was es ebenfalls zu bewerkstelligen gilt. Die Unternehmen jeglicher Branche sind damit angewiesen, die Effizienz ihrer Geschäftsprozesse kontinuierlich zu steigern und an dynamischen Gegebenheiten anzupassen.^[2] In diesem Zusammenhang bekommt die Informationstechnik eine tragende Rolle, da sie maßgeblich zur Gestaltung und Umsetzung dieser Anforderungen beiträgt, insbesondere durch software-technische Unterstützung. Innerhalb der Softwaretechnik existiert eine Vielzahl unterschiedlicher Teilgebiete, die allesamt auf die erfolgreiche Planung, Entwicklung und Wartung von Software abzielen. Neben den Kernprozessen der Spezifikation, Planung, Entwurf, Implementierung, Validierung und Wartung existieren weitere, begleitende Themen. Als Beispiel seien die Aspekte des Projekt- und Qualitätsmanagements sowie die Dokumentation in allen Phasen genannt.^[3] Letzteres stellt im Zusammenhang mit Softwarearchitekturen den Kernaspekt der Arbeit dar.

Auf die Bedeutung von Software-Architekturen, insbesondere ihrer Dokumentation, wird im Verlauf der Arbeit noch präzise eingegangen. Vorab kann jedoch vermittelt werden, dass es sich um ein Thema handelt, welches einerseits häufig als unbequeme Nebensache „unter den Tisch fällt“, andererseits jedoch weitreichende oder gar fatale Konsequenzen mit sich bringt, sofern dem Thema nicht genügend Beachtung geschenkt wird.^[4] Um dies zu verhindern, ist ein strukturierter und methodisch geprägter Umgang mit der Dokumentation von elementarer Wichtigkeit.^[5] Insbesondere unter der Prämisse eines agilen Vorgehensmodells, welches durch kurze, iterative Entwicklungszyklen geprägt ist und damit zusätzliche Anforderungen mit sich bringt. Mit der Dokumentation sollte zudem ein bestimmter Zweck verfolgt werden. Im Idealfall ist dieser bereits vor Projektbeginn definiert und entsprechend unter den Projektbeteiligten kommuniziert, was in der Praxis jedoch nur selten Beachtung findet.^[6]

Dies wirft konsequenterweise die Frage auf, wie die Dokumentation von Softwarearchitekturen in agilen Projekten strukturiert und zielgerichtet gestaltet werden kann. Damit lassen sich verschiedene Überlegungen verknüpfen. Als wichtigen Schritt könnte sich eine Vorüberlegung herausstellen, welche auf die unterschiedlichen Interessen der Projektbeteiligten eingeht. Damit könnte gewährleistet werden, dass die Dokumentation in einem überschaubaren Maße gehalten wird und somit schließlich zweckerfüllend ist. Weiterhin könnte es sinnvoll sein, bereits vorhandene Architekturframeworks als Werkzeug bei der Gliederung verschiedener Architekturthemen zu Rate zu ziehen oder gar zu übernehmen. Auf dem Markt existieren zu diesem Zweck bereits verschiedene Ablage- und Bearbeitungstools, die sich ebenfalls als hilfreiche Unterstützung bei der Dokumentation herausstellen könnten. Im Idealfall erlauben diese Erkenntnisse zudem, die Dokumentation unter prozessualen Aspekten zu beleuchten. Damit wäre es möglich, verschiedenen Aufgaben und Tätigkeiten in einer zeitlich-logischen Abfolge zu visualisieren.

Diese Fragestellungen lassen sich jedoch nicht pauschal beantworten. Vielmehr bedarf es einer eingehenden Analyse der vorliegenden Projektgegebenheiten, die es letztlich überhaupt ermöglichen Handlungsempfehlungen auszusprechen.

1.2 Aufbau der Arbeit

Die vorliegende Arbeit umfasst in Summe fünf Kapitel, die sich über einen theoretischen und einen praktischen Teil erstrecken. Die theoretischen Grundlagen dienen dabei als fundamentierte Basis der Untersuchung und Bearbeitung innerhalb des praktischen Teils.

Das zweite Kapitel liefert den Einstieg in die Theorie und beinhaltet eine kurze Vorstellung des Unternehmens, der relevanten Abteilungen sowie dem Projekt „technische Pakete“, auf dessen Basis das Thema der Arbeit letztlich entstand.

Kapitel drei geht auf die fachlichen Grundlagen von Vorgehensmodellen und Softwarearchitekturen ein. Hierfür werden verschiedene Themen betrachtet. Neben begrifflichen Abgrenzungen und der Ausprägung von Architekturen werden zudem Bewertungsmethoden und Dokumentationsgrundlagen angesprochen und erläutert. Nicht zuletzt folgt die Betrachtung verschiedener Rahmenwerke, die sich im Architekturbereich bereits etabliert haben. Das Kapitel schließt daraufhin mit der Vorstellung unternehmensinterner Vorgaben und Standards ab.

Der praktische Teil der Arbeit beginnt mit dem vierten Kapitel. Nach einer kurzen Übersicht der wesentlichen Bearbeitungsschritte, folgt die Definition der Dokumentationsziele sowie einer Kurzvorstellung der projektseitig vorgegebenen und verwendeten Tools. Im weiteren Verlauf wird auf die Identifizierung und Ableitung von Interessen der Stakeholder eingegangen. Die Ergebnisse fungieren dabei als Basis weiterer Untersuchungen. Daraufhin folgt die Überprüfung eines gewählten Frameworks hinsichtlich der Verwendungsmöglichkeiten im Projekt „technische Pakete“. Dabei werden die unternehmensseitigen Standards hinsichtlich ihrer Integration in das Rahmenwerk analysiert und ausgewertet. Aufgrund der Verwendung unterschiedlicher Tools ist es zudem erforderlich, die bereits vorhandene Dokumentation auf Lücken und Redundanzen zu überprüfen. Im Anschluss wird ein vollständiger Dokumentationsauszug anhand eines vorgegebenen Tools erstellt und erläutert, bevor das Kapitel letztlich mit einer prozessualen Betrachtung abschließt.

Das fünfte Kapitel beinhaltet das Fazit des Autors auf Basis der (Teil-)Ergebnisse im vierten Kapitel. Der Erkenntnisgewinn liefert daneben einen Ausblick auf zusätzliche Aspekte und Weiterentwicklungsmöglichkeiten.

2 Unternehmen und Projektumfeld

2.1 Die Daimler AG

Die Daimler AG, mit Hauptsitz in Stuttgart, ist mit rund 280.000 Mitarbeitern einer der größten und traditionsreichsten Automobilhersteller der Welt. Die bekannteste Marke stellt dabei Mercedes Benz dar. Die Gründer der Firma waren Gottlieb Daimler und Carl Benz, die durch die Erfindung des Automobils im Jahre 1886 Geschichte schrieben.

Derzeit investiert die Daimler AG bei der Entwicklung neuer Antriebe in den Hybrid-, Elektromotor sowie in die Brennstoffzelle mit dem Ziel, langfristig emissionsfreies Fahren zu ermöglichen. Insgesamt verfügt die Daimler AG über die folgenden Geschäftsbereiche:

- Mercedes-Benz Cars
- Daimler Trucks
- Mercedes-Benz-Vans
- Daimler Buses
- Financial Service AG^[7]

2.2 Die Abteilung ITS/GR

Die Abteilung ITS/GR (Aftersales Dokumentation Retail) ist eine IT-Abteilung der Daimler AG in Fellbach. Diese ist zuständig für die Projekte und Systeme zur weltweiten Erstellung der Teile-, Service-, Retail- und Zeitensysteme. Dahingehend plant, entwickelt und betreut die Abteilung IT-Systeme für den Fachbereich GSP/OR (Global Service & Parts). ITS/GR besteht aus fünf Teams, welche die jeweiligen Systeme des ihnen zugeordneten Themengebietes betreuen (Vgl. Abbildung 1).^[8]

Abbildung 1: Aufbau der Abteilung ITS/GR

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung in Anlehnung an Daimler AG (2013a)

2.3 Die Abteilung GSP/ORP

Die Abteilung GSP/ORP ist der zugehörige Fachbereich im Projektumfeld Technische Pakete, der für die Erstellung der Dokumentation des Systems EPC verantwortlich ist. Die Gestaltung von Methoden und Prozessen für integrierte Teileinformationen stellt dabei einen Hauptbestandteil dar. Neben der Einführung eines Product-Lifecycle-Managements im Aftersales-Sektor verantwortet der Fachbereich zudem die Administration des Datenmanagements sowie die kontinuierliche Weiterentwicklung von Methoden, Prozessen und Systemen.^[9]

2.4 Technische Pakete: Projekt „TecPac“

Mit einem technischen Paket ist eine Sammlung von Daten (Teilen, Arbeiten, Zeiten) gemeint, die durch das Zusammenspielen mehrerer Systeme zusammengeführt werden und in die Werkstattsysteme einfließen. Diese Pakete werden für die Systeme in den Werkstätten erstellt, welche für die KFZ-Mechaniker zur Verfügung stehen, um dem Kunden letztlich Kostenvoranschläge anhand dieser Daten zu erstellen.

Bislang sind die Daten über die voneinander unabhängigen Erstellketten Cebacus-SPPS- und ELDAS-Retas bereitgestellt. Jedoch besteht eine starke Abhängigkeit vom Datenlieferanten Cebacus, da sich das Autorentool und der Erstellprozess vollständig im Besitz dieser Firma befindet, was die eigenverantwortliche Erstellung technischer Pakete. Zudem ist das daimlerinterne Tool ELDAS stark veraltet und wird in den nächsten Jahren abgelöst. Aus diesen Gründen soll hierzu im Rahmen dieses Projektes ein TecPac-Tool für die technische Paketerstellung entstehen, das eine Planungskomponente enthält, um eine anschauliche und übersichtliche Beauftragung von Überarbeitungen und neue Erstellung im System zu ermöglichen. Das System enthält mitunter Stammdaten, um die Richtigkeit der Werte nach erfolgter Zuordnung sicherzustellen.

Folgende Ziele werden mit diesem Autorentool verfolgt:

- Vereinfachung der Auftragserstellung für häufig wiederkehrende Wartungs- und Reparaturarbeiten auf Händlerebene.
- Ermöglichung von Festpreisangaben für schnelle und sichere Preisauskunft.
- Unterstützung von Marketingkampagnen.
- Ablösung der Datenlieferantenabhängigkeit.

Das Projekt wird in mehreren Stufen agil umgesetzt, wodurch die ersten Teilprodukte schon sehr früh geliefert und getestet werden und Fortschritte zum Thema Pakete und Anforderungen schnell sichtbar sind (Vgl. Kapitel 3.2).

Stufe 1a:

In der ersten Stufe geht es hauptsächlich um die Entwicklung des TecPac-Tools. Der Inhalt an sich ist mehrsprachig, während die Benutzeroberfläche nur einsprachig sein muss. Des Weiteren wird das Datenmodell aktualisiert um SPPS- und Retas-Pakete aufnehmen zu können. Die Pakete werden nun den Gültigkeiten zugeordnet, was die ursprüngliche Mehrfachdokumentation vermeidet. Die Schnittstelle zu den Nachbarsystemen wird zudem standardisiert. Zunächst wird ein SPPS-Adapter erstellt, der für Export von Daten an SPPS zuständig ist. Mit der Migration der Cebacus-Daten wird die Schnittstelle Cebacus – SPPS abgelöst. Das Zusammenspiel der Systeme ist in Abbildung 2 dargestellt.

Abbildung 2: Zusammenspiel der Systeme im Projekt „TecPac“

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Daimler AG (2012c), S. 179.

EWA dient online als Informationslieferant zur Feststellung der Paketdaten und umfasst alle Werkstattinformationssysteme.

Stufe 1b:

In dieser Stufe werden sowohl das Datenmodell, als auch die einzelnen Schnittstellen angepasst. Die ELDAS Daten werden in TecPac migriert und mit Hilfe des Retas-Adapters wird die ELDAS-Schnittstelle abgelöst. Während der Migration wird überprüft, welche die importierten Retas-Pakete mit Paketen gleicher Arbeit verbindet, was die Qualität erheblich verbessert.

Weiterhin stellt das Tool Pakete über die SPPS- und Retas-Schnittstelle bereit. Damit werden angebundene Schnittstellen, wie PUE, DC-Repa und Primus mit unterschiedlichen Daten versorgt. PUE liefert Gültigkeitsinformationen und die Produktübersicht, Primus liefert die Teilersetzungen und DC-Repa die entsprechenden Arbeiten.^[10]

3 Grundlagen

3.1 Klassische Softwareentwicklung

3.1.1 Wasserfallmodell

Das Wasserfallmodell wurde eigens von J. Royce in den 1970er Jahren veröffentlicht und stellt somit das älteste Verfahren unter den Projektmanagementmethoden dar. Der Projektablauf ist strikt sequenziell, weshalb es in der Praxis nur noch in bestimmten Gebieten Anwendung findet. Die einzelnen Schritte des Softwarelebenszyklus sind in Form eines Wasserfalls dargestellt, was letztlich der Grund für die Namensgebung ist. Die einzelnen Phasen der Methode werden sequenziell durchlaufen (Vgl. Abbildung 3). Die Freigabe einer neuen Phase verlangt den vollständigen Abschluss der vorherigen. Mittels Verifikationen wird die Erreichung der geforderten Qualität überprüft. Im Falle einer gescheiterten Validierung kann die vorherige Phase erneut durchlaufen werden.

Abbildung 3: Schematischer Ablauf des Wasserfallmodells

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Schatten (2010), S. 49.

Das Wasserfallmodell kann bei strikten Anforderungsvorgaben und Abläufen eingesetzt werden, da die Planbarkeit durch die deutlich abgegrenzten Phasen im Vordergrund steht. Aufgrund der beschränkten Flexibilität sollte das Modell zum Zweck einer frühen Fehlererkennung und -behebung vermieden werden. Durch den sequentiellen Ablauf erhält der Kunde die Lösung gegen Ende des Projektes, was dazu führt, dass dieser erst im Nachhinein feststellen kann, ob das Produkt tatsächlich seinen Wünschen entspricht. Zu diesem Zeitpunkt jedoch können keine grundlegenden Änderungen mehr getätigt werden. Das Modell ist aufgrund flexiblerer Entwicklungsmodelle beinahe vollständig verdrängt worden.^[11]

3.1.2 V-Modell

Eine Erweiterung des Wasserfallmodells stellt das V-Modell dar. Ein wesentlicher Unterschied besteht darin, dass sowohl Test, Wartung als auch die Weiterentwicklung Bestandteile des Vorgehens sind. Zudem trennt das V-Modell den Entwicklungsprozess in eine analytische und synthetische Phase, was zu dem charakteristischen „V“ führt (Vgl. Abbildung 4).

Abbildung 4: Schematischer Ablauf des V-Modells

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Schatten (2010), S. 50.

Innerhalb der analytischen Phasen wird die Spezifikation mit jedem Schritt detaillierter, bis hin zur Komponentenebene. Daraufhin beginnt in der synthetischen Phase die Umsetzung der Komponenten. Diese geschieht schrittweise, bis die Lösung schließlich vollständig umgesetzt ist. Zusätzlich findet nach jeder Phase ein Review statt. Dieser Schritt muss zwingend durchlaufen werden, um die Qualität der Phase bewerten zu können. Damit wird die frühzeitige Entdeckung und Behebung von Fehlern ermöglicht. Das V-Modell ist wie das Wasserfallmodell hauptsächlich in Projekten mit strikten Anforderungen und Abläufen einsetzbar. Die Systematik dieses Verfahrens ermöglicht eine strukturierte Planung und Durchführung, weshalb es heute noch in Projekten des öffentlichen Bereichs bevorzugt wird.^[12]

3.2 Agile Software-Entwicklung

3.2.1 Allgemeines zum agilen Vorgehen

Agile Softwareentwicklung ist ein iteratives Verfahren mit häufigen Rückkopplungen auf den Ebenen Entwicklung, Team und Management. Ein großer Unterschied zu klassischen Methoden besteht darin, dass die zu entwickelnde Software nicht im Voraus schon detailliert durchgeplant wird. Stattdessen nutzt man die Erkenntnis, dass sich Anforderungen im Laufe des Projekts ändern oder zu Beginn gar nicht vollständig bekannt sind. Planungs- und Entwicklungsphasen wechseln sich demnach ständig miteinander ab.

Agile Methoden besitzen ein gänzlich anderes Leitbild, als dies bei klassischen Modellen der Fall ist. Geprägt und verfasst wurde es im Jahre 2001 von einer Gruppe aus 17 aktiv tätigen Softwareentwicklern. Mit diesem Zusammentreffen formulierten sie ein Leitbild für die Softwareentwicklung, welches heute als agiles Manifest gilt (Vgl. Tabelle 1). In der Softwareentwicklung sind sowohl die rechte als auch die linke Spalte wichtig. Dem agilen Manifest zufolge wird der linken Spalte jedoch eine höhere Bedeutung zugesprochen.

Tabelle 1: Die vier Prinzipien des agilen Manifests

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung in Anlehnung an Hruschka (2009), S. 2.

Der erste Zyklus eines iterativen Verfahrens beginnt, sobald eine Vision für das System entwickelt wurde und die ersten Ziele abgeleitet und gewichtet sind. Daraufhin folgt die Planung einer ersten Version, welche dann fließend in die Entwicklungs- und Ausführungsphase übergeht. Nach den letzten Anpassungen ist der Zyklus beendet. Die Einflüsse, Erkenntnisse und Rahmenbedingungen des vorherigen Zyklus können dabei Auswirkungen auf den Folgezyklus haben. Die wichtigsten Features der Software sollten frühzeitig in einer Basisversion verfügbar sein. Dieser frühe Systemeinsatz dient der Bewertung und Anpassung im Gespräch mit dem Produktverantwortlichen. Daraus gewonnene Erkenntnisse fördern erneut den Lern- und Verbesserungsprozess im Projekt.^[13]

3.2.2 Scrum

Der ursprüngliche Begriff des Scrum stammt aus der Rugby-Welt und bezeichnet einen Spielausschnitt, in dem die Mannschaften bei einem Einwurf eng auf einem Haufen stehen, um den Ball für sich zu gewinnen. Der Begriff wurde durch Ken Schwaber, Jeff Sutherland und Mike Beedle geprägt. Scrum ist keine Projektmanagementmethode im eigentlichen Sinne. Vielmehr ist es ein Vorgehensmodell zur Bewältigung komplexer Projekte mit fest definierten Mustern, Regeln und Rollen.^[14]

Der Scrum-Prozess (Vgl. Abbildung 5) besteht aus Iterationszyklen, die in der Regel zwei bis vier Wochen andauern. Diese Iterationen werden auch Sprints genannt. Sämtliche Anforderungen, die es im Rahmen des Projekts umzusetzen gilt, sind in einem Product-Backlog (PB) aufgeführt. Wird der nächste Sprint geplant, werden Anforderungen und Features aus diesem PB übernommen und vom Entwicklerteam umgesetzt. In Scrum entwerfen, entwickeln und testen die Entwickler selbstgesteuert und eigenverantwortlich innerhalb der Sprints. Eine präzise Rollenvergabe findet demnach nicht statt. Das Entwicklerteam organisiert die Rollen Programmierer, Designer, Tester und Qualitätssicherer innerhalb des Teams selbst.^[15]

Abbildung 5: Der Scrum-Zyklus im Überblick

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Hruschka/Rupp/Starke (2009), S. 66.

Der Product Owner (PO) ist nicht Teil des eigentlichen Entwicklerteams, sondern fungiert als Treiber des Projekts aus Sicht der Organisation. Er legt sowohl Vision als auch Eigenschaften des Produktes fest und kommuniziert diese entsprechend. Da er die volle Verantwortung für das Produkt trägt, ist er legitimiert, Umfang und Reihenfolge der Anforderungen und Funktionalitäten zu priorisieren, um nach dem Erhalt der Lieferung die Ergebnisse der Entwickler zu bewerten. Hierfür verwendet er das PB als Basis, welches ihm erlaubt Vereinbarungen nachzuvollziehen, anzunehmen oder gegebenenfalls abzulehnen. Nicht zuletzt arbeitet der PO permanent am PB und Releaseplan.^[16]

Ein Daily-Scrum-Meeting sichert die tägliche Kommunikation innerhalb des Teams und verhindert damit, dass Unstimmigkeiten und Probleme zu spät entdeckt werden. Anfallende Aufgaben werden ebenfalls verteilt. Typischerweise wird dieses Treffen jeden Tag zur selben Zeit für ca. 15 Minuten abgehalten.^[17]

Ein Scrum-Master dient dem Entwicklerteam als Methodenfachmann aber auch als Rückgrat. Er versucht, sowohl eine solide Arbeitsumgebung zu schaffen, als auch jegliche Störungen zu verhindern oder im Zweifelsfall auch zu beseitigen. Seine Hauptaufgabe besteht zudem im Schulen der Projektbeteiligten über die jeweiligen Rollen.^[18]

Vor einem Sprint treffen sich sämtliche Beteiligte zur Planung. Der PO erläutert dabei die Anforderungen mit den höchsten Prioritäten. Unter den Beteiligten wird nun ein gemeinsames Sprintziel definiert, welches es am Ende des kommenden Sprints zu erreichen gilt. In der Regel ist dieses Ziel ein kurzer, prägnanter Satz, nicht jedoch die Summe aller Features. Dies ist zugleich ein Schutzmechanismus, um sich auf die tatsächliche Intention des Auftraggebers zu konzentrieren.^[19]

Das Ergebnis eines jeden Sprints ist es, die Features in vereinbartem Umfang vollständig implementiert und getestet zu haben. Zuvor einigt sich das agile Team im Rahmen einer ‚Definition of Done‘, nach welchen Kriterien ein Feature als umgesetzt gilt. Davon abgesehen existieren keinerlei sonstige Randbedingungen oder Einschränkungen. Das Entwicklerteam kann demnach seine Aufgaben problemlos abarbeiten und verliert den Fokus auf das Sprintziel nicht. Die Aufwände der einzelnen Features schätzen die Entwickler grob ab. Dadurch wird sichergestellt, dass ein Sprint auch zu bewältigen ist.

Am Ende eines Sprints werden die Ergebnisse im Rahmen eines Sprint Reviews unter den Beteiligten präsentiert. In der Regel bestehen die Teilnehmer aus den Entwicklern, den Kunden, dem Management und dem PO. Typischerweise werden die neuen Features seitens der Entwickler aufbereitet und präsentiert. Zudem wird die Erreichung des Sprintziels überprüft. Sollte dies nicht der Fall sein, muss das PB abgeändert werden. Die Anzahl der Sprints ist von den verbleibenden Anforderungen im Backlog abhängig. Solange diese nicht vollständig abgearbeitet sind, bedarf es weiterer Sprints bis hin zur Fertigstellung und Abnahme des Produkts.^[20]

3.2.3 Anpassungen im Projekt „Technische Pakete“

Das Projekt „Technische Pakete“ verwendet kein Scrum im eigentlichen Sinne. Es verwendet jedoch viele Elemente und größtenteils auch das Vokabular. Im Folgenden werden die wichtigsten Unterschiede zum klassischen Scrum aufgezeigt.

Das Projekt verwendet ein Festpreismodell, welches auf Basis einer initialen Schätzung bei der Ausschreibung ausgefertigt wurde. In der Regel wird in agilen Softwareentwicklungen ein variables Preismodell verwendet.

Zu den bereits beschriebenen Rollen (Vgl. Kapitel 3.2.2) kommen in „TecPac“ noch weitere Rollen zum Einsatz. Ein „Subject Solution Expert“ verantwortet durch seine übergeordnete Rolle die qualitative Umsetzung der Gesamtlösung. Der „Project Manager“ seitens HP führt regelmäßig Reviews zum Umfang, zur Planung und zur Verfügbarkeit durch. Das „Project Steering Board“ beaufsichtigt den Fortschritt des Projekts und unterstützt bei Problemen. Der „Scrum Master“ übernimmt neben der eigentlichen Organisation noch eine zusätzliche Rolle als technischer Projektleiter.

Neben den Sprints und anderen Zyklen existieren weitere Meetings, die in regelmäßigen Abständen stattfinden. Das „Anforderermeeting“ findet wöchentlich statt und unterstützt den Product Owner mit der auftraggeberseitigen Sortierung und Priorisierung von Anforderungen und Testfällen. Zudem werden ein „Kernteammeeting“ zwei-wöchentlich und ein „Steuerkreis“ drei-wöchentlich abgehalten. Dadurch wird sichergestellt, dass die Kommunikation, u.a. auch mit dem Management, regelmäßig stattfindet.^[21]

3.3 Software-Architektur

3.3.1 Begriff der Architektur

Die Architektur von Software-Systemen ist heute noch ein schwer abgrenzbarer Begriff. In einschlägigen Literaturen existiert eine Vielzahl unterschiedlichster Begriffsdefinitionen. Das Software Engineering Institute (SEI) der Carnegie Mellon University in Pittsburgh stellt eigens sogar eine Plattform bereit, in welcher Definitionen unterschiedlichster Herkunft zum Thema Softwarearchitektur gesammelt werden.^[22] Die Architektur eines Softwaresystems ist seinerseits nicht immer transparent oder greifbar, was erneut die Schwierigkeit einheitlicher Definitionen zum Ausdruck bringt. Das Institute of Electrical and Electronics Engineers (IEEE) definiert den Begriff der Architektur wie folgt: “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“.^[23] In diesem Ansatz wird neben der Entwicklung von Software auch die Weiterentwicklung und Wartung betrachtet, welcher ebenfalls eine wichtige Bedeutung zugeschrieben werden sollte. Im Wesentlichen stellen Architekturinhalte eine grob-granulare Sicht auf das System dar, sowohl isoliert als auch im Zusammenspiel mit Schnittstellen- oder Partnersystemen. Dabei geht sie ebenso auf Strukturen und Bausteine ein, wie auch auf Beziehungen der Komponenten untereinander.^[24] Analog zur Architektur von Gebäuden sind es lediglich die fundamentalen Entscheidungen und Sichten auf das Softwaresystem, die ein Software-Architekt beschreibt. Diese bilden die tragenden Säulen und kommen ohne Details aus.^[25] Typischerweise kommen bei nahezu allen Softwareentwicklungs-projekten folgende Fragen auf:

- Wie stehen die Bausteine eines Systems zueinander?
- Welche Schnittstellen liefern dem System welche Daten?
- Ist die Software server- oder cloudbasierend?
- Welche Sicherheitsstandards soll das System beinhalten?

Das Ziel der Architekturarbeit ist die Entwicklung, Unterstützung und Pflege von grundlegenden Entscheidungen und Komponenten eines Software-Systems. Damit liefert sie die Grundlage für die Entwicklung einer Software. Allerdings geschieht dies auf einer höheren Abstraktionsebene. Sowohl Systemgröße, Qualitätsmerkmale als auch Risiken können als Maßstab für die Granularität genutzt werden. Schließlich ist es bei großen Softwaresystemen nicht zwangsläufig möglich auf die Ebene einzelner Bausteine zu abstrahieren. Sind jedoch kritische Qualitätsmerkmale zu erfüllen, kann es im Einzelfall wichtig sein auf detaillierter Ebene zu beschreiben. Hinzu kommt die Frage, ab wann eine Softwarearchitektur ihren Zweck erfüllt. Dies ist der Fall, wenn sie dem System im gesamten Lebenszyklus ermöglicht, die Verhaltens-, Qualitäts- und Nutzungsanforderungen ausreichend zu erfüllen. Dabei gilt jedoch die Erkenntnis, dass es grundsätzlich keine einheitliche oder korrekte Architektur gibt. Sie stellt lediglich eine Abstraktion für ein gegebenes Problem dar.^[26]

Softwarearchitektur ist sehr abstrakt und kann in der Regel nur schwer und mühevoll von Beginn an vollständig beschrieben werden. Daher hat sich in der Zwischenzeit ein Ansatz etabliert, der eine synchrone Dokumentation und Weiterentwicklung während der Code-Implementierung erlaubt.^[27]

3.3.2 Der Software-Architekt

Im Gegensatz zur weitverbreiteten Meinung der Praxis sind Software-Architekten keine Übermenschen oder Alleskönner.^[28] Dennoch kommt ihnen eine besondere Rolle zu. Nach Gernot Starke bilden sie „(…) die Schnittstelle zwischen Analyse, Entwurf, Implementierung, Management und Betrieb von Software.“^[29] Jedoch können auch Softwarearchitekten nicht alle Probleme selbstständig lösen. Sie sind zudem abhängig von einem sauber durchgeführten Projektmanagement, fachkundigem Entwicklerteam sowie den Vorstellungen der Auftraggeber. Weiterhin müssen Softwarearchitekten die Umsetzbarkeit der Anforderungen überprüfen, gewährleisten und im Folgenden auch überwachen.^[30] Die Aufgaben dieser Rolle ist so unterschiedlich wie komplex und verlangt eine Vielzahl unterschiedlicher Kompetenzen, die im Nachfolgenden kurz erläutert werden.

Softwarearchitekten konstruieren sämtliche Bestandteile wie Komponenten, Schnittstellen und Strukturen, die für Entwicklung, Betrieb und Wartung anfallen. Dabei legen sie Verantwortlichkeiten fest, beschreiben Schnittstellen und entwerfen statische und dynamische Strukturen. Sie haben zudem die Aufgabe, die Machbarkeit der Anforderungen z.B. anhand von Prototypen zu belegen und dies stets unter Berücksichtigung der Wirtschaftlichkeit eines Systems.

Die Dokumentation der Architekturarbeit ist ebenfalls ein Schwerpunkt des Architekten. Eine angemessene Dokumentation ist ein kritischer Faktor, den es vom Architekten festzulegen und zu bewältigen gilt. Dabei muss er sowohl Umfang und Granularität, als auch Interessen der einzelnen Adressaten beachten (Siehe Kapitel 3.4). Softwarearchitekten besitzen zudem eine Beratungsfunktion und stehen für nahezu alle architektonischen Fragestellungen sämtlicher Projektbeteiligten Rede und Antwort. Dies beinhaltet u.a. die Projektplanung, Organisation, Anforderungsanalyse, Einteilung und Steuerung der Teams, Kritikalitätsbewertung, Risikomanagement und Qualitätssicherung. Dabei haben sie stets den Anspruch Komplexität zu vereinfachen, Zielkonflikte zu umgehen und Alternativen bereitzustellen.

Ein guter Softwarearchitekt besitzt zudem weitreichende soziale Kompetenzen, die es ihm erlauben, anderen Projektbeteiligten architektonische Entscheidungen erfolgreich zu vermitteln und das Team von der Richtigkeit zu überzeugen. Hierfür sind sie in der Lage Architekturdokumente für unterschiedliche Adressaten aufzubereiten, zu präsentieren und schließlich kontrovers zu argumentieren. Weiterhin fungieren sie als Trainer und Lehrer, nutzen ihr Wissen und vermitteln das Know-How innerhalb des Teams. Für die effiziente und erfolgreiche Bewältigung der eben genannten Kompetenzen und Tätigkeiten bedienen sich Architekten gerne verschiedener Werkzeuge, die im Folgenden aufgezählt sind:^[31]

- Modelle und Abstraktionen
- Dokumentationen und Beschreibungen von Systemen
- Heuristik und Best Practice
- Muster und Frameworks (Vgl. Kapitel 3.6)
- Zerlegung und Aggregation von Komponenten
- Iteratives und zyklische Vorgehen
- Compiler, Debugger und Prototypen zur Überprüfung technischer Risiken

Die oben genannte Beschreibung trifft auf die Tätigkeiten und Kompetenzen eines Architekten auf Projektebene zu. Weiterhin existieren diese auch auf Unternehmensebene. Diese nehmen grundsätzlich ähnliche Tätigkeiten wahr wie der Projektarchitekt, jedoch mit einem wesentlichen Unterschied. Der Fokus des Unternehmensarchitekten liegt in der Planung, Steuerung und Umsetzung unternehmensübergreifender Architekturen. Er berücksichtigt dabei die Architekturentwicklung und Integration verschiedener Teil- und Subsysteme, um sie im Gesamtkontext zu einer Anwendungslandschaft zusammen zuführen.

3.3.3 Enterprise Architecture (Management)

Die Unternehmensarchitektur^[32], oder auch Enterprise Architecture, beschäftigt sich im Vergleich zur Softwarearchitektur mit weitaus mehr als nur einem System oder Systemverbund. Vielmehr werden sämtliche Modelle, Methoden und Richtlinien betrachtet, die für das Design unternehmensweiter Organisations- und Infrastrukturen, Geschäftsprozesse und IT-Systemen von Bedeutung sind. Demnach ist die Unternehmensarchitektur die Summe mehrere Teilarchitekturen. Eine simple Aufteilung kann beispielsweise in Geschäfts- und IT-Architektur vorgenommen werden. Die Geschäftsarchitektur beinhaltet dabei sämtliche nicht-technische Komponenten wie Prozesse, Ressourcen oder Strategien. Die IT-Architektur hingegen bildet Anwendungsarchitekturen sowie Infrastrukturen aus technischer Sicht ab. Unternehmensarchitekturen versuchen demnach eine Brücke zwischen den wesentlichen Elementen der IT und der eigentlichen Geschäftvision zu schlagen, dabei ein solides Fundament bereitzustellen, ohne jedoch die nötige Flexibilität oder Anpassbarkeit zu verlieren.^[33] Durch den unternehmensweiten Fokus ist die Granularität typischerweise auf höherer Ebene angesetzt. Details einzelner Systeme oder Applikationen werden in der Regel vermieden. Ausnahmen davon gibt es lediglich in Bereichen, in denen eine detaillierte Einsicht in Objekte erforderlich ist. Diese ganzheitliche Betrachtung besitzt einen hohen Schwierigkeitsgrad, ist jedoch für den Geschäftserfolg ein kritischer Erfolgsfaktor.^[34]

Das Enterprise Architecture Management (EAM) ist dem Begriff nach das Planungs- und Steuerungselement der EA. Es verantwortet die Erstellung, Einsatz und Pflege von Unternehmensarchitekturen, mit dem Ziel bestehende Architekturen zu überblicken und ggf. in Planarchitekturen zu transferieren. Dadurch werden Entscheidungen ermöglicht, die vorherrschende Architektur an die Strategie des Unternehmens auszurichten. EAM umfasst eine Vielzahl unterschiedlichster Aufgabenbereiche wie bspw. Demand Management, SOA Transformation Management, Project Portfolio Management oder auch Infrastructure Management. Eine tragende Rolle in nahezu allen Unternehmen spielt das Landscape Management^[35]. Es befasst sich mit der Ist-Analyse und Dokumentation vorhandener Architektur-Landschaften bis hin zur geplanten Umgestaltung in Soll-Landschaften. In diesem Zusammenhang werden sowohl fachliche als auch systemtechnische Fragestellungen beantwortet.^[36]

Die Gründe für den Einsatz von EAM sind vielseitig. Unternehmen jeglicher Branche stehen vermehrt Problemen gegenüber, die z.B. auf überhöhte IT-Kosten oder mangelnder Flexibilität von Prozessen zurückzuführen sind. Im Wesentlichen lassen sich zwei Arten von Gegebenheiten unterscheiden, interne und externe Treiber.

Bei internen Treibern handelt es sich um unternehmensinterne Motive für die Einführung von EAM. Als Beweggründe seien IT-Alignment, Qualitätsverbesserung sowie Effizienzsteigerung durch die Nutzung von Synergieeffekten genannt.^[37]

Externe Treiber sind Beweggründe, die von äußeren Einflüssen abhängig sind und nicht von Unternehmen beeinflusst werden können. Hierunter fallen bspw. Complianceanforderungen, die sich mit der Einhaltung von Gesetzen und Vorgaben auf landes-, bundes-, europaweiter oder gar internationaler Ebene auseinandersetzen. Als Beispiele seien Basel III, EuroSOX oder SEPA genannt.^[38] Weitere externe Treiber könnten strategische Allianzen oder Mergers & Acquisitions sein.^[39]

3.4 Grundlagen zur Dokumentation

Die gewissenhafte und saubere Dokumentation von Architekturen sorgt dafür, dass das Wissen darüber nicht verloren geht. Lediglich in kleinen Projekten kann es vorkommen, dass die Softwarearchitekturen von einer einzelnen Person oder Rolle dokumentiert werden. In den häufigsten Fällen handelt es sich jedoch um komplexe Systeme, die alleine nicht mehr zu bewältigen sind. Strukturen und Beziehungen von Komponenten und Teilsystemen sind häufig schwer greifbar. Daher hat eine Dokumentation stets den Anspruch, für alle Beteiligten transparent und verständlich zu sein, nicht zuletzt um sie als Diskussionsgrundlage zu nutzen. Eine Architekturdokumentation sollte jedoch nicht mehr Aufwand kosten, als es Nutzen bringt. Der Nutzen einer sauberen und gewissenhaften Dokumentation kann in drei Kategorien eingeteilt werden:^[40]

- Wissensgrundlage für die Einarbeitung neuer Projektmitarbeiter, genauso wie für Wartung und Weiterentwicklung
- Kommunikation für die Projektstakeholder
- Ansatzpunkte für Systemanalysen

3.4.1 Anforderungen an die Dokumentation

Im Vorfeld ist es wichtig sich über die Architekturziele Gedanken zu machen. Sowohl die Beherrschung von Komplexität als auch die Verständlichkeit stellen wichtige Ziele dar, aus denen im nächsten Schritt die Anforderungen abgeleitet werden können. Der Komplexität kann mit Hilfe von Sichten entgegengewirkt werden, wogegen eine einheitliche Notation für die notwendige Verständlichkeit sorgt.^[41] Hinsichtlich einer sauberen Dokumentation existieren allgemeine Grund-sätze, die es unabhängig von der Thematik zu beachten gilt.

Aufgrund der Vielzahl unterschiedlicher Rollen im Projekt sollte die Dokumentation stets zielgruppenorientiert und auf die Interessen der Adressaten abgestimmt sein. Dadurch kann der Aufwand verringert, Nutzen und Qualität hingegen deutlich gesteigert werden. Redundante Informationen oder Wiederholungen bedürfen zusätzlicher Pflege und sorgen daher für unnötigen Mehraufwand. Dem kann dadurch entgegengewirkt werden, dass an entsprechenden Stellen auf bereits vorhandenes Wissen verwiesen wird. Architekturen besitzen in der Regel Interpretationsspielräume. Eine gute Dokumentation schränkt diesen jedoch ein und sorgt dafür, dass Unstimmigkeiten vermieden werden. Eine einheitliche und standardisierte Notation ist darüber hinaus für das Verständnis der Beteiligten vorteilhaft. Fundamentale Architekturentscheidungen sind mit ihren Entscheidungsgründen und betrachteten Alternativen ebenfalls zu dokumentieren, nicht zuletzt um im späteren Verlauf die Nachvollziehbarkeit zu ermöglichen. Abschließend sei die Aktualität genannt, welche stets im Verhältnis von Aufwand und Nutzen stehen sollte. Das bedeutet, dass nicht jede Änderung sofort dokumentiert werden muss. Häufig empfiehlt sich, die Änderungen zu sammeln und in vereinbarten Abständen in die Dokumentation einzupflegen.^[42]

3.4.2 Sichten

Nachdem auf die grundlegenden Anforderungen an eine Dokumentation eingegangen wurde, ist es nun Zeit sich über die Struktur und den Aufbau der Dokumentation Gedanken zu machen. Mit dem Begriff Sichten sind unterschiedliche Abstraktionen der Realität gemeint. Die Gesamtheit des Systems wird von verschiedenen Blickwinkeln beleuchtet, was dazu führt, dass überflüssige Informationen für die jeweiligen Zielgruppen vernachlässigt werden. Die Perspektive richtet sich stets nach der jeweiligen Zielgruppe und deren Interessen. Architekturen können in ihrer Komplexität und Vielschichtigkeit meist nicht durch eine einzige Darstellung vollständig veranschaulicht werden. Sichten hingegen reduzieren die Komplexität der Darstellung, indem sie sich auf einzelne Teilaspekte des Systems konzentrieren. Die Sichtenbeschreibung erfolgt sowohl grafisch als auch textuell und kann dabei unterschiedliche Abstraktionsebenen oder Granularitäten aufweisen.^[43] Die vier wichtigsten Sichten einer zielgruppen- und zweckorientierten Dokumentation finden sich als Übersicht in Abbildung 6.^[44]

[...]

---

^[1] Softwareentwicklung und Softwaretechnik werden im Rahmen der Arbeit synonym verwendet.

^[2] Vgl. Vogel (2009), S.1f; Matthes (2011), S. 1.

^[3] Vgl. Schatten (2010), S. 12f; S. 32f.

^[4] Vgl. Zörner (2012), S. 9f.

^[5] Vgl. Zörner (2012), S. 9; Schatten (2010), S. 6f.

^[6] Vgl. Zörner (2012), S. 7f.

^[7] Vgl. Daimler AG (URL).

^[8] Vgl. Daimler AG (2013a).

^[9] Vgl. Daimler AG (2013b).

^[10] Vgl. Daimler AG (2012d), S. 15ff.

^[11] Vgl. Schatten (2010), S. 48f.

^[12] Vgl. Schatten (2010), S. 49ff.

^[13] Vgl. Wolf/ Roock (2011), S.3f.

^[14] Vgl. Hruschka/Rupp/Starke (2009), S.65.

^[15] Vgl. Hruschka/Rupp/Starke (2009), S.65.

^[16] Vgl. Gloger (2011), S. 15, S. 78.

^[17] Vgl. Gloger (2011), S. 15.

^[18] Vgl. Hruschka/Rupp/Starke (2009), S.65 ;Gloger (2011), S. 14.

^[19] Vgl. Gloger (2011), S. 78.

^[20] Vgl. Hruschka/Rupp/Starke (2009), S.66ff.

^[21] Vgl. Daimler AG (2012a).

^[22] Vgl. Zörner (2012), S. 17.

^[23] Institute of Electrical and Electronics Engineers (2000), S. 3.

^[24] Vgl. Starke/Hruschka (2011), S. 2f.

^[25] Vgl. Vogel (2009), S. 9.

^[26] Vgl. Posch (2011), S. 9ff..

^[27] Vgl. Starke/Hruschka (2011), S. 3.

^[28] Vgl. Bien (2006)

^[29] Starke (2005), S. 6.

^[30] Vgl. Starke (2006), S. 6.

^[31] Vgl. Starke (2005), S. 18-23.

^[32] Unternehmensarchitektur ist der deutsche Begriff für EA und wird im Rahmen der Arbeit synonym verwendet.

^[33] Vgl. Lankhorst (2009), S. 3. ;Schwarzer (2009), S. 19f.

^[34] Vgl. Lankhorst (2009), S. 3f.

^[35] In der Literatur zum Thema EAM häufig auch als Bebauungsplanung vorzufinden.

^[36] Vgl. Schwarzer (2009), S. 22ff.

^[37] Vgl. Schwarzer (2009), S. 79.

^[38] Auf die Ausführung der Beispiele wird im Rahmen der Arbeit verzichtet.

^[39] Vgl. Schwarzer (2009), S. 80 – 84.

^[40] Vgl. Posch (2011), S. 127f.

^[41] Vlg. Posch (2011), S. 129.

^[42] Vgl. Posch (2011), S. 130f.

^[43] Vgl. Starke (2005), S. 78 – 81f.

^[44] Vgl. Starke (2005), S. 85.