Lade Inhalt...

Wirtschaftlichkeitsanalyse einer Umstellung von Client/Server- auf Terminalserver-Architektur im Bereich klassischer Office-Anwendungen

©2008 Diplomarbeit 89 Seiten

Zusammenfassung

Inhaltsangabe:Einleitung:
Seit der Ablösung des hostbasierten Netzwerkparadigmas durch Personal Computer (PC) in den 80er Jahren, steigen die Anforderungen an die Desktop-PC's. Immer höhere Leistung der Hardware, aber auch eine hohe Anzahl an Programmen, mit immer höheren Systemanforderungen ließen die PC's zu sehr leistungsfähigen Rechnern werden. Doch mit der Leistung stieg auch die Komplexität der Systeme. Diese Komplexität macht es den Administratoren schwer, das Netzwerk zu kontrollieren und zu supporten. Dies ist vor allem durch die Komplexität, Größe und Menge der clientseitigen Software und durch heterogene Umgebungen bedingt, in denen die Softwareversionen schwer aktuell und einheitlich zu halten sind. Dadurch werden PC-basierte Netzwerke immer schwieriger zu administrieren und Change Management-Prozesse somit immer schwieriger umzusetzen. Seit einiger Zeit wird daher in der IT-Presse immer häufiger das Thema Terminalserver-Systeme bzw. das synonym verwendete Server Based Computing (SBC) als Alternative zur klassischen Client/Server-Architektur diskutiert. Gemeint sind Betriebssystem-Plattformen, die es ermöglichen die clientseitigen Anwendungen auf einem zentralen Server zu betreiben und lediglich Tastatur- und Mauseingaben sowie das Bildschirmbild zwischen Client und Server zu transportieren. Antrieb sich für diese Technologien zu interessieren sind vor allem wirtschaftliche Gründe, aber auch Stabilität und Verfügbarkeit der Systeme.
Von den Herstellern und den Analysten werden erhebliche Kosteneinsparungsmöglichkeiten suggeriert, die daraus resultieren sollen, dass eine zentrale Administration möglich ist und so keine Verteilung der Software auf die einzelnen Clients erfolgen muss.
Diese Arbeit beschäftigt sich mit der Wirtschaftlichkeitsanalyse einer Umstellung von der klassischen Client/Server-Technologie auf die Terminalserver-Technologie. Es konkurrieren also die Entscheidung für die Beibehaltung der bisherigen Client/Server- Architektur und die Entscheidung für eine Umstellung auf die Termialserver-Architektur. Da im Bereich klassischer Office-Anwendungen das größte Einsparungspotenzial zu erwarten ist, beschränkt sich diese Arbeit auf diese Art von Anwendungen. Zu untersuchen ist, ob sich durch eine Umstellung wirklich erhebliche Einsparungen und dadurch ein höherer Nutzen ergibt. Dabei soll nicht nur die Kostenseite betrachtet werden, sondern auch der nicht quantifizierbare Nutzen der Entscheidung, wie zum Beispiel die […]

Leseprobe

Inhaltsverzeichnis


Jens Goldelius
Wirtschaftlichkeitsanalyse einer Umstellung von Client/Server- auf Terminalserver-
Architektur im Bereich klassischer Office-Anwendungen
ISBN: 978-3-8366-2283-7
Herstellung: Diplomica® Verlag GmbH, Hamburg, 2009
Zugl. FOM - Fachhochschule für Oekonomie und Management Essen, Essen,
Deutschland, Diplomarbeit, 2008
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden und der Verlag, die Autoren oder
Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für evtl.
verbliebene fehlerhafte Angaben und deren Folgen.
© Diplomica Verlag GmbH
http://www.diplomica.de, Hamburg 2009

Inhaltsverzeichnis
Abbildungsverzeichnis
vi
Tabellenverzeichnis
vii
1
Einleitung
1
2
Grundlagen / Begriffsabgrenzungen
3
2.1
Netzwerkumgebungen
. . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1.1
¨
Uberblick . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.1.2
Klassische Client/Server-Architektur
. . . . . . . . . . . . .
3
2.1.3
Terminalservertechnologie . . . . . . . . . . . . . . . . . . .
5
2.2
Klassische Office-Anwendungen . . . . . . . . . . . . . . . . . . . .
10
2.3
Methoden der Wirtschaftlichkeitsanalyse . . . . . . . . . . . . . . . .
10
2.3.1
Einordnung der Wirtschaftlichkeitsanalyse
. . . . . . . . . .
10
2.3.2
Abgrenzung Wirtschaftlichkeitsberechnung und Kosten/Nutzen-
Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3.3
Arten der Wirtschaftlichkeitsberechnungen . . . . . . . . . .
12
2.3.4
Grundlagen der Kostenanalyse mit Hilfe der Total Cost of Ow-
nership-Analyse
. . . . . . . . . . . . . . . . . . . . . . . .
13
2.3.5
Grundlagen der Nutzenanalyse . . . . . . . . . . . . . . . . .
15
3
Kostenanalyse
21
3.1
Ermittlung der direkten Kosten . . . . . . . . . . . . . . . . . . . . .
21
3.1.1
Annahmen der Kostenanalyse direkter Kosten . . . . . . . . .
22
3.1.2
Eingaben in den Costanalyzer . . . . . . . . . . . . . . . . .
25
3.1.3
Ergebnis/Auswertung des Costanalyzers . . . . . . . . . . . .
31
3.1.4
Migrationskosten . . . . . . . . . . . . . . . . . . . . . . . .
33
3.1.5
Interpretation der Kostenauswertung . . . . . . . . . . . . . .
33
3.2
Ermittlung der indirekten Kosten . . . . . . . . . . . . . . . . . . . .
33
3.2.1
Downtime . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
3.2.2
End-User-Operations . . . . . . . . . . . . . . . . . . . . . .
34
3.3
Gesamtkosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
4
Nutzenanalyse
36
4.1
Quantifizierbarer Nutzen . . . . . . . . . . . . . . . . . . . . . . . .
36
4.2
Nicht quantifizierbarer Nutzen . . . . . . . . . . . . . . . . . . . . .
36
4.3
Nutzwertanalyse
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
36

