Die Seminararbeit “Steuerungsmöglichkeiten der Projektkultur zur Erfolgssteigerung von Projekten” habe ich im 3. Semester im Fach Projektmanagement an der FOM Hamburg geschrieben. Die Arbeit wurde unter extremen Zeitdruck geschrieben. Benotet wurde sie mit 1,3. Meiner Meinung nach viel zu gut.

Inhaltsverzeichnis

• 1 Einleitung
• 2 Grundlagen
• • 2.1 Unternehmenskultur
• 2.2 Projektkultur
• 3 Steuermöglichkeiten der Unternehmens- und Projektkultur
• 3.1 Abgrenzung des Analysebereiches
• 3.2 Gegenüberstellung der Denkweisen
• 3.2.1 Objektivistische Denkweise
• 3.2.2 Subjektivistische Denkweise
• 3.3 Thesen zur Gestaltbarkeit von Kulturen
• 3.4 Erkenntnisse aus der Hirnforschung
• 3.5 Fazit
• 4 Schlussbetrachtung
• 5 Quellenverzeichnis

1 Einleitung

Die Projektarbeit ist in einer Vielzahl an Unternehmen zur Selbstverständlichkeit geworden. Doch noch längst werden nicht alle Projekte erfolgreich abgeschlossen. In den Unternehmen und in der wissenschaftlichen Projektmanagementdebatte ist daher eine Fragestellung, wie der Erfolg von Projekten erhöht werden kann. Dabei finden die sogenannten “weichen Faktoren” zu denen unter anderem die Projektkultur gehört Aufmerksamkeit. Die Projektkultur ist Untersuchungsgegenstand dieser Arbeit.

Hierfür wurde die These aufgestellt, dass sich die Projektkultur durch das Management hinsichtlich der Erfolgssteigerung von Projekten steuern lässt. Im ersten Schritt dieser Arbeit werden Definitionen der Begriffe “Projektkultur” und “Unternehmenskultur” aufgeführt. Da für diese Begriffe eine Vielzahl an Definitionen vorliegt, wird jeweils eine Definition gewählt, die Untersuchungsgegenstand dieser Arbeit ist. Im Anschluss wird anhand von Fachliteratur geprüft, ob und inwieweit sich Kultur mit dem Ziel der Steigerung des Projekterfolges vom Management gestalten lässt. Die Arbeit wird im Anschluss mit einem Fazit und einer Schlussbetrachtung abgeschlossen.

Während der Erstellung dieser Arbeit konnte eine Vielzahl an Literatur gefunden werden, die sich mit der Gestaltung von Projektkulturen in der Praxis befasst. Diese setzte jedoch bereits von vorneherein voraus, dass das Projektmanagement in der Lage ist, die Projektkultur maßgeblich zu steuern. Eine kritische Auseinandersetzung, ob die Gestaltung von Projektkultur überhaupt möglich ist, fand hingegen nicht statt. Daher musste maßgeblich Literatur aus der Unternehmenskulturforschung herangezogen werden, um diese Frage zu erörtern. Die Unternehmenskultur ist bereits seit Anfang der 1980er Gegenstand der wissenschaftlichen Forschung, so dass hier bereits viele Publikationen vorliegen. Daher wird in dieser Arbeit versucht, die Auseinandersetzung mit der Unternehmenskultur auf die Projektkultur zu übertragen.

2 Grundlagen

2.1 Unternehmenskultur

Bereits bevor die Projektarbeit im großen Stil in deutschen Unternehmen eingeführt wurde, fand der Begriff “Unternehmenskultur” in den Betriebswissenschaften Erwähnung. Mit der Unternehmenskulturforschung hat sich innerhalb der Wirtschaftswissenschaften ein eigener Forschungszweig entwickelt, der sich mit der Thematik der Unternehmenskultur auseinandersetzt. Aus diesem sind eine Vielzahl von Definitionen des Begriffes “Unternehmenskultur” entstanden. Eine einheitliche Definition existiert nicht. Knut Bleicher definiert den Begriff wie folgt:

„Unter der Bezeichnung Unternehmenskultur werden allgemein die kognitiv entwickelten Fähigkeiten einer Unternehmung sowie die affektiv geprägten Einstellungen ihrer Mitarbeiter zur Aufgabe, zum Produkt, zu den Kollegen, zur Führung und zur Unternehmung in ihrer Formung von Perzeptionen (Wahrnehmungen) und Präferenzen (Vorlieben) gegenüber Ereignissen und
Entwicklungen verstanden.“1

Eine weitere Definition des Begriffes “Unternehmenskultur”:
“Unternehmenskultur ist die Gesamtheit der tradierten, wandelbaren, zeitspezifischen, jedoch über Symbole erfahrbaren und erlernbaren Wertvorstellungen, Denkhaltungen und Normen, die sich im Verlaufe der Zeit in einer Unternehmung herausbilden und das Handeln der Mitarbeitern aller Stufen sowie das Erscheinungsbild des Unternehmens prägen.”2

Im weiteren Verlauf dieser Arbeit wird im Zweifel von ersterer Definition, der Definition Bleichers ausgegangen.

Die Diskussion um die Unternehmenskultur als wichtige Einflussgröße für unternehmerischen Erfolg hat ihren Ursprung in den 1970er Jahren. Ausgelöst wurde die Diskussion durch den Erfolg japanischer Firmen auf den Weltmärkten. Diesen Erfolg begründeten Studien nicht mit überlegenen betriebswirtschaftlichen Strategien, sondern vor allem mit dem starken Einsatz der Mitarbeiter und der Verbundenheit zu ihrem Unternehmen.3

2.2 Projektkultur

Laut Weinsteiger kann Bleichers Definition der Unternehmenskultur analog auf die Projektkultur übertragen werden, da das Projekt als ein “Unternehmen im Unternehmen” angesehen werden könne. Zwischen Unternehmens- und Projektkultur bestünde eine Wechselwirkung. Die Unternehmenskultur begrenze und präge die Projektkultur. Weinsteiger differenziert zwischen allgemeiner und projektspezifischer Projektkultur. Die allgemeine umfasse, wie ein Unternehmen mit dem Thema Projekte und Projektmanagement umgehe. Zum Beispiel wie viel Relevanz der Bewältigung von Aufgaben als Projekt beigemessen wird, welcher Aufwand für das Entwickeln eines Projektwesens betrieben wird und inwieweit projektspezifische Kulturen zugelassen werden.4

Die projektspezifische Projektkultur, die in dieser Arbeit behandelt werden soll, ist auf ein bestimmtes Projekt begrenzt. Laut Weinsteiger entsteht eine projektspezifische Projektkultur insbesondere, wenn das jeweilige Projekt eine längere Laufzeit hat, die Ziele besonderer Art sind oder wenn mehrere Unternehmen an einem Projekt beteiligt sind.4

[Grafik Weinsteiger (3) folgt noch]

Weder die Unternehmens- noch die Projektkultur ist ganzheitlich fassbar. Lediglich die Folgen und Erscheinungsformen von Annahmen über den Projektsinn, Normen und Wertevorstellungen sowie Verhaltensweisen werden laut Weinsteiger in Form von Symptomen sichtbar.4

Beispiele für Symptome ist die Art wie mit Kunden kommuniziert wird und wie ihre Anliegen behandelt werden. Auch die Form der internen Kommunikation stellt ein Symptom dar. Beispielsweise wie und wie oft wird kommuniziert? Wird geduzt oder gesiezt? Wie wird mit Fehlern und Konflikten umgegangen? Ein weiteres Symptom ist der Eifer und die Motivation mit denen die Projektmitglieder ihre Aufgaben verrichten. Auch die Qualität der Arbeit ist ein Symptom. Beispielsweise wie werden Vorgaben, Methoden und Vorgehensmodelle gelebt?4

Kritisch betrachtet wird der jedoch die Frage ob und inwieweit die Unternehmens- und Projektkultur gestaltet werden kann. Diese Fragestellung soll im folgenden Kapitel betrachtet werden.

3 Steuermöglichkeiten der Unternehmens- und Projektkultur

3.1 Abgrenzung des Analysebereiches

Die in diesem Kapitel folgende Argumentation, ob und inwieweit Kultur durch das Management gesteuert werden kann, bezieht sich maßgeblich auf die Unternehmenskultur. Es wird von der Annahme ausgegangen, dass sich die Gestaltungsmöglichkeiten der Projektkultur weitestgehend mit der der Unternehmenskultur deckt. Jedoch können beide Kulturen als nicht vollständig gleichwertig betrachtet werden. Die Schaffung einer Projektkultur steht vor größeren Schwierigkeiten als bei der Unternehmenskultur. Durch die Einmaligkeit von Projekten kann schwer auf bestehende Traditionen zurückgegriffen werden. Auch die befristete Laufzeit von Projekten, lässt wenig Spielraum für die Entwicklung einer tiefgreifenden Projektkultur. Ein Projekt beginnt jedoch kulturell nicht als unbeschriebenes Blatt. Die Unternehmenskultur übt ihren Einfluss auch auf Projekte aus, da die Projektmitglieder ebenfalls Angehörige des jeweiligen Unternehmens sind und ihre Einflüsse in das Projekt hineintragen. Ebenfalls muss die angestrebte Projektkultur mit der Unternehmenskultur übereinstimmen, um Konflikte zu vermeiden.5

3.2 Gegenüberstellung der Denkweisen

Die Frage, ob Projektkultur steuerbar ist, wird in der Literatur nicht hinreichend erörtert, daher musste für diese Arbeit die Unternehmenskultur als übergeordnete Ebene der Projektkultur untersucht werden.

In der wissenschaftlichen Diskussion ist umstritten, ob und inwieweit unternehmensinterne Kultur steuerbar ist. Es lassen sich zwei grundlegend entgegengesetzte Standpunkte erkennen: der Objektivismus und der Subjektivismus. Vertreter des Objektivismus sind der Auffassung, dass ein Unternehmen eine Kultur hat, während die Vertreter des Subjektivismus anführen, dass ein Unternehmen eine Kultur ist.6

3.2.1 Objektivistische Denkweise

Die objektivistische Denkweise ist eine systemtheoretische Betrachtungsweise. Sie sieht die Unternehmenskultur als ein Bestandteil des Unternehmens, das als Gesamtsystem fungiert. Die Unternehmenskultur wird als eine “interne Variable” des Gesamtsystemes betrachtet, deren Änderung bzw. Gestaltung möglich ist. Die Unternehmenskultur sei ein Mittel um Wettbewerbsvorteile zu erreichen, jedoch nur eine Variable unter vielen. Weitere Variablen für den Erfolg eines Unternehmens sind beispielsweise die Unternehmensstrategie oder die Organisationsform.7

3.2.2 Subjektivistische Denkweise

Die subjektivistische Sichtweise sieht die Unternehmenskultur nicht als einen Bestandteil, eine Variable des Unternehmens, sondern als das Ergebnis einer ganzheitlichen Unternehmensbetrachtung. Die Unternehmenskultur ergibt sich aus den alltäglichen Handeln der Unternehmensangehörigen und gilt als nicht steuerbar.8

3.3 Thesen zur Gestaltbarkeit von Kulturen

Aus der objektivistischen und subjektivistischen Denkweise lassen sich drei Thesen ableiten, die Klaus Macharzina und Joachim Wolf untersucht haben:9

1. Unternehmenskultur kann durch das Management nicht maßgebend gestaltet werden.
2. Die Unternehmenskultur ist gestaltbar, ein Eingriff sollte jedoch aus ethischen Gründen und der Gefahr von Dysfunktionen unterlassen werden.
3. Ein Eingriff in die Unternehmenskultur ist möglich und empfehlenswert.

Auf die drei Standpunkte soll im Folgenden eingegangen werden.

1. Die Unternehmenskultur kann vom Management nicht gestaltet werden

Diese vom Subjektivismus geprägte Denkweise wird unter anderem damit begründet, dass die Unternehmenskultur auf Traditionen und Gewohnheiten beruhen, die sich erst mit der Zeit entwickeln würden. Diese können nicht ohne Weiteres geplant werden, sondern “sind vielmehr das Ergebnis eines Prozesses spontaner Ordnung an dem alle Unternehmensangehörigen beteiligt sind.”9 Dieser Standpunkt wird insbesondere von Gunnar Westerlund und Sven-Erik Sjöstrand in “Organisationsmythen” vertreten. Sie führen an, dass das Management die Unternehmenskultur nicht tiefgehend prägen könne. Es sei zwar möglich, dass nach außen getragene Verhalten von Mitarbeitern zu ändern, tiefgehende Veränderungen wie zum Beispiel das Ändern von Wertmaßstäben und Einstellungen seien jedoch nicht oder nur sehr schwer möglich.10

