Buzzriders-Module
wie im vorherigen Artikel angesprochen kommen wir nun zu den einzelnen Komponenten, die zunächst einmal schematisch aufgezeigt werden. Primär dienen sie als Leitfaden für die Roadmap, was die Umsetzung angeht.
Die Maxime für die Startphase ist dabei: Je weniger man benötigt, um den Nutzer für das Produkt zu begeistern und das Produkt zu vermitteln, umso eher erreicht man das Ziel, eine Startbasis geschaffen zu haben. Um ausgehend davon in kleinen Teilschritten weiter zu iterieren, abgeleitet aus der Kundennutzung, den weiteren Bedürfnissen und der Kundenzufriedenheit. Groß Denken, klein Umsetzen!
BWL-Entscheidungstheorie: Warum schlank und schmal?
Die Maxime basiert auf zwei Gedanken: Alle Theorie ist grau, die Praxis ist die Messlatte. Wozu also groß planen und (!) umsetzen? Menschen lernen aus der Praxis. Und zweitens? Stelle kontrollierbare Lösungen vorher auf die Beine und fixe daraus entstehende Probleme unterwegs. Probleme jetzt zu lösen, die in der Zukunft liegen könnten, ist eine schwachsinnige Methodik, da man nicht weiß, ob das Problem auftreten wird. Beispiel: Es ist unsinnig, sich über Skalierung von IT-Systemen für 1 Mio User vorab Gedanken zu machen. Mache Dir lieber Gedanken, wie man Kunden überhaupt erreicht und begeistert. Wenn das auftritt, kannst Du Dir gratulieren, dass Du ein Skalierungsproblem hast!
Egro? Die Kunst “Nein” zu sagen, ist zwar einerseits schwer umzusetzen, erleichtert aber die Minimierung von Entscheidungsvariablen. Viele Variablen sind zudem weder messbar noch bekannt, gerade zum Start. Die umgekehrte Alternative lautet: Ein Produkt komplex aufzubauen, um verschiedenste Kundenbedürfnisse und Nutzungsszenarien abzudecken, ist verführerisch. Damit steigt jedoch die Wahrscheinlichkeit von Fehlentscheidungen exponentiell an. Und man kann zugleich nicht mehr Szenarien-gesteuert beschränkte Marketingressourcen effizient platzieren. Warum? Komplexe Produkte bedürfen immens hohe Ressourcenkapazitäten, um Kunden zu informieren. Nach innen bedeuten komplexe Produkte eine präzise Steuerung von Entwicklern, Marketiers, Vertrieblern und damit einer ausgefeilten Organisatorik. Über dieses Know-How verfügen Startups jedoch nicht zu Beginn. Dieses Problem ist nicht einmal mit Cash im Überfluss zu lösen, das zeigen mit genügend Geld vollgestopfte Startups in der Moderne auf.
Wie wird Buzzriders umgesetzt, was sind die Lokationskomponenten?
Das Schemata der Einzelmodule folgt dem Prinzip der kleinen Schritte. Klein bauen, weiter denken, umsetzen.
Die Module werden einzeln vom Stapel gelassen, miteinander peu á peu verbunden. Jedes der Module wird zu Beginn so schlank wie nur möglich sein. Das erleichtert einerseits die Weiterentwicklung, andererseits das Testing.
Die ersten drei Module -User, Lokation, Thema- sind separat voneinander zu betrachten und können im Idealfall alleine für sich oder kombinierbar betrieben werden. Das Kommunikations- und Sicherheits/Privacy-Modul schafft den verbindenden Rahmen. Beispiel?
Alle Module werden separat als Open Source Module zum eigenen Hosting zur Verfügung gestellt. Buzzriders wird so oder so das Komplettsystem unter dem Label “Buzzriders” betreiben. Vergleicht es am besten mit Wordpress.com und auf Wordpress.org basierenden Einzelkämpfer-Blogs.
Beispiel zum Verständnis, wie die Module zusammenhängen und was sie bedeuten
So kann ein Webmaster das Modul “User” installieren. Das Kommunikations- und Sicherheits/Privacy-Modul wird mitgeliefert und erkennt, dass ein Lokations- und Themenmodul nicht benötigt wird. Mit dieser Konstellation kann der Webmaster ein eigenes Local Social Network betreiben, das nur auf die Vernetzung und Kommunikation von Menschen abhebt, Lokationen und Themen vor Ort bleiben außen vor. Lokation? Das kann eine Straße sein oder ein Cafe, was auch immer einen physischen Platz vor Ort darstellt. Thema? Das kann ein Stammtisch zum Thema Fußball des ansässigen Ortsvereins sein.
Bleibt es damit ein Local Social Network? Antwort: Ja, aber eingeschränkt! Konkret: Eine Kommunikation mittels “Housing-Mail” wird auf Straßenebene weiterhin ermöglicht (Beispiel aus einer Reihe von Konsequenzen). Doch kann sich kein User mehr mit einer bestimmten Lokation vernetzen, er kann nämlich weder spezifische Orte präziser an einer eigenen Stelle in diesem Netzwerk -ihm steht nur das Userprofil für personenbezogene Daten zur Verfügung- beschreiben, noch kann er für bestimmte Themen eigene Sammelstellen schaffen. Aber was ist dann mit Housing-Mail? Wo laufen diese Informationen auf? Nicht mehr gesammelt an einer Stelle, nämlich der Adresse -die im Netzwerk separat aufrubar wäre und damit auch alle Nachrichten, wenn das Lokationsmodul freigeschaltet wäre-, sondern in den User-Profilen (u.a. bestehend aus einer Art von “Timeline”/Inbox” á la Facebook), die sich diese Adresse zugeordnet haben. Die ortsbasierende Gruppenkommunikation wird damit lediglich auf individueller User-Ebene und innerhalb des User-Netzwerks ermöglicht, nicht mehr aber genau an diesem Ort gesammelt (wichtiger Unterschied für ortsbasierenden Nachrichtenfluss!!!).
Diese gedankliche und funktionale Trennung via Modulen erzwingt per se ein klares Vorgehensmodell bei der Ausprägung der Einzelkomponenten und erhöht zugleich die Variabilität beim iterativen Vorgehen, ausgehend von den Praxiserfahrungen.
Die Module User, Lokation und Thema sind Anlaufstellen, das Kommunikationssystem ist sozusagen das Schmieröl, das diese Anlaufstellen miteinander verbindet und das notwendige Leben einhaucht. Das Modul “Sicherheit/Privacy” ermöglicht es dem Benutzer, seine eigene Teilöffentlichkeit zu kontrollieren. Das Modul “Admin” steht dem Betreiber zur Verfügung.
Soweit das Schema. Im nächsten Artikel gehe ich näher auf das User-Profil und das Kommunikationssystem ein.
10 Reaktionen zu “Buzzriders-Module”
Schreibe mir
Suche:
Sponsoren
Buzzriders
Links
Meta
[...] Housing-Mail -> KFZ-Mail Buzzriders-Module [...]
[...] « Buzzriders-Module [...]
Genau bei dem von Dir aufgeführten Beispiel in “BWL-Entscheidungstheorie” bezüglich der technischen Skalierung widerspreche ich Dir. Das Thema wird gerne mal ignoriert, sollte es aber nicht. Um so mehr hat man später auf einmal ein Problem, wenn das System unter der Last zusammenbricht. Denke, Twitter ist hier ein gutes Besipiel. Wir können uns sicherlich noch gut daran erinnern, wie der Failwhale ein Dauergast auf unseren Schirmen war. Dies dürfte sicherlich auf ein schlecht skalierendes System hinweisen. Das kann dann auch sehr schnell zu einem schlechten Feedback der Nutzer führen.
Ich meine nicht, dass man sich an der Stelle bis zum letzten Tüpfelchen Gedanken machen muss, aber gewisse Gedanken zur Skalierung beim Design der Architektur und der Implementierung sollten schon mit berücksichtigt werden.
ich denke, hier gibt es zu Genüge gute Grundregeln, die schon mal zu 80% helfen. Gerade im DB Design und den Abfragen. Das ist das eine. Die anderen 20% sind den Pros vorbehalten, die kommen noch früh genug zum Zuge, hope so. Hast Du Vorschläge ob dem Vorgehen? Mitnehmen zum nächsten Buzzcamp?
[...] “Buzzriders-Produktmodule” = groß denken, klein [...]
Wir sollten abfragen,ob es in den Reihen der Interessierten (Entwickler/IT-Fuzzis/wie auch immer genannt) welche gibt, die auf dem Gebiet Skalierung Know-How haben. Speziell (MySql?) DBAs, die an dem Projekt mitarbeiten wollen und sich in dem Gebiet entsprechend auskennen und Lösungen anbieten (z.B. Clustering der DB?). Im PHP-Bereich bin ich aktuell überhaupt nicht drinnen, vielleicht gibt es hier schon fertige Lösungen/Frameworks, die einen dabei unterstützen? Hat Apache vielleicht bereits etwas eingebaut? Oder braucht man einen Loadbalancer vorgeschaltet?
Hast Du vielleicht Kontakte, die einem zu diesen Themen einen Einblick geben könnten?
Ich denke auch einfach daran, dass wir rechtzeitig dieses Thema bedenken, nicht das wir uns durch mögliche Design/Architektur-Entscheidungen das Leben später schwer machen. Lieber jetzt nochmal zweimal darüber nachdenken…und dafür eine saubere und skalierende Architektur.
mein Plan war und ist die Gurus von IBM, Microsoft und Sun dazu zu gewinnen.
[...] Source Service in allen Belangen voranbringen möchte. Es geht nicht nur um Module, die man als Webmaster selber betreiben kann. Es geht ebenso um das Sharing von Ideen, Konzepten, Daten, Erkenntnissen in allen Belangen. [...]
Es gibt ein schönes Buch: “Building Scalable Web Sites” im O’Railly-Verlag. Außerdem: Falls das Projekt in PHP programmiert wird, würde ich das Framework PHP-Cake empfehlen (vom MIT entwickelt). Damit kann übrigens PHP alles, was das neumodische RubyOnRails auch kann (MVC-Pattern). Wenn man damit arbeitet, ist das Ergebnis (fast) automatisch skalierbar. Über Clustering braucht man mit PHP-Cake nicht viel nachdenken bzw. kann die Daten auf verschiedene Server mit geringen Anpassungen im Programm verteilen, wenn die Zugriffszahlen steigen. Die Business-Logik wird bei PHP-Cake hauptsächlich auf Programmebene festgelegt und weniger über ein dezidiertes SQL-Datenmodell, was vor und Nachteile hat. Der Vorteil liegt aber gerade in der Skalierbarkeit. Allerdings erfordert PHP-Cake am Anfang etwas Einarbeitung. Der Einstieg ist nicht unbedingt trivial. Der Aufwand zahlt sich aber später aus (RAD).
Nur mal eine kurze Anmerkung zum Failwhale: Hat das Twitter geschadet? Nein! Der Failwhale ist Kult geworden und hat ausserdem vermittelt: Hey auf der Seite ist voll viel los, dass der Server nicht mehr mitkommt.
Natürlich sind die Nutzer davon auch irgendwann genervt, aber es ist kein Weltuntergang.