Unter Skalierbarkeit versteht man die Fahigkeit eines Systems, Netzwerks oder Prozesses zur Großenveranderung. Meist wird dabei die Fahigkeit des Systems zum Wachstum bezeichnet.

In der Elektronischen Datenverarbeitung bedeutet Skalierbarkeit die Fahigkeit eines Systems aus Hard- und Software, die Leistung durch das Hinzufugen von Ressourcen ? z. B. weiterer Hardware ? in einem definierten Bereich proportional (bzw. linear) zu steigern.

Eine allgemein gultige Definition dieses Begriffs ist allerdings nicht trivial. ^{[1] [2]} Es ist erforderlich, fur den jeweiligen speziellen Fall stets einen Bereich anzugeben (z. B. muss ein System bei 100 gleichzeitigen Zugriffen nicht zwangslaufig gleich gut skalieren wie bei 100.000 Zugriffen). Ressourcen konnen z. B. CPU, RAM, Festplatten oder Netzwerk-Bandbreite sein.

Die Skalierbarkeit eines Systems wird mit dem Skalierungsfaktor ? auch SpeedUp genannt ? angegeben.

In der Betriebswirtschaftslehre dient der Begriff ganz allgemein zur Bezeichnung der Expansionsfahigkeit eines Geschaftsmodells durch Kapazitatsausweitung zur Erreichung hoherer Effizienz und Profitabilitat. Interessant fur Investoren ist insbesondere die Skalierbarkeit von Geschaftsmodellen ohne (hohe) zusatzliche Investitionen und Fixkosten. Dies ist insbesondere in der Internet-Okonomie moglich. Von Skalierbarkeit spricht man auch in Bezug auf Kapitalmarkte, sofern die Effizienz bei steigendem Handelsvolumen ebenfalls steigt.

Vertikale vs. horizontale Skalierung [ Bearbeiten | Quelltext bearbeiten ]

Man kann die Leistung eines Systems auf zwei verschiedene Arten steigern: ^[3]

Vertikale Skalierung (scale up) [ Bearbeiten | Quelltext bearbeiten ]

Unter vertikaler Skalierung versteht man ein Steigern der Leistung durch das Hinzufugen von Ressourcen zu einem Knoten/Rechner des Systems. Beispiele dafur waren das Vergroßern von Speicherplatz, das Hinzufugen einer CPU, oder das Einbauen einer leistungsstarkeren Grafikkarte.

Charakteristisch fur diese Art von Skalierung ist, dass ein System unabhangig von der Implementierung der Software schneller gemacht werden kann. Das heißt, es muss keine Zeile Code geandert werden, um eine Leistungssteigerung durch vertikales Skalieren zu erfahren. Der große Nachteil dabei ist jedoch, dass man fruher oder spater an eine Grenze stoßt, bei der man den Rechner nicht weiter aufrusten kann, wenn man bereits die beste Hardware verwendet, die zu diesem Zeitpunkt am Markt ist.

Horizontale Skalierung (scale out) [ Bearbeiten | Quelltext bearbeiten ]

Im Gegensatz zur vertikalen Skalierung sind der horizontalen Skalierung keine Grenzen (aus Sicht der Hardware) gesetzt. Horizontale Skalierung bedeutet die Steigerung der Leistung eines Systems durch das Hinzufugen zusatzlicher Rechner/Knoten. Die Effizienz dieser Art der Skalierung ist jedoch stark von der Implementierung der Software abhangig, da nicht jede Software gleich gut parallelisierbar ist.

Arten von Skalierbarkeit [ Bearbeiten | Quelltext bearbeiten ]

Abhangigkeit zwischen den Arten von Skalierbarkeit

	A hat Auswirkungen auf B
A		B
Lastskalierbarkeit		Raumliche Skalierbarkeit	nein
		Zeitlich-raumliche Skalierbarkeit	nein
		Strukturelle Skalierbarkeit	nein