2. Eingriffe in die Unternehmenskultur sind möglich, aber nicht ethisch und können nicht kalkulierbare Nebenwirkungen erzeugen

Einen entgegengesetzten Standpunkt vertreten Wolfgang Mayrhofer und Michael Meyer. Diese sind der Auffassung, dass die Unternehmenskultur aktiv vom Management gestaltet werden könne, dies aber aus Gründen der Ethik zu unterlassen sei. “Kulturinterventionen” würden die Lebenswelt der Mitarbeiter stärker beeinflussen, als Arbeitsgestaltung und Reorganisation. Es sei fragwürdig, ob das Management berechtigt sei, die Werte und Normen von Mitarbeitern zu instrumentalisieren. Mayhofer und Meyer verweisen ebenfalls darauf, dass Kulturinterventionen nicht kalkulierbar seien und die Ergebnisse auch negativer Art sein könnten. Ein Eingriff in die bestehende Unternehmenskultur könne funktionierende Unternehmensprozesse stören. Sie verweisen weiterhin darauf, dass der aktuelle Stand der Unternehmenskulturforschung weder in der Lage sei Nebenwirkungen von Kultureingriffen abzuschätzen, noch sei ein Stand erreicht bei dem geeignete Methoden und Werkzeuge zur Verfügung stünden. So lange die Unternehmenskulturforschung hierzu nicht in der Lage sei, seien Kulturinterventionen nicht zu empfehlen.11

Aufgrund der fehlenden Zeit kann diese These im weiteren Verlauf dieser Arbeit nicht weiter behandelt werden.

3. Die Gestaltung der Unternehmenskultur ist möglich und sollte durch das Management vorangetrieben werden

Diese dritte Denkrichtung entstammt dem Objektivismus und entspricht genau der These, die im Rahmen dieser Arbeit aufgestellt wurde. Sie wird unter anderem durch Alphons Schnyder vertreten und sieht die Unternehmenskultur als durch das Management gestaltbar. Eine Intervention in die Unternehmenskultur wird klar befürwortet. Dieser Standpunkt sieht die Unternehmenskultur als ein geeignetes Mittel, um den unternehmensinternen Zusammenhalt, die Produktivität, Gewinnmaximierung zu stärken sowie weitere Ziele zu erreichen. Die Unternehmenskultur soll hierbei für Mitarbeiter eine Koordinations-, Integrations- und Motivationsfunktion beinhalten.12 Die Koordinationsfunktion schaffe bei unterschiedlichen Zielvorstellungen (siehe auch Prinzipal-Agenten-Theorie13) von Unternehmensmitgliedern eine Abstimmung auf übergeordnete Ziele. Die Unternehmenskultur sorge also für einen Basiskonsens für die zu erreichenden Ziele.14

Die Integrationsfunktion soll durch gemeinsam entwickelte Normen und Werte erreicht werden. Ziel ist die Schaffung eines Gefühls von Gemeinsamkeit und Zugehörigkeit (“Wir-Gefühl”). So sollen Abteilungs- sowie Konkurrenzdenken vermieden werden und unternehmensinterne Subkulturen integriert werden.15 Insbesondere bei Projekten treffen in der Regel eine Vielzahl solcher Subkulturen aufeinander, da die Projektmitglieder aus verschiedensten Unternehmensbereichen kommen können.

Eine starke Unternehmenskultur könne zudem die Arbeitsmotivation erhöhen, indem sie dem Mitarbeiter einen Sinnzusammenhang zwischen seinen Aufgaben und dem unternehmerischen Handeln vermittelt.15

Krulis-Randa als Vertreter dieser Denkrichtung beschreibt die Unternehmenskultur als erlernbar, da Kultur nicht angeboren sei, sondern sich angeeignet wird. Dies geschehe in einem langen sozialen Lernprozess. Wie stark die Unternehmenskultur angenommen oder gar verinnerlicht wird, hänge von der Integrationsfähigkeit der einzelnen Mitarbeiter ab.16 Auch Weinsteiger betont, dass sich Unternehmens- und Projektkultur durch Verhaltensänderung der Mitarbeiter bzw. der Projektbeteiligten ändern ließe:
„Wenn in einem Unternehmen die Kultur entwickelt oder die Kultur im Rahmen eines
Projekts verändert werden soll, bedeutet dies, dass gewachsene Einstellungen und
Verhaltensweisen der Beteiligten zu ändern sind. Das heisst auch, dass angestammte und vertraute Einstellungen und Verhaltensweisen aufgegeben oder angepasst werden müssen. Wir können annehmen, dass jeder Mensch Entwicklungspotential besitzt, das heisst, unter geeigneten Voraussetzungen können nicht nur Wissen und Fähigkeiten, sondern auch soziale Verhaltensweisen erlernt und auch verlernt werden.“17

3.4 Erkenntnisse aus der Hirnforschung

Die erste These, Kultur könne nicht tiefgreifend durch das Management geprägt werden, sowie die subjektivistische Denkweise erhalten Unterstützung durch neuste Erkenntnisse aus der Hirnforschung. In einem Interview mit dem Magazin “Der Spiegel” führt Gerhard Roth, Biologe und Hirschforscher, mehrfach die Schwierigkeit an, die Persönlichkeit, beispielsweise das Verhalten und die Wertvorstellungen von erwachsenen Menschen zu ändern: “Der Spielraum, in dem ein Mensch überhaupt empfinden, sich verhalten und sich verändern kann, ist bei der Geburt bereits in beträchtlichem Maße umrissen.” Die wesentliche nachgeburtliche Prägung des Gehirns und somit der Persönlichkeit des Menschen, findet laut Roth in den ersten drei Jahren des Lebens statt. Nachträgliche Änderungen der Persönlichkeit seien kaum noch möglich. Es sei schwer gegen “Kommandos” des Unterbewusstseins anzugehen. “Das unbewusste Selbst ist in seinen neuronalen Grundzügen kaum kaputtzukriegen. [...] [Es] lässt sich die Regie nicht mehr aus der Hand nehmen, wenn das Kind mit etwa drei Jahren sein Kleinkindverhalten ablegt.”18

Während sich das rationale Wissen noch ins hohe Alter erweitern ließe, sei dies bei Verhaltensweisen weniger möglich. “Was sich früh ausbildet und unser Verhalten am stärksten beeinflusst – unser emotionales Grundgerüst -, hört am frühesten auf, stark veränderbar zu sein. Und was am längsten veränderbar ist – das rationale Wissen -, hat am wenigsten Auswirkungen auf unser Verhalten.”19

Roth verweist jedoch darauf, dass die Möglichkeit der Anpassung von Individuum zu Individuum sehr unterschiedlich sei. “Die Persönlichkeit eines Menschen gibt nun mal den Rahmen vor, an dem er sich entlanghangelt. Bei manchen ist der sehr eng; diese Menschen sind absolut null anpassungsfähig.” 19

Während eine tiefgehende Änderung der Persönlichkeit laut Roth nicht möglich ist, lässt sich seiner Ansicht jedoch Verhalten von außen ankonditionieren. Beispielsweise über das Belohnungsprinzip. Sei es durch Lob und Anerkennung oder durch Beförderung.19

3.5 Fazit

Unter Einbeziehung der neusten Erkenntnisse der Hirnforschung lässt sich darauf schließen, dass Unternehmens- und Projektkultur sich nicht willkürlich durch das Management gestalten lässt. Mitarbeiter sind ohne Weiteres in der Lage sich oberflächlichen Anpassungen hinzugeben. So ist es wahrscheinlich, dass bestimmte Verhaltensweisen beispielsweise durch ein Belohnungs- oder Sanktionsprinzip ankonditioniert werden können. Nur in diesem schmalen Gestaltungsraum ist die objektivistische Denkweise überzeugend.

Sobald das Management die Unternehmens- oder Projektkultur jedoch durch Intervention in Bereiche der Mitarbeiterpersönlichkeit, -normen und -wertevorstellungen gestalten will, scheinen hier soziale und biologische Grenzen gesetzt zu sein, was für die subjektivistische Denkweise spricht.

4 Schlussbetrachtung

Aufgrund mangelnder Zeit konnte die These, ob Projektkultur durch das Management zur Erfolgssteigerung von Projekten gestaltet werden kann, nur oberflächlich behandelt werden. Auch lag der Fokus der Arbeit entgegen der aufgestellten These hauptsächlich nicht bei der Projekt-, sondern bei der Unternehmenskultur. Grund hierfür war, wie bereits in der Einleitung erwähnt, dass keine passende Literatur mit direktem Bezug zum Projektmanagement gefunden werden konnte. Daher blieb die Betrachtungsweise zum Großteil allgemein auf das Unternehmen beschränkt und es wurde die Annahme von Weinsteiger übernommen, dass sich die Definition der Unternehmenskultur quasi mit Projektkultur gleichsetzen ließe, da Projekte Unternehmen in Unternehmen seien. Ob diese Projektion ohne Weiteres möglich ist, ist ebenfalls diskussionsbedürftig.

Dennoch konnten in dieser Arbeit zumindest die grundlegenden Standpunkte (Objektivismus vs. Subjektivismus) bezüglich der Gestaltung von unternehmensinternen (Sub-)Kulturen herausgearbeitet werden. Es existieren noch weitere Standpunkte in dieser Debatte. So beispielsweise der integrative Ansatz, der ebenfalls aus Zeitgründen in dieser Arbeit nicht behandelt werden konnte.

Quellenverzeichnis

1. Das Konzept Integriertes Management, Knut Bleicher, Frankfurt, Campus Verlag, 1991
2. Unternehmenskultur, Basis strategischer Profilierung erfolgreicher Unternehmen: Die Orientierung Nr. 85, Schriftenreihe der Schweizerischen Volksbank, Pümpin u.a., Schweizerische Volksbank 1985
3. Klaus Macharzina, Joachim Wolf, Unternehmensführung: Das internationale Managementwissen – Konzepte – Methoden – Praxis, 6. Auflage, Gabler Verlag 2008, S. 236
4. Walter Weinsteiger, Erfolgsfaktor PROJEKTKULTUR, http://www.softwarequalitaet.at/pages/texte/Fachtagung_2008/BeitrWintersteigernachher.pdf
5. Klaus Macharzina, Joachim Wolf, Unternehmensführung: Das internationale Managementwissen – Konzepte – Methoden – Praxis, 6. Auflage, Gabler Verlag 2008, S. 244
6. Eva Stafflage, Unternehmenskultur als erfolgsentscheidender Faktor, Modell zur Zusammenführung bei grenzüberschreitenden Mergers & Acquisitions, Deutscher Universitäts-Verlag, 2005, S. 20
7. Eva Stafflage, Unternehmenskultur als erfolgsentscheidender Faktor, Modell zur Zusammenführung bei grenzüberschreitenden Mergers & Acquisitions, Deutscher Universitäts-Verlag, 2005, S. 20
8. Eva Stafflage, Unternehmenskultur als erfolgsentscheidender Faktor, Modell zur Zusammenführung bei grenzüberschreitenden Mergers & Acquisitions, Deutscher Universitäts-Verlag, 2005, S. 22
9. Klaus Macharzina, Joachim Wolf, Unternehmensführung: Das internationale Managementwissen – Konzepte – Methoden – Praxis, 6. Auflage, Gabler Verlag 2008, S. 248
10. Gunnar Westerlund und Sven-Erik Sjöstrand, Organisationsmythen, Klett-Cotta Verlag, 1981, S. 97ff. und 162f.
11. Wolfgang Mayrhofer, Michael Meyer, Organisationskultur. In: Georg Schreyögg (Hrsg.): Handwörterbuch der Organisation, Stuttgart: Schäffer-Poeschel, 2004, S. 561
12. Alphons Schnyder: “Unternehmenskultur und Corporate Identity – Modell,
Methode und Prozess zur Erreichung einer kulturellen Identität” in: Zeitschrift Führung + Organisation, 4/199, S. 262
13. Hans-Christian Brauweiler (HRSG), Unternehmensführung heute, Oldenburg Verlag, 2008, S. 305
14. Klaus Macharzina, Joachim Wolf, Unternehmensführung: Das internationale Managementwissen – Konzepte – Methoden – Praxis, 6. Auflage, Gabler Verlag 2008, S. 245
15. Arne König, Internationale Megafusionen: Kulturelle Integration als Erfolgsfaktor, Diplomica Verlag, S. 65
16. Krulis-Randa, Einführung in die Unternehmenskultur, 1990, S. 6, 9
17. Weinsteiger, http://www.softwarequalitaet.at/pages/texte/Fachtagung_2008/BeitrWintersteigernachher.pdf, S. 4
18. Lakotta, Beate und Thimm, Katja: “Das Ich ist eine Einbahnstraße”, in: Der Spiegel Heft 35/2007, S. 124-127