I
NHALTSVERZEICHNIS
Seite ii
4.3.1
K.O.-Kriterien definieren . . . . . . . . . . . . . . . . . . . .
37
4.3.2
Sammeln von Alternativen . . . . . . . . . . . . . . . . . . .
37
4.3.3
Verwerfen von Alternativen, die eines der K. O.-Kriterien erf¨ullen 37
4.3.4
Definition und Gewichtung der Zielkriterien . . . . . . . . . .
37
4.3.5
Erf¨ullung der Teilziele je Alternative bewerten . . . . . . . .
40
4.3.6
Berechnung der gewichteten Teilziel- und Gesamtzielerf¨ullung
je Alternative . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.3.7
Begr¨undung der Gewichtung und Bewertung . . . . . . . . .
43
4.3.8
Auswahl der besten Alternative
. . . . . . . . . . . . . . . .
46
4.3.9
Sensibilit¨atsanalyse . . . . . . . . . . . . . . . . . . . . . . .
46
4.4
Ermittlung und Bewertung des Gesamtnutzens . . . . . . . . . . . . .
47
4.4.1
Bewertung quantifizierbaren Nutzens . . . . . . . . . . . . .
47
4.4.2
Bewertung nicht quantifizierbaren Nutzens . . . . . . . . . .
47
5
Wirtschaftlichkeitsbetrachtung
49
5.1
Wirtschaftlichkeitsanalyse als Unterst¨utzung der Entscheidungsfindung
49
5.1.1
Vorbetrachtungen . . . . . . . . . . . . . . . . . . . . . . . .
49
5.1.2
Die Kosten-Vergleichsrechnung als Methode f¨ur die Wirtschaft-
lichkeitsberechnung
. . . . . . . . . . . . . . . . . . . . . .
50
5.2
Bewertung des nicht quantifizierbaren Nutzens
. . . . . . . . . . . .
52
5.2.1
User-spezifische Kriterien . . . . . . . . . . . . . . . . . . .
52
5.2.2
IT-Organisationsspezifische Kriterien . . . . . . . . . . . . .
53
5.2.3
Sicherheitsrelevante Kriterien . . . . . . . . . . . . . . . . .
53
5.2.4
Kundenorientierte Kriterien . . . . . . . . . . . . . . . . . .
53
5.3
Risikoanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
5.4
Entscheidungshilfe Thin-Client oder Thick-Client . . . . . . . . . . .
54
5.5
Kritische Gesamtbewertung . . . . . . . . . . . . . . . . . . . . . . .
56
5.5.1
Stabilit¨at der Alternativen
. . . . . . . . . . . . . . . . . . .
56
5.5.2
Einschr¨ankungen der Alternativen . . . . . . . . . . . . . . .
56
5.5.3
Realisierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . .
57
6
Fazit
59
Anh ¨ange
63
A ACE-Costanalyzer
63
A.1 Screenshots der Eingaben . . . . . . . . . . . . . . . . . . . . . . . .
63
A.2 Originalergebnisse der Auswertungen . . . . . . . . . . . . . . . . .
70

I
NHALTSVERZEICHNIS
Seite iii
A.2.1
3-Year Summary: Comparison & Savings . . . . . . . . . . .
70
A.2.2
3-Year Accumulated Costs Comparison - Current Environment
vs. Citrix Solution . . . . . . . . . . . . . . . . . . . . . . .
71
A.2.3
Year-1 Detailed Cost Breakdown Current Environment vs. 100%
Thin-client Appliances Citrix Solution . . . . . . . . . . . . .
72
A.2.4
3-Year Accumulated Costs Comparison Current Environment
vs. 100% Thin-client Appliances Citrix Solution . . . . . . .
73
B Gartner Hype Cycle
74
Literatur
75

Abk ¨
urzungsverzeichnis
ACE
Application Computing Environment
BIOS
Basic Input Output System
bzw.
beziehungsweise
ca.
cirka
CAD
Computer Aided Design
CIO
Chief Information Officer
C/S
Client/Server
EDV
Elektronische Datenverarbeitung
etc.
et cetera
f
folgende
ff
fortfolgende
GPRS
General Packet Radio Service
GSM
Global System for Mobile Communications
HD
Hard Disk
HW
Hardware
IBM
International Business Machines
ICA
Independent Computing Architecture
IPX
Internetwork Packet eXchange
ISDN
Integrated Serverices Digital Network
IT
Informationstechnologie
J
Ja
KBit/s
Kilobit pro Sekunde
K. O.
Knock Out
KNA
Kosten/Nutzen-Analyse
KWh
Kilowattstunde
LAN
Local Area Network
lt.
laut
MBit/s
Megabit pro Sekunde
MS
Mircrosoft
N
Nein
NETBEUI NetBIOS Extended User Interface
NWA
Nutzwertanalyse
o. A.
ohne Autor
o. J.
ohne Jahr
o. S.
ohne Seite p. a.
per annum (pro Jahr)

I
NHALTSVERZEICHNIS
Seite v
PC
Personal Computer
SBC
Server Based Computing
SPX
Sequence Packet eXchange
sog.
sogenannte(n)
SQL
Structured Query Language
SW
Software
T
Tausend
TCO
Total Cost of Ownership
TCP/IP
Transmission Control Protocol / Internet Protocol
TMS
Teminalsever
TSE
Terminal Server Edition
RDP
Remote Desktop Protokoll
u.a.
unter anderem
US
United States
vgl.
vergleiche
VPN
Virtual Private Network
WB
Wirtschaftlichkeitsberechnung
WAN
Wide Area Network
WWW
World Wide Web
XML
Extensible Markup Language
z.B.
zum Beispiel