Raumliche Skalierbarkeit		Lastskalierbarkeit	evtl.
		Zeitlich-raumliche Skalierbarkeit	evtl.
		Strukturelle Skalierbarkeit	nein
Zeitlich-raumliche Skalierbarkeit		Lastskalierbarkeit	evtl.
		Raumliche Skalierbarkeit	nein
		Strukturelle Skalierbarkeit	nein
Strukturelle Skalierbarkeit		Lastskalierbarkeit	evtl.
		Raumliche Skalierbarkeit	nein
		Zeitlich-raumliche Skalierbarkeit	nein

Grundsatzlich unterscheidet man vier Arten von Skalierbarkeit: ^[4]

Lastskalierbarkeit [ Bearbeiten | Quelltext bearbeiten ]

Lastskalierbarkeit steht fur ein konstantes Systemverhalten uber großere Lastbereiche hinweg. Das bedeutet, dass ein System zum einen sowohl bei geringer, mittlerer, als auch bei hoher Last keine zu große Verzogerung aufweist und die Anfragen rasch abgearbeitet werden konnen.

Beispiel Museumsgarderobe [ Bearbeiten | Quelltext bearbeiten ]

Bei einer Garderobe in einem Museum, bei welcher Besucher Jacken abgeben und wieder abholen, gilt das First-Come-First-Served -Prinzip. Dabei gibt es eine beschrankte Anzahl an Kleiderhaken und eine großere Anzahl an Besuchern. Die Garderobe, an der sich die Besucher in einer Reihe anstellen, ist ein Karussell. Um einen freien Haken bzw. seine Jacke zu finden, sucht jeder Besucher linear danach.

Unser Ziel ist es nun, die Zeit, die ein Besucher tatsachlich im Museum verbringen kann, zu maximieren.

Die Performance dieses Systems ist unter hoher Last dramatisch schlecht. Erstens wird das Suchen freier Haken immer aufwandiger, je weniger freie Haken zur Verfugung stehen. Zweitens ist unter hoher Auslastung (z. B. im Winter) ein Deadlock vorprogrammiert. Wahrend am Morgen samtliche Besucher ihre Jacken abgeben, holen sie sich diese am Abend wieder alle ab. Ein Deadlock wird voraussichtlich mittags und am fruhen Nachmittag auftreten, wenn keine freien Kleiderhaken mehr verfugbar sind und weitere Besucher am Ende der Schlange stehen, um ihre Jacke abzuholen.

Personen, die ihre Jacke abholen mochten, konnten diesen Deadlock auflosen, indem sie die anreisenden Besucher bitten, in der Schlange vorgelassen zu werden. Da die Personen, welche ihre Jacke abholen, erst nach einem gewissen Timeout danach fragen werden, ist dieses System hochst inperformant.

Das Erhohen der Anzahl an Kleiderhaken wurde das Problem lediglich hinauszogern, jedoch nicht beheben. Die Lastskalierbarkeit ist folglich sehr schlecht.

Raumliche Skalierbarkeit [ Bearbeiten | Quelltext bearbeiten ]

Raumliche Skalierbarkeit weist ein System bzw. Anwendung auf, wenn der Speicherbedarf bei einer wachsenden Anzahl an zu verwaltenden Elementen nicht inakzeptabel hoch ansteigt. Nachdem ?inakzeptabel“ ein relativer Begriff ist, spricht man in diesem Zusammenhang in der Regel von akzeptabel, wenn der Speicherbedarf hochstens sub-linear ansteigt. Um das zu erreichen, kann z. B. eine dunnbesetzte Matrix (engl. sparse matrix ) bzw. Datenkompression angewendet werden. Da Datenkompression eine gewisse Zeit beansprucht, steht diese jedoch haufig in Widerspruch zur Lastskalierbarkeit.

Zeitlich-raumliche Skalierbarkeit [ Bearbeiten | Quelltext bearbeiten ]