1 Titel

2 Inhaltsverzeichnis

2.1 Abkürzungsverzeichnis

3 Abbildungsverzeichnis

4 Tabellenverzeichnis

5 Einleitung

Nach der Einführung des iPad durch Apple im April 2010 erlebte der Bereich der Tablet PC einen starken Aufschwung. Gleichzeitig bieten viele weitere Hersteller Tablet PCs an. Für das iPad wird das Betriebssystem iPhone OS eingesetzt, für Tablet PCs anderer Hersteller zumeist Android. Hierbei stehen sich beide Betriebssysteme konträr gegenüber. iPhone OS ist proprietär, quellgeschlossen und nur für Endgeräte von Apple verfügbar. Android, welches durch das Android Open Source Project unter der Federführung von Google entwickelt wird, ist hingegen quelloffen und für verschiedenste Endgeräte unterschiedlicher Hersteller einsetzbar. Das iPad bzw. das Betriebssystem iPhone OS wird häufig als geschlossenes System bezeichnet.

Tablet PCs auf Basis von Android hingegen als offenes System. Gegenstand dieser Arbeit ist der Vergleich von offenen und geschlossenen Systemen anhand einer Risikoanalyse am Beispiel von Android und iPhone OS. Es soll die Frage beantwortet werden, welches System für Softwareentwicklungsfirmen die geringeren Risiken birgt. Die Risikoanalyse soll hierzu Informationen für die Entscheidungsfindung liefern, welches System als Entwicklungsplattform zu bevorzugen ist. Der Fokus der Risikoanalyse wird hierbei auf wirtschaftliche Risiken gelegt.

In dieser Fallstudie werden zunächst die Grundlagen und Begriffe erläutert.

Die Risikoanalyse wird anhand eines Szenarios durchgeführt.
Des Weiteren wird dargelegt, ob die Einordnung von Android als offenes System und iPhone OS als geschlossenes System zutreffend ist.

In der Risikoanalyse werden die schützenden Werte und die möglichen Gefahren sowie deren Folgen identifiziert. Daran anschließend sollen die Risiken bewertet und ergebnisorientiert dargestellt werden.

Schlussendlich wird der Risiko-Vergleich auf offene und geschlossene Systeme übertragen.

6 Grundlagen

6.1 System

Im folgenden werden die Begriffe “System, “Offenes System” und “Geschlossenes System” erläutert. Im Verlauf der Arbeiten für diese Studie ergab sich, dass auch dem Begriff “Halboffenes System” Bedeutung zukommt. Daher wird dieser ebenfalls erläutert.

6.1.1 Begriff

Es gibt verschiedene Möglichkeiten, den Begriff “System” zu definieren. Ursprünglich kommt der Begriff aus dem griechischen und beschreibt “…eine Einheit, die aus mehreren miteinander in Beziehung stehenden Elementen zusammengesetzt ist”^[1]. Das “Digitale Wörterbuch der deutschen Sprache des 20. Jahrhunderts” definiert System als eine zum Teil hierarchisch strukturierte “Gesamtheit von Aussagen, die eine Einheit bildet”, andererseits aber auch eine “sinnvolle Ordnung, Gliederung von etwas” darstellt^[2].

“Ein System hat eine begrenzte geografische Ausdehnung aus unabhängigen, jedoch untereinander verbundenen und miteinander wechselwirkenden Komponenten oder Subsystemen. Ein System reagiert (üblicherweise) auf äußere Einflüsse.”^[3] Systeme lassen sich in offene und geschlossene Systeme einteilen, wobei insbesondere bei Softwaresystemen eine Verwechslung von offenen Systemen und offener Software zu vermeiden ist^[4].

6.1.2 Offenes System

Die IEEE (Institute of Electrical and Electronics Engineers) definierte offene Systeme im Dezember 1990: “OPEN SYSTEM ENVIRONMENT: a comprehensive and consistent set of international information technology standards and functional standards that specify interfaces, services and supporting formats to accomplish interoperability and portability of applications, data and people….”^[5] Somit gehören zu einem offenen System nicht nur die Technik, sondern auch die Daten und die Menschen. Etwas enger definiert Tom Wheeler offene Systeme als “jene Hard- und Software-Implementierungen, die der Sammlung von Standards entsprechen, die den freien und leichten Zugang zu Lösungen verschiedener Hersteller erlauben. Die Sammlung von Standards kann formal definiert sein oder einfach aus De-facto-Definitionen bestehen, an die sich die großen Hersteller und Anwender in einem technologischen Bereich halten.”^[6] Wichtige Merkmale sind demnach Portierbarkeit, Skalierbarkeit und Interoperabilität. M: Bues fügt noch Standards als “Fundamente für Interoperabilität und Portabilität” hinzu^[7].

Interoperabilität gilt dabei als das wichtigste Merkmal bzw. auch Ziel eines offenen Systems. Verschiedene Systeme mit unterschiedlichen Funktionen von teilweise verschiedenen Herstellern arbeiten gemeinsam um ein Ziel zu erreichen. Für den Anwender sollte sich dieser Verbund als ein homogenes System darstellen^[8].

Portabilität, was Übertragbarkeit bedeutet, bezieht sich nach der Definition der IEEE nicht nur auf die Anwendungen, die auf verschiedenen Systemen lauffähig sein soll, sondern auch auf die Daten und Menschen. Der Wechsel zwischen den Systemen sollte keinen zusätzlichen Lernaufwand bedeuten^[9].

Skalierbarkeit kann auch als Unterpunkt der Portierbarkeit gesehen werden, nämlich die Portierbarkeit auf größere bzw. kleinere Systeme^[10].
Offene Systeme haben sowohl für den Anwender als auch für den Hersteller einige Vorteile. Der Anwender verspricht sich:

• Reaktionsschnelligkeit, da offene Systeme sich schnell auf äußere Einflüsse einstellen können
• Kooperationsfähigkeit, offene Systeme können mit anderen offenen Systemen kommunizieren
• Investitionsschutz durch Erweiterung und Skalierung der offenen Systeme
• Unabhängigkeit durch Verringerung der Abhängigkeit von einem Hersteller und da sich Komponenten verschiedener Hersteller zu einem System zusammenfügen lassen
• Integrationsfähigkeit, da sich offene Systeme optimal an Erfordernisse anpassen lassen

Aus den genannten Punkten ergibt sich weiterhin der Vorteil der:

• Wirtschaftlichkeit^[11].

Der Hersteller kann durch offene Systeme eine größere Anwendergemeinschaft erreichen und seine Entwicklungskosten reduzieren^[12]. Wichtig sind hierbei Schnittstellen. Sie stellen definierte Übergänge zwischen den Systemen dar und können auch selbst Systeme sein. Zum Beispiel stellt ein Satellitenreciever die Schnittstelle zwischen dem Satelliten und dem Fernseher dar und bildet selbst ein System.

6.1.3 Geschlossenes System

In der Literatur finden sich kaum Definitionen von geschlossenen Systemen. Grundsätzlich gilt aber, dass geschlossene Systeme in bestimmten Kategorien oder in ihrer Gesamtheit nichts oder zumindest weniger als offene Systeme mit der Umwelt austauschen.

In der IT werden meist proprietäre Systeme mit geschlossenen Systemen gleichgesetzt, was aber nicht in jedem Fall zutreffend ist ^[13]. Andererseits meint die IT mit “geschlossenem System” oft auch Systeme “aus einem Guss”, bei denen alle Komponenten perfekt zueinander passen und aufeinander abgestimmt sind. Diese Systeme können dann aus Komponenten eines einzigen Herstellers bestehen. Ebenso kann es aber auch um einen Verbund aus offenen Systemen handelt, die über Schnittstellen miteinander kommunizieren.

6.1.4 Halboffenes System

Teilweise wird auch von halboffenen Systemen gesprochen. Diese werden sehr stark vom Hersteller kontrolliert, sind aber im Bezug auf ihre eigentlichen Funktionen sehr offen^[14]. Ein Beispiel ist die Automobilwelt. “Ein BMW 7er läuft mit dem gleichen Benzin wie ein Toyota Prius und hat eine zumindest ähnliche “Benutzeroberfläche”, aber abgesehen davon sind diese zwei Fahrzeuge sehr verschieden. Niemand würde auf die Idee kommen, dass BMW-Ersatzteile auch im Prius funktionieren sollten. Autos teilen sich eine gemeinsame, offene Infrastruktur (das Tankstellennetz, das standardisiertes Benzin verkauft) und gewisse Bedienungsprinzipien (Steuerrad, Gaspedal etc.), aber ansonsten sind die Produkte sehr verschieden und proprietär.”^[15] Auch in der IT ist ein Trend zu halboffenen Systemen erkennbar. So ist beispielsweise Google in vielen Bereichen sehr offen und nutzt quelloffene Elemente. Der Kernbereich, die Google Suchmaschine, ist jedoch geschlossen^[16]. Hierdurch entstehen Produkte, die für den Konsumenten einfach und problemlos zu nutzen sind. Die Funktionsweise bleibt dem Nutzer jedoch verborgen.

6.2 Quelloffenheit

6.2.1 Quelloffenheit

Quelloffene Software (engl. Open Source) wird im allgemeinen Sprachgebrauch häufig mit offenem System gleichgesetzt. Die Begriffe dürfen jedoch nicht als Synonym gesehen werden. Quelloffene Software kann sowohl ein offenes wie auch ein geschlossenes System sein. Das Gegenteil von Quelloffenheit ist Quellgeschlossenheit (engl. Closed Source), nicht etwa geschlossenes System^[17]. Allerdings ist es aufgrund der Eigenschaft von quelloffener Software durchaus möglich, aus einem geschlossenen System ein offenes zu machen.