Abbildungsverzeichnis
1
Client/Server-Prinzip . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2
Terminalserverprinzip . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3
ICA-Protokoll: Darstellungsschicht . . . . . . . . . . . . . . . . . . . . .
8
4
Einflussfaktoren der Entscheidungsfindung
. . . . . . . . . . . . . . . .
11
5
Einteilung der Verfahren f¨ur Wirtschaftlichkeitsberechnungen und Kosten/Nut-
zen Untersuchungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
6
Aufteilung TCO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
7
TCO-Kostenstruktur
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
8
Verteilung der Kosten mit und ohne Citrix . . . . . . . . . . . . . . . . .
32
9
Gesamtkosten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
10
Kriterienbaum und Gewichtung . . . . . . . . . . . . . . . . . . . . . . .
40
11
Grundschema der Entscheidungsunterst¨utzung . . . . . . . . . . . . . . .
50
12
ACE-Costanalyzer Screenshot Schritt 1 . . . . . . . . . . . . . . . . . .
63
13
ACE-Costanalyzer Screenshot Schritt 2 . . . . . . . . . . . . . . . . . .
63
14
ACE-Costanalyzer Screenshot Schritt 3 . . . . . . . . . . . . . . . . . .
64
15
ACE-Costanalyzer Screenshot Schritt 4 . . . . . . . . . . . . . . . . . .
64
16
ACE-Costanalyzer Screenshot Schritt 5 . . . . . . . . . . . . . . . . . .
65
17
ACE-Costanalyzer Screenshot Schritt 5b . . . . . . . . . . . . . . . . . .
65
18
ACE-Costanalyzer Screenshot Schritt 6 . . . . . . . . . . . . . . . . . .
66
19
ACE-Costanalyzer Screenshot Schritt 7 . . . . . . . . . . . . . . . . . .
66
20
ACE-Costanalyzer Screenshot Schritt 8 . . . . . . . . . . . . . . . . . .
67
21
ACE-Costanalyzer Screenshot Schritt 8b . . . . . . . . . . . . . . . . . .
67
22
ACE-Costanalyzer Screenshot Schritt 8c . . . . . . . . . . . . . . . . . .
68
23
ACE-Costanalyzer Screenshot Schritt 9 . . . . . . . . . . . . . . . . . .
68
24
ACE-Costanalyzer Screenshot Schritt 9b . . . . . . . . . . . . . . . . . .
69
25
Costanalyzer Auswertung: Zusammenfassung 3-Jahres-Berechnung . . .
70
26
Costanalyzer Auswertung: Detaillierte 3-Jahres-Berechnung . . . . . . .
71
27
Costanalyzer Auswertung: 1-Jahres-Berechnung mit ThinClients . . . . .
72
28
Costanalyzer Auswertung: Detaillierte 3-Jahres-Berechnung mit Thin Cli-
ents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
29
Gartner Hype Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74

Tabellenverzeichnis
1
Eingaben in den Costanalyzer
. . . . . . . . . . . . . . . . . . . . .
31
2
Ergebnisse des Costanalyzers in
e . . . . . . . . . . . . . . . . . . .
32
3
Summe indirekter Kosten f¨ur 1000 Clients in T
e . . . . . . . . . . .
34
4
Gesamtkosten (Total costs of ownership) in
e f¨ur 3 Jahre . . . . . . .
35
5
Nutzen der Terminalserverumstellung . . . . . . . . . . . . . . . . .
36
6
Zielwertmatrix
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
7
Kostenvergleichsrechnung
. . . . . . . . . . . . . . . . . . . . . . .
51

1 Einleitung
Seit der Abl¨osung des hostbasierten Netzwerkparadigmas durch Personal Computer
(PC) in den 80er Jahren, steigen die Anforderungen an die Desktop-PC's. Immer h¨ohe-
re Leistung der Hardware, aber auch eine hohe Anzahl an Programmen, mit immer
h¨oheren Systemanforderungen ließen die PC's zu sehr leistungsf¨ahigen Rechnern wer-
den. Doch mit der Leistung stieg auch die Komplexit¨at der Systeme. Diese Komplexit¨at
macht es den Administratoren schwer, das Netzwerk zu kontrollieren und zu suppor-
ten. Dies ist vor allem durch die Komplexit¨at, Gr¨oße und Menge der clientseitigen
Software und durch heterogene Umgebungen bedingt, in denen die Softwareversionen
schwer aktuell und einheitlich zu halten sind. Dadurch werden PC-basierte Netzwerke
immer schwieriger zu administrieren und Change Management-Prozesse somit immer
schwieriger umzusetzen.
1
Seit einiger Zeit wird daher in der IT-Presse immer h¨aufiger
das Thema Terminalserver-Systeme bzw. das synonym verwendete Server Based Com-
puting (SBC) als Alternative zur klassischen Client/Server-Architektur diskutiert. Ge-
meint sind Betriebssystem-Plattformen, die es erm¨oglichen die clientseitigen Anwen-
dungen auf einem zentralen Server zu betreiben und lediglich Tastatur- und Mausein-
gaben sowie das Bildschirmbild zwischen Client und Server zu transportieren. Antrieb
sich f¨ur diese Technologien zu interessieren sind vor allem wirtschaftliche Gr¨unde,
aber auch Stabilit¨at und Verf¨ugbarkeit der Systeme.
2
Von den Herstellern und den Analysten werden erhebliche Kosteneinsparungsm¨o-
glichkeiten suggeriert, die daraus resultieren sollen, dass eine zentrale Administration
m¨oglich ist und so keine Verteilung der Software auf die einzelnen Clients erfolgen
muss.
Diese Arbeit besch¨aftigt sich mit der Wirtschaftlichkeitsanalyse einer Umstellung
von der klassischen Client/Server-Technologie auf die Terminalserver-Technologie. Es
konkurrieren also die Entscheidung f¨ur die Beibehaltung der bisherigen Client/Server-
Architektur und die Entscheidung f¨ur eine Umstellung auf die Termialserver-Archi-
tektur. Da im Bereich klassischer Office-Anwendungen das gr¨oßte Einsparungspoten-
zial zu erwarten ist, beschr¨ankt sich diese Arbeit auf diese Art von Anwendungen.
Zu untersuchen ist, ob sich durch eine Umstellung wirklich erhebliche Einsparungen
und dadurch ein h¨oherer Nutzen ergibt. Dabei soll nicht nur die Kostenseite betrachtet
werden, sondern auch der nicht quantifizierbare Nutzen der Entscheidung, wie zum
Beispiel die Akzeptanz der Benutzer.
Die Messgr¨oße der Wirtschaftlichkeitsanalyse ist der monet¨are Nutzen der sich aus
1
Vgl. Sch¨uler,P., C'T - Magazin f¨ur Computertechnik, Office aus dem Netz, 1/2005, S. 178.
2
Vgl. Kaplan, S., Mangus, M., Citrix Server-Based Computing, 2001, S. 26f.

E
INLEITUNG
Seite 2
der Entscheidung f¨ur eines der konkurrierenden Modelle ergibt.
Die Wirtschaftlichkeitsanalyse wird in den folgenden Schritten durchgef¨uhrt.
Zun¨achst werden mit Hilfe der Total Cost of Ownership-Analyse (TCO) die Kos-
ten f¨ur Anschaffung und Betrieb der Infrastrukturen ermittelt. Dabei sollen nicht nur
Hard- und Softwarekosten betrachtet, sondern auch Supportkosten und Kosten, die
durch Verwaltung und Nichtverf¨ugbarkeit des Systems entstehen. Die Kosten werden
auf der Basis eines fiktiven Unternehmens mit 1000 Clients ermittelt.
Da sich in den meisten Unternehmen die etablierte Client/Server-Infrastruktur be-
reits im Einsatz befindet, m¨ussen weiterhin die Umstellungskosten auf die Terminalserver-
Architektur ermittelt werden.
Im Anschluss daran wird der Nutzen ermittelt. Dabei soll der monet¨ar messbare Nut-
zen, also die Ersparnis bei der Entscheidung f¨ur eines der konkurrierenden Modelle,
betrachtet werden. Es sind nat¨urlich auch die Umstellungskosten zu ber¨ucksichtigen
und es muss ermittelt werden, nach wie vielen Jahren sich diese durch Einsparung von
Betriebskosten amortiesieren. H¨aufig werden nur monet¨ar messbare Aspekte in IT-
Projekten betrachtet. In dieser Arbeit soll dar¨uber hinaus auch der nicht direkt messba-
re Nutzen betrachtet werden. Dazu z¨ahlen u.a. Akzepanz der User sowie Performance-
und Verf¨ugbarkeitsaspekte. Dem nicht messbaren Nutzen wird sich mit Hilfe der Me-
thodik der Nutzwertanalyse gen¨ahert.
Im letzten Schritt soll durch Abw¨agung von Kosten und Nutzen die Wirtschaft-
lichkeit beider Modelle ermittelt werden. Dabei muss nicht zwingend eine pauscha-
le Wertung pro oder kontra einer L¨osung gegeben werden. Dies kann diese Arbeit
nicht leisten, da die Berechnung der Kosten und des Nutzens auf der Basis zahlrei-
cher Annahmen durchgef¨uhrt wird, und die Umgebungen zu unterschiedlich und die
Anwendungsf¨alle zu verschieden sind. Es kann aber eine fundierte Analyse geliefert
werden, in welchen Konstellationen sich der Umstieg lohnen kann und wann nicht.
Dies kann Entscheidungstr¨agern als Hilfe dienen, sich f¨ur eines der beiden Modelle zu
entscheiden.

2 Grundlagen / Begriffsabgrenzungen
Im folgenden Kapitel wird der Focus der Diplomarbeit festgelegt. Insbesondere wer-
den die zu betrachtenden Alternativen Client/Server- und Terminalserver-Architektur
aus historischer und technischer Sicht vorgestellt. Weiterhin werden die Methoden zur
Wirtschaftlichkeitsanalyse benannt, definiert und beschrieben.
2.1 Netzwerkumgebungen
2.1.1 ¨
Uberblick
Folgende Umgebungen werden unterschieden:
3
· Host-Umgebungen
· Unix-Umgebungen
· File-Server-Betrieb
· Client/Server-Umgebungen
· Network Computing
· Terminalserver-Umgebungen
Diese Arbeit beschr¨ankt sich auf die in fast jedem Unternehmen zu findende Client/Ser-
ver-Architektur und als m¨ogliche Alternative dazu, die Terminalserver-Architektur.
Diese Alternativen werden daher auch im weiteren Verlauf der Ausarbeitung betrach-
tet.
2.1.2 Klassische Client/Server-Architektur
Technische Grundlagen
Bei Client/Server-Architekturen liegen die Daten auf einem zentralen Server und die
Applikation befindet sich auf einem Client. Der Client stellt eine Anfrage an den Ser-
ver und wird vom Server mit Daten bedient. Die h¨aufigsten Anwendungen sind Daten-
bankabfragen. Der Client sendet eine Anfrage (meist in der Datenbankabfragesprache
SQL) an den in dem Netzwerk installierten Datenbankserver und erh¨alt von diesem
die gew¨unschten Datens¨atze. Hier werden je nach Abfrage viele Datens¨atze ¨uber das
Netzwerk transportiert. Der gr¨oßte Teil der Logik und die grafischen Aufbereitung der
Daten befindet sich jedoch auf dem Client.
4
3
Vgl. Dreyer, C., Citrix Meta Frame, 2002, S. 29.
4
Vgl. Dreyer, C., Citrix Meta Frame, 2002, S. 32f.