Ein System verfugt uber eine zeitlich-raumliche Skalierbarkeit , wenn sich das Erhohen der Anzahl von Objekten, die ein System umfasst, nicht erheblich auf dessen Performance auswirkt. Beispielsweise weist eine Suchmaschine mit linearer Komplexitat keine zeitlich-raumliche Skalierbarkeit auf, wahrend eine Suchmaschine mit indizierten, bzw. sortierten Daten, z. B. unter Verwendung einer Hashtabelle oder eines balancierten Baums , sehr wohl eine zeitlich-raumliche Skalierbarkeit vorweisen konnte.

Strukturelle Skalierbarkeit [ Bearbeiten | Quelltext bearbeiten ]

Strukturelle Skalierbarkeit zeichnet ein System aus, dessen Implementierung das Erhohen der Anzahl von Objekten innerhalb eines selbst definierten Bereichs nicht maßgeblich behindert.

Abhangigkeit zwischen den Arten von Skalierbarkeit [ Bearbeiten | Quelltext bearbeiten ]

Da ein System naturlich mehrere Arten von Skalierbarkeit aufweisen kann, stellt sich die Frage, wie und ob diese miteinander zusammenhangen. Siehe dazu die Tabelle oben .

Die Lastskalierbarkeit eines Systems wird nicht zwangslaufig durch eine schlechte raumliche oder strukturelle Skalierbarkeit negativ beeinflusst. Systeme mit schlechter raumlicher oder zeitlich-raumlicher Skalierbarkeit haben, aufgrund des Overheads an Speicherverwaltung bzw. des hohen Suchaufwands, moglicherweise auch eine schlechte Lastskalierbarkeit. Systeme mit guter zeitlich-raumlicher Skalierbarkeit haben unter Umstanden eine schlechte Lastskalierbarkeit, wenn z. B. nicht ausreichend parallelisiert wurde.

Der Zusammenhang zwischen struktureller Skalierbarkeit und Lastskalierbarkeit sieht folgendermaßen aus: Wahrend letztere keine Auswirkungen auf erstere hat, kann das umgekehrt sehr wohl der Fall sein.

Die verschiedenen Arten von Skalierbarkeit sind also nicht ganz unabhangig voneinander.

Skalierungsfaktor [ Bearbeiten | Quelltext bearbeiten ]

Der Skalierungsfaktor ( SpeedUp ) beschreibt den tatsachlichen Leistungszuwachs einer zusatzlichen Ressourcen-Einheit. Z. B. kann eine zweite CPU 90 % zusatzliche Leistung bringen.

Von einer super-linearen Skalierbarkeit spricht man, wenn der Skalierungsfaktor beim Hinzufugen von Ressourcen großer wird.

Lineare Skalierbarkeit bedeutet, dass der Skalierungsfaktor eines Systems pro hinzugefugter Ressourcen-Einheit gleich bleibt.

Sub-Lineare Skalierbarkeit steht im Gegensatz dazu fur die Abnahme des Skalierungsfaktors beim Hinzufugen von Ressourcen.

Negative Skalierbarkeit wird erreicht, wenn sich die Leistung durch das Hinzufugen von Ressourcen/Rechnern sogar verschlechtert. Mit diesem Problem hat man zu kampfen, wenn der Verwaltungsaufwand, welcher durch den zusatzlichen Rechner entsteht, großer ist als der dadurch erreichte Leistungszuwachs.

Amdahls Gesetz ist ein relativ pessimistisches Modell zur Abschatzung des Skalierungsfaktors. Basierend darauf ist Gustafsons Gesetz eine weitere Methode zur Berechnung dieses Faktors.

System als Schichtenmodell [ Bearbeiten | Quelltext bearbeiten ]

Um ein System nun moglichst skalierbar aufzubauen, hat es sich in der Praxis bewahrt, ein solches als Schichtenmodell umzusetzen, da mit diesem Ansatz die einzelnen Schichten logisch voneinander getrennt sind und jede Schicht fur sich skaliert werden kann.

Eine sehr populare Architektur im Web-Bereich ist die 3-Schichten-Architektur. Um dabei eine hohe Skalierbarkeit zu erzielen, ist ein entscheidender Faktor, dass jede dieser 3 Schichten gut skaliert.

