Von Bernd Stahl, Netzwerkexperte von Nash Technologies und Teilnehmer des Informare-Panels, kamen folgende Überlegungen:
Hauptthese: es geht um fortschreitende Vereinfachung des Systems und der User-Experience. Das Reduziert die Kosten des Systems: sowohl Herstellung als auch Betrieb. Diese Vereinfachung umfasst das Internet auf der Netz-Ebene und auf der Anwendungs-Ebene. Es geht einfacher, effizienter, eleganter und effektiver und mit den sich daraus ergebenden natürlichen Geschäftsmodellen.
Formel: E4+G. Einfacher, Effizienter, Effektiver, Eleganter. Und damit baut man Geschäftsmodelle.
o Kunden kaufen, wenn man etwas hat, mit dem man entweder Kosten sparen kann oder zusätzliches Geld verdienen kann. Das ist die Basis für Geschäftsmodelle.
o Einfacher (mach es nicht komplizierter, sondern einfacher!) und effizienter (macht es richtig gut! Z.B. sollte man das mal auf die vielen Apps anwenden) steht dafür, wie man Geld sparen kann.
o Effektiver (tue ich überhaupt das richtige Ding oder müsste ich eigentlich nicht etwas ganz anderes tun? Z.B. nicht noch einen Balkon im Internet, sondern ein besseres IP++, einen Single View of Social, Social Media Dial Tone, etc.) und eleganter (was kann ich tun, damit das Leben angenehmer, beschwingter, lustiger, etc. wird? Z.B. das iPhone plus iTunes App Store) steht dafür wie man zusätzliches Geld verdienen kann.
o Die Geschäftsmodelle der Internetwirtschaft beruhen auf folgenden zwei Säulen: den Usern muss der Dienst gefallen, und den Service Providers müssen die dadurch gewonnenen User Data Gewinn bringen. D.h. kostenloser Service bezahlt durch User Daten. Hier gilt das Prinzip: je größer und wirkungsvoller die Plattform des Service Providers, desto höheren Wert kann man aus den User Daten gewinnen. Die Frage ist: kann man dieses Prinzip so aufbrechen, dass es eine große Zahl dezentraler Service Providers mit deren Plattformen begünstigt, sowohl in der Entstehung als auch nachhaltig?
Die Vereinfachung auf der Netzebene betrifft den IP-Layer, d.h. den Network Layer.
o In den vergangenen drei Jahrzehnten tobte ein Glaubenskrieg (der 30-jährige Krieg der Kommunikation-Systeme): Packet Switching vs. Circuit Switching. Getrieben letztendlich von Wirtschaftsinteressen. Heute weiß man, man braucht beides, nahtlos integriert.
o Will man die Leistungsmerkmale von Circuit Switching mit Packet Switching realisieren, dann muss man hohen technischen Aufwand treiben, d.h. das System wird unnötig komplex und anfällig.
o Will man andererseits die Leistungsmerkmale von Packet Switching mit Circuit Switching realisieren, dann verschwendet man Netzwerk-Ressourcen.
o Auf dem Ethernet-Layer ist man mit Carrier Ethernet bereits dabei, die Hausaufgaben zu lösen, d.h. man hat eine einheitliche Plattform für beides.
o Problem: Auf dem IP-Layer gibt es nur Packet Switching. Dies bedeutet, dass man auf den darüber liegenden Schichten die Features Circuit Switching nicht vollständig emulieren kann, selbst wenn diese auf Ethernet-Ebene vorhanden sind und man mit TCP z.B. über eine Connection Oriented Protocol verfügt. Die Verbindungsorientierung schafft eben doch keine maximal definierbare End-to-End Bandbreiten- und Antwortzeitgarantie, weil es in IP eben Queues gibt.
o Zusätzlich gibt es eine Innovationsblockade auf dem IP Layer: es gibt nur ein einziges Protokoll für alles, die anderen sind im Wettbewerb ausgestorben. Man müsste also die Möglichkeit schaffen, auf dem IP Layer mehrere weitgehend disjunkte Protokolle zuzulassen, die überlebensfähig wären, so wie es die Georgia Tech University fordert. Oder man schafft ein innovativ offenes und erweiterbares Internet-Protokoll IP++. Mit beiden Optionen wäre der Innovationsstau aufgelöst.
o Das Ganze ist ein operator-freundliches Scenario. D.h. wegen der Vereinfachung der Kommunikationsarchitektur, wird auch die Herstellung von Netzelementen günstiger bei gleichzeitiger Steigerung der Leistungsfähigkeit und Senkung des Energieverbrauchs. Kehrseite: der Verdrängungswettbewerb der Hersteller geht weiter, aber der Erste gewinnt.
o Wenn IP++ sowohl Circuit Switching als auch Packet Switching unterstützt, dann fallen Balkon-Protokolle wie MPLS, LISP, etc. weg. Ebenso fallen zusätzliche Protokolle und Mechanismen für Bandbreitenreservierung weg, weil man sie direkt in IP++ erledigt, ohne Balkone. Das Routing ließe sich vereinfachen: Routing-Protokolle und –Mechanismen könnten teilweise oder ganz wegfallen und gleichzeitig das Routing robuster und weniger anfällig für Störungen und Angreifer gemacht werden. Durch Einführung topologischer Adressen würden die Routingpläne um Größenordnungen kleiner werden bei gleicher Leistungsfähigkeit. Dadurch würde das Betreiben vereinfacht und die Fehleranfälligkeit verringert. Durch Dienstgüteklassen in IP++ könnte man über mehrere Netze hinweg Quality of Service garantieren. Durch SLAs können die beteiligten Netzbetreiber die Dienstgüte über Netzwerkgrenzen hinweg garantieren und effektive Geschäftsmodelle aufbauen.
o Durch explizite effektive Service Classes spart man sich das teure und umstrittene Deep Packet Inspection.
Für die Entwicklung auf dem Application Layer spielen mehrere Trends eine Rolle:
o Immer mehr Firmen denken darüber nach, für ihre interne Kommunikation Social Media einzusetzen und auf E-Mails zu verzichten. Firmen bauen interne Social Networks auf. Die werden aber mit Sicherheit keine öffentlichen Netze wie Facebook sein. Vertrauliche Information wird abgesichert und wird von den Firmen selber gehostet oder von einem lokalen Cloud-Anbieter. Es entstehen viele soziale Inselnetze mit höherwertiger Information. Die Technologie kann die gleiche sein, die Netze selber haben aber klare Abgrenzungen. Partiell wird man sein Unternehmensnetz auch öffnen wollen: Partner, Kunden, Lieferanten. Man muss soziale Netze miteinander verknüpfen. Dazu müssen die entsprechenden APIs zugänglich gemacht werden. Das Ganze wird durch die Kosten getrieben, denn Unternehmen haben kein Interesse daran, ihre Informationen mehrfach einzugeben, nur damit man in mehreren Netzen präsent ist. Die logische Konsequenz: eine sehr große Anzahl unabhängiger Social Networks.
o Apples Siri stellt eine einzige sprachgesteuerte Benutzerschnittstelle dar, die derzeit etwa ein Duzend Apps steuert. Damit ist Siri die singuläre Schnittstelle zum User. Der Rest wandert schrittweise unter die Haube.
o Die Marktmacht weniger Großer Player und deren beginnende / fortschreitende Zensur bewirkt immer mehr Unbehagen. Die Lösung liegt in dezentralen miteinander konkurrierender Strukturen. Immer mehr Leute denken über sogenannte Mesh-Networks nach. Es wäre eine Renaissance des ursprünglichen Internet Spirits, angewandt auf den bereits stark kommerzialisierten Application Layer.
o Schließlich werden es auch einfache Rationalisierungsgründe sein. Soziale Mehrfachkonten sind einfach erhebliche Mehrarbeit. Wer das vereinfacht, präsentiert einen besseren Business Case.
Mein Traum: ein „Social Media Dial Tone“ auf dem Application Layer (bei Google findet man für diesen String nur 7 Links). So wie früher beim Telefon. Ohne Mehrfachkonten bei Facebook, Twitter, G+, LinkedIn & Co. Ohne zusätzliche Balkon-Tools. Ein Access. Ein View. In alle Netze. Semantisch angereichert. Sozusagen unter der Haube. Wieso muss der Wildwuchs-Spaghetti der Entwickler dem User eins zu eins zugemutet werden? Wie könnte sich so etwas entwickeln?
o Ein Dial Tone beim Telefon bedeutet: Einfacher Access zum weltweiten Telefonnetz, unabhängig wo mein Kommunikationspartner sich befindet und an welchem Operator er angeschlossen ist. Auch die Directories waren global vernetzt. Der Ton stand auch für Carrier Grade: d.h. hoch verfügbar (5-7 neuner), definierte Services mit definierter Quality of Service. Für den Internanschluss auf IP-Ebene gibt es mittlerweile auch so etwas wie einen Dial Tone: der DSL-Anschluss, SmartPhone, etc. Bei Google findet man folgende Links – noch sind es sehr wenige – mit dem String „Social Media Dial Tone“:
Hier geht’s darum, dass es einen Social Media Dial Tone nicht gibt, d.h. ein soziales Netz kann jeder Zeit abgeschaltet werden ohne Ankündigung. Daher der Rat, seine Social Media Presence auf so viele Netzwerke wie möglich duplizieren. Verständlich, aber nicht wirklich eine Lösung.
Mein Verbesserungsvorschlag: ein Social Shadow auf meiner privaten Cloud. Für Unternehmenskritische Daten ist das sowieso die Lösung.
Hier wird der Social Media Dial Tone als API zu einem Social Network definiert, von denen es de facto tausende gibt und die bekanntesten sind Facebook, Twitter, G+, YouTube, LinkedIn, etc. Aber der Text skizziert auch schon die Möglichkeit eines einzigen Accesses auf vernetzte Social Networks.
Mein Verbesserungsvorschlag: meine Definition eines Social Media Dial Tones ist: ein einziger API auf vernetzte Social Networks mit Customised View.
Hier wird auch das Problem der zu vielen Social Networks dargestellt. Der Lösungsvorschlag: nicht zu viele Social Networks.
Hier geht’s um die versteckten Kosten für „Free Social Media“: der zu bezahlende Preis ist User-generated Content und User Demographic Information.
Mein Verbesserungsvorschlag: ein echter Social Media Dial Tone ist ein Mehrwert der in der Internet Flatrate eingehen sollte und für den man bezahlt um verlässliches und einfaches Social Media zu haben. Für Firmen lohnt sich das, weil es Kosten spart. Und: Firmen wissen, dass ihre Daten extrem wertvoll sind. D.h. „Free Social Media“ ist eine Werbeplattform, echter Content ist nicht umsonst.
Auch hier geht man davon aus, dass man einen Social Media Dial Tone braucht, weil Social Media derzeit kein wirklicher Service ist, sondern nur eine Application Destination.
Mein Verbesserungsvorschlag: Social Media muss tatsächlich ein echter Service werden, vernetzt, hochverfügbar, customisable, unabhängig vom Endgerät.
Überträgt man das auf Social Networks und Search dann kommt etwa folgendes dabei heraus:
Ein echter Service (im Gegensatz zu einer Applikation auf Servern eines Rechenzentrums), vernetzt mit allen anderen Social Media Networks, hochverfügbar, ein einziger Customisable View, unabhängig vom Endgerät, bereitgestellt durch den Internet-Provider. Durch die Bereitstellung via Internet-Provider wird „Social“ mehr und mehr zu einer Commodity.
Grob vereinfacht besteht ein Social Network aus:
· Einer Datenbanktechnologie.
· Einer Datenbank-Applikation.
· Einem API.
· Einem User View.
Diese 4 Komponenten sollte man konsequent trennen:
· Die Datenbanktechnologie kann dazu verwendet werden, unabhängige Social Networks aufzubauen.
· D.h. damit schafft man viele unabhängige Datenbank-Applikationen.
· Der API wird standardisiert um Interoperabilität zu gewährleisten.
· Der User View gehört als App aufs Endgerät oder in einen Browser.
· Durch die Trends oben wird das Social Media Network auf allen Protokoll-Ebenen dezentral. Damit wird ein Big Brother vermieden. Wodurch wird die dezentrale Lösung getrieben? Folgende Möglichkeiten:
o Wenn Firmen ihre interne Kommunikation durch Web 2.0 und Social Media Technologien E4 gestalten, dann geht es nicht mehr um das Geschäft Free Service gegen Werbung mit User Daten. Es geht dann einfach um höhere Produktivität in der Wissensgesellschaft und geringere Kosten.
o Die Information, die hierdurch in Firmen generiert wird, hat einen hohen Wert an sich, für die Firma selber, aber auch für Partner, Kunden, Lieferanten.
o Wenn sich diese hochwertigen Web 2.0 Inseln durch Knowledge Peering vernetzen, dann geht es unterm Strich für das daraus entstehende Gesamtsystem wieder um höhere Produktivität in der Wissensgesellschaft und geringere Kosten. D.h. alle gewinnen.
o Ein Social Media Dial Tone ist hier ein zentrales Kostenargument.
o Der Basis-Dienst ist Teil der Internet-Flatrate. Für höherwertigen Content kann man aus einer Fülle von Geschäftsmodellen wählen.
Die Social Media Existenz kann abgesichert werden durch einen Social Shadow auf einer privaten Cloud. Dieser Social Shadow erlaubt dann weitere Anwendungen.
· Das heutige Geschäftsmodell für „Free Social Media“ wird sich durch Werbung finanzieren, Werbung die auf der Ressource User Data aufbaut. Neue Geschäftsmodelle für „Value Content Social Media“ werden ebenfalls entstehen, je mehr diese Art von Inseln de facto aufgebaut werden. Diese Inseln werden ihre Daten semantisch annotieren.
· Ebenso findet Search heute fast ausschließlich „Free Content“. Z.B. landet Google oft auf Wikipedia. Höherwertiger Content, obwohl begehrt, wird nicht gefunden. Hier gibt es eine Fülle neuer Geschäftsmöglichkeiten. Semantic und Social Search: Paid Content veröffentlicht ein semantisches API, mit oder ohne Binding an ein kommerziell betriebenes Portal. Idee: Online Semantic Crawler.
Allerdings hat Google laut Vizechefin Marissa Mayer einen allwissenden Suchdienst im Sinn, der im voraus schon weiß, was der User will.
Meine These: Google wird nicht der Big Brother werden können, sondern bestenfalls der Klebstoff zwischen den Hochwertigen Content Inseln.
· Ein spannende Frage ist hier auch, wie die Aufgabenteilung zwischen Endgerät und Netz / Applications liegen wird. Ich gehe davon aus, dass das sich Endgeräte zu einer Kombination von R2D2 und C-3PO entwickeln werden, d.h. die Personalisierung ist fast ausschließlich im Endgerät. Und damit ist sie wieder dezentral.
· Schließlich noch was zu den Endgeräten: Die meisten Leute denken beim Mobilen Internet heute an Smartphones und Pads. Mobile und Festgeräte werden über einen singulären Dial Tone verfügen: man beginnt den Film auf dem Smartphone und beendet ihn auf dem TV. Aber: die Miniaturisierung der Endgeräte geht weiter. D.h. Smartphones und Tablets werden nach und nach zu Teilen der Kleidung wie Armbanduhren oder Brillen. Die Benutzerschnittstelle wir 3D (3D Screen, Hologramme, Virtuelles 3D via Brille, etc.), gesteuert mit Sprache, Händen (effektivere Gesten), Augen und Gedanken, etc. Ein neues Lebensgefühl. Auch die Endgeräte haben Wechselwirkungen, wie Internet und Soziale Netze verwendet werden. Diese Funktionsmächtigkeit will man doch sicher keiner zentralen Instanz anvertrauen.
Vom Co-Moderator Heinrich Bruns folgender Blogpost interessant: Die Wolke ist … ähm, ja … wolkig
Siehe auch:
