Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
Inhaltsverzeichnis
Anhangsverzeichnis ......................................................................................................... - 4 -
Abbildungsverzeichnis ..................................................................................................... - 5 -
Tabellenverzeichnis .......................................................................................................... - 6 -
Abkürzungsverzeichnis .................................................................................................... - 7 -
1. Grundlagen von E-Shop Software ............................................................................ - 8 -
1.1. Definition von E-Business und E-Commerce ........................................................ - 8 -
1.2. Elektronische Geschäftsbeziehungen ................................................................... - 9 -
1.3. Geschäftsmodelle im E-Business und E-Commerce .......................................... - 11 -
1.4. Entwicklung des B2C E-Commerce .................................................................... - 15 -
1.5. E-Commerce Plattform ....................................................................................... - 17 -
1.6. E-Shop Software ................................................................................................. - 20 -
1.7. E-Shop Softwarekomponenten ........................................................................... - 22 -
1.8. E-Shop Softwaretrends ....................................................................................... - 23 -
1.9. Betreibermodelle ................................................................................................. - 27 -
2. Anforderungen an E-Shop Software ...................................................................... - 31 -
2.1. Architektur ........................................................................................................... - 33 -
2.1.1. Architekturmuster ......................................................................................... - 34 -
2.1.2. Zwei- und n-Schichten Architektur ............................................................... - 35 -
2.1.3. Service orientierte Architekturen .................................................................. - 36 -
2.1.4. Datenaustausch ........................................................................................... - 37 -
2.1.5. Ladezeit ....................................................................................................... - 39 -
2.2. Funktionen .......................................................................................................... - 40 -
2.2.1. Produktkatalog und Suchfunktion ................................................................ - 43 -
2.2.2. Bestellfunktion ............................................................................................. - 48 -
2.2.2.1. Produktwarenkorb .................................................................................... - 48 -
2.2.2.2. Bestellformular ......................................................................................... - 49 -
-1-

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
2.2.3. Content Management .................................................................................. - 51 -
2.2.4. Multi-Shop Funktion ..................................................................................... - 52 -
2.2.5. Unterstützung für Lokalisierungen und Mehrsprachigkeit ............................ - 53 -
2.2.6. Web Analytics .............................................................................................. - 53 -
2.2.7. Suchmaschinenfreundlichkeit ...................................................................... - 54 -
2.2.8. Kundenmanagement ................................................................................... - 55 -
2.3. Sicherheit ............................................................................................................ - 56 -
2.3.1. Sicherheitsmechanismen ............................................................................. - 59 -
2.3.2. Kryptografie ................................................................................................. - 60 -
2.3.2.1. Hash Coding Kryptografie ........................................................................ - 61 -
2.3.2.2. Asymmetrische und symmetrische Kryptografie ...................................... - 61 -
2.3.3. Digitale Zertifikate ........................................................................................ - 62 -
2.3.4. Hypertext Transfer Protocol ......................................................................... - 63 -
2.3.5. Administratorenrechte und -überwachung ................................................... - 64 -
2.4. Strategie.............................................................................................................. - 65 -
2.4.1. Service ......................................................................................................... - 66 -
2.4.2. Finanzkraft ................................................................................................... - 69 -
2.4.3. Marktpräsenz ............................................................................................... - 70 -
3. Evaluierungsmodell ................................................................................................. - 73 -
3.1. Ermittlung der Ziele ............................................................................................. - 78 -
3.2. Gewichtung der Ziele .......................................................................................... - 81 -
3.3. Vergabe von Punkten für die Varianten .............................................................. - 84 -
3.4. Punkttotale .......................................................................................................... - 84 -
3.5. Einführung der Total Cost of Ownership als weitere Dimension ......................... - 85 -
3.6. Kritische Betrachtung der Methodik .................................................................... - 89 -
4. Beispiele aus quelloffenen Shopsystemen ........................................................... - 90 -
4.1. Evaluierungsbedingungen .................................................................................. - 91 -
4.1.1. Messung der Ladezeit ................................................................................. - 93 -
4.2. xt:Commerce....................................................................................................... - 94 -
4.2.1. Evaluierung .................................................................................................. - 95 -
-2-

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
4.3. OXID CE ............................................................................................................. - 98 -
4.3.1. Evaluierung .................................................................................................. - 99 -
4.4. Magento ............................................................................................................ - 103 -
4.4.1. Evaluierung ................................................................................................ - 104 -
4.5. Zusammenfassung der Evaluierung von xt:Commerce, OXID CE und Magento- 109
-
5. Fazit und Ausblick ................................................................................................. - 111 -
Anhang ........................................................................................................................... - 114 -
Literaturverzeichnis ...................................................................................................... - 115 -
-3-

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
Anhangsverzeichnis
Anhang 1: Gartner TCO Modell ....................................................................................... - 114 -
-4-

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
Abbildungsverzeichnis
Abbildung 1: E-Business und E-Commerce ........................................................................ - 9 -
Abbildung 2: Elektronische Geschäftsbeziehungen .......................................................... - 10 -
Abbildung 3: Aggregator kombiniert Produkte und diktiert Preise ..................................... - 13 -
Abbildung 4: Struktur der B2C Internetumsätze in Deutschland ....................................... - 16 -
Abbildung 5: E-Commerce Schichtenpyramide ................................................................. - 19 -
Abbildung 6: E-Commerce Plattform ................................................................................. - 21 -
Abbildung 7: Beispielhafte Darstellung der E-Shop Softwarekomponenten ..................... - 22 -
Abbildung 8: Die zwei Dimensionen des Internets ............................................................ - 25 -
Abbildung 9: Wertbeiträge-Modell für E-Shop Lösungen .................................................. - 29 -
Abbildung 10: Einsatz der E-Shop Distributionsmodelle in Abhängigkeit zum Wertbeitrag- 30
-
Abbildung 11: Auf die Entwicklung einer Softwarearchitektur wirkende Faktoren ............ - 34 -
Abbildung 12: Transaktionsphasen im B2C E-Commerce ................................................ - 41 -
Abbildung 13: Ein Modell für Katalogdatenbereiche ......................................................... - 45 -
Abbildung 14: Optimierungsproblem von Sicherheitsmaßnahmen ................................... - 58 -
Abbildung 15: Risikomanagement Model .......................................................................... - 59 -
Abbildung 16: Die einzelnen Schritte des Schlüsseltausch ............................................... - 64 -
Abbildung 17: Services zur Generierung von Werten ....................................................... - 67 -
Abbildung 18: Struktureller Aufbau des Evaluierungsmodells ........................................... - 76 -
Abbildung 19: Über- oder Untergewichtung von Zielkriterien je nach Betreibermodell ..... - 83 -
Abbildung 20: Systemlebenszyklus und relevante Kosten ................................................ - 86 -
Abbildung 21: Kosten der Anpassung einer E-Shop Software .......................................... - 88 -
Abbildung 22: Netz-Darstellung der Stärken und Schwächen ........................................ - 110 -
Abbildung 23: E-Shops der Otto Group im Kontext zum BetreibermodellFehler! Textmarke
nicht definiert.
-5-

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
Tabellenverzeichnis
Tabelle 1: Geschäftsmodelle nach Tapscott, Ticoll und Lowy .......................................... - 12 -
Tabelle 2: B2C Geschäftsmodelle nach dem Typ Aggregator .......................................... - 14 -
Tabelle 3: B2C E-Commerce Umsatzzahlen für Deutschland im Vergleich in Mrd.€ ........ - 17 -
Tabelle 4: Trends und Einflüssen mit Relevanz für E-Shop Software ............................... - 26 -
Tabelle 5: Vergleich CSV-, EDI- und XML-basierter Datenformate .................................. - 38 -
Tabelle 6: Transaktionsphasen, Aktivitäten des Besuchers und E-Shop Funktionen ....... - 43 -
Tabelle 7: Sicherheitsmechanismen ................................................................................. - 60 -
Tabelle 8: Aufbau des Evaluierungsmodells ..................................................................... - 77 -
Tabelle 9: Erklärung zur Tabelle 8 .................................................................................... - 77 -
Tabelle 10: Ziel- und Hilfskriterien für die Kategorie Architektur ....................................... - 79 -
Tabelle 11: Ziel- und Hilfskriterien für die Kategorie Funktionen ....................................... - 80 -
Tabelle 12: Ziel- und Hilfskriterien für die Kategorie Sicherheit ........................................ - 80 -
Tabelle 13: Zielkriterien für die Kategorie Strategie .......................................................... - 80 -
Tabelle 14: Die Gewichtung der Zielkriterien-Kategorien .................................................. - 81 -
Tabelle 15: Die Gewichtung der Zielkriterien .................................................................... - 82 -
Tabelle 16: Für eine E-Shop Software relevante Kostenfaktoren ..................................... - 87 -
Tabelle 17: Serverdaten .................................................................................................... - 91 -
Tabelle 18: Links zu dem Front- und Back-Ends der E-Shops ......................................... - 91 -
Tabelle 19: Login Informationen ........................................................................................ - 91 -
Tabelle 20: Serveranforderungen der E-Shop Software ................................................... - 92 -
Tabelle 21: Ladezeiten-Test .............................................................................................. - 93 -
Tabelle 22: Für die Tests genutzte Dienstleister ............................................................... - 93 -
Tabelle 23: Bedingungen der Ladezeiten-Tests ................................................................ - 94 -
Tabelle 24: Ladezeitentest mit 100 Artikeln und vier Kategorien ...................................... - 94 -
Tabelle 25: Wertung der Zielkriterien-Kategorie Architektur von xt:Commerce ................ - 95 -
Tabelle 26: Wertung der Zielkriterien-Kategorie Funktionen von xt:Commerce ................ - 97 -
Tabelle 27: Wertung der Zielkriterien-Kategorie Sicherheit von xt:Commerce ................. - 97 -
Tabelle 28: Wertung der Zielkriterien-Kategorie Strategie von xt:Commerce ................... - 98 -
Tabelle 29: Wertung der Zielkriterien-Kategorie Architektur von OXID CE ....................... - 99 -
Tabelle 30: Wertung der Zielkriterien-Kategorie Funktionen von OXID CE .................... - 102 -
Tabelle 31: Wertung der Zielkriterien-Kategorie Funktionen von OXID CE .................... - 103 -
Tabelle 33: Teilnutzwerte der Zielkriterien ...................................................................... - 109 -
Tabelle 34: Teilnutzwerte der Zielkriterien-Kategorien und der Gesamtnutzwerte ......... - 110 -
Tabelle 35: Zielkriterien-Kategorien ohne die Gewichtung der Kategorien ..................... - 110 -
-6-

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
Abkürzungsverzeichnis
B2B Business to Business
B2C Business to Consumer
CE Community Edition
CMS Content Management Seite
CRM Customer Relationship Management
ERP Enterprise Resource Planning
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
SEO Search Engine Optimization
SOA Service Oriented Architecture
SOAP Simple Object Access Protocol
UDDI Universal Description, Discovery and Integration
URL Uniform Resource Locator
WSDL Web Service Description Language
-7-

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
1. Grundlagen von E-Shop Software
In diesem Kapitel werden Begriffe des elektronischen Handels abgegrenzt und näher
erläutert. Weiterhin werden die Grundlagen für die Entwicklung des Evaluierungsmodells
gebildet. Es werden bestehende Theorien und Erklärungsansätze aus verschiedenen
Disziplinen herangezogen, um ein solides Verständnis für das E-Commerce im allgemeinen
und E-Shop Software im Speziellen zu gewinnen.
1.1. Definition von E-Business und E-Commerce
Der Begriff Electronic Commerce wird sowohl in der wissenschaftlichen als auch in der
praxisorientierten Literatur seit Mitte der 90er Jahre diskutiert und sehr unterschiedlich
verwendet. 1 In einer frühen Phase des Internets wurde unter E-Commerce, der Verkauf von
Dienstleitungen und Gütern über elektronische Netzwerke verstanden. 2 In diesem Sinne wird
der Begriff E-Commerce von Herrmanns und Sauter auch als Electronic Shopping oder
Online Shopping bezeichnet. 3
Allerdings ist dieser Begriff damit sehr eng gefasst, um alle kommerziellen Aktivitäten des
Internets zu erfassen. In der Literatur schlagen deshalb eine Reihe von Autoren vor, den
Begriff E-Commerce weiter zu fassen und die Unterstützung aller kommerzieller Aktivitäten
wie Geschäftsprozesse, Geschäftstransaktionen, sowie die Beziehungen zu sämtlichen
internen und externen Partnern eines Unternehmens durch Informations- und
4
Kommunikationstechnologien in die Definition einzubeziehen. Nach dieser breiten Definition
umfasst der Begriff E-Commerce de facto jegliche kommerzielle Aktivität im Internet.
Da jedoch mit dem Einzelbegriff Commerce vordergründig Handel gemeint ist, schlagen das
mcm Institute und PwC vor, für alle kommerziellen Aktivitäten im Internet den Begriff E-
Business zu verwenden: „E-Business ist die Integration von Systemen, Prozessen,
Organisationen, Wertschöpfungsketten und ganzen Märkten durch die Anwendung von
internetbasierten und –verwandten Technologien und Konzepten. Electronic Commerce ist
1
Vgl. Schmeken, 2007, S. 11; Choi / Stahl / Whinston, 1997, S. 1-4; Clement / Peters / Preiß, 1999,
S.49-53.
2
Vgl. Kalakota / Whinston, 1996, S. 1-3.
3
Vgl. Hermanns / Sauter, 1999, S. 14.
4
Vgl. Wigand, 1997, S. 5; Turban / McLean / Wetherbe, 1999, S. 3,5; Stähler, 2002, S. 53; Haertsch,
2000, S. 13;
-8-

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
demnach ein Teilbereich von E-Business und beschränkt sich im Wesentlichen auf die
Marketing- und Verkaufsprozesse.“ 5
In diesem Sinne, findet sich laut Heinemann, der Online Handel im Geschäftskonzept E-
Commerce wieder, weil hier die Anbahnung, Aushandlung und Abwicklung von
geschäftlichen Transaktionen über Netzwerke erfolgt, d.h. dass ein Leistungsaustausch
zwischen Marktteilnehmern mit Hilfe öffentlicher oder privater Netzwerke, wie dem Internet,
mit dem Ziel der Wertschöpfung stattfindet. 6
Die nachfolgende Abbildung 1 stellt die Unterscheidung von E-Business und E-Commerce
dar und setzt diese gleichzeitig in Relation zu elektronischen Geschäftsbeziehung.
Business to Business (B2B) Business to Concumer (B2C)
Geschäftspartner Extranet Unternehmen Internet Kunde
E-Commerce E-Commerce
E-Business
Abbildung 1: E-Business und E-Commerce 7
1.2. Elektronische Geschäftsbeziehungen
Für die systematische Ableitung der Einsatzmöglichkeiten des E-Commerce, bietet sich die
nachfolgende Abbildung 2 an, die neun Markt- und Transaktionsbereiche beschreibt. Damit
werden die drei wichtigsten Gruppen von Marktteilnehmern und ihre möglichen
Geschäftsverbindungen dargestellt.
5
mcm institute & PwC, 1999, S. 4.
6
Heinemann, 2009, S. 27.
7
In Anlehnung an Stähler, 2002, S. 54.
-9-

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
Nachfrager der Leistung
Consumer Busines Administration
Consumer
Consumer to Business Consumer to Administration
Consumer to Consumer
Z.B. Jobbörsen mit Anzeigen von Z.B. Steuerabwicklung von
Z.B. Internet-Kleinanzeigenmarkt
Arbeitssuchenden Privatpersonen
Business to Business
Anbieter Business to Consumer Business to Administration
Busines
der Z.B. Bestellung eines
Z.B. Bestellung eines Kunden bei Z.B. Steuerabwicklung von
Leistung einem E-Shop
Unternehmens bei einem
Unternehmen
Zulieferer
Administration
Administration to
Administration to Consumer Administration to Business
Administration
Z.B. Abwicklung der Z.B. Beschaffung von
z.B. Transaktionen zwischen
Einkommenssteuer Lizenzrechten bei Behörden
Behörden
Abbildung 2: Elektronische Geschäftsbeziehungen 8
Als Anbieter und Nachfrager einer Leistung können sowohl private Konsumenten
(Consumer), Unternehmen (Business) als auch öffentliche Institutionen (Administration)
auftreten.
Mit Business to Consumer (B2C) und Business to Business (B2B), bieten Unternehmen
Produkte und Dienstleistungen für Kunden oder weitere Unternehmen an. Auf diese beiden
Bereiche geht der Großteil der Umsätze zurück. 9
Weitere Austauschbeziehungen gehen von der öffentlichen Hand (Administration) aus und
führen zu weiteren Optionen A2A, A2B und A2C. Bei Administration to Administration
werden Kommunikation- und Informationstechnologien verwendet, um verwaltungsinterne
Abläufe elektronisch zu gestalten. Dies kann innerhalb einer oder zwischen mehreren
Verwaltungsebenen geschehen. Außerdem können Behörden Angebote an Bürger (A2C)
oder Unternehmen (A2B) richten.
Personen können grundsätzlich sowohl als Leistungsanbieter als auch als
Leistungsnachfrager auftreten. Die Option C2C (Consumer to Consumer) beschreibt eine
elektronische Geschäftsbeziehung zwischen Einzelpersonen, wie sie beispielsweise über
elektronische Marktplätze zustande kommen kann. Des Weiteren können Personen auch
Leistungen für Unternehmen oder Verwaltungseinheiten erbringen.
8
In Anlehnung an Hermanns / Sauter, 1999, S. 23.
9
Vgl. Hermanns / Sauter, 1999, S. 22.
- 10 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
1.3. Geschäftsmodelle im E-Business und E-Commerce
Der Begriff des Geschäftsmodells im E-Business wird in der Literatur sehr uneinheitlich
verwendet. 10 Folglich fehlt auch eine allgemein anerkannte Definition. Nach Wirtz, definiert
ein E-Business Geschäftsmodell die Schwerpunkte von Unternehmungen und ihrer
Erlöserzielung. Timmers schlägt dazu die folgende Definition vor: „A business model is
defines as the organization (or architecture) of product, service and information flows, and
the sources of revenues and benefits for suppliers and customers.“ 11 Nach Trimmers
Definition, beschreibt ein Geschäftsmodell im E-Business also Organisationsstrukturen, die
Erlöserzielung und Vorteile, die sich für Anbieter und Kunde ergeben.
Ein Geschäftsmodell erlaubt es in einer sehr vereinfachten und zusammengefassten Weise,
die für eine Unternehmung einfließenden Ressourcen und die Transformation zu
vermarktungsfähigen Produkten und Dienstleistungen darzustellen. Aus einem
Geschäftsmodell geht die Kombination der Produktionsfaktoren hervor, die für die
Umsetzung der Geschäftsstrategie notwendig ist. Weiterhin werden auch die Rollen
einzelner Akteure beschrieben. Grundsätzlich werden in der Literatur eine Vielzahl
unterschiedlicher E-Business Geschäftsmodelle beschrieben. Allerdings entwickelt sich der
E-Business Markt auch fortwährend weiter und verhält sich dynamisch, weswegen
kontinuierlich neue Geschäftsmodelle entstehen und alte an Bedeutung verlieren.
Timmers identifiziert elf E-Business Geschäftsmodelle, die in der Literatur vielfach
12
aufgegriffen werden. Rappa beschreibt neun E-Business Geschäftsmodelle aus der
Perspektive der Umsatzgenerierung. 13 Im Folgenden werden fünf für das E-Business
relevante Geschäftsmodelle nach Tapscott, Ticoll und Lowy beschrieben, die sich durch ihre
hohe Abstraktion und Beschränkung auf grundlegende Prozesse von denen anderer Autoren
im Bereich des E-Business unterscheiden und wesentlich weniger unter dem Einfluss von
Modeerscheinungen stehen.
Die folgende Tabelle stellt eine Übersicht der fünf Typen nach Tapscott, Ticoll und Lowy dar,
die anschließend näher erläutert werden, wobei nur der Typ Aggregator in seinem Wesen,
eine reine B2C E-Commerce Geschäftsbeziehung beschreibt und daher detaillierter erläutert
wird. 14
10
Vgl. Wirtz, 2001, S. 210f.
11
Vgl. Timmers, 1999, S. 31.
12
Vgl. Timmers, 1998, S. 3-7.
13
Vgl. Rappa, 18.12.2009.
14
Vgl. Tapscott / Ticoll / Lowy, 1999, S. 198-208.
- 11 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
Agora Aggregator Integrator Allianz Distributor
Ziel- Marktplatz für Digitaler Optimierte selbst organi- Austausch von
setzung Waren und Supermarkt Wertschöpfung sierender Informationen,
Werte skette Wert- Waren und
schöpfungs- Diensten
raum
Merk- § Markt- § Auslage von § gezielte § Innovation § Netz-
male information Produkten Lieferanten- § Vertrauensbil optimierung
§ Verhandlung § fester Preis auswahl dung § unein-
sprozess § einfache § Prozess- § Verzicht auf geschränkte
§ dynamische Erfüllung optimierung hierarchische Nutzung
Preisfindung § Produkt- Kontrolle § Logistik-
integration prozess
Kunden- Markt- Käufer Wertmotor Beitragender Empfänger
rolle teilnehmer
Nutzen Verhandelbare Bequeme Kundenspezifis Kreative und Zeitgerechte
Marktleistung Auswahl und ches Produkt gemeinschaftli Lieferung
Erfüllung che Lösung
Tabelle 1: Geschäftsmodelle nach Tapscott, Ticoll und Lowy 15
Der aus der Antike stammende Begriff Agora, ist ein elektronischer Marktplatz auf dem
Käufer und Verkäufer zusammenkommen, um über die angebotenen Güter und Preise zu
verhandeln. Demnach, gehört die dynamische Preisfindung zu den Hauptmerkmalen. Des
Weiteren können unterschiedliche Anbieter Produkte und Dienstleistungen offerieren,
weswegen das Angebot theoretisch sehr vielfältig und nicht vorhersehbar sein kann. Indes
ist die Werteintegration vergleichbar eingeschränkt, wobei gleichzeitig die Marketing und
Vertriebskosten gering ausfallen. 16
Ein Integrator kontrolliert eine Wertschöpfungskette mit allen seinen Komponenten in Form
externer Partner und integriert ihre Wertbeiträge. Damit kontrolliert der Integrator die
Gestaltung des Produktes bzw. der Dienstleistung, indem er unterschiedliche Hersteller zu
einer Wertschöpfungskette zusammenfügt. Der Anstoß geht i.d.R. vom Kunden aus, der eine
komplexe und individuelle Lösung nachfragt. 17
Eine Allianz besteht aus eigenständigen in einer Gemeinschaft organisierten Partnern, die
gemeinsame Lösungen entwickeln. Mitglieder des Netzwerks bringen ihr spezifisches Know-
15
Vgl. Tapscott / Ticoll / Lowy, 1999, S. 198.
16
Vgl. Meier / Stormer, 2008, S. 35.
17
Vgl. Meier / Stormer, 2008, S. 35-37.
- 12 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
how ein und agieren innerhalb des Netzwerkes sowohl als Nachfrager als auch als
Anbieter. 18
Ein Distributor gewährleistet einen Austausch von Dienstleistungen, Waren und
Informationen. Damit stellt er ein Verteilungsnetzwerk zur Bedienung unterschiedlicher
Anbieter und Nutzer dar. 19
Aggregatoren übernehmen eine Vermittlerfunktion zwischen Endkunden und
Warenlieferanten, wobei der Warenlieferanten i.d.R Großhändler oder Hersteller ist. Der
Aggregator wählt die Produkte und Dienstleistungen, entscheidet über die Preise und
20
kontrolliert die Abwicklung. Die folgende Abbildung stellt die Konstellation eines
Aggregators abstrakt dar.
Hersteller
Käufer
Hersteller
Aggregator Käufer
Hesteller
Käufer
Abbildung 3: Aggregator kombiniert Produkte und diktiert Preise
Dabei greift der Aggregator auf mehrere Hersteller zurück und bietet insgesamt eine große
Auswahl an Produkten bzw. Dienstleistungen an. Zu den Kernfunktionen gehört damit die
Auslage der Produkte für den Kunden, der seinen Nutzen aus der bequemen
Auswahlmöglichkeit und Erfüllung zieht. Aus der Erfüllung der reinen Vermittlerfunktion geht
allerdings nur eine geringe Werteintegration hervor.
Der Aggregator hat nach Meier und Stormer folgende Vorteile: 21
18
Vgl. Meier / Stormer, 2008, S. 36-38.
19
Vgl. Meier / Stormer, 2008, S. 36-38.
20
Vgl. Meier / Stormer, 2008, S. 37.
21
Vgl. Meier / Stormer, 2008, S. 34-37.
- 13 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
§ Große Verhandlungsmacht: Dem Aggregator obliegen die Produktauswahl und die
Bestimmung der Preiskonditionen
§ Einsatz digitaler Berater: Softwareagenten helfen bei Such- und Vergleichsvorgängen
und erfüllen eine Beratungsfunktion
§ Unabhängige Produktbewertung: Vor- und Nachteile von Produkten werden von den
Kunden erfasst und durch den Aggregator als Entscheidungshilfe publiziert
§ Stimulierung des Verkaufs: Produktbündelungen, Cross-Selling Maßnahmen und
diverse andere Instrumenten der Promotion können realisiert werden
Da im Kern Produkte bzw. Dienstleistungen von Unternehmen (Business) an Konsumenten
(Consumer) weitergereicht werden, eignet sich der Typ Aggregator seiner Definition nach für
die Beschreibung von B2C E-Commerce Geschäftsmodellen, die im Fokus der
nachfolgenden Arbeit stehen.
Grundsätzlich können die Funktionen des Aggregators, wie nach Tapscott, Ticoll und Lowy
definiert, in der Praxis von verschiedenen Typen von Unternehmen erfüllt werden. Laudon
und Traver identifizieren vier B2C E-Commerce Geschäftsmodelle, die in der folgenden
Tabelle dargestellt werden und dem Typ Aggregator entsprechen: 22
Variation Beschreibung Beispiele
Internet Pure Player Händler, die nur das Internet als Amazon.com
Absatzkanal nutzen Notebooksbilliger.de
Einzelhändler- Einzelhändler, die das Internet als Walmart.com
Versender zusätzlichen Absatzkanal nutzen Schlecker.de
Kataloghändler- Kataloghändler, die das Internet als Otto.de
Versender zusätzlichen Absatzkanal nutzen Neckermann.de
Hersteller- Hersteller, die ihre Produkte über das Dell.com
Versender Internet direkt an Endkonsumenten Sony.com
vertreiben
Tabelle 2: B2C Geschäftsmodelle nach dem Typ Aggregator 23
Diese praxisnahe Sicht gibt bereits einen Hinweis darauf, dass ursprünglich E-Commerce
fremde Unternehmen, das Internet als weiteren Absatzkanal nutzen.
Als Internet Pure Player werden Unternehmen bezeichnet, die ausschließlich das Internet als
Vertriebskanal nutzen. Oftmals sind diese Unternehmen auf bestimmte Marktsegmente
konzentriert und können flexibel auf Veränderungen reagieren. 24
22
Vgl. Laudon / Traver, 2009, S. 2,14- 2,17.
23
In Anlehnung an Laudon / Traver, 2009, S. 2,14- 2,16.
24
Vgl. Heinemann, 2009, S. 69.
- 14 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
Im Zuge der zunehmenden Verbreitung des Internets haben auch Einzelhändler und
Kataloghändler ihre Unternehmensstrategie angepasst und das Internet als Absatzkanal
entdeckt. Da diese Unternehmen mindesten zwei Absatzkanäle nutzen, werden sie auch als
Multi-Channel Händler bezeichnet. 25 Allerdings gibt es auch den umgekehrten Fall, dass ein
ursprünglicher Internet Pure Player im Einzelhandelsgeschäft aktiv wird und damit ebenfalls
der Kategorie Multi-Channel Handel zugeordnet werden kann.
Die Hersteller Versender zeichnen sich durch die Beherrschung der kompletten Supply-
Chain aus und nutzen den Online Handel als Instrument zur vertikalen Integration, indem sie
das Internet als Direktvertriebskanal verwenden. 26
Neben diesen Unternehmenstypen lassen sich insbesondere zwei innovative
Ausprägungstypen des Aggregators identifizieren, die insbesondere auf Internet Pure Player
zurückgehen, aber auch verstärkt von anderen Marktteilnehmern adaptiert werden:
§ Liveshopping: Eine sehr begrenzte Produktpalette, in aller Regel nur ein Produkt, für
einen begrenzten Zeitraum, in aller Regel nur für einen Tag, zu einen sehr deutlich
reduzierten Preis angeboten. Das Konzept wurde inzwischen von einer Vielzahl von
etablierten Unternehmen wie z.B. Otto mit dem HAPPY PREIS des Tages, LIDL mit
Highlight des Tages und QVC mit Tagesangebot übernommen, die jeweils ein
Produkt pro Tag besonders günstig anbieten. Als allgemein bekannte Beispiele reiner
Liveshopping Unternehmen können die iBOOD GmbH 27 oder die Live Shopping
GmbH 28 genannt werden.
§ Clubverkauf: Der Besucher muss sich zunächst anmelden, bevor ihm Einblick in das
Produktsortiment gewährt wird, wobei die Zahl der möglichen Anmeldungen begrenzt
ist. Die Exklusivität steht im Vordergrund. 29 Die Verkaufsaktionen sind zeitlich
begrenzt. Üblich sind fünf Aktionen je Woche, die jeweils über ein bis zwei Tage
gehen. 30 Als allgemein bekannte Beispiele reiner Clubverkäufer können die Private
Sale GmbH oder BuyVIP GmbH geannt werden. 31
1.4. Entwicklung des B2C E-Commerce
Der Großteil der Umsätze des Online Handels ist auf die Bereiche B2B und B2C
zurückzuführen. Da jedoch alleine der B2C für diese Arbeit von Interesse ist, werden andere
Marktzahlen vernachlässigt.
25
Vgl. Heinemann, 2009, S. 70.
26
Vgl. Heinemann, 2009, S. 75.
27
Vgl. iBOOD GmbH, 20.02.2010.
28
Vgl. Live Shopping GmbH, 20.02.2010.
29
Vgl. Heinemann, 2009, S. 69.
30
Vgl. Heinemann, 2009, S. 69.
31
Vgl. Krisch, 20.02.2010.
- 15 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
Grundsätzlich werden in Deutschland sehr unterschiedliche Marktzahlen seitens
verschiedener Organisationen publiziert, die unterschiedliche Detailgrade und
Betrachtungsweisen aufweisen und z.T. im Kontrast zueinander stehen, wie die
nachfolgende Untersuchung näher erläutert.
Der Bundesverband Informationswirtschaft, Telekommunikation und neue Medien e.V.
(BITKOM) weist für 2006 einen B2C Online Umsatz in Deutschland von 46 Mrd. EUR aus
und gibt eine durchschnittliche Wachstumsrate von 33 Prozent zwischen 2004 und 2007
an. 32 Für das Jahr 2010 wird ein Umsatz von 145 Mrd. EUR prognostiziert. 33
Die
Gesellschaft für Konsumforschung (GfK) weist für das gleiche Jahr einen Umsatz von nur
15,4 Mrd. EUR aus. 34 Aufgrund der deutlichen Unterschiede soll hier ein kurzer direkter
Vergleich erfolgen.
Anders als bei den BITKOM Zahlen, berücksichtigen die GfK Umsatzzahlen keine Online
Reiseumsätze, Online Kraftfahrzeug Umsätze und weitere Bereiche, wie Online Apotheken
und kommerzielle Onlineinhalte. 35 Zieht man jedoch auch diese Umsatzzahlen in Betracht,
dann ergibt sich ein schlüssigeres Bild, wie die nachfolgende Abbildung zeigt.
Sonstiges:
§ Pharma Kraftfahrzeug
Online-Einzelhandel § kostenpflichtiger Online-Handel Online-Reisen
Content (z.B. online
Zetungsartikel)
46 Mrd.€
15,4 Mrd.€ 14,2 Mrd.€ 8,4 Mrd.€ 8 Mrd.€ B2C-Umsatz
Deutschland 2006
Abbildung 4: Struktur der B2C Internetumsätze in Deutschland 36
Wie Tabelle 3 zeigt, weisen trotz der sehr unterschiedlichen Marktzahlen, alle aufgeführten
Organisationen eine zweistellige jährliche Wachstumsrate auf. Online einkaufen wird immer
beliebter. 2008 haben 42 Prozent der Deutschen im Internet Waren oder Dienstleistungen
bestellt. 37 Aufgrund dieser schnellen Marktentwicklung bezeichnet Heinemann das Internet
32
Vgl. BITKOM, 18.02.2010.
33
Vgl. BITKOM, 18.02.2010.
34
Vgl. GfK, 14.02.2010, S. 2.
35
Vgl. Heinemann, 2009, S. 69.
36
In Anlehnung an Heinemann, 2009, S. 10.
37
Vgl. BITKOM, 2009, S. 11.
- 16 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
auch als Vertriebskanal mit der höchsten Wachstumsdynamik, der inzwischen einen
Massenmarkt bildet. 38
2003 2004 2005 2006 2007 2008 Jährliche
Wachstumsrate
39
BITKOM 22 32 46 27,87%
40
GfK 5,8 7,6 9 10,2 11,4 13,6 15,26%
HDE 41 11 13 14,5 16,3 18,3 20 10,48%
bvh 42 3,6 5,3 7,4 10 10,9 13,4 24,49%
Tabelle 3: B2C E-Commerce Umsatzzahlen für Deutschland im Vergleich in Mrd.€
Über den Markt für technische Lösungen für die Nutzung des B2C E-Commerce liegen keine
zuverlässigen Zahlen vor, was einerseits auf die Intransparenz des Marktes und andererseits
auf den komplexen Kostenbegriff 43 zurückzuführen ist. Zudem müssen alleine für die
Bereitstellung einer E-Shop Software u.U. Leistungen unterschiedlicher Unternehmen in
Anspruch genommen werden. 44 Außerdem besteht eine E-Commerce Plattform aus sehr
unterschiedlichen Komponenten, wie die nachfolgenden Kapitel näher erläutern werden.
Dadurch wird die Erfassung monetärer Größen ungleich schwieriger.
Allerdings weisen die genannten B2C Marktzahlen indirekt auf eine hohe Nachfrage nach
technischen E-Commerce Lösungen hin. Diese Vermutung wird durch eine Umfrage von
Forrester Research bestätigt, die zu dem Ergebnis kommt, dass im Jahr 2009 26 Prozent
aller befragten Unternehmen beabsichtigten eine neue E-Shop Software einzusetzen oder
die bestehende deutlich weiterzuentwickeln. Trotz Finanzkrise, haben nur vier Prozent aller
befragten Unternehmen geplant ihre Investitionen in eine E-Shop Software zurückzufahren. 45
1.5. E-Commerce Plattform
In der Literatur wird zwischen verschiedenen Plattformen im E-Business unterschieden.
Sowohl Kollmann als auch Roumois schlagen mit E-Procurement, E-Shop, E-Community
38
Vgl. Heinemann, 2009, S. 11.
39
Vgl. BITKOM, 18.02.2010.
40
Vgl. GfK, 14.02.2010, S. 2.
41
Vgl. HDE, 14.02.2010.
42
Vgl. Bundesverband des Deutschen Versandhandels e.V., 26.12.2009.
43
Vgl. Kapitel 4.5.
44
Vgl. Kapitel 2.9.
45
Vgl. Forrester Research, 2009b, S. 4.
- 17 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
und E-Marketplace eine Unterscheidung von vier Plattformen für die Abwicklung von
elektronischen Geschäftsprozessen vor. 46
E-Procurement bezieht sich auf den Einkauf von Produkten und Dienstleistungen durch
Unternehmen. Als zentrale Plattform erlaubt es die Integration von Kommunikations- und
Informationstechnologien, um die elektronische Abwicklung bzw. Unterstützung in der
Beschaffung, möglich zu machen. 47
E-Marketplace bezeichnet einen elektronischen Marktplatz auf dem Käufer und Verkäufer
zusammenkommen, um über die angebotenen Güter und Preise zu verhandeln. 48 Demnach,
gehört die dynamische Preisfindung zu den Kernprozessen eines E-Marketplaces.
Eine E-Community ermöglicht den Kontakt zwischen Personen bzw. Institutionen über
elektronische Kanäle durch die Integration innovativer Kommunikationstechniken. Diese
Plattform dient primär dem Wissens- und Datenaustausch. 49
Ein E-Shop ermöglicht den elektronischen Vertrieb von Produkten und Dienstleistungen.
Damit geht eine „Integration innovativer Informations- und Kommunikationstechnologien zur
Unterstützung bzw. Abwicklung von operativen taktischen und strategischen Aufgaben im
Absatz“ einher. 50 Ein E-Shop kann als ein virtueller Verkaufsraum beschrieben werden und
als ein eigenständiges System aus Hard- und Software beschrieben werden, das einem
51
Händler erlaubt, seine Wirtschaftsgüter über Rechnernetze anzubieten. Das Gabler
Wirtschaftslexikon bezeichnet E-Shops in diesem Zusammenhang auch als Plattform, „auf
der Anbieter ihre Waren oder Dienstleistungen präsentieren und der Interessent die
Handhabe besitzt, Produktinformationen einzuholen.“ 52
Allerdings muss hier kritisch angemerkt werden, dass diese in der Literatur verbreitete
Unterscheidung der Plattformen E-Shop und E-Community z.T. im Widerspruch zur Praxis
steht, da es durch den Web 2.0 Trend und hier insbesondere der Zunahme von User
Generated Content, 53 es zur Entwicklung hybrider Modelle gekommen ist. 54 Als Beispiele
55
können die Integration von E-Shops in die E-Community Plattform Facebook oder
46
Vgl. Kollmann, 2007, S. 38; Roumois, 2007, S. 99.
47
Vgl. Meier / Stormer, 2008, S. 34.
48
Vgl. Meier / Stormer, 2008, S. 34.
49
Vgl. Kollmann, 2007, S. 39-41.
50
Kollmann, 2007, S. 165.
51
Vgl. Zwißler, 2002, S. 32, S. n. zitiert nach Kollmann, 2007, S. 189, S. m. .
52
Gabler Wirtschaftslexikon, 12.02.2010.
53
Vgl. Kapitel 2.8.
54
Vgl. Hahn, 08.12.2009.
55
Vgl. Wauters, 08.12.2009.
- 18 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
andersherum die umfangreichen E-Community Funktionen in den E-Shops der Internetstores
AG 56 und Kolibrishop GmbH 57 genannt werden.
Die für den B2C E-Commerce relevante Plattform ist, analog zum Geschäftsmodell Typus
Aggregator, der E-Shop, da nur dieser auf einen reinen B2C Handel fokussiert ist.
Gleichwohl ist nach Definition auch auf der Plattform E-Marketplace ein B2C Handel möglich,
was dem Typ Agora entsprechen würde. Allerdings sind E-Marketplaces für den B2C in der
Praxis für mittelständische und insbesondere Großunternehmen von minimaler Relevanz.
Dies ist insbesondere auf Imagegründe und dem daraus resultierenden Boykott seitens
Markenherstellern zurückzuführen. 58 Alle nachfolgenden Ausführungen beziehen sich somit
auf die Plattform E-Shop.
Nach Kollmann besteht jede Plattform aus weiteren Bausteinen, die betriebswirtschaftlicher
und technischer Natur sind, und zwangläufig für die Umsetzung notwendig sind. Demnach
stellt die Plattform E-Shop, ein Fundament für Technologien und Produkte dar. 59 Laudon und
Traver beschreiben eine praxisorientiertere Sichtweise aus der Perspektive eines Betreibers
und identifizieren sechs Komponenten, aus denen eine E-Shop Plattform bestehen kann:
Hardware Architektur, Software, Telekommunikations-Infrastruktur, Site-Design, personelle
60
Ressourcen und organisatorische Ressourcen. Diese sechs Komponenten stehen
grundsätzlich in gegenseitiger Abhängigkeit zueinander, wobei ein wesentlicher Einfluss von
der Wahl der E-Shop Software ausgeht.
Internet-
verbindung
E-Shop
Software
Server Software
Server Betriebssystem
Web Server Hardware
Abbildung 5: E-Commerce Schichtenpyramide 61
Eine Betrachtungsweise nach Reynolds und Stair führt, mit den technischen
Schlüsselkomponenten Server Hardware, Server Betriebssystem, Server Software und E-
56
Vgl. internetstores AG, 08.12.2009a; vgl. internetstores AG, 08.12.2009b.
57
Vgl. Kolibrishop GmbH 08.12.2009.
58
Vgl Krisch, 20.02.2010; Greif, 20.02.2010; Höschl, 20.02.2010.
59
Vgl Loshin / Vacca, 2005, S. 3.
60
Vgl Laudon / Traver, 2009, S. 4,5f
61
In Anlehnun an Reynolds / Stair, 2003, S. 192.
- 19 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
Shop Software, zu einer vier schichtigen pyramidenartigen Gliederung, wie Abbildung 5
zeigt. 62 Die E-Shop Software bildet dabei die oberste Schicht der E-Commerce Plattform und
steht im Mittelpunkt der nachfolgenden Arbeit.
1.6. E-Shop Software
Das vorherige Kapitel 2.5 und insbesondere die darin aufgeführten Betrachtungsweisen nach
Laudon und Traver, sowie Reynolds und Staire, weisen bereits daraufhin, dass die E-Shop
Software zu den Hauptbestandteilen einer E-Shop Plattform gehört. Mit der Definition der E-
Shop Plattform wurde somit auch ein Teil der Definition der E-Shop Software bereits vorweg
genommen.
Für alle weiteren Ausführung, wird der E-Shop Besucher, d.h. also der potentielle online
Besteller, als Endkunde bezeichnet. Das in Kapitel 2.3 als Aggregator definierte
Unternehmen, das ein E-Shop für die Teilnahme am online Handel betreibt wird nachfolgend
als E-Shop Betreiber bezeichnet.
Im Unterschied zu den anderen nach Reynold und Stair definierten Bausteine einer E-Shop
Plattform, wie z.B. der Server Hardware, sieht der Endkunde die E-Shop Software bzw.
dessen Front-End 63 und führt über diese Transaktionen aus. Somit nimmt der Endkunde
subjektiv auch nur die E-Shop Software bzw. dessen Front-End direkt wahr. Daher
bezeichnet Tassabehji eine E-Shop Software auch als Schnittstelle zwischen E-Shop
Betreiber und Endkunde. 64
In der Literatur werden unterschiedliche Begriffe zur Bezeichnung von E-Shop Software
verwendet. Verbreitet sind insbesondere die aus dem englischen übernommenen
Bezeichnungen Online Shop Software, Shopping Cart Software, Shopsystem oder Webshop.
Seltener wird der abstraktere Begriff E-Commerce Software verwendet. Der Begriff
Shopsystem kann folglich als Synonym für E-Shop Software verwendet werden.
Goluchowski, Filipczyk und Malgotzta definieren drei Kernaufgaben einer E-Shop Software: 65
§ Übermittlung und Austausch von Informationen
§ Kommunikation
§ Verkaufstransaktion
Die Übermittlung und der Austausch von Informationen können beispielsweise durch einen
Newsletter oder eine Produktbewertung erfolgen. Als Beispiele für kommunikative
62
Vgl Reynolds / Stair, 2003, S. 3.
63
Vgl. Kapitel 2.7.
64
Vgl Tassabehji, 2005, S. 102.
65
Vgl. Goluchowski / Filipczyk / Jablonska, 2007, S. 16f.
- 20 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
Funktionen können u.a. ein Kontaktformular oder Live Chat mit dem Service, genannt
werden. Verkaufstransaktionen können z.B. mit Hilfe eines virtuellen Warenkorbes oder einer
Bezahlfunktion realisiert werden.
Nach Reynolds und Stair bilden die Elemente Katalog, Kunden und Geschäftsprozesse den
Kern einer E-Shop Software, wie die Abbildung 6 darstellt. Folglich gehören typischerweise
mindestens das Produktkatalogmanagement, Kundenmanagement und die zugehörigen
Geschäftsprozesse zur Abwicklung von Transaktionen zu den Komponenten einer E-Shop
Software. 66
Katalog Kunden
Geschäftsprozesse
Abbildung 6: E-Commerce Plattform
Die Funktionen können von einer oder mehreren Softwares erfüllt werden. 67 Der Betreiber
muss die Möglichkeit haben, die Geschäftsprozesse nach Bedarf zu modellieren und zu
automatisieren, wie viele unterschiedliche Softwares eingesetzt werden müssen, hängt von
dem individuellen Bedarf ab.
Im Mittelpunkt steht jedoch stets eine zentrale Software, die in allen weiteren Ausführungen
als E-Shop Software bezeichnet wird, da alle weiteren E-Shop Softwarekomponenten i.d.R.
ihr angehängt werden oder zumindest in direkter Abhängigkeit zu ihr stehen. Jede durch
einen Endkunde elektronisch angestoßene Transaktion geht prinzipiell von der E-Shop
Software aus.
66
Vgl. Reynolds / Stair, 2003, S. 193.
67
Vgl. Illik, 2002, S. 131.
- 21 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
1.7. E-Shop Softwarekomponenten
Eine E-Shop Software besteht i.d.R. aus verschiedenen Komponenten. 68 In diesem Sinne,
wird insbesondere in der amerikanischen Literatur manchmal auch die Begriff Softwaresuite,
d.h. also zu Softwaresammlung, gebraucht. 69 Wodurch deutlicher darauf hingewiesen wird,
dass eine E-Shop Software aus einer Vielzahl von Komponenten bestehen kann. Allerdings
wird in der Literatur oftmals nicht näher diskutiert, ob diese sog. Komponenten in der Praxis
integrierte Bestandteile der E-Shop Software oder z.B. eigenständige Software mit
entsprechenden Schnittstellen zur E-Shop Software darstellen. Gleichwohl trägt die rein
theoretische Betrachtung der Komponenten unter Vernachlässigung der Integrationstiefe, zur
übersichtlicheren Darstellung und damit besserem Verständnis bei.
Abbildung 7 zeigt in diesem Sinne den abstrakten Aufbau einer möglichen E-Shop
Softwarelösung, welches wie in bei diesem Beispiel das Katalog-, Kunden- und
Transaktionsverwaltung als Schlüsselkomponenten beinhalten kann. Jedem dieser drei
Komponenten, können prinzipiell weitere Komponenten angehängt werden, wie Abbildung 7
darstellt.
Marketing
Werbeinstrumente gezielte Kundenansprache
Content
Management
User Generated Content Kunden-
Katalog
ERP Produktempfehlungen management
Anbindung
Verfügbarkeit Kommunikation mit Kunden
La
g
un
ge
d
rve
bin
rw
en
a
nd
ltu
Ku
ng
Liefermanegement Retourenmanagement
Transaktions-
verwaltung
Zahlungsabwicklung
Abbildung 7: Beispielhafte Darstellung der E-Shop Softwarekomponenten 70
Grundsätzlich kann eine E-Commerce Software in ein sog. Front-End und Back-End
71
unterteilt werden. Der Endkunde sieht jedoch nur das Front-End, mit dessen
68
Vgl. Laudon / Traver, 2009, S. 4,1- 4,29; Bigdoli, 2007, S. 138-140.
69
Vgl. Laudon / Traver, 2009, S. 4,26- 4,28.
70
In Anlehnung an Walker, 2009, S. 10.
- 22 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
Benutzeroberfläche er interagiert. Das Back-End dient im Gegensatz dazu, der internen
Abwicklung der Prozesse und der Administration der Plattform. 72
Zu den Funktionen im Front-End-Bereich gehören insbesondere 73:
§ Produktkatalog (Kapitel 3.2.1)
§ Kundenkonto (Kapitel 3.2.8)
§ Produktwarenkorb (Kapitel 3.2.2.1)
§ Bestellformular (Kapitel 3.2.2.2)
§ After-Sales-Funktionen (Kapitel 3.2.8)
Zu den wesentlichen Funktionen im Back-End-Bereich gehören 74:
§ Content Management System (Kapitel 3.2.3)
§ Kundenmanagement (Kapitel 3.2.8)
§ Web Analytics (Kapitel 3.2.5)
§ Produktkatalog (Kapitel 3.2.1)
Die aufgeführten Komponenten sind, sofern vorhanden, entweder integrierte Bestandteile
der E-Shop Software oder stehen zumindest im Datenaustausch. Die einzelnen
Komponenten des Front- und Back-Ends werden in Kapitel 3 im Detail erläutert.
1.8. E-Shop Softwaretrends
Auch nach über dreizehn Jahren des Online Handel, eines Internetbooms, dem Niedergang
der New Economy und der Wiederauferstehung dessen, kann eine dynamische
Innovationskraft beobachtet werden, die maßgeblichen Einfluss auf E-Shop Software hat.
Diese Einflüsse sind nicht nur technischer, sondern durchaus vielfältiger Natur und folgen
z.T. dem Zeitgeist der Gesellschaft.
Social Software, neue Internettechnologien und die Veränderung der Nutzeraktivitäten im
Internet werden zusammenfassend auch als Web 2.0 bezeichnet. Bis heute gibt es keine
eindeutige Definition des Begriffes. 75 O’Reilly definiert den Begriff Web 2.0 wie folgt: „Web
2.0 is the business revolution in the computer industry caused by the move to the internet as
platform, and an attempt to understand the rules for success on that new platform. Chief
among those rules is this: Build applications that harness network effects to get better the
71
Vgl. Kollmann, 2009, S. 213.
72
Vgl. Kollmann, 2009, S. 213.
73
Vgl. Kollmann, 2009, S. 213-215.
74
Vgl. Kollmann, 2009, S. 213-215.
75
Vgl. Deans, 2009, S. 5.
- 23 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
more people use them. This is what I've elsewhere called harnessing collective
intelligence.“ 76 Trotz unscharfer Definition verbirgt sich hinter dem Begriff die konkrete
Vorstellung von einer neuen Art des Internets. Sie basiert auf der Annahme, dass das
Platzen der Internetblase (Dot-Com-Kollaps) Ende des letzten Jahrzehnts zu einem
Zusammenbruch des Internets in der damaligen Form geführt hat. Erfolgreich fortbestehen
konnten nur diejenigen, die in der Lage waren, sich weiter zu entwickeln und einen neuen
Ansatz für den Umgang mit dem Internet zu finden. 77
Der Benutzer dieser neuen Form des Internets ist nicht nur Konsument, sondern zugleich
auch Inhaltslieferant. Dafür findet er im Gegenzug aber auch besser auf seine Bedürfnisse
abgestimmte Inhalte vor. Daraus kann sich eine kollektive Intelligenz im Internet formen, die
im Wesentlichen auf der Verknüpfung bzw. Vernetzung der Inhalte durch seine Benutzer
mittels Hyperlinks beruht. Dynamische Inhalte haben statische Homepages abgelöst und
bieten vielfältige Dialog- und Interaktionsmöglichkeiten mit anderen Nutzern des Internets. 78
Da die Anwendungen auf den Nutzer zugeschnitten werden, wird ein besonderes
Augenmerk auf ihre Benutzerfreundlichkeit gerichtet und Wert auf Feedbacks der Nutzer
gelegt. 79
Da es sich bei der Entwicklung von Web 1.0 zu Web 2.0 nur um eine wahrgenommene
Entwicklung und nicht um eine neue Version des Webs handelt, zeigt die folgende Abbildung
8 die Art und Weise der Betrachtung. 80
76
O'Reilly, 07.01.2010.
77
Vgl. O'Reilly, 08.01.2010.
78
Vgl. Beckert, 2007, S. 7f.
79
Vgl. Ebersbach et al., 2008, S. 24.
80
Vgl. Trump et al., 2007, S. 9.
- 24 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
gestaltend
Web 2.0
Kommunikation
Kommunikation
individuelle
öffentliche
Web 1.0
betrachtend
Aktiv partizipierende Nutzer
Passiv partizipierende Nutzer
Abbildung 8: Die zwei Dimensionen des Internets 81
Die Betrachtungsweisen gehen hier von rein betrachtend und individuell kommunizierend bis
zu gestaltend und öffentlich kommunizierend. Die Dimension Gestaltungsgrad erstreckt sich
von rein betrachtender Nutzung, z.B. durch das Lesen eines Artikels, bis zur gestaltender
82
Nutzung, z.B. durch Verfassen von Texten im Internet. Die zweite Dimension
Kommunikationsgrad erstreckt sich vom Bereich der individuellen Kommunikation, z. B.
versenden von privaten E-Mails, bis zum Bereich der öffentlichen Kommunikation. 83
Bei der Evaluierung und Auswahl von E-Shop Software ist es unabdingbar diese Einflüsse
zu berücksichtigen, da sie sich in den Bedürfnissen des Endkunden widerspiegeln. Dieses
Kapitel soll eine Übersicht dieser Einflüsse und Trends aufzeigen, die innerhalb der nächsten
Kapitel aufgegriffen und z.T. im Detail behandelt werden. In diesem Sinne gewährt die
folgende Tabelle eine Übersicht über heutige Trends und Einflüsse auf Grundlage von
Walkers Vorschlägen, die relevant für E-Shop Software sind. 84
Perso- Die Beziehung zwischen E-Shop Betreiber und Endkunden „weicht,
nalisierung getrieben von einer Verlagerung der Endkundenerwartungen, zunehmend
einer stärkeren Integration des Nachfragers in die Angebotserstellung von
Personalisierung und Individualisierung der Angebote.“ 85 Dazu eignen sich
81
In Anlehnung an Trump et al., 2007, S. 9.
82
Vgl. Trump et al., 2007, S. 10.
83
Vgl. Trump et al., 2007, S. 10.
84
Vgl. Walker, 2009, S. 6.
85
Wirtz, 2001, S. 289.
- 25 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
Produktempfehlungsfunktionen, wie z.B. Cross- oder Up-Selling
86
Funktionen. Beim Up-Selling werden Produkte auf Basis der bisherigen
Wahl, passende Produkte mit einem höheren Preis angeboten. 87 Cross-
Selling kann als sinnvolle Produktempfehlungen, über Produktkategorien
hinweg definiert werden. 88
Multiple Eine zunehmende Anzahl an Ausprägungstypen des Geschäftsmodells
Geschäfts-
Aggregator, wie z.B. Clubverkauf und Liveshopping, 89 stellen besondere
modelle
Anforderungen an die E-Shop Software flexibel für unterschiedliche
Ausprägungstypen verwendbar zu sein.
Inter- International aufgestellte E-Shop Betreiber sehen sich gefordert in den
nationalisierung
Zielmärkten regionalspezifisch angepasst, andererseits aber
wiedererkennbar und mit den gleichen Daten aufzutreten und das
möglichst zentral zu steuern. 90 Globale E-Commerce Lösungen sollten
unterschiedliche lokale Gepflogenheiten hinsichtlich Sprache,
Adressformate, Workflows, Mehrwertsteueranzeige etc. unterstützen und
die unterschiedlichen lokalen E-Commerce Varianten in einem System
konsolidieren und betreiben. Die Unterstützung von internationalen E-
Commerce Aktivitäten durch die E-Shop Software wird in Kapitel 3.2.5
näher erläutert.
User Generated Mediale Inhalte, wie z.B. Text, Fotos und Videos, die vom Nutzer
Content
bereitgestellt werden, können als User Generated Content bezeichnet
werden. 91 Bei E-Shops findet man diese insbesondere in Form von E-
Shop-Bewertungen, Produktbewertungen und produktbezogenen
Diskussionen wieder. Dies kann innerhalb des E-Shops, z.B. durch
entsprechende Bewertungsformulare je Produkt, die Integration von Foren
und Blogs, sowie Anbindung von Bewertungssysteme Dritter, realisiert
werden. User Generated Content stellt eine zusätzliche Informationsquelle
für potenzielle Endkunden dar, bindet Endkunden und führt zu einer
verbesserten Suchmaschinenfreundlichkeit.
Tabelle 4: Trends und Einflüssen mit Relevanz für E-Shop Software 92
86
Vgl. Panniello / Gorgoglione / Palmisano, 2009, S. 248-250.
87
Vgl. Bustos, 08.01.2010.
88
Vgl. Netessine / Savin / Xiao, 2004, S. 2-3.
89
Vgl. Kapitel 2.3.
90
Vgl. BITKOM, 2009, S. 26.
91
Vgl. Tapp, 2008, S. 302-303.
92
Vgl. Walker, 2009, S. 6.
- 26 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
1.9. Betreibermodelle
Die Nutzung und Verbreitung von Software unterliegt als Ausdruck einer schöpferischen
Leistung dem urheberrechtlichen Schutz. Entsprechend des deutschen Urhebergesetzes
kann der geistige Schöpfer eines Werkes bezüglich der Nutzung und Verbreitung
entscheiden. 93 Die genaue Ausgestaltung der vom Urheber gewährten Nutzungsrechte, wird
in der Softwarelizenz festgehalten. Dabei unterscheiden sich je nach Distributions-Modell,
die Nutzungsrechte und Möglichkeiten sehr deutlich.
Nach der ibi research an der Universität Regensburg GmbH, kann aus Sicht eines E-Shop
Software Nachfragers grundsätzlich zwischen vier E-Shop Software-Distributionsmodell
unterscheiden: 94
§ quelloffene Software
§ Miet-Software
§ Eigenentwicklung
§ Kauf-Software
Als quelloffen, im Englischen auch Open Source genannt, werden Programme bezeichnet,
deren Quellcodes offen zugänglich sind, die uneingeschränkt genutzt, verändert und
erweitert werden können, sowie „in modifizierter wie in nichtmodifizierter Form
lizenzkostenfrei vervielfältigt und verbreitet werden dürfen.“ 95 Folglich kann sie i.d.R. beliebig
weiterentwickelt und je nach Anwendungszweck angepasst werden. Quelloffene E-Shop
Software ist ihrer Definition nach, grundsätzlich kostenlos beziehbar.
Miet-Software basiert auf dem Grundsatz, dass die Software von einem externen
Dienstleister betrieben wird. Miet-Software für E-Shops, wird somit i.d.R. auf dem Servern
des Anbieters installiert und lässt sich nach einem Baukastensystem einrichten und
erweitern. Allerdings kann i.d.R. nur das Partnerunternehmen, das die Miet-Software
anbietet auch weitreichende Änderungen am Softwarecode vornehmen, da die
Anpassungsmöglichkeiten seitens des Nachfrager begrenzt sind. In der Literatur und der
Industrie werden z.T. unterschiedliche Begriffe wie ASP (Application Service Providing),
SaaS (Software as a Service) oder on demand Solutions verwendet.
Dabei beschreiben diese Begriffe unterschiedliche Varianten von Miet-Software, die sich
oftmals durch ihren Standardisierungsgrad unterscheiden und nicht selten zu
93
Vgl. Mundhenke, 2007, S. 40.
94
Vgl. ibi research an der Universität Regensburg GmbH, 2009, S. 45-47.
95
Mundhenke, 2007, S. 15.
- 27 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
96
Marketingzwecken genutzt werden. An dieser Stelle soll auf diese Varianten der Miet-
Software verwiesen werden, wobei auf eine tiefere Diskussion dieser verzichtet wird. 97
Intern entwickelte E-Shop Software ist i.d.R. sehr individuellen Bedürfnissen zugeschnitten
und wird als Eigenentwicklung bezeichnet. Theoretisch sind der Entwicklung keine Grenzen
gesetzt. In der Praxis hängt die Entwicklung jedoch von verfügbaren Ressourcen ab.
Kauf-Software basiert entweder auf eine Eigenentwicklung oder quelloffener-Software. In der
Literatur wird Kaufsoftware auch als Fertigsoftware oder kommerzielle Standardsoftware
bezeichnet. 98 Kauf-Software wird oftmals in Kombination mit zusätzlichen Dienstleistungen,
wie z.B. Supportverträgen, erworben. Die Nutzung der Software kann seitens des Herstellers
auf verschiedenste Weise, wie z.B. zeitlich, funktional oder nach Anzahl der Administratoren
bzw. Mitarbeiter, eingeschränkt werden. Ebenso können Änderungen am Code untersagt
99
sein. Grundsätzlich hängen die Rechte des E-Shop Betreibers von dem jeweils
vereinbarten Kaufvertrag ab.
Die unterschiedlichen Distributionsmodelle zeigen, dass der E-Shop Betreiber, abhängig
vom gewählten Modell, ein unterschiedliches Maß an Ressourcen selber bereitstellen bzw. in
unterschiedlichem Maße externe Unternehmen einbeziehen muss. Kollmann greift diese
Problematik auf und unterscheidet mit dem Betreiber-, Dienstleister- und Partner-Modell,
zwischen drei Modellen, die sich durch unterschiedliche Wertbeiträge unterscheiden, wie die
Abbildung 9 verdeutlicht. 100
96
Vgl. Lassmann, 2006, S. 130; Schaffry, 04.01.2010; Grobmann, 2008, S. 15-17.
97
Für weitere Informationen sei auf folgende Literatur verwiesen: Beinhauer / Herr / Schmidt, 2008;
Buxmann / Diefenbach / Hess, 2008; Grobmann, 2008.
98
Vgl. Henning, 2004, S. 11.
99
Vgl. Gläßer, 2004, S. 19f.
100
Vgl. Kollmann, 2007, S. 319-321.
- 28 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
Betreiber Dienstleister Partner
E-Shop Individual- Standard-
Software lösung lösung
Eigen-
Administration Partner
verantwortung
Resourcen-
hoch niedrig
bedarf
Strategischer
hoch niedrig
Einfluss
Abbildung 9: Wertbeiträge-Modell für E-Shop Lösungen 101
Mit Abbildung 9 wird E-Shop Software in Relations zum Wertbeitrag seitens des E-Shop
Betreibers, idealistisch betrachtet.
Charakteristisch für das Betreiber-Modell ist die hohe Eigenverantwortung des E-Shop
Betreiber, da sie eine Lösung größtenteils bis vollständig im eigenen Haus entwickelt und
selber alle notwendigen Dienstleistungen, wie die Administration und Instandhaltung erbringt.
Dem entsprechend ist das Modell sehr individuell. Allerdings muss das jeweilige
Unternehmen auch weitreichende Ressourcen, wie z.B. Know-how, bereitstellen. 102 Dafür
behält der E-Shop Betreiber einen hohen strategischen Einfluss.
Das Partner-Modell bildet das andere Extrem innerhalb der Skala. Charakteristisch für diese
Modelle ist die überwiegende bis vollständige Übertragung aller Aufgaben auf ein
Partnerunternehmen, das sämtliche Dienstleistungen, wie die Administration, Installation der
E-Shop Software und Bereitstellung der technischen Infrastruktur gewährleistet. Ebenso ist
diese i.d.R. für die Wartung und den Support verantwortlich. Folglich fallen die Startkosten
geringer aus als bei den anderen beiden Modellen. Auch fällt der Ressourcenbedarf
vergleichbar gering aus, da das Partnerunternehmen weitreichende Aufgaben erfüllt. 103
Allerdings verfügt das Unternehmen, das diese Dienstleistungen nachfragt über einen nur
geringen strategischen Einfluss und ist stark abhängig vom externen Dienstleister.
Das Dienstleister-Modell befindet sich innerhalb der Skala zwischen dem Betreiber- und
Partner-Modell. Dem entsprechend stellt es eine Mischung aus beiden Modellen dar. Es
101
In Anlehnung an Kollmann, 2007, S. 321.
102
Vgl. Kollmann, 2007, S. 319-321.
103
Vgl. Kollmann, 2007, S. 319-321.
- 29 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
nutzt nur bis zu einem bestimmten Grad externe Dienstleister und nutzt auch eigene
Ressourcen. Folglich verfügt es über einen deutlichen strategischen Einfluss. 104
Da das Betreiber-Modell auf eine sehr individuelle Lösung setzt, eignet sich sowohl eine
Eigenentwicklung, als auch eine quelloffene E-Shop Software, da dessen Quellcode beliebig
verändert werden darf.
Für das Dienstleister-Modell eignet sich Kauf-Software, da der E-Shop Betreiber damit einen
vorgefertigten Shop erwirbt, der je nach seinen Bedürfnissen insbesondere optisch
angepasst werden muss.
Beim Partner-Modell wird eine Miet-Software angeboten, da das Partnerunternehmen sehr
weitreichende Aufgaben erfüllt und selbst hostet. Die Miet-Software an sich kann auf andere
Distributionsmodelle basieren und z.B. eine Eigenentwicklung sein. Aber aus Sicht des E-
Shop Betreiber handelt es sich um eine Miet-Software.
Allerdings kann die Miet-Software an sich ein E-Shop Software sein die vom Partner-
Unternehmen auf Basis eines quelloffenen E-Shops entwickelt wurde oder eine Kauf-
Software eines anderen Herstellers darstellt.
Diese drei Szenarien stellen typische Beispiele dar. Da es sich jedoch um eine Skala
handelt, sind diverse Mischformen denkbar. Für den Bereich zwischen Betreiber- und
Dienstleister-Modell kann sich z.B. eine quelloffene Software anbieten, wobei diverse
Dienstleistungen, z.B. zur Anpassung der Software, eingekauft werden
Die nachfolgende Abbildung verbildlicht die Verknüpfung der Distributionsmodelle mit dem
Wertbeiträge-Modell.
Abbildung 10: Einsatz der E-Shop Distributionsmodelle in Abhängigkeit zum Wertbeitrag
104
Vgl. Kollmann, 2007, S. 319-324.
- 30 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
Abbildung 10 zeigt sehr idealistisch und allgemein, welche bis zu welchem Grad E-Shop
Software Distributionsmodelle externe Dienstleister einbinden, ohne Anspruch auf
Vollständigkeit zu erheben.
2. Anforderungen an E-Shop Software
Thayer und Dorfman definieren Anforderungen als eine vom Anwender benötigte Fähigkeit
des Systems, um ein Problem zu lösen oder ein Ziel zu erreichen, oder eine Fähigkeit, die
das System besitzen muss, damit es einen Vertrag, einen Standard, eine Spezifikation oder
ein anderes formelles Dokument erfüllt. 105 Thayer und Dorfmans Definition aufgreifend, muss
an dieser angemerkt werden, dass im Falle von E-Shop Software zwei Anwendertypen
berücksichtigt werden müssen. Der Endkunde, der einmal später Produkte und
Dienstleistungen über den E-Shop beziehen soll, sowie der Betreiber, der den E-Shop zum
Vertrieb seiner Produkte oder Dienstleistungen nutzt. Dabei ist eine einseitige Betrachtung
der Anforderungen, wie z.B. nur aus Sicht des Endkunden oder E-Shop Betreibers nicht
sinnvoll, da gegenseitige Abhängigkeiten bestehen.
Eine E-Shop Software, die nahtlos in das bestehende Informationssystem eines E-Shop
Betreibers eingebunden werden kann, aber wegen mangelnder Funktionen wenig
kundenfreundlich ist, stellt keinen Idealzustand dar. Ebenso wenig erfolgreich wäre
voraussichtlich ein aus Endkundensicht komfortabel zu bedienender E-Shop, der jedoch
aufgrund von fehlenden Schnittstellen, für den E-Shop Betreiber sehr hohe Kosten in der
Abwicklung von Transaktionen verursacht.
Opuchlik z.B. definiert mit Produkten, Verkaufsförderung, Service, Komfort und Navigation,
Warenkorb und Bezahlung, sowie Sicherheit, sieben Anforderungen aus Endkundensicht,
die jedoch nur sehr bedingt relevante Anforderungen für die Evaluierung von E-Shop
Software darstellen. Schließlich hängt die Verkaufsförderung beispielsweise vom
Unternehmensmarketing ab, die Bezahlung von der Unternehmenspolitik und der Service
sind abhängig vom Liefer- und Kundenservice. Freilich sind das Unternehmensmarketing,
die Unternehmenspolitik oder der Liefer- und Kundenservice keine Faktoren, die maßgeblich
abhängig von der E-Shop Software wären. Folglich bedarf es zwar eine gesamtheitliche
Betrachtung der Anforderungen, sowohl aus Endkunden- als auch E-Shop Betreiber Sicht,
wobei Anforderungen ohne Relevanz für die Evaluierung einer E-Shop Software von der
Betrachtung ausgeschlossen werden müssen.
105
Vgl. Thayer, Richard H.; Dorfman, Merlin; Baili, 1997, S. 23-28.
- 31 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
Die in Kapitel 2 aufgeführten Definitionen und Diskussionen des Geschäftsmodell Typus
Aggregator, der E-Commerce Plattform E-Shop und der E-Shop Software, werden in diesem
Kapitel als Grundlage für die Identifizierung, Definition und Gruppierung der Anforderungen
an E-Shop Software, seitens E-Shop Betreiber und Endkunden verwendet. Des Weiteren
werden die nachfolgenden Unterscheidungen verschiedener Autoren berücksichtigt.
Reynolds und Staire schlagen mit Katalog Management, Produktwarenkorb und
Produktmanagement eine dreigliedrige Gruppierung vor. 106 Schneider schlägt mit Katalog,
Produktwarenkorb und Transaktionsverwaltung eine sehr ähnliche Unterscheidung vor. 107
Schneider sieht anders als Reynolds und Staire, das Produktmanagement als Teil des
Katalog Managements, wobei er die Abwicklung von Transaktionen nicht der Gruppe
Produktwarenkorb getrennt betrachtet. Insgesamt basieren die Unterschiede zwischen
Reynolds und Staire sowie Schneiders Betrachtung, also auf unterschiedliche Definitionen.
Opuchlik schlägt mit der Gruppierung der Anforderungen in Architektur, Administration,
Sicherheit und Skalierbarkeit eine weitergehende Unterscheidung vor, wobei unter dem
Begriff Administration im Grunde Back-End Funktionen 108 zusammengefasst werden. 109 Die
bisher erwähnten Autoren definieren Anforderungen an eine E-Shop Software ohne jedoch
den Einfluss des Herstellers für die zukünftige Entwicklung der E-Shop Software zu
berücksichtigen. Die BITKOM bleibt bei der Formulierung von Anforderungen sehr allgemein,
weist jedoch auf verschiedene Betreibermodelle hin und unterstreicht die Bedeutung des
Herstellersupports. 110 Die Einbeziehung des E-Shop Softwareherstellers, stellt aufgrund der
z.T. hohen Abhängigkeit je nach Betreibermodel, ein wichtiges Kriterium dar. 111
Aufbauend auf die hier dargestellten Vorschläge verschiedener Autoren, werden
nachfolgend die Anforderungen an E-Shop Software, bei einer Gliederung in die Teilbereiche
Architektur, Funktionen, Sicherheit und Strategie, im Detail erläutert.
106
Vgl. Reynold / Staire, 2003, S.193f.
107
Vgl. Schneider, 2004, S. 361.
108
Vgl. Kapitel 2.7.
109
Vgl. Opuchik, 205, S. 117.
110
Vgl. BITKOM, 2009, S. 29-32.
111
Vgl. Turban / Rainer Jr., 2009, S. 14,47-14,51; Reynolds, 2004, S. 200f; Korper / Ellis, 2001, S.
172-175.
- 32 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
2.1. Architektur
E-Commerce Lösungen müssen in der Position sein, wachsende Benutzerzahlen bewältigen
zu können und Dienste auch bei einer hohen Auslastung zuverlässig bereitstellen zu können.
Sich schnell verändernde Anforderungen, bedürfen die zuverlässigen, interaktiven und
sicheren Zusammenarbeit interner und externer Ressourcen, bei gleichzeitiger Wahrung der
Flexibilität. 112
Die Architektur beschreibt die Struktur eines Systems, dessen Bausteine, Schnittstellen und
deren Zusammenspiel. 113 Die Architektur besteht aus Plänen und enthält i.d.R. Hinweise und
Vorschriften, nach denen das System zusammengebaut werden sollte. 114 Damit kann die
Software-Architektur auch als Plan eines Systems gesehen werden.
Durch die Architektur wird die Komplexität eines Systems besser erfassbar und
verständlicher. Tom DeMarco bezeichnet die Architektur auch als framework of change, d.h.
sie kann einen Rahmen darstellen innerhalb dessen die Software entwickelt werden kann. 115
Bass, Clements und Kazman definieren Software-Architektur als die Struktur eines Systems,
das Softwarekomponenten, die Eigenschaften dieser Komponenten sowie deren
116
Beziehungen aufzeigt. Der in dieser Definition genannte Begriff Komponente, kann
beispielsweise eine Datenbank oder ein Server sein. Durch die Beziehung der Komponenten
untereinander und der Eigenschaften dieser Beziehungen entsteht eine Struktur, die man
Software-Architektur nennt. 117
Entsprechend der sich mit der Zeit verändernden Anforderungen an Software, unterliegt
auch die Architektur Veränderungen. Die Anforderungen können sich grundsätzlich sowohl
während der Entwicklungsphase als auch danach ändern. Die folgende Abbildung stellt die
Einflussfaktoren in Bezug auf die Architektur dar.
112
Vgl. Strobel, 2004, S121.
113
Vgl. Starke / Hruschka, 2009, S. 2.
114
Vgl. Starke / Hruschka, 2009, S. 3.
115
Vgl. DeMarco,1995, S. 128; Eichinger, 2003, S. 66.
116
Vgl. Bass / Clements / Kazman, 2003, S. 3.
117
Vgl. Müller, 2005, S. 59.
- 33 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
Fu
ät
nk
lit
tio
ua
ne
Q
n
Software Architektur
Te
ch
ni
g
un
sc
hr
he
fa
As
Er
pe
kt
e
Abbildung 11: Auf die Entwicklung einer Softwarearchitektur wirkende Faktoren 118
Wie in der Abbildung 11 dargestellt, können vier unterschiedliche Einflussfaktoren
unterschieden werden. Die funktionalen Faktoren beziehen sich die Clienten und andere
Nutzergruppen. Zu den qualitativen Faktoren können insbesondere die Erweiterbarkeit,
Performance und Wiederverwendbarkeit gezählt werden. Ein technische Aspekt kann z.B.
das Betriebssystem sein. Der Einflussfaktor Erfahrung bezieht sich z.B. auf das
Projektmanagement und Erfahrungswerten aus bestehenden Softwarearchitekturen. 119
In den nachfolgenden Unterkapiteln werden Softwarearchitekturen mit Fokus auf E-Shop
Software näher erläutert.
2.1.1. Architekturmuster
Eine bewährte Form der Dokumentation von Software-Architekturstrukturen ist das
Schichten-Architekturmuster. 120 Mit dieser kann die Anordnung von Systembausteinen auf
unterschiedlichen Ebenen dokumentiert werden. Unter einer Schicht kann ein abgekapseltes
Objekt oder eine Komponente verstanden werden. 121 Durch die Schichten-Architektur wird
eine klare Trennung der Funktionen und Aufgaben erreicht. Grundsätzlich sind
unterschiedliche Merkmale der Trennung möglich. In Anlehnung an das ISO-
118
Vgl. Eichinger, 2003, S. 67.
119
Vgl. Eichinger, 2003, S. 67.
120
Vgl. Vogel u.a., 2005, S. 34.
121
Vgl. Strobel, 2004, S. 122.
- 34 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
Schichtenmodell, dürfen die Schichten nur mit den benachbarten Schichten kommunizieren,
d.h. mit den Schichten, die über oder unter ihnen liegen. 122
2.1.2. Zwei- und n-Schichten Architektur
Eine Client/Server Lösung stellt eine typische zwei-Schichten-Architektur dar. 123 Der Server
beherbergt die Datenbank und realisiert die Zugriffe auf die Daten, die vom Client initiiert
werden. Diese Architektur basiert auf einem einfachen Anfrage- /Antwort Konstrukt.
Grundsätzlich ist sie für einfache Anwendungen geeignet und funktioniert bei einer
bestimmten Anzahl an Clienten gut, wobei jedoch, die Leistung bei hohen Nutzerzahlen stark
abnimmt. 124
Strobel identifiziert dazu weitere Nachteile 125:
§ Der Entwicklungsprozess der Anwendung geschieht auf einem Computersystem, das
die Informationen darstellt und verarbeitet. Dadurch wird der Anwendungscode aus
den verschiedenen Teilen miteinander vermischt und das individuelle Programm lässt
sich schwer warten.
§ Es ist eine Entwicklungsgruppe notwendig, die sich mit der grafischen und der
Verarbeitungslogik auskennt, da sich die Verarbeitungslogik und Präsentation der
Daten in der gleichen Schicht befinden.
§ „Die Wiederverwendung der Anwendungsteile ist wegen Individualität des Codes
schwierig.“ 126
§ Der Datenbankserver muss zusätzlich gesichert werden, um nicht für jede
Benutzergruppe zugänglich zu sein.
Eine n-Schichten oder Mehr-Schichtenarchitektur setzt bei den Schwachstellen der zwei-
Schichtenarchitektur an und sieht mit einer Präsentationsschicht, Business-Logik-Schicht
und Datenschicht, mindestens drei Schichten vor. Weitere Schichten können beispielsweise
hinzugezogen werden, um Ausfallsicherheitsanforderungen zu begegnen oder zur
Lastverteilung durch die Verteilung der Clientanfragen an verschiedene Server. 127
Die Schichten arbeiten getrennt voneinander und besitzen eigene Eigenschaften und
Methoden. Jede Schicht verfügt über Kommunikationsschnittstellen zu seinen
122
Vgl. Müller, 2005, S. 62.
123
Vgl. Müller, 2005, S. 64.
124
Vgl. Vogel u.a., 2005, S. 212; Müller, 2005, S. 64.
125
Vgl.Strobel, 2004, S. 123-125.
126
Strobel, 2004, S. 123.
127
Vgl. Vogel u.a., 2005, S. 212f.
- 35 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
128
Nachbarschichten. Folglich ist es möglich, dass die Schichten auf jeweils
unterschiedlichen physikalischen Servern arbeiten.
Strobel identifiziert folgende Eigenschaften von n-Schichtenarchitekturen 129:
§ Die Trennung der Schichten erlaubt den Austausch von Modulen
§ Es können Entwicklungsgruppen gebildet werden, die sich auf einen
Anwendungsbereich spezialisieren
§ Die Anwendungslogik muss nur einmal implementiert werden
Im Vergleich zu zwei-Schichtigen Lösungen haben n-schichtige Architekturen also deutliche
Vorteile im E-Commerce Bereich. 130 Die Stärken zeigen sich z.B. durch wiederverwendbare
Komponenten, verteilte Ressourcen, standardisierte Schnittstellen und
Transaktionsüberwachungen.
2.1.3. Service orientierte Architekturen
Eine Service orientierte Architektur (SOA) beschreibt den Aufbau einer
Anwendungslandschaft, bestehend aus einzelnen Anwendungsbausteinen, die verbunden
131
sind und einander ihre Services anbieten. In diesem Sinne ist ein Service eine definierte
Leistung, die „als Element eines oder mehrerer Verarbeitungsabläufe verwendet werden
kann.“ 132
Eine einheitliche und allgemein anerkannte Definition des Begriffe SOA besteht jedoch
nicht. 133 Forrester Research definiert SOA als Art und Weise, wie Anwendungen und
134
Software-Infrastruktur gestaltet, bereitgestellt und verwaltet werden. Gemäß dem
Unternehmen IBM bestimmt SOA die Art und Weise wie man Software baut und erlaubt eine
Software Services für eine andere Software bereitzustellen. Somit wird als Basis der Service
als wiederholbarer Arbeitsschritt innerhalb einer Geschäftsprozesses verstanden. 135
Zu den Charakteristiken einer SOA zählen die verteilte Architektur, die lose Kopplung von
Services und standardisierte Schnittstellen. Zu den Vorteilen zählen die
128
Vgl. Web-Technologien, C.Strobel, S. 123.
129
Vgl. Web-Technologien, C.Strobel, S. 131.
130
Vgl. Strobel, 2004, S. 135.
131
Vgl. Richter / Haller / Schrey, 2005, S. 413-416.
132
Richter / Haller / Schrey, 2005, S. 413.
133
Vgl. Liebhart, 2007, S. 6.
134
Vgl. Liebhart, 2007, S. 6.
135
Vgl. Liebhart, 2007, S. 6.
- 36 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
Wiederverwendbarkeit (der Services), die Flexibilität, Kosteneffizienz, Transparenz und hohe
Kompatibilität. 136
Der modulare Aufbau verringert im Allgemeinen die Komplexität der IT Struktur. Module zur
Erweiterung von E-Shop Software werden in der Literatur auch als Plugins bezeichnet. Da
ein Modul theoretisch beliebig oft für eine E-Shop Software verwendet werden kann, lassen
sich durch diese Wiederverwendbarkeit Kosten senken. Zudem stellt dies einen zusätzlichen
Anreiz für externe Dienstleister dar, Module zu entwickeln.
Die Erweiterbarkeit durch Module ist insbesondere für E-Shop Software von sehr großer
Wichtigkeit, weil hier z.T. sehr viele externe Anwendungen angebunden werden müssen, wie
Kapitel 2.7 detaillierter zeigt. In diesen Fällen kann es von bedeutendem Vorteil sein Module,
wie z.B. Content Management Systeme 137 oder der Web Analytic Software 138 einfach
anbinden zu können, und nach Möglichkeit von Herstellern Standardmodule bereitgestellt zu
bekommen. Bereits die Wiederverwendbarkeit von Standardmodule kann externe
Dienstleister motivieren, Softwaremodule zu entwickeln und am Markt anzubieten.
Allerdings müssen bei individuellen Projekten neben den eigenen Anforderungen auch die
möglichen zukünftigen Anforderungen anderer Bausteine berücksichtigt werden, was eine
vorausschauenden Vorgehensweise bedarf. Folglich setzt SOA ein tiefes Verständnis der
Geschäftsprozesse voraus. 139
2.1.4. Datenaustausch
Um den Datenaustausch im E-Business und damit auch mit der E-Shop Software effizienter
und kostensparender zu machen, sind nutzbare Standards notwendig. Der Datenaustausch
kann sowohl zwischen Unternehmen, als auch zwischen unterschiedlichen Anwendungen
innerhalb eines Unternehmens erfolgen, . Im Allgemeinen bezieht sich der Datenaustausch
auf produkt oder kunden-bezogene Daten. Als Beispiele können der Import von
Produktdaten von einem ERP Software, der Export von Bestelldaten an eine ERP Software
oder der Export von Produktdaten zu Marketingzwecken z.B. für Preisvergleichsportale oder
Affiliate-Netzwerke genannt werden.
Der Datenaustausch erfolgt dabei stets auf Grundlage definierter Datenformate. 140 Dabei
lassen sich Standards im Vergleich zu proprietären Formaten grundsätzlich leichter
136
Hermann Krallermann u.a., 2007, S. 16.
137
Vgl. Kapitel 3.2.3.
138
Vgl. Kapitel 3.2.6.
139
Vgl. Holtkamp, 2009, S. 14.
140
Vgl. Leukel, 2004, S. 67f.
- 37 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
gegenüber Partnern durchsetzen, werden von vielen Unternehmen unterstützt und benötigen
141
kein schwer zu akquirierendes Wissen. Des Weiteren sind E-Business Standards
142
konvertierbar. D.h. die Daten eines z.B. XML-basierten Formats, lassen sich mit Hilfe der
entsprechenden Transformationsregel stets in ein anderes XML-basiertes Format
umwandeln.
Zu den bedeutendsten Standards gehören die Datenformate CSV, EDI und XML, die in der
Tabelle 5 miteinander verglichen werden. 143
CSV-Formate EDI-Formate XML-Formate
Übertragungsgröße Minimal Gering Hoch
Formale Spezifikation Nein Nein Ja
Multimediadaten Nein Nein Ja
Plattformunabhängig Nein Nein Ja
144
Tabelle 5: Vergleich CSV-, EDI- und XML-basierter Datenformate
Der Vergleich von XML Dokumenten mit der zugehörigen, formalen Spezifikation stellt die
Gültigkeit der Dokumente und damit die Konformität zum definierten Format sicher. Dadurch
keine fehlerhafte Daten, z.B. weil sie falsche Datentypen oder nicht definierte Datenelemente
beinhalten, verarbeitet. Dies ist beim CSV- und EDI-Format nicht gegeben. 145 Die Aufnahme
von Multimediadaten, wie z.B. Abbildungen, ist ebenso nur mit dem XML Format möglich.
Für die Kommunikation eines E-Shops mit externen Anwendungen, bedarf es i.d.R. weiterer
Technologien. Insbesondere das Netzwerkprotokoll SOAP (Simple Object Access Protocol),
mit dessen Hilfe Daten zwischen zwei Systemen ausgetauscht werden können, gilt als ein
Industriestandard und wird u.a. von IBM, Hewlett-Packard, Sun Microsystems
(Tochterunternehmen von Oracle) 146 und Microsoft unterstützt. 147 Die Unterstützung von
SOAP seitens einer E-Shop Software, gehört somit bereits aufgrund der Verbreitung von
SOAP zu den Grundvoraussetzungen für einen Datenaustausch mit unterschiedlichen
Anwendungen. 148
141
Vgl. Quantz / Wichmann, 2003, S. 10.
142
Vgl. Kollmann, 2007, S. 67.
143
Vgl. Leukel, 2004, S. 78.
144
Vgl. Leukel, 2004, S. 78.
145
Vgl. Leukel 2004, S. 77.
146
Vgl. Oracle, 04.01.2010.
147
Vgl. Blakey, 05.01.2010; Amor, Daniel, 2004, S. 358-360.
148
Vgl. Hawk / Zheng, 2008, S. 2208-2211; Papazoglou, 2008, S. 120.
- 38 -

Keyvan Karimi - Entwicklung eines Evaluierungsmodells für E-Shop Software
Weitere Technologien, die für eine Datenübertragung relevant sein können und auf die sich
SOAP z.T. stützt, sind u.a. Web Service Description Language (WSDL), Hypertext Transfer
Protocol (HTTP), HyperText Transfer Protocol Secure (HTTPS), 149 und Universal
Description, Discovery and Integration (UDDI), auf die hier nur verwiesen werden soll. 150
Zusätzliche Funktionen, die eine Verwaltung- und Automatisierung des Datenaustausches
über eine Benutzeroberfläche erlauben, können helfen, den Datenaustausch zu vereinfachen
und transparenter zu gestalten.
Alternativ können Export- und Import-Abläufe beispielsweise durch i.d.R. eigenentwickelte
Skripte realisiert werden, sofern die Rahmenbedingungen es erlauben. Bei diesem Beispiel
könnte der Datenaustausch durch die Einstellung von sog. Cron Jobs, einer Software zur
Ausführung von Kommandos zu einer festgesetzten Zeit oder in festgelegten Abständen,
automatisiert werden. 151
2.1.5. Ladezeit
Aufgrund der enormen Informationsflut im Internet, hat der Nutzer das Bedürfnis, in wenigen
Schritten zur gewünschten Information zu gelangen. Folglich stellt die Ladezeit eines E-
Shops einen wichtigen Erfolgsfaktor dar. 152
Tests bei der Firma Amazon haben gezeigt, dass eine Erhöhung der Ladezeit von
amazon.com um 100ms zu einem Umsatzrückgang von einem Prozent führt. 153 Google
stellte fest, dass die Umstellung von der Anzeige von zehn Suchergebnissen je Seite bei
einer Ladezeit von 0,4s hin zur Anzeige von 30 Suchergebnissen je Seite bei einer Ladezeit
von 0,9s, zu einem Rückgang der Besucherzahlen und einem Umsatzrückgang von 20%
führen kann. 154
Eine Studie in den USA kommt zu dem Schluss, dass eine Ladezeit von länger als drei
Sekunden für 40 Prozent aller Befragten nicht akzeptabel sei. 155 Dauert der Aufbau länger,
verlassen die Nutzer den Shop und suchen einen anderen Online-Händler.
Allerdings hängt die Ladezeit von zahlreichen unterschiedlichen Faktoren ab, worauf die
Betrachtung von Laudon und Traver oder Stair und Reynolds in Kapitel 2.5 schließen
149
Vgl. Kapitel 3.3.4.
150
Für weitere Informationen sei auf folgende Literatur verwiesen: Lee u.a., 2003, S. 186-1992; Hawk
/ Zheng, 2008, S. 2208f; Papazoglou, 2008, S. 120-122.
151
Vgl. Lexitron, 05.01.2010.
152
Vgl. BITKOM, 2009, S. 26f; Müller, 2004, S. 97-101; Groß, 04.01.2010.
153
Vgl. Kohavi / Longbotham, 2007, S. 103‐105.
154
Vgl. Mayer, 19.12.2010.
155
Vgl. Forrester Research, 2009a, S. 7f.
- 39 -