Wahrend die Prasentationsschicht relativ einfach horizontal skaliert werden kann, ist bei der Logikschicht dafur eine speziell dafur ausgelegte Implementierung des Codes erforderlich. Dabei ist zu berucksichtigen, dass ein moglichst großer Anteil der Logik parallelisiert werden kann (siehe Amdahls Gesetz und Gustafsons Gesetz weiter oben). Am interessantesten ist jedoch die horizontale Skalierung der Datenhaltungsschicht, weshalb diesem Thema ein eigener Abschnitt (siehe horizontales Skalieren der Datenhaltungsschicht weiter unten) gewidmet ist.

Praktische Methoden zur Verbesserung der Skalierbarkeit von Webseiten [ Bearbeiten | Quelltext bearbeiten ]

Verbesserung der Skalierbarkeit von Webseiten kann durch Steigerung der Performance erzielt werden, da ein Server dadurch mehr Clients in der gleichen Zeit bedienen kann.

Martin L. Abbott und Michael T. Fisher haben 50 Regeln aufgestellt, die es in Bezug auf Skalierbarkeit zu beachten gilt. ^[5] Fur Webseiten sind dabei unter anderem folgende Regeln relevant:

Reduzieren von DNS-Lookups und Anzahl von Objekten [ Bearbeiten | Quelltext bearbeiten ]

Beim Betrachten des Ladens einer Seite in einem beliebigen Browser mit einem Debugging-Tool (z. B. Firebug ) fallt auf, dass ahnliche große Elemente unterschiedlich lange Ladezeiten beanspruchen. Bei genauerer Betrachtung erkennt man, dass einige dieser Elemente einen zusatzlichen DNS -Lookup benotigen. Dieser Vorgang der Adressauflosung kann durch DNS-Caching auf unterschiedlichen Ebenen (z. B. Browser, Betriebssystem, Internet-Provider etc.) beschleunigt werden. Um die Anzahl der Lookups zu reduzieren, konnte man nun alle JavaScript- und CSS-Dateien zu jeweils einer zusammenfassen und man konnte alle Bilder auf ein großes zusammenfugen und mittels CSS-Sprites nur den gewunschten Bildausschnitt anzeigen. Allgemein kann man folgende Regel dazu aufstellen: Je weniger DNS-Lookups beim Laden einer Seite erforderlich sind, desto besser ist die Performance. Die folgende Tabelle ^[5] veranschaulicht, wie teuer der DNS-Lookup und der Verbindungsaufbau verhaltnismaßig sind.

Moderne Browser konnen jedoch mehrere Verbindungen gleichzeitig zu einem Server offen halten, um mehrere Objekte parallel herunterzuladen. Laut HTTP/1.1 RFC 2616 ^[6] sollte das Maximum an gleichzeitigen Verbindungen je Server im Browser auf 2 limitiert werden. Einige Browser ignorieren diese Richtlinie jedoch und verwenden ein Maximum von 6 gleichzeitigen Verbindungen und mehr. Reduziert man auf einer Webseite nun jedoch alle JavaScript- und CSS-Dateien sowie alle Bilder lediglich auf jeweils eine Datei, so entlastet man zwar die anbietenden Server, hebelt jedoch gleichzeitig diesen Mechanismus der parallelen Verbindungen des Browsers aus.

Idealerweise nutzt man diese Parallelisierung im Browser zur Ganze aus und hat gleichzeitig moglichst wenige DNS-Lookups. Um das zu erreichen, verteilt man eine Webseite am besten auf mehrere Subdomains (z. B. ruft man Bilder von einer Subdomain auf, wahrend man Videos von einer anderen ladt). Durch diese Vorgehensweise lasst sich relativ einfach eine beachtliche Performance-Steigerung erzielen. Es gibt jedoch keine allgemeine Antwort darauf, wie viele Subdomains man verwenden sollte, um die bestmogliche Leistung zu erzielen. Einfache Performance-Tests der zu optimierenden Seite sollten daruber jedoch rasch Aufschluss bieten.

Horizontales Skalieren der Datenhaltungsschicht [ Bearbeiten | Quelltext bearbeiten ]

Skalierung hinsichtlich Datenbankzugriffe [ Bearbeiten | Quelltext bearbeiten ]

Der am schwierigsten zu skalierende Teil eines Systems ist meistens die Datenbank bzw. die Datenhaltungsschicht (s. o.). Der Ursprung dieses Problems kann bis zum Paper A Relational Model of Data for Large Shared Data Banks ^[7] von Edgar F. Codd zuruckverfolgt werden, welches das Konzept eines Relational Database Management System (RDBMS) vorstellt.

Eine Methode, um Datenbanken zu skalieren, ist es, sich zu Nutze zu machen, dass die meisten Anwendungen und Datenbanken wesentlich mehr Lese- als Schreibzugriffe aufweisen. Ein durchaus realistisches Szenario, das in dem Buch von Martin L. Abbott und Michael T. Fisher beschrieben wird, ist eine Buchreservierungsplattform, welche ein Verhaltnis zwischen Lese- und Schreibzugriffen von 400:1 aufweist. Systeme dieser Art konnen relativ einfach skaliert werden, indem mehrere read-only Duplikate dieser Daten angefertigt werden.

Es gibt mehrere Wege, um die Kopien dieser Daten zu verteilen, abhangig davon, wie aktuell die Daten der Duplikate wirklich sein mussen. Grundsatzlich sollte es kein Problem sein, dass diese Daten lediglich alle 3, 30, oder 90 Sekunden synchronisiert werden. Bei dem Szenario der Buchplattform gibt es 1.000.000 Bucher, und 10 % davon werden taglich reserviert. Angenommen, die Reservierungen sind gleichmaßig uber den gesamten Tag verteilt, so findet ca. eine Reservierung pro Sekunde (0,86 Sekunden) statt. Die Wahrscheinlichkeit, dass zum Zeitpunkt (innerhalb 90 Sekunden) einer Reservierung ein anderer Kunde das gleiche Buch reservieren mochte, betragt (90/0,86)/100.000 = 0,104 %. Naturlich kann und wird dieser Fall irgendwann eintreffen, doch diesem Problem kann ganz einfach durch eine abschließende, erneute Uberprufung der Datenbank entgegentreten werden.

Eine Moglichkeit, um diese Methode umzusetzen, ist es, die Daten, z. B. mit einem Key-Value-Store (etwa Redis ), zu cachen . Der Cache muss erst nach Ablauf seiner Gultigkeit erneuert werden und entlastet damit die Datenbank enorm. Der einfachste Weg, diesen Cache zu implementieren, ist, ihn in einer bereits bestehenden Schicht (z. B. der Logikschicht) zu installieren. Fur eine bessere Performance und Skalierbarkeit verwendet man dafur jedoch eine eigene Schicht, bzw. eigene Server, zwischen der Logikschicht und der Datenhaltungsschicht.

Der nachste Schritt ist nun, die Datenbank zu replizieren. Die meisten bekannten Datenbanksysteme verfugen bereits uber eine solche Funktion. MySQL bewerkstelligt dies mit dem master-slave -Prinzip, wobei die master -Datenbank die eigentliche Datenbank mit Schreibrechten ist und die slave -Datenbanken die duplizierten read-only Kopien sind. Die Master-Datenbank zeichnet samtliche updates, inserts, deletes etc. im sogenannten Binary-Log auf, und die Slaves reproduzieren diese. Diese Slaves steckt man nun hinter einen Load Balancer (s. u.), um die Last entsprechend zu verteilen.

Diese Art von Skalierung lasst die Anzahl der Transaktionen relativ einfach skalieren. Je mehr Duplikate der Datenbank verwendet werden, desto mehr Transaktionen konnen auch parallel bewaltigt werden. In anderen Worten bedeutet das, dass nun beliebig viele User (naturlich abhangig von der Anzahl der Server) gleichzeitig auf unsere Datenbank zugreifen konnen. Diese Methode hilft uns nicht dabei, auch die Daten an sich zu skalieren. Um nun auch beliebig viele Daten in der Datenbank speichern zu konnen, ist ein weiterer Schritt notig. Dieses Problem wird im nachsten Punkt behandelt.

Skalierung hinsichtlich Datenbankeintrage ? Denormalisierung [ Bearbeiten | Quelltext bearbeiten ]

Was man hiermit erreichen mochte, ist, eine Datenbank auf mehrere Rechner aufzuteilen und ihre Kapazitat beliebig durch weitere Rechner zu erweitern. Dazu muss die Datenbank zu einem gewissen Grad denormalisiert werden. Unter Denormalisierung versteht man die bewusste Rucknahme einer Normalisierung zum Zweck der Verbesserung des Laufzeitverhaltens einer Datenbankanwendung .

Im Zuge der Denormalisierung muss die Datenbank fragmentiert werden.

Fragmentierung [ Bearbeiten | Quelltext bearbeiten ]

Man unterscheidet horizontale und vertikale Fragmentierung.

Bei der Horizontalen Fragmentierung ( Eng. sharding ) wird die Gesamtheit aller Datensatze einer Relation auf mehrere Tabellen aufgeteilt. Wenn diese Tabellen auf demselben Server liegen, dann handelt es sich meistens um Partitionierung. Die einzelnen Tabellen konnen aber auch auf unterschiedlichen Servern liegen. So konnen z. B. die Daten fur die Geschafte in den USA auf einem Server in den USA gespeichert werden und die Daten fur die Geschafte mit Europa liegen auf einem Server in Deutschland. Diese Aufteilung wird auch als Regionalisierung bezeichnet.

Horizontale Fragmentierung schafft keine Redundanz der gespeicherten Daten, sondern der Strukturen. Wenn eine Relation geandert werden muss, dann muss nicht nur eine Tabelle geandert werden, sondern es mussen alle Tabellen geandert werden, uber die die Daten aus der betreffenden Relation verteilt sind. Hier besteht die Gefahr von Anomalien in den Datenstrukturen.

Bei der Vertikalen Fragmentierung werden die abhangigen Attribute (nicht-Schlussel-Attribute) einer Tabelle in zwei oder mehrere Gruppen aufgeteilt. Aus jeder Gruppe wird eine eigene Tabelle, die noch um alle Schlussel-Attribute der Ursprungstabelle erganzt werden. Das kann dann sinnvoll sein, wenn die Attribute einer Relation Datensatze mit einer sehr großen Satzlange ergeben. Wenn zusatzlich noch die Zugriffe meistens nur einige wenige Attribute betreffen, dann kann man die wenigen haufig zugegriffenen Attribute in eine Gruppe zusammenfassen und den Rest in eine zweite Gruppe zusammenfassen. Die haufig auszufuhrenden Zugriffe werden dadurch schneller, weil eine geringere Menge an Daten von der Festplatte gelesen werden muss. Die selten auszufuhrenden Zugriffe auf die restlichen Attribute werden dadurch nicht schneller, aber auch nicht langsamer.

Ab welcher Satzlange eine Aufspaltung in mehrere kleinere Tabellen sinnvoll ist, hangt auch von dem Datenbanksystem ab. Viele Datenbanksysteme speichern die Daten in Form von Blocken mit einer Große von 4  KiB , 8 KiB oder 16 KiB ab. Wenn die durchschnittliche Satzlange wenig großer als 50 % eines Datenblocks ist, dann bleibt viel Speicherplatz ungenutzt. Wenn die durchschnittliche Satzlange großer als die verwendete Blockgroße ist, dann werden die Datenzugriffe aufwandiger. Wenn BLOBs zusammen mit anderen Attributen in einer Relation vorkommen, ist vertikale Fragmentierung fast immer von Vorteil.