G
RUNDLAGEN
/ B
EGRIFFSABGRENZUNGEN
Seite 4
Server
Client
Antwort
Anfrage
www
LAN
WAN
ISDN
Bildererzeugung
+ Business-Logik
+ Darstellung
Datenhaltung
Abbildung 1: Client/Server-Prinzip
Vorteile
Der gr¨oßte Vorteil der Client/Server-Technologie ist die Aufteilung von Daten und Lo-
gik. Der Server wird also mit eventuell aufwendigen Berechnungen der Businesslogik
nicht belastet. Er ist f¨ur das Zusammenstellen der Daten zust¨andig. Die Businesslogik
und die grafische Darstellung wird von jedem einzelnen Client ¨ubernommen. Es wird
von dem Prinzip der Lastverteilung gesprochen.
5
Nachteile
Der gr¨oßte Nachteil dieser Architektur liegt in dem hohen Aufwand f¨ur die Adminis-
tration. Jeder Client muss immer mit der aktuellsten Version der Software ausgestattet
sein. Change Management-Prozesse k¨onnen daher sehr aufwendig sein. Auch wenn es
mittlerweile gute Werkzeuge f¨ur die Verteilung von Software gibt, k¨onnen einige Ein-
stellungen nicht ¨uber das Netz durchgef¨uhrt werden, so dass jeder einzelne User von
Hand bedient werden muss.
6
Da der Client sehr viel der Business-Logik ¨ubernimmt,
kann durch steigende Systemanforderungen bei einem Releasewechsel ein Austausch
der Hardware erforderlich sein. Ein weiterer Nachteil ist, dass den Benutzern die Frei-
heit gelassen wird, die Daten zentral oder lokal abzuspeichern. Weiterhin besteht, wenn
auch h¨aufig durch das Betriebssystem bereits eingeschr¨ankt, die M¨oglichkeit Software
zu installieren oder auch nur Einstellungen vorzunehmen.
5
Vgl. Br¨uggemann, T., Vorlesung: Datenorganisation SS2003, 2003, S. 16ff.
6
Vgl. o.A., Wikipedia.de, IT-Architektur, o. S.

G
RUNDLAGEN
/ B
EGRIFFSABGRENZUNGEN
Seite 5
Je nach Intelligenz des Designs der Anwendungen, werden mehr oder weniger auf-
wendige SQL-Abfragen an den Server gesendet, die auch entsprechend viele Datens¨atze
zur¨uckliefern, die meist nicht alle ben¨otigt werden oder angezeigt werden k¨onnen.
W¨unschenswert w¨are nur ein Transport der ben¨otigten oder darstellbaren Datens¨atze,
um das Netzwerk nicht unn¨otig zu belasten. Fordert ein Benutzer die n¨achste Bild-
schirmmaske an, so werden die n¨achsten Daten abgefragt.
7
2.1.3 Terminalservertechnologie
Das Grundprinzip der Terminalserver-Architektur oder des synonym dazu verwende-
ten Begriff des Server Based Computing ist die zentrale Installation der Anwendung
auf einem zentralen Server und der ¨
Ubertragung der Bildinformationen zum Client.
Tastatur- und Mauseingaben werden auf dem gleichen Weg zum Server ¨ubertragen.
Zum besseren Verst¨andnis, kann die Vorstellung eines sehr langen Maus-, Tastatur-
und Monitorkabels dienen.
Geschichte
Die Idee des Server Based Computing geht auf das X Window-System zur¨uck. 1984
von MIT entwickelt, unterst¨utzte es die M¨oglichkeit von X Windows-Clients aus die
Rechenleistung von UNIX-Servern zu nutzen und dabei nur Bildschirm-, Maus- und
Tastaturinformationen zu ¨ubertragen. Die Firma Citrix in Fort Lauderdale hat sehr
fr¨uh (1989) den Bedarf an der Terminalserver-Technologie erkannt und entwickel-
te den ersten Terminalserver. Der Gr¨under Ed Iacobucci hatte die Idee, dass unter-
schiedliche Computer auf die gleichen Anwendungen zugreifen k¨onnten, ohne das
gleiche Betriebssystem zu haben. Es wurde die Basistechnologie f¨ur den Terminal-
server entwickelt, das so genannte MultiWin. Es setzte auf IBMs OS/2 auf und konnte
mehrere Desktopsessions parallel betreiben. 1993 brachte Citrix ihr erstes Multiuser-
Betriebssystem auf den Markt, das so genannte WinView.
8
Jedoch erst durch die Offenlegung des Quellcodes von Windows NT 3.51 durch Mi-
crosoft, entwickelte Citrix ein Mehrbenutzerbetriebssystem mit dem Namen WinFra-
me. Diese Technologie wurde 1997 von Microsoft aufgekauft und als Windows NT 4.0
Terminal Server Edition (TSE) vermarktet.
9
Bis dato f¨uhrten die Terminalservices ein
Nischendasein und wurden erst durch den Einsatz von Microsoft bekannt.
10
Windows
7
Vgl. Dreyer, C., Citrix MetaFrame und Windows Terminal Services, 2002, S. 33.
8
Vgl. Kaplan, S., Mangus, M., Citrix Server-Based Computing, 2001, S. 53.
9
Vgl. Dreyer, C., Citrix Meta Frame, 2002, S. 27ff.
10
Vgl. Taschkow, N, Praxishandbuch Microsoft Terminal Server und Citrix MetaFrame, 2004, Editorial,
o.S.

G
RUNDLAGEN
/ B
EGRIFFSABGRENZUNGEN
Seite 6
TSE war allerdings nicht ganz identisch mit der Citrix-Technologie. Microsoft nutzte
das eigene RDP-Protokoll an Stelle des ICA (Independent Computing Architecture)-
Protokolls von Citrix. Mit der Verwendung von RDP war der Anwender clientseitig
auf das Betriebssystem Windows festgelegt.
Um dieses Problem zu l¨osen ver¨offentlichte Citrix im Jahre 1998 MetaFrame. Me-
taFrame ist kein eigenes Betriebssystem, sondern setzt auf MS Windows NT 4.0 TSE
auf. MetaFrame verwendet das citrixeingene ICA-Protokoll und ist so clientseitig un-
abh¨angig von Microsoft. MetaFrame wurde stetig weiterentwickelt und bietet viele
Funktionalit¨aten, die ¨uber die Basistechnologie von Microsoft hinaus gehen. Dazu
geh¨oren Lastenverteilung ¨uber ganze Serverfarmen sowie Anwendungs- und Userma-
nagement.
11
Anbieter von Terminalservertechnologien
Citrix ist mit 77% Marktanteil mit Abstand der Marktf¨uhrer im Terminalserverge-
sch¨aft.
12
Daher wird bei der Berechnung und Beschreibung der Eigenschaften immer
von einer Umstellung auf Citrix Produkte ausgegangen. Zwar setzt die Citrix Meta-
Frames Access-Produktlinie auf der Multiuser-F¨ahigkeit von Microsoft Server Be-
triebssystem auf, jedoch liefert nur Citrix die Zussatzprogramme mit, die eine Admi-
nistration und den Webzugriff auf Anwendungen erst m¨oglich machen.
13
Als weitere
Anbieter seien hier GraphOn, Jetro Platforms, NeTraverse und Tarantella genannt.
14
Technische Grundlagen
Die Darstellung der Oberfl¨ache wird auf einem Terminalserver realisiert und lediglich
die Bildschirminformationen werden zum Client ¨ubertragen. Auf dem umgekehrten
Wege werden Tastatur- und Mausinformationen zum Terminalserver gesendet.
Die Programme werden also nicht auf einem Client, sondern auf dem Server aus-
gef¨uhrt. Auf dem Client muss lediglich ein Terminalserver-Client installiert sein, der
die Verbindung zum Server aufbaut und die Bildinformationen darstellt (vergleiche
Abbildung 2).
Dies setzt voraus, dass jedem User ein eigener
"
Bereich" auf dem Server zur Verf¨ugung
steht, im dem er seine Anwendungen ausgef¨uhrt werden. Das Betriebssystem muss al-
so die Trennung der Prozesse, des Speichers und die Abgrenzung von Berechtigungen
11
Vgl. Kaplan, S., Mangus, M., Citrix Server-Based Computing, 2001, S. 55f.
12
Vgl. Rosal,C., Citrix Access Stratgie, o.J., o.S.
13
Vgl. Sch¨uler,P., C'T - Magazin f¨ur Computertechnik, Office aus dem Netz, 2005, S. 179.
14
Vgl. o. A., Windows-Terminal-Server - Dicke Leistung, d¨unne Clients, 2005, o.S.

G
RUNDLAGEN
/ B
EGRIFFSABGRENZUNGEN
Seite 7
realisieren. Jeder Benutzer besitzt einen eigenen Rechtekontext mit Programmen, die
er ausf¨uhren darf.
15
Weiterhin bieten SBC-L¨osungen den Vorteil, dass Anwendungen auch ¨uber das In-
ternet bereitgestellt werden k¨onnen. Die z.B. vom Hersteller Citrix angebotene Citrix
Web Portal Technologie bietet die M¨oglichkeit Anwendungen, die zentral auf einem
Server bereitgestellt werden, ¨uber jeden beliebigen Internetbrowser von intern oder
extern zu nutzen.
16
Terminal-Server Farm
Terminalclient
www
LAN
WAN
GPRS
ISDN
UMTS
Bildschirmbilder
Tastatur- und Maus-Eingaben
Datenhaltung +
Bilderzeugung
Bilddarstellung
Abbildung 2: Terminalserverprinzip
Eine Untersuchung von Gartner Inc. ergab, dass bereits im Jahre 2004 die Server
Based Computing-L¨osungen marktreif waren. Dies geht aus einer sog. HypeCycle-
Studie hervor.
17
(Vgl. dazu Abbildung 29 im Anhang A.3).
Das ICA-Protokoll
Das ICA wurde von Citrix entwickelt und kam erstmals 1998 im MetaFrame-System
zum Einsatz. Die Bildschirm-, Maus- und Tastaturinformationen werden ¨uber das ICA-
Protokoll ¨ubertragen. Da das Protokoll weniger als 5 Kbit/s an Bandbreite ben¨otigt,
um die Eingaben zu ¨ubertragen, reichen schon sehr geringe Bandbreiten aus um eine
gute Performance zu erzielen.
18
Dabei kann zus¨atzlich die SpeedScreen-Technologie
15
Vgl. Dreyer, C., Citrix Meta Frame, 2002, S. 34.
16
Vgl. o.A., Citrix MetaFrame 1.8 bis MetaFraem XP: Funktionsupdate, 2001, S. 268f.
17
Vgl. Fiering, L., et al, Hype Cycle for PC Technologies, 2004, o.S.
18
Vgl. Kaplan, S., Mangus, M., Citrix Server-Based Computing, 2001, S. 59.

G
RUNDLAGEN
/ B
EGRIFFSABGRENZUNGEN
Seite 8
genutzt werden. Diese Technologie erm¨oglicht es die Anwendungsdarstellung zu op-
timieren. Normalerweise m¨usste nach jeder Maus- oder Tastatureingabe das von der
Anwendung neu generierte Bild an den Client gesendet werden. Die SpeedScreen-
Technologie vergleicht allerdings das zuvor an den Client ¨ubertragene Bild mit dem
was f¨ur die kommende ¨
Ubertragung ansteht und bildet die Differenz. ¨
Ubertragen wird
anschließend nur noch die Differenz. Da sich h¨aufig nur ein geringer Anteil des Bild-
schirmbildes ¨andert, kann so die Menge der zu ¨ubermittelnden Informationen auf bis
zu 30% gesenkt werden. Die Darstellungsschicht des ICA-Protokolls ist in Abbildung
3 erl¨autert.
19
Server
Client
Monitor
Monitor
E
the
rnet
100
M
bit
s/
s
Dr
aht
los
es
E
ther
n
et
10 M
b
it/
s
IS
D
N
6
4 K
bi
t/s
M
od
em
28.
8 K
bit
s/
s
Monitor
Mit
SpeedScreen
Darstellungsschicht
Darstellungsschicht
Mit
SpeedScreen
ICA
10 Kbit/s
Monitor
Verbindungsart
Abbildung 3: ICA-Protokoll: Darstellungsschicht
Das ICA-Protokol in der Version 3.0 weist die folgenden Eigenschaften auf. Das
ICA-Protokoll ist plattformunabh¨angig und kann ¨uber verschiedene Netzwerkproto-
kolle transportiert werden (TCP/IP, IPX, SPX oder NETBEUI). Es k¨onnen Bildin-
formationen mit einer Farbtiefe von bis zu 24 Bit ¨ubertragen werden. Zus¨atzlich zu
Bildschirm-, Maus- und Tastatureingaben k¨onnen auch Audiodaten, Informationen der
Zwischenablagen und Daten zum Drucken ¨ubertragen werden. Dazu verwendet das
ICA-Protokoll f¨ur jeden Datentyp einen eigenen virtuellen Kanal. Die ¨
Ubertragung
wird mit 128 Bit verschl¨usselt.
20
Vorteile
Der gr¨oßte Vorteil ist die zentrale Administration, Installation und Wartung der An-
wendungen. Dies macht Change Management-Prozesse sehr einfach. Die Software
19
Vgl. Kaplan, S., Mangus, M., Citrix Server-Based Computing, 2001, S. 60
20
Kaplan, S., Mangus, M., Citrix Server-Based Computing, 2001, S. 57ff.

G
RUNDLAGEN
/ B
EGRIFFSABGRENZUNGEN
Seite 9
muss nur einmal auf dem Server installiert werden. Selbst beim Einsatz von Server-
farmen ist es m¨oglich, die Software nur einmal zu installieren. Die Installation auf den
weiteren Servern erfolgt automatisch.
21
Es werden nur geringe Anforderungen an die Bandbreite gestellt. Dadurch wird es
auch Außendienstmitarbeitern erm¨oglicht, auf interne Anwendungen im Netzwerk zu-
zugreifen. Dabei spielt es fast keine Rolle ¨uber welches Medium eine Verbindung
zu dem Terminalserver aufgebaut wird. Bei den meisten Anwendungen reicht eine
ISDN-Verbindung. Es ist allerdings auch m¨oglich ¨uber das GSM-Netz eine GPRS-
Verbindung herzustellen.
Dadurch, dass die Berechnungen und die Logik auf dem Server ausgef¨uhrt wer-
den, haben SBC-L¨osungen nur geringe Anforderungen an die Hardware der Clients,
so dass Clients nicht nach einigen Jahren bereits ausgetauscht werden m¨ussen. Bei
Reinvestitionen kann auf so genannte ThinClients umgestellt werden, deren Kosten
(etwa 260
e/Client
22
) weit unter denen von normalen Clients liegen.
23
Verbindungsabbr¨uche haben keine Auswirkungen auf den Ablauf des Programms,
da die Session auf dem Server erhalten bleibt und vom Benutzer wieder aufgenommen
werden kann. Dies stellt sich insbesondere in Funknetzen als Vorteil dar.
Nachteile
Server bzw. Serverfarmen m¨ussen leistungsf¨ahiger sein als beim Client/Sever-Computing,
da Berechnung f¨ur die Business-Logik nun auch vom Server ¨ubernommen werden
muss. Diese sind bei modernen Terminalservern aber gut skalier- und erweiterbar.
24
Ebenso werden erh¨ohte Anforderungen an die Administration gestellt. Die Adminis-
tratoren m¨ussen gut ausgebildet sein und auch die Fehlertoleranz ist sehr niedrig zu
halten, da die Abh¨angigkeit von der zentralen Serverkomponente sehr hoch ist.
25
Die Terminalserver-Architektur eignet sich nicht f¨ur sehr grafikintensive Anwen-
dungen wie bei CAD-Anwendungen oder Spielen. Es werden nur Bilder in 16 bzw.
24 Bit Farbtiefe ¨ubertragen und bei sehr vielen Bildver¨anderungen, wie es z.B. bei
Spielen der Fall, ist lassen sich Performance-Probleme erkennen. Ebenso ist dies bei
Multimediaanwendungen und Softwareentwicklungsumgebungen zu erwarten.
26
21
Vgl. o. A., Windows-Terminal-Server - Dicke Leistung, d¨unne Clients, 2005, Kap. Drei Kernaufga-
ben, o.S.
22
Vgl. o.A., HP Compaq t5300 Thin-Client - ¨
Ubersicht
23
Vgl. von Suchodoltz, D., Betriebshandbuch Thin-Clients auf Linuxbasis, 2000, Einleitung, o. S.
24
Vgl. Enck, J., Margevicius, M., Thin-Client Computing Dictates Fat-Server, 2004, S. 3.
25
Vgl. Kaplan, S., Mangus, M., Citrix Server-Based Computing, 2001, S. 124f.
26
Vgl. o. A., Windows-Terminal-Server - Dicke Leistung, d¨unne Clients, 2005, Kap. Drei Kernaufga-
ben, o. S.

