Einen Ausblick auf eine mögliche Entwicklung des M2M Marktes bis 2020 hat Bill Zujewski, als CMO von Axeda zuständig für die Produktstrategie, gegeben. Dabei geht der Trend bei M2M Lösungen von der Vernetzung („connect“) der Geräte, über das Steuern („manage“) sowie die damit eingeführten Neuerungen der Produkte („innovate“) hin zu mitwirkenden Geräten („collaborate“). Aus Kundensicht bedeutet dies, dass immer neue Touchpoints kreiert werden, auch in bislang noch ungenutzten Situationen.

Bei den technischen Vorträgen waren natürlich die neuen Features des Axeda Plattform Releases 6.5 und die geplanten Features des Releases 6.6 besonders interessant. Beispielsweise wird über das Axeda Ready Codec/Agent Programm an der Unterstützung von mehr Client-Plattformen und Geräten gearbeitet. Weiterhin wird die Plattform API erweitert und verbessert, die sehr leicht mit eigenen Groovy-Skripten oder über RESTful Webservices zu nutzen ist.

Die sehr professionell organisierte und durchgeführte Veranstaltung wurde neben einem Gala-Abend offiziell gekrönt. Dort wurden die M2Me Awards in verschiedenen Kategorien vergeben. Insgesamt konnten wir dort wie auch über die gesamten vier Tage unser M2M Netzwerk pflegen und weiter ausbauen. Inoffizielles Highlight war allerdings in unseren Augen der Besuch des Baseball-Spiels der heimischen Boston Red Sox gegen die Minnesota Twins und der Besuch am Boston Freedom Trail.

Das Internet der Dinge ist eine Bewegung, die noch an ihren Anfängen steht. Das volle Potential kann erst entfaltet werden, wenn Lösungen für die im letzten Artikel beschriebenen Herausforderungen gefunden werden. Zu Beginn ging es vor allem darum, physische Dinge digital greifbar zu machen. Ein Beispiel dafür ist der Einsatz von RFID-Technologie. Diese Phase ist bereits angelaufen. Schon 2008 setzte laut ¹ die Hälfte aller deutschen Großunternehmen RFID ein. In der nächsten Phase wird diesen Dingen eigene Intelligenz gegeben. Hieran wird momentan gearbeitet. Notwendige Schritte sind die Integration einer Datenverarbeitung, Möglichkeiten zur Vernetzung mit anderen Systemen, sowie Sensoren, mit denen sie ihren Kontext erfassen können. All dies sind Fähigkeiten, die Smartphones bereits innehaben. Für sich allein sind sie schon intelligente Dinge, die über das Internet vernetzt sind. Durch ihre Schnittstellen bieten sie darüber hinaus einen Zugangspunkt für Gegenstände ohne eigene Internetverbindung. Dadurch haben sie im Internet der Dinge eine zentrale Rolle als Vermittlungspunkt und Steuerungseinheit inne.

Ebenfalls wichtiger Bestandteil dieses Netzwerkes sind Backend-Systeme. Sie übernehmen die Sammlung und Verarbeitung der, von den intelligenten Dingen erzeugten Daten. Der Wichtigkeit solcher Systeme werden sich immer mehr Hersteller bewusst. Ihr Ausbau wird eine wesentliche Aufgabe der nächsten Jahre darstellen. Beispiele für solche Plattformen sind Axeda, Cumulocity, EVRYTHNG, Thingsquare Mist, und SmartThings.

In Zukunft sind wir umgeben von intelligenten Dingen, die ihren Kontext mithilfe von Sensoren erfassen. Die so erlangten Daten nutzen sie, um unser Leben noch angenehmer zu gestalten. Paradigmen wie das Internet der Dinge, context-aware Computing und Mobile Sensing sind dafür die Grundlage. Möglicherweise kann Mark Weiser’s Vision vom Ubiquitous Computing somit schon in naher Zukunft umgesetzt werden.

Von den Autoren: Marc Mai und Marco Bratz

Lesen Sie auch aus dieser Reihe:

1. Was ist Mobile Sensing?
2. Die Herausforderungen von Mobile Sensing
3. Entwicklung von Mobile Sensing Systemen
4. Ausblick: Mobile Sensing und das Internet der Dinge

1. Transparenz: Der Fortschritt und die Hindernisse eines Projektes werden täglich und für alle sichtbar festgehalten.
2. Überprüfung: In regelmäßigen Abständen werden Produktfunktionalitäten geliefert und beurteilt.
3. Anpassung: Die Anforderungen an das Produkt werden nicht ein und für alle Mal festgelegt, sondern nach jeder Lieferung neu bewertet und bei Bedarf angepasst.