Partitionierung [ Bearbeiten | Quelltext bearbeiten ]

Partitionierung ist ein Spezialfall der horizontalen Fragmentierung.

Große Datenbestande lassen sich leichter administrieren, wenn die Daten einer Relation in mehrere kleine Teile (=Partitionen) aufgeteilt und diese separat gespeichert werden. Wenn eine Partition einer Tabelle gerade aktualisiert wird, dann konnen andere Partitionen der Tabelle zur selben Zeit reorganisiert werden. Wenn in einer Partition ein Fehler entdeckt wird, dann kann diese einzelne Partition aus einer Datensicherung wiederhergestellt werden, wahrend Programme auf die anderen Partitionen weiter zugreifen konnen. Die meisten etablierten Datenbankhersteller bieten Partitionierung an, siehe z. B. Partitionierung bei DB2 und Partitionierung bei MySQL .

Die meisten Datenbanksysteme bieten die Moglichkeit, entweder einzelne Partitionen anzusprechen oder alle Partitionen unter einem einheitlichen Tabellennamen anzusprechen.

Durch Partitionierung konnen die Datenzugriffe beschleunigt werden. Der wesentliche Vorteil ist jedoch die leichtere Administrierbarkeit der gesamten Tabelle.

Skalierbarkeit in der Betriebswirtschaftslehre [ Bearbeiten | Quelltext bearbeiten ]

Als Skalierbarkeit eines Geschaftsmodells wird die Fahigkeit definiert, durch Einsatz zusatzlicher Ressourcen ein Kapazitats- und Umsatzwachstum ohne entsprechende Ausweitung der Investitionen und Fixkosten zu erreichen. Fur Grunder und Investoren ist insbesondere die Form der Skalierbarkeit eines Geschaftsmodells interessant, die es ermoglicht, Kapazitats- und Umsatzwachstum ohne entsprechende Ausweitung der Investitionen und Fixkosten zu erreichen.

Bei auf den lokalen Markt zielenden Existenzgrundungen ist eine Skalierbarkeit selten gegeben, da das Gewerbe an einen Standort gebunden ist. Auch bei Grundungen, die stark von der individuellen Fachkompetenz des Grunders abhangig sind (z. B. in beratenden und anderen Dienstleistungsberufen), markieren die Grenzen der eigenen Arbeitszeit die Grenzen der Skalierbarkeit. In beiden Fallen kann der Umsatz nicht einfach gesteigert werden, so dass man zusatzliche Ressourcen nutzen und in einen neuen Standort investieren oder neue Mitarbeiter einstellen muss und dadurch neue Fixkosten verursacht.

Bei Produktionseinheiten mit begrenzter Kapazitat erfordert die Skalierung uber die maximale Kapazitat hinaus hohe Investitionen, um eine zweite, dritte usw. Produktionseinheit aufzubauen. In der digitalen Wirtschaft, z. B. bei einem Internethandel hingegen muss zunachst in Website, Software, Werbung usw. investiert werden; anschließend konnen Umsatzsteigerungen jedoch ohne zusatzlichen Ressourceneinsatz erzielt werden, ^[8] wenn man von den Logistikkosten absieht.

Folgende Merkmale eines skalierbaren Geschaftsmodells werden allgemein angefuhrt:

• Geringes Anlagevermogen
• Geringe Fixkosten (im Verhaltnis zu den Gesamtkosten)
• Hoher Anteil variabler Kosten
• Effektive Marketing- und Vertriebsaktivitaten, um die Produkte und Dienstleistungen bei Kapazitatserhohungen rasch absetzen zu konnen
• Expansion in benachbarte Markte und Lander

Die Beurteilung der Skalierbarkeit eines Geschaftsmodells ist wichtig fur professionelle Investoren, erhoht sie doch die Wahrscheinlichkeit einer hohen Verzinsung ihrer Investitionen und/oder einer schnellen Wertsteigerung des Unternehmens bei sinkender Notwendigkeit großer Kapitalnachschusse. Das ist interessant fur Wagniskapital geber, aber auch fur Grunder, die die Verwasserung der eigenen Anteile vermeiden und Aussicht auf steigende Gewinnausschuttungen haben.