G
RUNDLAGEN
/ B
EGRIFFSABGRENZUNGEN
Seite 10
2.2 Klassische Office-Anwendungen
Terminalserver eignen sich f¨ur eine Vielzahl von Anwendungen. Wie im Abschnitt vor-
her dargestellt eignen sie sich aber insbesondere f¨ur die Anwendungen des klassischen
Office-Bereichs. Mit einer zentralen Installation kann der gr¨oßte Teil der Mitarbei-
ter mit Standardanwendungen bedient werden. In den meisten Unternehmen gibt es
sehr viele Desktops oder Notebook mit identischen Installationen. Es gibt einige An-
wendungen, die alle Mitarbeiter eines Unternehmens ben¨otigen. Diese Anwendungen
sind beispielsweise Textverarbeitung, Tabellenkalkulation, E-Mail-Client und Waren-
wirtschaftssystem. Diese Arbeit beschr¨ankt sich in ihrer Analyse auf die Betrachtung
solcher Office-Anwendungen, da diese Anwendungen f¨ur die meisten Mitarbeiter aus-
reichend sind. Weiterhin sind hier die gr¨oßten Einsparungspotenziale zu erzielen.
2.3 Methoden der Wirtschaftlichkeitsanalyse
2.3.1 Einordnung der Wirtschaftlichkeitsanalyse
Die Entscheidung eine Investitionsmaßnahme durchzuf¨uhren oder nicht sollte auf-
grund von objektiven Kriterien erfolgen. Die Wirtschaftlichkeitsanalyse ist als ein sol-
ches objektives Kriterium h¨aufig ein Bestandteil von Entscheidungsprozessen. Gene-
rell ist zu beachten, dass die Wirtschaftlichkeitberechnungen Entscheidungen nur vor-
bereiten, nicht aber treffen k¨onnen.
27
Bei der Entscheidungsfindung k¨onnen pers¨onli-
che Pr¨aferenzen, strategische Vorgaben der Unternehmensf¨uhrung oder auch nicht quan-
tifizierbaren Nutzenaspekte eine Rolle spielen. Diese Effekte werden auch als intangi-
ble Effekte bezeichnet.
28
(Vergleiche Abbildung 4).
Der Wirtschaftlichkeit liegen zwei grundlegende Prinzipien der Betriebswirtschaft-
lehre zu Grunde. Das Minimal- und das Maximalprinzip. Bei beiden Prinzipien ist
jeweils eine Gr¨oße (Input oder Output) fix. Ziel ist es, die jeweils andere Gr¨oße zu ma-
ximieren bzw. zu minimieren. Das Minimalprinzip gibt vor, einen definierten Output
mit m¨oglichst geringem Mitteleinsatz zu erreichen. Ziel des Maximalprinzipes ist es
durch den Einsatz vorgegebener Mittel, einen m¨oglichst hohen Output zu erzeugen.
29
Das Hauptaugenmerk dieser Arbeit liegt auf der Wirtschaftlichkeitsanalyse. Um die-
se durchzuf¨uhren, k¨onnen verschiedene Methoden zur Hilfe herangezogen werden. Die
Methoden, die innerhalb einer wissenschaftlichen Arbeit verwendet werden, m¨ussen
im Vorfeld hinreichend beschrieben und definiert werden.
27
Vgl. Diederichs, C.J., Wirtschaftlichkeitsberechnungen Nutzen-Kosten-Untersuchungen, 1985, S. 11.
28
Vgl. Diederichs, C.J., Wirtschaftlichkeitsberechnungen Nutzen-Kosten-Untersuchungen, 1985, S. 90.
29
Vgl. Kredel, L., Wirtshaftlichkeit von B¨urokommunikationssystemen - Eine vergleichende Darstel-
lung, 1988, S. 24.

G
RUNDLAGEN
/ B
EGRIFFSABGRENZUNGEN
Seite 11
Persönliche
Präferenzen
Gesetzliche
Vorgaben
Subjektive
Nutzenaspekte
Erfahrung
Unternehmens-
strategie
und -kultur
Wirtschaftlichkeit
Entscheidung
Abbildung 4: Einflussfaktoren der Entscheidungsfindung
2.3.2 Abgrenzung Wirtschaftlichkeitsberechnung und
Kosten/Nutzen-Analyse
Die Wirtschaftlichkeitsberechnung (WB) geh¨ort zur innerbetrieblichen oder betriebs-
wirtschaftlichen Investitionsrechnung. Bei ihr werden Methoden verwendet, die dem
Investor das jeweils wirtschaftlichste der konkurrierenden Projekte nachvollziehbar
ausw¨ahlt. Dabei werden alle Kosten und Nutzenfaktoren monet¨ar bewertet. Nicht quan-
tifizierbare Aspekte k¨onnen nur erg¨anzend diskutiert werden.
Die Kosten/Nutzen-Analyse hingegen verfolgt drei Ziele. Sie hilft die Entscheidung
¨uber die Wirtschaftlichkeit von ¨offentlichen Projekten zu treffen, w¨ahlt aus einer Reihe
von Projekten eines aus und bestimmt den richtigen Zeitpunkt f¨ur die Durchf¨uhrung
des Projektes.
30
Kosten/Nutzen-Analysen (KNA) hingegen eignen sich eher f¨ur den
gesamtwirtschaftlichen bzw. volkswirtschaftlichen Bereich. Mit KNA werden nicht
nur betriebswirtschaftliche, sondern auch gesellschaftliche Zielvorstellungen ber¨uck-
sichtigt. Daher kommen KNAs h¨aufig bei Investitionsprojekten ¨offentlicher Investoren
zum Einsatz. In KNA gehen auch nicht monet¨ar bewertbare Nutzenfaktoren mit ein
(vergleiche Abbildung 5).
31
30
Vgl. Recktenwald, H., Die Nutzen-Kosten-Analyse, 1971, S. 12.
31
Vgl. Diederichs, C.J., Wirtschaftlichkeitsberechnungen Nutzen-Kosten-Untersuchungen, 1985, S. 9.

Details

Seiten
Erscheinungsform
Originalausgabe
Jahr
2008
ISBN (eBook)
9783836622837
DOI
10.3239/9783836622837
Dateigröße
1.7 MB
Sprache
Deutsch
Institution / Hochschule
FOM Essen, Hochschule für Oekonomie & Management gemeinnützige GmbH, Hochschulleitung Essen früher Fachhochschule – Wirtschaftsinformatik
Erscheinungsdatum
2008 (November)
Note
1,3
Schlagworte
wirtschaftlichkeitsanalyse citrix terminalserver kosten-nutzenanalyse
Zurück

Titel: Wirtschaftlichkeitsanalyse einer Umstellung von Client/Server- auf Terminalserver-Architektur im Bereich klassischer Office-Anwendungen
Cookie-Einstellungen