Wir sind in der Produktentwicklung unseres Unternehmens im Oktober dazu übergegangen, Scrum für die Entwicklung unserer Produkte einzusetzen.
Davor wurden die Produkte nach dem klassischen Wasserfallmodell geplant und umgesetzt. Es gab 4 Releases pro Jahr mit einem Entwicklungszyklus von 3 Monaten. Dem ging eine Priorisierungs- und Konzeptionsphase voraus. Gegen Ende eines Releases stand dann noch das Gateway mit Tests und Abnahmen. Das Team war somit für lange Zeit gebunden und Unterbrechungen führten zu einem starken Effizienzverlust. Den gleichen Effekt hatten Änderungen in einem Release durch Change Requests oder Änderungen der Teamzusammensetzung. Ebenso gab es Missverständnisse in Meetings oder unterschiedliche Auffassungen bezüglich der Konzepte, die erst spät erkannt wurden. Alles hatte zur Folge, dass die Entwicklung sehr schwerfällig von statten ging und die Stakeholder immer erst am Ende eines Releases das Ergebnis zu sehen bekamen.

Die Umstellung auf Scrum brachte dann für alle Beteiligten die erhoffte Besserung. Diese wurde durch mehr Agilität herbeigeführt. Das Team wurde flexibler und reaktionsfähiger.
Flexibel, da es nicht langfristig gebunden ist. In Scrum gibt es innerhalb eines Release sogenannte Sprints. Das sind kurze Entwicklungszyklen von 2 bis 3 Wochen. Nach Ablauf eines Sprints wird eine Retrospektive abgehalten, bei der das Team prüft, wo es sich verbessern kann. Es findet ein Review (Überprüfung) statt, bei dem das Team die geleistete Arbeit den Stakeholdern in Form von lauffähiger Software vorstellt. Danach werden die Inhalte des kommenden Sprints definiert. Die Stakeholder bekommen somit immer zeitnah einen Einblick in den Stand der Entwicklung und wurde etwas anders umgesetzt als gedacht, kann die Änderung bereits in einen folgenden Sprint eingeplant werden.
Somit wurde das Team auch reaktionsfähiger (Anpassung). Änderungen, nicht nur von Änderungswünschen sondern auch von anderen Themen, können schneller eingeplant werden. Reaktionsfähig meint hier auch auskunftsfähig, da der Fortschritt schneller vorgezeigt werden kann.
Klingt gut? Ist es auch.
Durch die Umstellung wurde das Team wesentlich effizienter. Ermöglicht wird dies auch durch optimal vorbereitete Anforderungen, die durch den Product Owner an das Team gegeben werden. Die Anforderungen werden im Vorfeld bereits geprüft, Unklarheiten direkt abgestimmt und korrigiert.
Zudem finden tägliche Meetings vor dem Taskboard statt. Dieses “Gedränge” nennt sich Daily (Transparenz). Im Daily, welches maximal 15 Minuten dauern sollte, erklärt jeder Entwickler den anderen Teammitgliedern kurz, was er am Vortag gemacht hat, womit er sich am aktuellen Tag beschäftigen wird und ob es Probleme gibt, die ihn an seiner Arbeit hindern. Sollte es solche geben, wird dies vom Scrum Master aufgenommen und er sorgt für Abhilfe. Das Team kann damit ungestört entwickeln und sich auf seine Aufgaben konzentrieren.
Die Umstellung auf Scrum war somit die richtige Entscheidung und hat sich zu aller Zufriedenheit bewährt. Dies zeigt auch ganz deutlich ein Satz eins Entwicklers in einer Retrospektive, den ich gerne abschließend zitieren möchte:

“Ich habe letztens festgestellt, dass sich Scrum positiv auf mein Seelenheil auswirkt.”

Seit 2001 ermittelt der Bundesverband Digitale Wirtschaft e.V. (BVDW) gemeinsam mit den Marketing-Fachmagazinen Horizont, dem Hightext Verlag iBusiness und W&V das objektive Ranking von den umsatzgrößten Agenturen, Dienstleister und Produzenten rund um die Herstellung von interaktiven Anwendungen. Der BVDW bietet mit dem Ranking ein neutrales Branchenbarometer nach Honorarumsatz und Mitarbeiteranzahl am deutschen Markt. Dieses Jahr haben insgesamt 218 Firmen am Ranking teilgenommen.

Darüber hinaus werden alle gemeldeten Firmen vom BVDW in verschiedenen Subrankings aufgeteilt. Bei dem Subranking “Intranet” konnte doubleSlash punkten und stieg in dieser Kategorie auf den ersten Platz auf. Wir freuen uns sehr über diese Platzierung, die unsere langjährige Erfahrung als Software-Dienstleister und auch das Knowhow von der Beratung & Konzeption über die Implementierung bis hin zum produktiven Betrieb wiederspiegelt.