Die wichtigste Eigenschaft von quelloffener Software ist, wie der Name bereits verdeutlicht, dass der Quellcode offen gelegt wird. Das fertige Programm muss sich hinsichtlich der Funktion nicht von Programmen in quellgeschlossener Software unterscheiden. Lediglich die Art der Erstellung, Verbreitung und Weiterentwicklung der Programme unterscheidet sich^[18]. Quelloffene Software erweitert die Befugnisse des Anwenders im Gegensatz zu anderen Softwareformen erheblich^[19]. Dabei geht es nicht nur um den kostenlosen bzw. sehr günstigen Erwerb der Software, sondern auch um die Rechte, die Software zu verändern, für beliebige Zwecke einzusetzen und an andere weiter zu geben^[20]. Dabei ist zu beachten, dass auch quelloffene Software Lizenzen unterliegt. Die Opensource Initiative (http://www.opensource.org/docs/osd) entwickelte eine Liste von Anforderungen die Lizenzen erfüllen müssen, um als quelloffene Software anerkannt zu werden:

• “Freie Weitergabe – Die Lizenz darf niemanden in der Weitergabe einschränken.
• Es dürfen keine Lizenzgebühren oder andere Beiträge erhoben werden.
• Quellcode – Der Quelltext der Software muss in einer verständlichen Programmiersprache öffentlich zugänglich vorliegen.
• Modifizierte Versionen – Modifizierte Versionen müssen die gleichen Lizenzbedingungen wie das Original erhalten.
• Unversehrtheit des Originalcodes – Bei der Verbreitung von verändertem Quellcode muss genau gekennzeichnet werden, welche Teile des Codes aus dem Original stammen und welche hinzuprogrammiert worden sind. Diese Änderungen müssen in einem externen Dokument festgehalten werden und zusammen mit der Software zur Verfügung stehen.
• Keine Diskriminierung einzelner Personen oder Gruppen – Es gibt keine Einschränkung bei der Anzahl der Benutzer oder der Installationen. Zudem dürfen keine Personen oder Gruppen von dem Gebrauch ausgeschlossen werden.
• Keine Einschränkung der Anwendungsbereiche – Die Lizenz darf kein bestimmtes Einsatzgebiet einschränken.
• Verbreitung der Lizenz – Der Lizenz dürfen keine weiteren Klauseln hinzugefügt werden.
• Die Lizenz darf nicht nur für ein bestimmtes Produkt gelten – Wenn in Softwarepaketen enthaltene Open-Source-Programme einzeln weiterverbreitet werden, gilt für diese parat stehende Anwendung dieselbe Lizenz wie für das Ausgangspaket.
• Die Lizenz darf keine andere Software beeinträchtigen – Die Lizenz darf keine Programme, die beispielsweise in demselben Softwarepaket enthalten sind, einschränken.”^[21]

Quelloffene Software, die unter der General Public License (GPL) steht, muss bei Weitergabe oder Modifizierung erneut unter GPL Lizenz gestellt werden. Somit wird eine Lizenzänderung verhindert. Ebenso darf GPL-Software keine Module enthalten, die nicht unter GPL stehen^[22].

Die Apache License der Apache Software Foundation ist deutlich offener. So kann selbst erstellte Software durchaus auf Apache lizenzierte Software aufbauen und muss trotzdem nicht nach dieser lizenziert werden. Allerdings muss kenntlich gemacht werden, das Software nach Apache License verwendet wurde^[23].

Quelloffene Software beinhaltet Vorteile und Nachteile. Diese sind in nachfolgender Tabelle gegenübergestellt.

6.2.2 quellgeschlossene Software

Quellgeschlossene Software, häufig auch als proprietäre Software bezeichnet, gehört in der Regel dem Hersteller. Der Käufer der Software erwirbt lediglich die Nutzungsrechte an der Software. Die Software wird als Binary ausgeliefert, der Quelltext verbleibt beim Hersteller. Das bedeutet, dass auch nur der Hersteller in der Lage ist, die Software weiter zu entwickeln oder Fehler zu beheben^[25].

Für das Nutzungsrecht muss der Anwender ein Entgelt entrichten. Dieses kann sich je nach Hersteller auf unterschiedliche Aspekte der Nutzung der Software beziehen. Beispiele sind:

• Anzahl der Nutzer
• Anzahl oder Wert der verwalteten Objekte
• Dauer der Nutzung
• Infrastruktur des Anwenders, zum Beispiel Anzahl der Prozessoren^[26].

In neueren Lizenzmodellen sind diese Gebühren nicht nur einmalig, sondern in monatlichen oder jährlichen Intervallen zu entrichten. Dafür werden dem Anwender alle neuen und fehlerbereinigten Versionen der Software kostenlos zur Verfügung gestellt.

Die meisten Nachteile von quelloffener Software können als Vorteile von quellgeschlossener Software angesehen werden. Die wichtigsten im professionellen Umfeld sind Gewährleistung und Support. Allerdings versuchen die Anbieter proprietärer Software zunehmend durch entsprechende Klauseln in den Lizenzbestimmungen auch die Gewährleistung und den Support einzuschränken^[27].

6.3 Tablet PCs

6.3.1 Begriff

Tablet PCs sind wenige Zentimeter flache und tragbare Computer. Sie haben weder Maus noch Tastatur. Die Bedienung erfolgt direkt über den als Touchscreen ausgeführten Bildschirm. Je nach eingesetzter Technologie kann die Bedienung direkt mit den Fingern erfolgen oder mit einem drahtlosen Eingabestift^[28].

6.3.2 Anwendungsbereich

In der Regel sind Tablet PCs leicht, handlich und haben eine lange Akkulaufzeit^[29]. Dadurch können sie mobil eingesetzt werden. Im Gegensatz zu Notebooks benötigen Tablet PCs zudem keine Ablagefläche und können so im Stehen bedient werden. Damit ergeben sich für Tablet PCs Anwendungsbereiche, die für ein Notebook nicht infrage kommen. Beispielsweise in der Gastronomie zur Aufnahme von Bestellungen oder in Lagerlogistik zur Kontrolle von Waren.

6.3.3 Android

Android ist ein freies quelloffenes Betriebssystem für mobile Geräte wie beispielsweise Smartphones oder Tablet PCs. Die Entwicklung von Android wird vom Android Open Source Project (AOSP) unter der Leitung des Unternehmens Google durchgeführt^[30]. Als Projektziel nennt das AOSP die Schaffung eines offenes Systems, indem kein Softwarehersteller die Anwendung anderer Software beschränken oder verbieten kann^[31]. Android liegt aktuell in der Version 2.2 vor^[32].

6.3.3.1 Technik

6.3.3.1.1 Software

Das AOSP hat klare Richtlinien geschaffen, wie Hardware- (z.B. Tablet PCs) bzw. Software-Entwicklungen erstellt werden müssen, damit diese den Anforderungen von Android entsprechen. Dazu hat das AOSP das Android Compatibility Program geschaffen. Dieses enthält definierte Richtlinien für Hardware- und Softwarehersteller, die Android als Plattform verwenden wollen. Diese Richtlinien sind im CDD niedergeschrieben. Weiterhin umfasst das Android Compatibility Program auch Tools mit denen sich die Kompatibilität prüfen lässt^[33]. Diese Tools sind in der Compatibility Test Suite (CTS) zusammengefasst ^[34].

6.3.3.1.2 Hardwareanforderungen

Im CDD sind konkrete Vorgaben definiert, an die sich ein Gerätehersteller halten muss, wenn dieser Android einsetzen will. Verwendet ein Gerätehersteller beispielsweise eine Hardwarekomponente, die standardmäßig über eine Schnittstelle für Entwickler verfügt, so muss diese Schnittstelle auch implementiert werden. Der Gerätehersteller verpflichtet sich weiterhin folgende Schnittstellen und Funktionen in das Gerät zu integrieren:

• USB
• Touchscreen
• WLAN
• Kamera
• Kompass
• GPS
• Mindestens 290 MB nicht flüchtiger Speicher^[35]

Diese Liste ist nicht komplett. Soll aber aus Gründen des Umfanges nicht weiter beleuchtet werden.

6.3.3.2 Apps

Für Android Systeme lassen sich Anwendungen (engl. Applications, Abk. Apps) hinzukaufen, welche die Funktionalität des Tablet PCs erweitern können. Diese Apps können zum einen im Android Market erworben werden, zum anderen gibt es aber auch weitere Bezugsquellen für Apps, z.B. http://www.androidfreeware.org/. Im Android Market stehen aktuell mehrere Zehntausend Apps zur Verfügung^[36]. Ein Beispiel für ein Android App ist “Wikitude”. Mit diesem lassen sich Restaurants und Sehnswürdigkeiten etc. anzeigen, die sich in der Nähe des Tablet PC-Anwenders befinden^[37].

6.3.3.3 Geschäftsmodell

Android steht unter Apache 2.0 Lizenz. Hier gibt es jedoch in Einzelfällen Ausnahmen. Beispielsweise ist der für Android verwendete Linux Kernel unter GPLv2 lizenziert^[38]. Das Betriebssystem Android wird Herstellern von mobilen Endgeräten und Anwendern frei zur Verfügung gestellt. Dennoch verfolgt Google mit der Verbreitung von Android eine Gewinnerzielungsstrategie. Ziel ist, durch standortabhängige Werbung Einnahmen zu erzielen^[39].

6.3.4 iPhone OS

Das Apple Betriebssystem iPhone OS wird für die Geräte iPod, iPhone und für das iPad verwendet. iPhone OS basiert auf dem Macintosh Betriebssystem Mac OS X, mit dem es viele Funktionalitäten gemeinsam hat. Jedoch ist iPhone OS auf mobile Endgeräte spezialisiert. So besitzt es im Gegensatz zu Mac OS X Funktionen für Touchscreens und Bewegungssensoren^[40].

6.3.4.1 Technik

6.3.4.1.1 Hardware

iPhone OS ist nur auf Apple Hardware installiert. Im Tablet PC Bereich wird aktuell nur das iPad angeboten. Apple liefert auf seiner Homepage einige Daten zum iPad, so ist es ca. 24 cm mal 19 cm groß und etwa 13,5 mm dick. Dabei wiegt es je nach Modell zwischen 680 g und 730 g. Die Eingabe erfolgt ausschließlich über einen 9,7 Zoll Touchscreen, sonstige Bedienelemente gibt es nur für den Ein-/Ausschalter, die Verriegelung des Displays und die Lautstärkeregelung. Folgende Ein- und Ausgänge werden zur Verfügung gestellt:

• 30-poliger Dock-Anschluss
• Stereo-Kopfhöreranschluss (3,5 mm)
• Integrierter Lautsprecher
• Mikrofon
• Fach für Micro-SIM-Karte (nur beim Wi-Fi + 3G Modell)

die Kommunikation mit der Außenwelt erfolgt ansonsten per

• Bluethooth
• WLAN/Wi-Fi
• und bei einigen Modellen 3G (UMTS/GSM).

Seinen Standort kann das iPad über die Funknetze oder per GPS ermitteln.
Es gibt Sensoren für das Umgebungslicht und einen Beschleunigungssensor, der auch die Informationen für das Umschalten zwischen Hoch- und Querformat liefert.
Es gibt Modelle mit 16GByte, 32GByte oder 64 GByte Flashspeicher.
Somit unterscheiden sich die verfügbaren Modelle nur in ihrer Speicherkapazität und dem Vorhandensein eines 3G Moduls^[41].

6.3.4.1.2 Software

Das iPad wird derzeit ausschließlich mit iPhone OS in der Version 3.2. ausgeliefert. Andere Betriebssysteme sind bislang nicht lauffähig. Das iPhone OS 3.2 ist eine geringfügig erweiterte Version des Betriebsystems für das iPhone. So verbessert sich die Bedienbarkeit des iPad durch zwei neue Gesten für den Touchscreen, es wird der Anschluss eines externen Monitors unterstützt sowie eine Erleichterung bei der Eingabe von Texten eingebaut^[42].
Einige Programme wie Browser, Mailprogramm und Bookreader sind im Lieferumfang des Betriebssystemes enthalten. Außerdem lassen sich viele Funktionen mittels Apps nachrüsten. Diese Apps müssen im Apple App Store bezogen werden. Eine andere Bezugsmöglichkeit ist von Apple nicht vorgesehen. Am 7. Juni 2010 hat Apple iPhone OS in iOS umbenannt. Außerdem wurde die Version 4.0 angekündigt. Diese unterstützt unter anderem Multitasking^[43].

6.3.4.2 Apps

Ähnlich wie Android Systeme, lässt sich auch die Funktionalität des iPads durch Apps erweitern. Im Apple App Store sind zurzeit über 150.000 Apps verfügbar. Nutzer von iPods und iPhones haben zudem die Möglichkeit ihre Apps auch für das iPad zu verwenden. Laut Aussage von Apple funktionieren fast alle dieser Apps auch für das iPad. Ein Beispiel für ein iPad kompatibles App ist das „Kindle“. Mit diesem lassen sich eBooks aus dem Amazon Kindle Store lesen, so dass das iPad als eBook-Reader verwendet werden kann^[44].

6.3.4.3 Geschäftsmodell

Über Apples Geschäftsmodell kann nur spekuliert werden, da Apple keine Zahlen hierzu veröffentlicht. Neben dem Verkauf der Hardware und Software wird Apple aber wohl einen Teil des Gewinns aus seinen Online Stores für Musik, Videos, eBooks und Apps ziehen.

6.4 Risikoanalyse

Ein Risiko wird im Allgemeinen als etwas Negatives, Bedrohliches oder auch Zukünftiges und Ungewisses angesehen^[45]. Das Zukünftige und Ungewisse kann betriebswirtschaftlich aber auch eine Chance sein, wenn die Abweichung in positiver Richtung stattfindet. So enthält auch das chinesische Schriftzeichen für Risiko die Zeichen für Chance und Gefahr. Diese Art des Risikos wird als entscheidungsorientiertes Risiko bezeichnet^[46].

Beschrieben wird das Risiko durch die Häufigkeit bzw. Wahrscheinlichkeit des Eintritts des gefährdenden Ereignisses sowie durch das zu erwartende Schadensausmaß^[47].

Eine betriebswirtschaftliche Definition nach Königs lautet: “Ein Risiko ist eine nach Häufigkeit (Eintrittserwartung) und Auswirkung bewertete Bedrohung eines zielorientierten Systems. Das Risiko betrachtet dabei stets die negative, unerwünschte und ungeplante Abweichung von System-Zielen und deren Folgen.”^[48].

Tritt der Risikofall ein, können die Folgen je nach Gegenstand der Betrachtung unterschiedlich ausfallen. So kann es in Projekten zu Abweichungen bezüglich “Dauer”, “Budget” und “Qualität” kommen^[49]. In der IT können die grundlegenden Sicherheitswerte “Vertraulichkeit”, “Integrität” und “Verfügbarkeit” betroffen sein^[50].

Damit ein Risikofall eintreten kann, muss es eine Bedrohung geben^[51]. In Projekten kann die Bedrohung darin bestehen, dass Mitarbeiter unzureichend qualifiziert sind, worunter die Qualität des Projektergebnisses leiden wird. In der IT ist eine mögliche Bedrohung das Ausspähen von Daten, wodurch die Vertraulichkeit dieser nicht mehr gegeben ist. Die Bedrohungen in der IT lassen sich in 4 Kategorien einteilen:

• Menschen
• organisatorische Mängel
• technisches Versagen
• höhere Gewalt^[52].

Weiterhin muss es für einen Risikofall auch eine Schwachstelle geben, durch welche die Bedrohung Schaden anrichten kann^[53]. In dem Projektbeispiel kann dies ein unzureichender Test bei der Auswahl der Projektmitarbeiter sein, beim IT-Beispiel eine Schwachstelle in der Firewallsoftware.

Aus diesen Bedrohungen und Schwachstellen ergibt sich dann die Wahrscheinlichkeit, mit welcher der Risikofall eintreten kann^[54]. Ist also die Bedrohung durch einen unqualifizierten Mitarbeiter gering, da die zu besetzende Stelle kaum Qualifizierung erfordert, wird auch die Wahrscheinlichkeit des Eintritts des Risikofalls “unzureichend qualifizierter Mitarbeiter” gering sein.

Tritt der Risikofall ein, kommt es zu einem Schaden.

Der Begriff Analyse bezeichnet eine Untersuchung wie auch Zergliederung eines Ganzen in seine Teilbereiche. In der Risikoanalyse finden beide Möglichkeiten Anwendung. Zum einen als heuristische Untersuchung, zum anderen als Zergliederung eines Systems^[55].

Die Risikoanalyse ist Teil des Risikomanagements. Hauptzweck ist die Ermittlung angemessener Sicherungsmaßnahmen. Des Weiteren kann eine Risikoanalyse zu einem verstärkten Sicherheitsbewusstsein der Mitarbeiter und Leitung führen. Das Verständnis relevanter Zusammenhänge wird verbessert. Nicht zuletzt werden mögliche Schwachstellen gefunden^[56].

7 Risikoanalyse

7.1 Methodik

Um festzustellen ob der Einsatz eines offenen oder geschlossen Systems für Softwareentwicklungsformen die geringeren Risiken birgt, wird im Folgenden eine Risikoanalyse anhand eines Szenarios durchgeführt. Hierbei wird ein Risikovergleich zwischen dem als offenen System geltenden Android und dem als geschlossenen System geltenden iPhone OS bzw. iPad gezogen. Dabei soll die Risikoanalyse in Anlehnung an die Arbeit von Freiling^[57] folgende Phasen durchlaufen werden:

• Szenario: Es wird ein Szenario aufgestellt, indem eine virtuelle Firma geschaffen wird. Dazu wird ein Geschäftsfall entwickelt, auf den die Risikoanalyse angewendet wird.
• Analysebereich: Im Anschluss wird der Analysebereich eingegrenzt. Dies ist notwendig, um die Übersicht zu bewahren und die Untersuchung nicht ausufern zu lassen. Des Weiteren soll erkennbar sein, welche Bereiche die Risikoanalyse abgedeckt und welche Bereiche für einen speziellen Anwendungsfall noch zu untersuchen sind.
• Typisierung der Alternativen: Es soll untersucht werden, inwieweit sich iPhone OS und Android in offene und geschlossene Systeme kategorisieren lassen.
• Szenarioanalyse: Die Szenarioanalyse unterteilt sich in einzelne Unterbereiche:
  • Identifikation der zu schützenden Werte: Hier wird untersucht, welche Werte tatsächlich relevant für das Unternehmen bzw. das Projekt sind. Nur wenn diese Werte gefährdet sind, besteht tatsächlich ein Risiko.
  • Identifikation von Gefahren: Hier werden die Gefahren identifiziert, welche die relevanten zu schützenden Werte tatsächlich bedrohen können.
  • Gefährdungsanalyse: In diesem Abschnitt werden die möglichen Folgen beim Eintritt einer Gefahr untersucht.
  • Risikobewertung: Hier wird eine Einschätzung der Wahrscheinlichkeit des Risikoeintritts und der Schadenshöhe vorgenommen. In diesem Szenario ist eine Arbeit mit genauen Geldwerten und prozentualen Wahrscheinlichkeiten nicht möglich. Daher wird die Kategorisierung an einer ordinalen Skalar durchgeführt.
  • Ergebnisse der Szenarioanalyse: Hier werden die Ergebnisse der Szenarioanalyse zusammengefasst und tabellarisch als auch grafisch dargestellt.
• Risiko-Vergleich offene und geschlossene Systeme: In diesem Punkt werden die Ergebnisse der Szenarioanalyse, soweit es möglich ist, auf das Ursprungsthema offene und geschlossene Systeme portiert.

7.2 Szenario

Um festzustellen, ob der Einsatz eines iPad oder Android Systems für ein Unternehmen die geringeren Risiken birgt, wird eine Szenarioanalyse durchgeführt. Hierfür wurde folgendes Szenario aufgestellt:

Die GK Software GmbH ist ein Dienstelistungsunternehmen für IT Lösungen. Ein mittelständisches Gartenplanungsunternehmen, die Gartenplanung GmbH, tritt an die GK Software GmbH mit dem Auftrag heran, eine Lösung für die Vertriebsmitarbeiter zu entwickeln, die mit Tablet PCs ausgestattet werden sollen. Die insgesamt 10 Vertriebsmitarbeiter sollen beim Kunden vor Ort eine grobe Planung des Gartens erstellen. Die Wahl fiel auf den Einsatz von Tablet PCs, da die Planungssoftware fertige Gartenbauelemente enthalten soll, die einfach per Touchscreen im Gartenmodell angeordnet werden soll. Die Kunden der Gartenplanung GmbH sollen so den Gartenplanungsprozess der Vertriebsmitarbeiter verfolgen können und direkt bei der Planung mitwirken können. Zusätzlich soll der Tablet PC als digitaler Notiz- und Zeichenblock verwendet werden, um den Kunden einfache Skizzen zu präsentieren. Sobald der Kunde mit der Planung zufrieden ist, sollen alle planungsrelevante Daten über das Internet an einem Server der Gartenplanung GmbH übermittelt werden. Hierbei werden auch kundenbezogene Stammdaten wie Name und Adresse übertragen.

Die GK Software GmbH erhält den Auftrag eine entsprechende Gartenplanungssoftware als App zu entwickeln. Außerdem soll sie der Gartenplanung GmbH einen Vorschlag unterbreiten, welche Hardware einzusetzen ist. Die GK Software GmbH zieht die beiden Alternativen iPad und ein Android basiertes System in Betracht. Das Gartenplanungsapp soll zukünftig für die Gartenplanungsbranche eine neue Standardsoftware werden und nach Fertigstellung auch anderen Gartenplanungsunternehmen angeboten werden. Der Verkauf des Apps an weitere Unternehmen ist entscheidend, um die Entwicklungskosten zu decken und um Gewinne zu erzielen.

Vor Ausführung des Auftrages führt die GK Software GmbH eine Risikoanalyse durch, um zu ermitteln, für welche Plattform bei der Entwicklung, dem Vertrieb und beim späteren Einsatz des Apps die geringeren Risiken bestehen.

7.3 Analysebereich

In dieser Risikoanalyse wird der Schwerpunkt auf offene vs. geschlossene Systeme gelegt. Es soll untersucht werden, welche Risiken die Systeme beinhalten und ob aus unternehmerischer Sicht ein System zu bevorzugen ist. Diese Risikoanalyse wird aus Sicht der GK Software GmbH durchgeführt. Daher beinhaltet die Risikoanalyse einerseits wirtschaftliche Aspekte der GK Software GmbH (Entwicklungskosten, Zeitplanung), aber auch technische Aspekte für den späteren Betrieb beim Kunden. Die Risikoanalyse ist auch Grundlage für die Empfehlung eines Systems an den Kunden.

7.4 Typisierung der Alternativen

Zunächst werden Android und iPhone OS in die Kategorien offenes oder geschlossenes System eingeordnet. Für die Kategorisierung orientieren wir uns an den Merkmalen:

• Portierbarkeit: Es soll untersucht werden, ob die Betriebssysteme und damit auch die Apps unter unterschiedlicher Hardware lauffähig sind.

• Skalierbarkeit: Es soll untersucht werden, ob die Betriebssysteme um zusätzliche Funktionen erweitert werden können.

• Interoperabilität: Es soll geprüft werden, ob das Betriebssysten mit anderen Systemen interagieren kann.

Android ist als offenes System zu betrachten, da es die vorgebenen Kriterien erfüllt. Beschränkungen kann es einzig durch die Richtlinien des CDD geben. iPhone OS kann weder als offenes noch als geschlossenes System angesehen werden. Geschlossene Systeme tauschen keinerlei Informationen mit der Außenwelt aus und besitzen keinerlei Schnittstellen. iPhone OS bietet jedoch sowohl Schnittstellen für den Anwender (bspw. durch die Internettauglichkeit), als auch für Entwickler, denen die Möglichkeit gegeben wird, Apps zu erstellen. Apple hat allerdings alleinige Entscheidungsgewalt über die angebotenen Schnittstellen und Apps und kann diese nach Belieben entfernen oder beschränken. Somit bestimmt Apple die Offenheit des Systems. Daher ist iPhone OS nicht als offenes System anzusehen sondern als halboffenes.

7.5 Szenarioanalyse

7.5.1 Identifikation der zu schützenden Werte

7.5.1.1 Sicherheitswerte

Da das zu erstellende App personenbezogene Kundendaten übertragen soll, ist der Schutz dieser Daten als besonders wichtig anzusehen. Das Bundesamt für Sicherheit in der Informationstechnik hat drei Sicherheitsziele für den Schutz von Daten festgelegt: Vertraulichkeit, Integrität und Verfügbarkeit.

• “Vertraulichkeit ist der Schutz vor unbefugter Preisgabe von Informationen. Vertrauliche Daten und Informationen dürfen ausschließlich Befugten in der zulässigen Weise zugänglich sein.”^[58]
• “Integrität bezeichnet die Sicherstellung der Korrektheit (Unversehrtheit) von Daten…”^[59]
• “Die Verfügbarkeit von Dienstleistungen, Funktionen eines IT-Systems, IT-Anwendungen oder IT-Netzen oder auch von Informationen ist vorhanden, wenn diese von den Anwendern stets wie vorgesehen genutzt werden können.”^[60]

7.5.1.2 Wirtschaftliche Werte

Für die Entwicklung des Apps fallen Kosten an. Hierbei muss beachtet werden, dass diese sich im Rahmen der Kalkulation halten. Ebenso muss beachtet werden, dass das App in der mit dem Kunden vereinbarten Zeit fertiggestellt wird.

Auch die oben beschriebenen Sicherheitswerte beeinflussen wirtschaftliche Werte, da Probleme bei der Datensicherheit häufig auch zu finanziellen Schäden führen. Stehen beispielsweise Funktionen eines IT-Systems nicht zur Verfügung kann es zu Produktionsausfällen kommen.

7.5.2 Identifikation von Gefahren

7.5.2.1 Datensicherheit

Datensicherheit oder auch IT- und Informationssicherheit befasst sich mit dem Schutz von Informationen^[61]. “IT-Sicherheit ist also der Zustand, in dem Vertraulichkeit, Integrität und Verfügbarkeit von Informationen und Informationstechnik durch angemessene Maßnahmen geschützt sind.”^[62]

Für den Softwareanwender ergeben sich bzgl. der Datensicherheit beim Gartenplanungsapp folgende Gefahren:

• Bezüglich dem Schutzziel der Vertraulichkeit:
  • Bei der Kommunikation zwischen Tablet PC und Server werden Kundendaten von dritter Seite abgefangen > Sehr leicht möglich bei unverschlüsselten WLAN Verbindungen.
  • Eine dritte Person verschafft sich unberechtigt Zugang auf den Tablet PC und stiehlt Daten > Zum Beispiel kann der Tablet PC verloren gehen oder gestohlen werden.
• Bezüglich dem Schutzziel der Integrität:
  • Die an den Server übertragenen Daten werden durch einen Fehler verändert > Kann bei schlechten Verbindungen passieren, wenn die Software keine entsprechenden Fehlerkorrekturen vorsieht.
  • Die an den Server übertragenen Daten werden von dritter Seite manipuliert > Kann durch Viren auf dem Tablet PC passieren
  • Eine dritte Person verschafft sich unberechtigt Zugang auf den Tablet PC und manipuliert Daten > Wenn der Tablet PC verloren geht oder gestohlen wird.

Bezüglich dem Schutzziel der Verfügbarkeit:

• Durch einen Angriff ist der Tablet PC nicht mehr verfügbar > Ein Virus kann den Tablet PC soweit in seiner Funktion stören, dass dieser nicht mehr benutzbar ist.
• Die Übermittlung der Daten an den Server schlägt fehl, da das Apps aufgrund eines Softwarefehlers keine Verbindung zum Server aufbauen kann.

Neben technischen Faktoren existieren noch rechtliche und organisatorische Faktoren, die die Verfügbarkeit gefährden können. Diese sollen im folgenden Kapitel “Dienstleistungsausfall” beleuchtet werden.

7.5.2.2 Dienstleistungsausfall

Dienstleistungsausfall bedeutet in dieser Arbeit, das vereinbarte Dienstleistungen nicht oder nicht vollständig erbracht werden können. Das kann sowohl zwischen der GK Software GmbH und der Gartenplanung GmbH als auch später zwischen der Gartenplanung GmbH und ihren Kunden der Fall sein. Im ersten Fall kann das geplante App nicht oder nicht den Anforderungen entsprechend fertig gestellt werden, im zweiten Fall kann die Gartenplanung GmbH ihrem Kunden die Dienstleistung der Gartenplanung nicht erbringen.

Bezüglich des Dienstleistungsausfalls bestehen somit folgende Gefahren:

• Gefahren für die Gartenplanung GmbH:
  • Notwendige Schnittstellen können wegfallen. > Das Betriebssystem stellt Schnittstellen zur Verfügung, über die auf die Hardware des Tablet PC und externe Dienste zugegriffen werden kann. Der Hersteller des Betriebssystems kann nun festlegen, das zukünftig z.B. die Bluetooth Schnittstelle entfällt und so der Abgleich des Tablet PC mit externen Geräten nicht mehr möglich ist.
  • Im Betrieb stellt sich heraus, dass weitere Schnittstellen für den reibungslosen Betrieb notwendig sind. > So kann der Kunde nach einiger Zeit feststellen, dass der Abgleich über das Internet nicht optimal ist und ein Abgleich über z.B. Bluetooth besser wäre. Das Betriebssystem muss diese Schnittstelle unterstützen bzw. es muss die Schnittstelle nachrüstbar sein.
  • Die Hardware entspricht nicht den Anforderungen und muss gewechselt werden. Eventuell läuft das App auf der neuen Plattform nicht mehr. > Es könnte sich herausstellen, das schnellere Hardware benötigt wird.
  • Das App kann von zentraler Stelle (Android oder Apple) deaktiviert werden^[63]
• Gefahren für die GK Software GmbH:
  • Notwendige Schnittstellen können wegfallen. > s.o.
  • Das App wird von zentraler Stelle (Android oder Apple App Store) nicht zugelassen oder zu einem späteren Zeitpunkt deaktiviert^[64].
  • Der Entwicklungsaufwand ist größer als kalkuliert.

7.5.3 Gefährdungsanalyse

7.5.3.1 Datensicherheit

Wie in Kapitel 7.5.2.1 ausgeführt, beziehen sich die folgenden Punkte auf die Gartenplanung GmbH.
Daher bezieht sich der Begriff “Kunden” in diesem Abschnitt auf die Kunden der Gartenplanung GmbH.

• Mögliche Folgen bei Verletzung der Vertraulichkeit:

Werden aufgrund mangelnder Datensicherheit Kundendaten ausgespäht, könnte eine andere Gartenbaufirma diese Daten nutzen, um dem Kunden ein besseres Angebot zu machen. Dadurch kommt es für die Gartenplanung GmbH zu Umsatzausfällen.

Handelt es sich beim Kunden um eine Privatperson, können personenbezogene Daten ausgespäht werden. Dies führt zur Verletzung des informationellen Selbstbestimmungsrechts der betreffenden Person. Neben zivilrechtlichen Konsequenzen kann dies negative Auswirkungen auf das Unternehmensimage nach sich ziehen.

• Mögliche Folgen bei Verletzung der Integrität:

Wenn Daten bei der Übertragung vom Tablet PC an den Server manipuliert oder aufgrund eines Softwarefehlers verloren gehen, besteht die Gefahr, dass Kundenaufträge falsch oder gar nicht ausgeführt werden. Dies kann zu Pflichtverletzungen bei Verträgen führen, was der Beziehung zum Kunden schadet oder gar Rechtsstreitigkeiten zur Folge haben kann. Die Nichterfüllung oder Falschausführung von Aufträgen sowie eventuelle Rechtsstreitigkeiten richten finanzielle Schäden an.

Mögliche Folgen bei Verletzung der Verfügbarkeit werden im folgenden Kapitel erläutert.

7.5.3.2 Dienstleistungsausfall

Wenn das App bzw. der Tablet PC nicht oder nur eingeschränkt zur Verfügung steht, kann es zu Dienstleistungsausfällen kommen.

• Folgen für die Gartenplanung GmbH:
  • Notwendige Schnittstellen können wegfallen. Das App wird nicht mehr funktionieren und muss angepasst oder auf ein anderes System portiert werden. Dies führt zu Umsatzausfällen und zusätzlichen Kosten für die Anpassung bzw. Portierung.
  • Im Betrieb stellt sich heraus, dass weitere Schnittstellen für den reibungslosen Betrieb notwendig sind. Wenn diese Schnittstelle vom Betriebssystem nicht angeboten wird, muss das App auf ein anderes portiert werden. Das führt zu höheren Kosten als ursprünglich vorgesehen.
  • Die Hardware entspricht nicht den Anforderungen und muss gewechselt werden. Eventuell läuft das App auf der neuen Plattform nicht mehr. Wenn das Betriebssystem auf keinen alternativen Hardwareplattformen lauffähig ist, muss das App portiert werden. Dies führt zu höheren Kosten.
  • Das App kann von zentraler Stelle (Android Market oder Apple App Store) deaktiviert werden. Im schlimmsten Fall ist die Anwendung auf absehbare Zeit nicht nutzbar. Der gesamte Gartenplanungsprozess muss angepasst werden, da nicht mehr auf die Tablett PC Variante gesetzt werden kann. Dies kann zu Umsatzverlusten und zusätzlichen Kosten führen.

• Folgen für die GK Software GmbH:
  • Notwendige Schnittstellen können wegfallen. Das App wird nicht mehr funktionieren und muss angepasst oder auf ein anderes System portiert werden. Das App kann bis zur erfolgten Anpassung nicht an andere Gartenplanungsunternehmen verkauft werden. Dies führt zu Umsatzausfällen und zusätzlichen Kosten für die Anpassung bzw. Portierung.
  • Das App kann von zentraler Stelle (Android oder Apple App Store) nicht zugelassen oder zu einem späteren Zeitpunkt deaktiviert werden. Im schlimmsten Fall ist die Anwendung auf absehbare Zeit nicht nutzbar. Ist eine Einigung mit dem Betreiber des Market nicht möglich, kann dies zu Umsatzverlusten und Vertragsstrafen führen.
  • Der Entwicklungsaufwand ist größer als kalkuliert. Führt zu höheren Kosten bei der Entwicklung des Apps und eventuell zu Vertragsstrafen, da das App verspätet übergeben wird.

7.5.4 Risikobewertung

Die zuvor identifizierten Gefahren und deren mögliche Folgen werden in diesem Kapital bewertet. Ziel dabei ist es festzustellen, bei welchem System das geringste Risiko zu erwarten ist. Um das Risiko zu ermitteln werden die beiden Größen “Eintrittswahrscheinlichkeit” und “Schadenshöhe” zueinander in Bezug gebracht. Die Eintrittswahrscheinlichkeiten der ermittelten Gefahren lassen sich nicht in Zahlen messen. Hierfür ist der Einblick in beide Systeme zu gering bzw. die Vorhersehrbarkeit zukünftiger Entscheidungen von Apple und Google sind ungewiss. So lässt sich beispielsweise keine prozentuale Wahrscheinlichkeit festlegen, ob eine bestimmte Schnittstelle in Zukunft entfernt wird. Deshalb soll die Einschätzung der Schadenshöhe und Eintrittswahrscheinlichkeiten der Gefahren auf einer Ordinalskalar bewertet werden. Für die Ermittlung der Eintrittswahrscheinlichkeiten der Gefahren wurden folgende Kategorien gewählt:

• Sehr gering: Der Eintritt des gefährdenden Ereignisses ist vernachlässigbar
• Gering: Der Eintritt des gefährdenden Ereignisses ist unwahrscheinlich
• Mittel: Durchschnittliche Wahrscheinlichkeit, dass das gefährdende Ereignis eintreten wird
• Hoch: Das gefährdende Ereignis wird mit hoher Wahrscheinlichkeit eintreten

Bezüglich der Schadenshöhe wurden folgende Kategorien gewählt:

• Sehr gering: Der Schaden ist komplett vernachlässigbar
• Gering: Geringe finanzielle Verluste, die das Überleben der Unternehmung nicht gefährden
• Mittel: Mittlere finanzielle Verluste, die zwar nicht zwangsläufig zum Konkurs führen, das Überleben der Unternehmung ist jedoch nicht gesichert
• Exzistenzvernichtend: Der Schaden führt zum Konkurs der Unternehmung

Die Bewertung kann hier nur subjektiv erfolgen. Bei einer späteren Verwertung der Arbeit für einen konkreten Fall ist daher unbedingt eine Neubewertung entsprechend den dann geltenden Bedingungen vorzunehmen.

Um den Umfang dieser Arbeit nicht zu überschreiten, sollen in den folgenden Kapiteln nur noch die Risiken der GK Software GmbH betrachtet werden.

7.5.4.1 Dienstleistungsausfall

7.5.4.1.1 Android

Im Folgenden werden die ermittelten Gefahren für Android bewertet, indem Eintrittswahrscheinlichkeit und Schadeshöhe der Gefahr zugeordnet werden.

• Notwendige Schnittstellen können wegfallen.

Es ist bisher nicht bekannt, dass das AOSP bestehende Schnittstellen entfernt hat. In den CDD ist sogar ausdrücklich festgelegt, dass Entwickler Schnittstellen implementieren müssen, wenn diese von einer Komponente zur Verfügung gestellt werden. Selbst wenn das AOSP zukünftig wichtige Schnittstellen im Android Betriebssystem entfernen würde, ließen diese sich aufgrund der Quelloffenheit Androids erneut einfügen. Die Wahrscheinlichkeit, dass Schnittstellen entfernt werden, kann somit als sehr gering bezeichnet werden. Die Schadenshöhe ist als gering zu bewerten, da lediglich geringe Programmieraufwände zu erwarten sind.

• Im Betrieb stellt sich heraus, dass weitere Schnittstellen für den reibungslosen Betrieb notwendig sind.

Gründe für den Bedarf weiterer Schnittstellen können beispielsweise Fehler in der Konzeption sein, wenn notwendige Schnittstellen nicht eingeplant worden sind. Zusätzlich können sich die Anforderungen an das App ändern, wodurch ebenfalls neue Schnittstellen notwendig sind. Die Wahrscheinlichkeit, dass ein Bedarf an weiteren Schnittstellen besteht ist schwer ermittelbar. Mittelfristig gesehen, kann das Risiko als gering betrachtet werden, wenn bei der Konzeption keine elementaren Fehler gemacht wurden.
Wie auch bei der Gefahr des Wegfalls einer Schnittstelle, können bei quelloffenen Systemen wie Android Schnittstellen hinzuprogrammiert werden, falls diese nicht bereits standardmäßig vom Betriebssystem zur Verfügung gestellt werden. Somit entsteht in diesem Fall nur ein geringer Schaden für die Hinzuprogramierung der Schnittstelle. Je nach Komplexität der Schnittstelle kann die Schadenshöhe jedoch variieren.

• Die Hardware entspricht nicht den Anforderungen und muss gewechselt werden.

Im Betrieb kann sich herausstellen, dass die Hardware nicht den Anforderungen entspricht. Beispielsweise kann die Anforderung an die Leistungsfähigkeit der Hardware höher sein als erwartet. Die Wahrscheinlichkeit hierfür kann als mittel betrachtet werden, da es zu viele Unsicherheiten gibt. Beispielsweise kann sich in der Entwicklung des Apps herausstellen, dass das App mehr Hardwareressourcen benötigt als erwartet. Hier muss geprüft werden, ob das jeweilige Endgerät nachgerüstet werden kann. Im schlimmsten Fall muss ein alternatives Endgerät eingesetzt werden. Da Android inklusive der Apps durch die Richtlinien der CDD auf den gängigsten Plattformen lauffähig ist, kann problemlos ein Alternativprodukt gefunden werden. Als Schaden fallen vor allem die Preise für neue Endgeräte und deren Konfiguration an. Der Kauf von neuen Endgeräten ist zwar mit Kosten verbunden, jedoch entsteht hierdurch in der Regel keine Existenzgefährdung. Der Schaden wird somit als gering kategorisiert.

• Das App kann von zentraler Stelle deaktiviert werden.

Google besitzt die Möglichkeit installierte Android Apps zu deaktivieren. Mögliche Gründe für eine Deaktivierung sind im “Android Market Developer Distribution Agreement” aufgeführt. Nach dieser Vereinbarung kann Google Apps deaktivieren, wenn diese:

• Rechte Dritter verletzen
• gegen geltendes Recht verstoßen
• pornografische Inhalte enthalten
• schädliche Inhalte, beispielsweise Viren, enthalten
• Google oder den Hersteller des Endgerätes für etwas haftbar macht
• wenn sonstige Verstöße gegen das “Android Market Developer Distribution Agreement” oder gegen Bedingungen des Endgeräte-Herstellers vorliegen^[65]

Im “Developer Distribution Agreement” führt Google jedoch an, dass das Unternehmen keine Absichten verfolgt, Apps zu überwachen und deaktivieren. Stattdessen würde Google eine Prüfung nur durchführen, wenn Hinweise für eine Verletzung des “Developer Distribution Agreements” vorliegen. Ob eine Verletzung der Vereinbarung vorliegt, liegt dabei im eigenen Ermessen von Google^[66].

Im Gegensatz zu Apple ist in der Vertragsvereinbarung von Google eine Entschädigung für User vorgesehen, deren gekaufte Apps deaktiviert wurden. Voraussetzung ist, dass das App innerhalb eines Jahres nach Kauf deaktiviert wurde. Die Entschädigung muss hierbei der Entwickler des Apps tragen. Der Entwickler muss sämtliche Einnahmen, die er mit dem App getätigt hat, an Google zurückzahlen. Neben den Einnahmen muss auch für eventuell entstandene Schäden oder Kosten des Geldverkehrs (z.B. Transaktionskosten) aufgekommen werden^[67].

Google hat von der Möglichkeit Apps zu deaktiveren bereits Gebrauch gemacht. So wurden 2009 Apps entfernt, mit denen sich das Smartphone G1 als Modem (bspw. um einen PC einen Internetzugang zu ermöglichen) umfunktionieren ließ. Die Deaktivierung erfolgte nach dem der Betreiber des G1 “T-Mobile” Druck auf Google ausgeführt hatte^[68].

Für Android Apps gibt es im Gegensatz zu iPhone OS mehr als nur eine Bezugsquelle. Neben diversen Websites, die Android Apps anbieten, besteht beispielsweise die Möglichkeit das App im .apk-Format (Android package file) auf das Endgerät zu übertragen und dort zu installieren^[69]. Bei dieser Vorgehensweise wäre eine zentrale Deaktivierung des Apps nicht ohne weiteres möglich, da Google nichts über die Existenz des Apps wüsste.

Es konnten keine Hinweise gefunden werden, dass Google im großen Maße Apps deaktiviert. Die Wahrscheinlichkeit das Apps bei Einhaltung des Android Market Developer Distribution Agreements von Google gelöscht werden, kann somit als sehr gering bezeichnet werden. Eine größere Wahrscheinlichkeit bestünde, wenn das App einen Interessenskonflikt mit dem Mobilfunkbetreiber oder Google auslöst. Hier zeigt das Beispiel des G1 Smartphones, dass Google bereit ist, Apps zu deaktivieren.

Da der Entwickler von kostenpflichtigen Apps dazu verpflichtet ist, seine Kunden bei der Deaktivierung von Apps zu entschädigen, hängt die mögliche Schadenshöhe maßgeblich davon ab, wie viel Apps insgesamt im Umlauf gebracht wurden. Die sofortige Leistung von Entschädigungszahlungen kann die GK Software GmbH in Zahlungsschwierigkeiten oder sogar zur Zahlungsunfähigkeit bringen. Nach § 17 Insolvenzordnung ist Zahlungsunfähigkeit ein Insolvenzgrund. Daher wird die Deaktivierung des Gartenplanung Apps im schlimmsten Falle einen existenzvernichtenden Schaden anrichten.

• Der Entwicklungsaufwand ist größer als kalkuliert.

Jedes größere Softwareprojekt birgt das Risiko, dass die zuvor vorgenommene Kalkulation vom tatsächlichen Entwicklungsaufwand abweicht. Bei der Entwicklung von Android Apps kommt erschwerend hinzu, dass die Programmierung an strenge Richtlinien gebunden ist. Diese Richtlinien sollen die Kompatibilität auf verschiedenen Endgeräten ermöglichen. So müssen beispielsweise diverse Schnittstellen programmiert werden oder unterschiedliche Bildschirmauflösungen diverser Endgeräte berücksichtigt werden. Im Android Market werden Apps nur gelistet, wenn diese den Kompatibilitätstest der CTS bestanden haben^[70]. Durch die große Hardwarevielfalt an Android Endgeräten erhöht sich die Wahrscheinlichkeit, dass zwischen App und einigen Endgeräten eine Inkompalibilität aufkommt, die durch zusätzlichen Programmieraufwand beseitigt werden muss. Die zusätzliche Programmierung sowie das Testen auf Kompatibilität birgt eine hohe Wahrscheinlichkeit, dass Kalkulation und tatsächlicher Aufwand abweichen, wenn keine Pufferzeit eingeplant wird. Verzögerungen bei der Fertigstellung des Apps können im schlimmsten Falle hohe Konventionalstrafen sowie eine Belastung des Verhältnisses zum Kunden nach sich ziehen. Zusätzlich bleiben einkalkulierte Erlöse aus dem Verkauf des Apps aus. Hierdurch kann die GK Software GmbH im schlimmsten Falle zahlungsunfähig werden, so dass dieser Schaden als existenzvernichtend einzustufen ist.

7.5.4.1.2 iPhone OS

Im Folgenden werden die ermittelten Gefahren für iPhone OS bewertet, indem Eintrittswahrscheinlichkeit und Schadeshöhe der Gefahr zugeordnet werden.

• Notwendige Schnittstellen und Technologien können wegfallen.

Apple hat in der Vergangenheit deutlich gemacht, dass die Entscheidung welche Technologien eingesetzt werden, einzig von Apple selbst getroffen werden. So hat Apple bewusst darauf verzichtet, die Flashtechnologie für iPhone OS zu implementieren, obwohl Flash eine weit verbreitete Technologie im Internet ist. So nutzt beispielsweise das Video Portal youtube.com den Adobe Flashplayer zum Abspielen der Videos^[71]. Apple Geschäftsführer Steve Jobs begründete diese Entscheidung in einem offenen Brief. Darin nannte er als Gründe u.a., dass Flash eine veraltete Technologie sei und zudem viele Sicherheitslücken beinhalte^[72]. Da Apple offenbar bereit ist, auch etablierte Technologien nicht zu implementieren, besteht die hohe Wahrscheinlichkeit, dass Apple bei zukünftigen iPhone OS Versionen oder Apple Endgeräten, Technologien nicht mehr unterstützen wird, die unter Umständen elementar für die Funktion des Gartenplanung Apps sind. Im schlimmsten Fall ist das Gartenplanung App auf zukünftigen Apple Geräten nicht mehr lauffähig. Der entstehende Schaden kann als “mittel” kategorisiert werden. Entweder muss eine Neuprogrammierung des Apps stattfinden oder es muss einen Verzicht auf dem Vertrieb der Software für neue Geräte erfolgen.

• Im Betrieb stellt sich heraus, dass weitere Schnittstellen für den reibungslosen Betrieb notwendig sind.

Die Wahrscheinlichkeit, dass ein Bedarf an weiteren Schnittstellen besteht ist schwer ermittelbar. Mittelfristig gesehen, kann das Risiko als gering betrachtet werden, wenn bei der Konzeption keine elementaren Fehler gemacht wurden. Da iPhone OS im Gegensatz zu Android quellgeschlossen ist, ist es nicht möglich weitere Schnittstellen hinzuzuprogrammieren. Somit ist eine Erweiterung des Apps nur begrenzt möglich. Sollten wichtige Schnittstellen bereits bei der Konzeption nicht bedacht worden sein und dies erst in der Entwicklung auffallen, müsste die Entwicklung für iPhone OS abgebrochen werden und das App auf ein anderes System portiert werden. Je nach Aufwand für die Portierung muss mit einem geringen bis mittleren Schaden für den zusätzlichen Programmieraufwand gerechnet werden.

• Die Hardware entspricht nicht den Anforderungen und muss gewechselt werden.

Wie auch beim Android System kann sich bei der Entwicklung des Apps herausstellen, dass das App mehr Hardware-Ressourcen benötigt als erwartet. Die Wahrscheinlichkeit kann auch hier als mittel eingeschätzt werden. iPhone OS ist nur auf Apple Endgeräten lauffähig. Sollte sich das eingesetzte Endgerät in der Praxis als ungeeignet erweisen, gibt es kaum Möglichkeiten ein alternatives Gerät zu finden. Hierbei kann nur auf die Apple Produktfamilie zurückgegriffen werden. Im Tablet PC Bereich steht zurzeit sogar ausschließlich das iPad in verschiedenen Produktvarianten zur Verfügung. Auch eine Aufrüstung des iPads ist nicht möglich. So lässt sich weder eigenständig der Akku austauschen noch der Speicher erweitern^[73]. Im schlimmsten Fall wird das App nicht lauffähig sein und kann somit nicht eingesetzt werden. Wenn dies erst nach Fertigstellung des Apps erkenntlich wird, gibt es kurzfristig keine Möglichkeit den Vertrag mit der Gartenplanung GmbH fristgerecht zu erfüllen. Hier drohen hohe Konventionalstrafen, Umsatzausfälle, da das App nicht weiter vertrieben werden kann sowie Kosten für die Portierung auf ein alternatives System. Der größtmögliche Schaden wäre eine Zahlungsunfähigkeit der GK Software GmbH. Somit ist der Schaden als existenzvernichtend einzustufen.

• Das App kann von zentraler Stelle deaktiviert werden.

Apps für Apple Systeme lassen sich ausschließlich über den Apple App Store beziehen. Eine andere Möglichkeit Software auf das iPad zu installieren gibt es nicht. Darüber hinaus verfügt Apple ähnlich wie Google auch über die Möglichkeit Apps zu deaktivieren. In der Vergangenheit wurde bereits mehrfach von dieser Möglichkeit Gebrauch gemacht. Das Internet Magazin “Mac Rumors” berichtet, dass alleine im Februar 2010 über 5.000 Apps von Apple deaktiviert wurden. Dies seien 3% aller damals zur Verfügung stehenden Apps gewesen. Die Löschung der Apps wurde durchgeführt, da diese von Apple als sexuell anstößig eingestuft worden^[74].

Doch nicht nur Apps mit sexuellen Inhalten wurden gelöscht. Auch Apps, die auf dem Dienst “Google Voice” des Konkurrenten Google zurückgreifen, wurden gelöscht. Bei Google Voice handelt es sich um einen Dienst mit dem über das Internet telefoniert werden kann^[75].

Als Begründung für die Löschung sämtlicher auf Google Voice basierender Apps führte Apple an, dass der Dienst die gleichen Funktionen wie das Betriebssystem iPhone OS bereitstelle (Internettelefonie)^[76].

Die Wahrscheinlichkeit, dass das Gartenplanungsapp aus dem App Store entfernt wird, kann langfristig im mittleren Bereich gesehen werden. Dies begründet sich aus der Deaktivierung von tausenden Apps. Hier muss jedoch zur Relativierung hinzugefügt werden, dass die deaktivierten Apps hauptsächlich aus sexuellen Gründen deaktiviert wurden. Das Beispiel der auf Google Voice basierenden Apps zeigt jedoch, dass Apple auch Apps entfernt, wenn diese eine Konkurrenz zu eigenen Produkten darstellen oder auf einer Technologie der Konkurrenz basieren.

Im Gegensatz zu Android Apps gibt es bei iPhone OS keine Möglichkeit, die Apps auf einer anderen Plattform als über den Apple App Store zu vertreiben. Somit lässt sich bei einer Deaktivierung des Apps seitens Apple dem Anwender das App nicht mehr zur Verfügung stellen. Das App kann also nicht weiter vertrieben werden. Anders als bei Android gibt es bei Apple keine Vertragsbedingungen, die dem Entwickler verpflichtet die Käufer des Apps zu entschädigen. Der entstehende Schaden beschränkt sich also auf ausbleibende Verkaufserlöse. Allerdings besteht die Möglichkeit, dass das App sofort nach Veröffentlichung deaktiviert oder gar nicht erst zugelassen wird. In diesem Falle fallen als Schaden die gesamten Entwicklungskosten an. Wenn diese sich über Monate hingezogen haben, kann der Schaden im schlimmsten Falle als existenzvernichtend bezeichnet werden.

• Der Entwicklungsaufwand ist größer als kalkuliert.

Wie bei jedem Softwareprojekt kann es auch bei der Entwicklung von Apps für das iPhone OS zu Fehlkalkulationen kommen. Im Gegensatz zu Android müssen aber weniger Vorgaben beachtet werden, da das Gartenplanung App nicht mit einer Vielzahl von Endgeräten kompatibel sein muss. Lediglich die Kompatibilität mit dem iPad muss sichergestellt werden. Dies vermindert die Wahrscheinlichkeit, dass eventuelle Inkompatibilitäten mit Endgeräten auftreten und ein zusätzlicher Programmieraufwand entsteht. Daher kann die Wahrscheinlichkeit als gering betrachtet werden. Erwartete Schäden sind schlimmstenfalls hohe Konventionalstrafen und eine Belastung des Verhältnisses zum Kunden. Zusätzlich bleiben einkalkulierte Erlöse aus dem Verkauf des Apps aus. Hierdurch kann die GK Software GmbH im schlimmsten Falle zahlungsunfähig werden, so dass dieser Schaden als existenzvernichtend einzustufen ist.

7.5.5 Ergebnisse der Szenarioanalyse

Die Ergebnisse der Szenarioanalyse sind in nachfolgender Tabelle dargestellt.

In Abbildung 1 sind die Ergebnisse grafisch dargestellt.

Die Szenarioanalyse zeigt, dass beide Alternativen für Entwickler Risiken bergen. Risikopotential bei Android liegt insbesondere bei dem komplexen Entwicklungsprozess für Apps. Hierbei müssen eine Vielzahl von Richtlinien des CDD eingehalten werden und die Kompatibilität mit einer Vielfalt an verschiedenen Endgeräten sichergestellt werden. Dies kann den Entwicklungsaufwand deutlich erhöhen. Weiterhin birgt eine Klausel im Android Market Developer Distribution Agreement das Risiko, dass Käufer entschädigt werden müssen, sollte Google von der Möglichkeit gebrauch machen ein App zu entfernen. Die Vorteile von Android zeigen sich jedoch in der großen Anpassbarkeit, da das Betriebssystem quelloffen ist. Somit lassen sich Schnittstellen hinzuprogrammieren oder erweitern. Die große Hardwarevielfalt an androidfähigen Endgeräten erhöht zwar den Entwicklungsaufwand, bringt aber den Vorteil, dass das App auf Endgeräten verschiedener Hersteller lauffähig ist.

iPhone OS hat die Schwachstelle, dass einzig Apple bestimmt welche Schnittstellen und Technologien zur Verfügung stehen. Dies birgt die Gefahr, dass in Zukunft wichtige Schnittstellen bzw. Technologien wegfallen, die für die Funktion eines Apps elementar sind. Auch ist es nicht möglich weitere Schnittstellen hinzuzuprogrammieren, da iPhone OS ein quellgeschlossenes Betriebssystem ist. Wie auch bei Android besteht bei iPhone OS das Risiko, dass das App von Apple aus dem App Store entfernt und auf allen Apple Geräten deaktiviert wird. Diese Vorgehensweise wird von Apple weit aus häufiger genutzt als von Google. Eine zusätzliche Schwachstelle von iPhone OS ist, dass es zurzeit nur auf einem einzigen Tablet PC (dem iPad) lauffähig ist. Ein Wechsel des Endgerätes ist deshalb nicht möglich. Vorteil von iPhone OS ist hingegen der geringere Entwicklungsaufwand für Apps.

7.6 Risiko-Vergleich offene und geschlossene Systeme

Das Ziel dieser Arbeit war ein Risikovergleich zwischen offenen und geschlossen Systemen. Bei der Bearbeitung dieser Fallstudie hat sich jedoch herausgestellt, dass es sich beim verglichenen System iPhone OS nicht um ein vollkommen geschlossenes System handelt. Stattdessen handelt es sich bei iPhone OS um ein halboffenes System, da es Schnittstellen für die Kommunikation mit der Umwelt bereithält. Somit ist kein Risikovergleich zwischen einem offenem und geschlossenem System durchgeführt worden sondern zwischen einem offenen und halboffenen. Generell hat sich beim Vergleich beider Systeme gezeigt, dass offene Systeme weniger Risiken bergen, da sie anpassungsfähiger sind und auf geänderte Umweltbedingungen flexibler reagieren können. Die Risiken, die bei Android höher eingestuft wurden als beim iPhone OS beruhen nicht auf der Eigenschaft von offenen Systemen sondern auf Richtlinien, die Google dem Android System aus Kompatibilitätsgründen auferlegt.

8 Schlussbetrachtung

Zusammenfassend lässt sich festhalten, dass Android für den Entwickler mehr Flexibilität und Freiheiten bei der Entwicklung von Apps bereithält als iPhone OS. Dadurch ist das Risiko, dass das App zuküntig nicht mehr lauffägig ist, geringer. Android Systeme haben dagegen den Nachteil, dass der Entwicklungsaufwand in der Regel größer ist als bei iPhone OS. Zudem müssen im Falle einer Deaktivierung des Apps Entschädigungen an die Käufer gezahlt werden.

Bei der Ergebnisbetrachtung muss jedoch bedacht werden, dass die Einordnungen der Wahrscheinlichkeiten und Schadenshöhen einer subjektiven Einschätzung unterliegen, da keine genauen verwertbaren Zahlen vorlagen.

Die Ergebnisse lassen sich jedoch nicht direkt auf offene und geschlossene Systeme übertragen. Bei Durchführung der Fallstudie wurde festgestellt, dass iPhone OS nicht als komplett geschlossenes sondern eher als halboffenes System betrachtet werden kann. Zudem basieren einige Risiken von Android nicht auf typische Eigenschaften von offenen Systemen sondern auf Richtlinien und Beschränkungen die Google dem System auferlegt. Somit konnte das Ziel der Fallstudie, einen Risikovergleich zwischen einem offenen und einem geschlossenen System durchzuführen, nicht erreicht werden. Dennoch konnte aufgezeigt werden, dass je offener ein System ist, die Risiken für Entwickler sinken.

In dieser Fallstudie wurden ausschließlich Risiken bewertet, die im Falle eines Dienstleitungsausfall bestehen. Anders als eingeplant, wurden wichtige Aspekte der Datensicherheit, beispielsweise Datenintegrität und Vertraulichkeit nicht in der Risikoanlyse behandelt. Grund hierfür war einerseits eine Unterschätzung des Zeitaufwandes der gesamten Fallstudie als auch die Unterschätzung des Umfanges der alleine durch die Betrachtung des Dienstleistungsausfalles zustande kam. Für eine fundierte Entscheidungsfindung sollte der Aspekt der Datensicherheit berücksichtigt werden. Nach der Risikoanlyse wäre der nächste Schritt, für die ermittelten Risiken Gegenmaßnahmen zu finden.

9 Fußnoten

1. ↑ Bundeszentrale für politische Bildung
2. ↑ vgl. Das Digitale Wörterbuch der deutschen Sprache des 20. Jahrhunderts
3. ↑ Mock, Ralf, S. 2
4. ↑ vgl. Bues, Manfred, S. 19
5. ↑ Bues, Manfred, S. 22
6. ↑ Wheeler, Tom, S. 4
7. ↑ vgl. Bues, Manfred, S. 23
8. ↑ vgl. Bues, Manfred, S. 27
9. ↑ vgl. Bues, Manfred, S. 28
10. ↑ vgl. Bues, Manfred, S. 29
11. ↑ vgl. Bues, Manfred, S. 24f
12. ↑ vgl. Wheeler, Tom, S. 4
13. ↑ vgl. Bues, Manfred, S. 19
14. ↑ vgl. Göldi, Andreas
15. ↑ Göldi, Andreas
16. ↑ vgl. Göldi, Andreas
17. ↑ vgl. Bues, Manfred, S. 19
18. ↑ vgl. Schiffner, Thomas, S. 4
19. ↑ vgl. Schiffner, Thomas, S. 6
20. ↑ vgl. Schiffner, Thomas, S. 5
21. ↑ Henning, Stephan, S. 93ff
22. ↑ vgl. Renner, Thomas; Vetter, Michael; Rex, Sascha; Kett, Holger, S. 21
23. ↑ Apache License
24. ↑ Renner, Thomas; Vetter, Michael; Rex, Sascha; Kett, Holger, S. 19
25. ↑ vgl. Henning, Stephan, S. 7
26. ↑ vgl. Henning, Stephan, S. 17f
27. ↑ vgl. Renner, Thomas; Vetter, Michael; Rex, Sascha; Kett, Holger, S. 17
28. ↑ vgl. ITWissen
29. ↑ vgl. ITWissen
30. ↑ vgl. About the Android Open Source Project
31. ↑ vgl. Android Philosophy and Goals
32. ↑ vgl. Android 2.2 Platform
33. ↑ vgl. Android Compatibility
34. ↑ vgl. Android Compatibility Program Overview
35. ↑ vgl. Android CDD, S. 17 – 22
36. ↑ vgl. Android Market
37. ↑ vgl. Wikitude World Browser
38. ↑ vgl. Android Licenses
39. ↑ vgl. Wentz, Dr. Rolf-Christian
40. ↑ vgl. iPhone OS Overview
41. ↑ vgl. iPad Technische Daten
42. ↑ vgl. Apple iPad: Details über das iPhone OS 3.2
43. ↑ vgl. Apple iPhone OS Wikipedia
44. ↑ vgl. iTunes
45. ↑ vgl. Stelzer, Dirk, S. 2
46. ↑ vgl. Prokein, Oliver, S. 7
47. ↑ vgl. Stelzer, Dirk, S. 2
48. ↑ Koenigs, Hans-Peter, S. 9
49. ↑ vgl. Koenigs, Hans-Peter, S. 9
50. ↑ vgl. Prokein, Oliver, S. 11
51. ↑ vgl. Koenigs, Hans-Peter, S. 9
52. ↑ vgl. Prokein, Oliver, S. 13
53. ↑ vgl. Koenigs, Hans-Peter, S. 10
54. ↑ vgl. Koenigs, Hans-Peter, S. 10
55. ↑ vgl. Stelzer, Dirk, S. 2
56. ↑ vgl. Stelzer, Dirk, S. 3f
57. ↑ vgl. Freiling, Jens: S. 12ff
58. ↑ BSI Grundschutzkatalog S. 56
59. ↑ BSI Grundschutzkatalog S. 50
60. ↑ BSI Grundschutzhandbuch S. 56
61. ↑ vgl. BSI Grundschutzkatalog S. 49
62. ↑ BSI Grundschutzkatalog S. 51
63. ↑ vgl. Perez, Marin
64. ↑ vgl. Perez, Marin
65. ↑ vgl. Android Market Developer Distribution Agreement, Punkt 7.2
66. ↑ vgl. Android Market Developer Distribution Agreement, Punkt 7.2
67. ↑ vgl. Android Market Developer Distribution Agreement, Punkt 7.2
68. ↑ vgl. Mick, Jason
69. ↑ vgl. All4Phones
70. ↑ vgl. Android Compatibility
71. ↑ vgl. Google Support
72. ↑ vgl. Apple Thoughts on Flash
73. ↑ vgl. TabletPCs Kindle, iPad & Co
74. ↑ vgl. Macrumors.com
75. ↑ vgl. Google Voice on iphone
76. ↑ vgl. Apple: Google Voice aus AppStore entfernt

10 Literatur- und Quellenverzeichnis