Auch Geschaftsmodelle, die auf Franchising basieren, sind leichter skalierbar, da die Investitionen fur den Aufbau neuer Standorte und Kapazitaten von den Franchisenehmern ubernommen werden. So ist es auch moglich, lokale Geschaftsmodelle zu skalieren, die ansonsten enge Kapazitatsgrenzen aufweisen.

Als vertikale Skalierung kann man die Verlangerung der Wertschopfungskette zwecks Umsatzsteigerung bezeichnen, als horizontale Skalierung die Vermarktung von bestehenden Produkten und Dienstleistungen in benachbarten Markten, die Erweiterung des Portfolios durch ahnliche Produkte und Dienstleistungen oder auch die Ubertragung eines bewahrten Geschaftsmodells auf andere Markte.

Wahrend die Bedeutung des innovativen Charakters eines Geschaftsmodells oft uberschatzt wird, wird die Skalierbarkeit von unerfahrenen Unternehmern haufiger vernachlassigt. ^[9]

Siehe auch [ Bearbeiten | Quelltext bearbeiten ]

• OSI-Schichtenmodell

Weblinks [ Bearbeiten | Quelltext bearbeiten ]

Wiktionary: skalieren  ? Bedeutungserklarungen, Wortherkunft, Synonyme, Ubersetzungen

Einzelnachweise [ Bearbeiten | Quelltext bearbeiten ]

1. ↑ Mark D. Hill: What is scalability? In: ACM SIGARCH Computer Architecture News . Band   18 , Nr.   4 , Dezember 1990, ISSN   0163-5964 , S.   18?21 .  
2. ↑ Leticia Duboc, David S. Rosenblum, Tony Wicks: A Framework for Modelling and Analysis of Software Systems Scalability . In: Proceeding of the 28th international conference on Software engineering ICSE ’06 . ACM, New York, NY, USA 2006, ISBN 1-59593-375-1 , S.   949?952 , doi : 10.1145/1134285.1134460 .  
3. ↑ M. Michael, J. E. Moreira, D. Shiloach, R. W. Wisniewski: Scale-up x Scale-out: A Case Study using Nutch/Lucene . In: IEEE International (Hrsg.): Parallel and Distributed Processing Symposium, 2007. 30. Marz 2007, S.   1?8 , doi : 10.1109/IPDPS.2007.370631 .  
4. ↑ Andre B. Bondi: Characteristics of Scalability and Their Impact on Performance . In: Proceedings of the 2nd international workshop on Software and performance (WOSP ’00) . ACM, New York NY 2000, ISBN 1-58113-195-X , S.   195?203 , doi : 10.1145/350391.350432 .  
5. ↑ ^{a b} L. M. Abbott, M. T. Fisher: Scalability Rules: 50 principles for scaling Web sites. Addison-Wesley, Indiana 2011, ISBN 978-0-321-75388-5 , S. 12?34.
6. ↑ RFC 2616  ? Hypertext Transfer Protocol ? HTTP/1.1 . Juni 1999 (englisch).
7. ↑ Edgar F. Codd : A Relational Model of Data for Large Shared Data Banks . In: Communications of the ACM . ACM Press, 13. Juni 1970, ISSN   0001-0782 , S.   377?387 ( eecs.umich.edu ( Memento vom 30. Januar 2012 im Internet Archive ) [PDF]).  
8. ↑ Patrick Stahler: Geschaftsmodelle in der digitalen Okonomie: Merkmale, Strategien und Auswirkungen. Josef Eul Verlag, Koln-Lohmar 2001.
9. ↑ Urs Fueglistaller, Christoph Muller, Susan Muller, Thierry Volery: Entrepreneurship: Modelle ? Umsetzung ? Perspektiven. Springer Verlag, 2015, S. 116.