Redefinition of Operating System


if you would ask a consumer about the tasks an operating system has, she would pretty much argue from her own point of view. Problably, it would burn down to three major things:

  • Storing and providing access to my data such as pictures, music, e-mails, documents…
  • Providing access to the internet via hosting a browser…
  • Maybe some fun activities like a game or two…

If we follow this definition – which for sure is a non-CS-ish – we see where companies like Google with Chrome or Firefox with Firefox OS are heading to. And we also understand imediately why Microsoft still fights for the Internet Explorer.

Today, the browser becomes the UI framework of your operating system. The storage is pretty much in the internet. There is no real need to store anything locally, it might even be more interesting to store in the cloud. Because the connection between you and cyberspace is no longer the PC alone. You certainly do not want to lock your life into the PC at home.

If you now introduce a layer like Google Chrome or Firefox OS which is pretty much device independent, it can become your default way of interacting with your new operating system.

And by the way, sooner or later, Apple will follow Microsoft in panic …




Mobile App Architecture


I found this nice deck

It details several aspects of architecture for mobile apps. They list the key problems quite nicely… almost. They missed a key aspect (well, they mentioned it halfways):

Mobile apps need to be distributed, installed, maintained. A problem we all learned to love in the PC era where huge infrastructures were build inside of company boundaries to install and update applications. When webpages took over, this aspect got less interest. But – hurrey – it is back.

So, deployment (aka app store or integration into app stores) is a necessity. Moreover, different platforms have different rules on updates. Sometimes your update is seen as a new app somehow and needs to run through the certification process once again.




From the Desk of the CTO: Native vs Hybrid – See it like MS Access…


there is lots of discussion and discussion regarding native apps are a must (since Facebook did switch from hybrid to native) or native are just fine… First, let’s sortout one thing: What is hybrid to start with?

It all boils down to two extremes and the middle layer. On the one side of the box ring is pure web, some call it web app. As matter of fact, it is a web site that uses javascript frameworks to optimize for mobile consumption. Those websites when designed neatly can supply a variety of different mobile device formats and OSes. But obviously they suffer from the typical drawbacks of all web sites. Things like limited local storage, limited to no access of hardware capabilities, performance, you name it. The upside is: It uses HTML5 and Javascript which should be common to all developers nowadays.

On the other side of the boy ring – the other extreme – is the native app. This is what we saw in the beginning as an app. It runs on the device, need to be installed and maintained (aka updated), is specific for the OS or even the device format, but can use all of the wealth of the modern hardware, run in the background and might survive even with no network connections (which depends on the use case of the app). Those apps come with a cost: They are OS specific and sometimes it is hard to find the right guys developing this.

Then there is the idea to mix both and combine the strengths of both worlds. Welcome to hybrid. Some seperate the pure hybrid from a mixed hybrid (when you combine platform specific code with hybrid on top) but this is not really of importance for us here. Critics say that hybrid do not inherit the strengths but more the weaknesses. Performance problems unknown to native, limited abilities due to limitations in the frameworks (because in the end the framework supports somehow only the least common dilimiter), complexity unknown to web, the need for maintainance unknown to web.

My point here is, I simply compare it to Microsoft Access. Some of you from the older ages remember Microsoft Access as admins greatest enemy. When Access came around the corner, it was not seen as an appropriate database (hey, it ran on the client!!). So, it started by being an ok solution to store the recipients of the christmas cards of a division. But it was good enough for A LOT of tasks. It provided a simple data entry and storing mechanism, a quite decent query engine, and – most important – an easy way to print out the stuff. And, bam, nobody imagined how many processes cried for a RDBMS solution. Sure, people started to fiddle around with it, stretching the limits and sometimes overdoing it tremendously. But hey, slowly but steadly it became business critical. In a way, Access and Excel were version 0.1 of the Consumerization of IT because for the first time the users took the initiative. And – as we see it today – IT was not able to cope with it.

I see hybrid in the same position as Access that days. There are so many obviously simple tasks that would tremendiously benefit from being “mobilized”. Most of the times, simple stuff like browsing a table of data and triggering some actions. With the ability to use greater amounts of local storage, doing this in a secure container, being able to work offline for some time etc. Performance is not the real critical factor here. Neither is the 120% UI. Don’t get me wrong: Software needs to serve its users and I am by no means preaching to forget about user experience. But good user experience does not need 3D animated, wobbeling buttons. At least not everywhere.

So, stop this senseless, emotional discussion. Believe me, the world will be a better place, if we could use what we learned with Access (which was a great deal how not to do it) and do more mobile apps.

Just my 2 cents.




From the desk of the CTO: 40 years gone and still the same problems…


I found this nice presentation:

The amazing thing here is, that this guy presents from a view of 1973 (please note the pens in the pocket of his shirt, really mimicking an IBM technician of that time). What is so remarkable is that the exact same problems he describes, we are still struggeling with today.

This reminded me, on the software crisis theme as stated in 1968 at a NATO conference (see Wikipedia). We are still struggeling with the amount of software we can produce in a given time. There is more software necessary than we can produce. To address this, we can increase productivity of developers or get more people into development. We are also struggeling with the quality. We learned is that a certain freedom comes with fragmentation meaning complexity meaning quality problems.

If you look on our roadmap with App Monitor, Code Analyzer, and the things we are about to release soon, you see how we want to address this.




Innovation in Konzernen vs Startup


Was man sich klarmachen muss, wenn man über Innovation in Konzernen versus Innovation im Startup nachdenkt, ist das Framing.

Wenn ich ein Spiel angeboten bekomme, in dem ich mit 10% Chance 100 Millionen verdienen kann, aber mit 90% Chance 5 Millionen Verlust mache, dann redet man hier wohl von Risiko-Kapital-Anlage. Das meiner Volksbank zu verkaufen wird schwierig und auch meine Lebensgefährtin wird mich seltsam ansehen (es sei denn, es war ihre Idee). Mit 5 Mille im Minus wird das weitere Leben sehr schwer oder man muss seine Seele alle halbe Jahre an RTL verkaufen.

Jetzt begeben wir uns in die Schuhe eines Konzern-CEOs. Vor ihm stehen 10 Manager, die alle dieses Spiel spielen können im Auftrag des Konzern. Ziemlich sicher werden 9 davon 5 Millionen minus machen, also 45 Millionen. Ebenfalls ziemlich sicher wird einer 100 Millionen verdienen. Aus Sicht des Konzernlenkers ein gutes Geschäft mit überschaubarem Risiko.

Sicherlich vereinfacht dieses Model extrem und ich habe es einem Buch entnommen („Schnelles Denken, langsames Denken“ von Kahneman , aber es zeigt wie VCs oder Konzerne funktionieren.

Warum gibt es aber dann so wenig intrinsische Innovation in Konzernen? Weil man lernen muss, dass Scheitern Teil des Geschäfts ist. Nicht alles wird funktionieren, eher im Gegenteil, das Meiste wird nicht funktionieren. Man braucht aber mutige Intrapreneure, die trotzdem den Einsatz wagen. Leider feiern wir zu gerne, die zufällig erfolgreichen und bemitleiden die zufällig nicht erfolgreichen. Aber das ist so Baby-Boomer und so nicht mehr Generation Y ( Hoffe ich wenigstens…



Sicherheit und die Cloud – Die Gefahren liegen ganz wo anders…


Auf die Frage, wer den Cloud Computing macht, wurde vor einigen Jahren im Fachpublikum noch mit leichten Lachanfällen reagiert. Alles viel zu unsicher. Wenn man dann gesagt hat, dass jeder, der privat eine gehostete Email-Adresse hat oder gar Online-Banking macht, eigentlich schon voll in der Cloud angekommen ist, gab es verdutzte Gesichter.

Heute ist das Thema Cloud salonfähig geworden – ob die IT-Abteilung das wollte oder nicht. Das Totschlag-Argument Sicherheit hat nicht gezogen – irgendwie. Ich nenne Sicherheit hier ein Totschlag-Argument, weil zumeist nicht viel dahinter steckt. Man sagt, „Unsicher“ und hofft, dass keiner eine weitere Frage stellt. In Wahrheit hat man sich mit dem Thema sowas von Null beschäftigt. Wenn man dann sagt, dass Cloud Daten wahrscheinlich die besser geschützten sind, reagiert man am besten mit Auslachen. Leider sprechen die Tatsachen eine andere Sprache.

Nehmen wir diesen netten Artikel . Überrascht uns eigentlich, dass Hacking und IT Probleme mit 6.3% es gerade noch so in die Top 5 Probleme geschafft haben?? Probleme wie das Stehlen von Laptops, Herumliegen von Ausdrucken und derartiges mehr, sind halt immer noch die Spitze. Und das sind Hinterlassenschaften der alten Zeit.

Nun sind die 6.3% immer noch zu viel, keine Frage. Und die Tatsache, dass alte Bekannte wie SQL Injection noch immer die Top 10 der OWASP Liste anführen, macht einen wundern. Wer heute keine Tools wie Code Analyzer einsetzt, ist selber schuld und sollte dafür auch haftbar gemacht werden.

Die Diskussion, die man zum Thema Cloud Security noch führen sollte, ist der Speicherort der Daten. Leider ist das Internet da nicht eine homogene Landschaft. Der Speicherort der Daten bestimmt den gesetzlichen Rahmen zum Thema Datenschutz. Wir Deutschen dürfen mit Recht sagen, dass wir es erfunden haben. Wir sollten dieses Erbe auch in eine Tradition verwandeln und uns bewusst sein, dass dies unser Beitrag für das globale Netz werden könnte. Aber nur, wenn wir Tradition nicht mit dem Bewachen der Asche sondern mit dem Erhalten des Feuers übersetzen. Datenschutz muss sich wandeln und die Zeichen der Zeit mitnehmen. Die Aussage einiger Datenschutzfundamentalisten, dass Social Networks sowieso des Teufels wären, wird da nicht helfen.



Telekom Tropo RevShare – Proposal II


This time in English because I need to address a larger audience. Please bear with me…

Revenue share model – second shot

After my first idea I got some feedback which I would like to include into the concept. The following is a product idea, it is nothing real – for now. My goal is to find the Minimal Valuable Product which I could set up and test. Therefore I need your help and let us refine the original idea.


I believe that developers have an interest to use the IVR system Telekom Tropo in their applications. But they do not want to do the accounting. And, potential interest would increase dramatically, if we would share the revenue with the developer that his app generates for us.

How would it look like?

The main concept stays the same. You, Mr Developer, build an app (which doesn’t need to be a mobile one and ) which uses Deutsche Telekom services – in my case the Telekom Tropo API. Your customer acquires the app (buying or getting it for free) and, through your app, sets up an account with us. She can use any payment mechanism.

Whenever your customer is now using your app and generates service revenue with us, we share this revenue with you. All customer communications will be done through your app. To do so, we provide a component, you can include into your app which supports themes so you can camouflage it as much as you want.


  • You, Mr Developer, need to register with us. You act as a kind of reseller and acquire an app id.
  • Your app provides this app id when using our services.
  • We provide a proper reporting on what happening.
  • Your customer sets up an account with us. We take all efforts regarding account management.
  • Your customer could use her account with us in different apps. Logically, you, Mr. Developer would only earn when your app is the caller (hey, be fair…).

We would take care on all accounting and calculate the revenue share. You would get it paid out regularly.

Would you follow us down this path??



Developer Life-Cycle Model


Wie Peter Drucker so schön sagte „Die Hauptaufgabe jeder Organisation ist es, Kunden zu gewinnen“. Es ist hinlänglich über den Zyklus diskutiert worden, wie man als Organisation Bedürfnisse erkennt, diese mit Produkten adressiert und zu guter Letzt, diese Produkte auf den Markt bringt. Für mich ist die Aufgabe von Marketing in allen drei Phasen eine aktive. Es ist Aufgabe von Marketing Bedürfnisse zu erkennen (Märkte zu identifizieren), passende Produkte entwickeln zu lassen (so dass sie auf diesen Markt passen) und dann ja auch zu verkaufen. Dabei ist das ein Zyklus, kein einfacher Prozess.

Wenn man Marketing machen will, so muss man sich Gedanken um seine Zielgruppe machen. Man muss sie verstehen und sich ein Model bauen. Naja, Letzteres machen vor allem Physiker, die jetzt einen Marketing-Job machen. Es gibt viele Modelle für den Consumenten (Beispielsweise hier, aber erstaunlicherweise wenig bis gar nichts zu Software-Entwicklern. Erstaunlicherweise weil derzeit ja alle Welt hinter App-Entwicklern her rennt.

Ich habe einen interessanten Beitrag hier gefunden. Eine Segmentierung mal als Beispiel.

Vielleicht vorab noch so viel: Ein Modell ist ein Modell. Es zeigt nicht die für jeden Einzelfall gültige absolute, dauerhafte Wahrheit. Vielmehr reduziert ein Modell strategisch, d.h. es konzentriert sich auf einige wesentliche Aussagen und blendet eine Menge komplexe Realität aus. Und der letzte Satz war ein Anthropomorphismus.

Ich habe mir auch ein paar Gedanken gemacht und folgendes Modell entwickelt:

Entwickler leben in einem Zyklus von Projekten, mit unterschiedlicher Laufzeit. Manchmal heißt Projekt-Ende, dass man eine ganz neue Umgebung bekommt (bei Freelancern häufig), manchmal ist es nur ein Produkt-Release und alles geht so weiter wie gewohnt. Bei einem solchen Projekt-Start steigt mein Modell ein. Zu Beginn haben Entwickler meist sehr viel Zeit sich mit neuen Dingen zu beschäftigen (Explore). Warum?? Nun, man sucht neue Tools, Prozesse, Technologien etc, um das neue Projekt erfolgreich gestalten zu können. Für manche ist diese Phase extrem groß (z.B. Architekten, die stets auf der Suche sind), für manche sehr schmal (z.B. den Abteilungs-ABAP-Programmierer… armer Kerl). Aber irgendwie sind wir alle aus dem Holz gemacht. Wir alle haben unsere Explore-Phase und wir geben sie nur sehr ungern auf. Mein Modell zeigt, dass Explore auch immer ein wenig bleibt. Weil wir halt Spielkinder sind und immer auf dem neuesten Stand bleiben wollen. Für mich als Evangelist ist jetzt die Frage, wie muss der Content in dieser Phase aussehen?? Es muss ein gute Mischung aus Entertainment und Education sein, Edutainment. Sehr viel Architektur, Beispiele zum ausprobieren, Trials, Video, Artikel, Kongress-Vorträge…

Irgendwann müssen wir aber zum Schuß kommen und wir wählen Tools und Kram zum Arbeiten. Manchmal bleibt alles beim alten, manchmal wechseln wir die ganze Plattform. Aber langsam müssen wir mehr Zeit wieder der eigentlich Arbeit zu wenden. Also gehen wir in die Work-Phase. Hier geht es jetzt nicht mehr Architekturen und lustig Overview, sondern konkrete Themen. Man hängt an Fehlern fest oder sucht die eine Funktion, die den String HTML-encoded. Hier ist eine andere Art von Content gefragt. Der kluge Developer checkt das natürlich vorher. In der Explore-Phase wird schon mal gecheckt, wie gut ist der Service, wie stark ist die Community, gibt es ausreichend Artikel etc und lala. Irgendwann – und wir kennen das alle – sitzen wir dann 16 Stunden am Tag am Codieren, weil die Abgabe nahe rückt. Wir haben doch etwas weniger Zeit für Explore, vielleicht auch gar keine Zeit mehr. Natürlich passiert uns das nie, da wir perfekt planen. Aber ich habe gehört, dass der Schwager eines entfernten Bekannten häufiger solche Zeiten hatte.

Ganz oben auf schwimmt das Thema Maintainance. Wir alle leben nicht prinzipiell immer wieder auf einer grünen Wiese. Vielmehr gibt es bestehende Themen, die wir so nebenher weiter pflegen müssen. Es mag Ausnahmen geben (wenn wir für die NASA eine Sonde bauen, müssen wir wahrscheinlich nicht alten Code pflegen). Meist haben wir aber alten Code in Form von alten Produkten oder Produkt-Versionen zu pflegen. Ich habe diese Phase ausgewiesen, weil diese Zeiten einige spezielle Eigenschaften hat. Zumeist kommt der Kram unvorhergesehen und zu dem, was wir sowieso tun müssen oben drauf. Dazu sind es eigentlich Kleinigkeiten, keine wesentlichen Änderungen. Wir waten tief durch Code, der ewig alt ist und den wir am Ende nicht mal selber geschrieben haben. Wir arbeiten hier mit alten Versionen von Tools, Betriebssystemen, Datenbanken, Tralala. Welchen Content man hier sucht, ist auch klar. Sehr stark wie in der Work-Phase, aber halt alte Versionen. Als Hersteller ist das interessant, weil man entscheiden muss, nicht nur wie lange man Content für alte Version hält (das ist ja noch einfach) sondern in wie weit man diesen Content noch pflegt.

Für mich ist dieses Modell ein wichtiger Leitfaden, den richtigen Content-Mix zu finden. Vielleicht auch für Euch interessant.




Telekom Tropo RevShare – A product proposal


ich brauche Euch. Ihr müsst mir helfen zu entscheiden, ob dieses Produkt von Interesse wäre und wie eine minimale Ausprägung aussehen müsste, damit es Sinn macht.


Ich glaube, dass Entwickler Interesse daran hätten, das IVR System Telekom Tropo in ihren Applikationen zu nutzen. Sie wollen aber nicht die Buchhaltung machen. Und, das Interesse würde expotentiell steigen, wenn wir sie am Umsatz beteiligen würden, dass ihre App bei uns erzeugt.

Mein Produkt:

Telekom Tropo Revenue Share

Wie würde es aussehen:

(1) Der Entwickler baut eine App, die Telekom Tropo Dienste nutzt und stellt sie dem Benutzer zur Verfügung. In meinem Beispiel ist das eine CRM Applikation, die mit Telekom Tropo Anruf-Verwaltung macht.

(2) Der Benutzer hat diese App und aktiviert die Telekom Tropo Funktion. Im ersten Schritt würde der Kunde ein Konto bei uns anlegen und das aufladen (Pre-Paid).

(3) Der Benutzer verwendet die CRM App und dadurch auch Telekom Tropo. Wir tracken welche App die Umsätze auslösen und bezahlen einen Anteil diesen Umsatzes an den Entwickler. Der Kunde würde marktübliche Preise bezahlen müssen und es nicht “spüren”, dass wir an den Entwickler Gewinne ausschütten.


Macht das Sinn?? Würden Eure Kunden ein Konto bei uns anlegen und aufladen?? Was würdet Ihr brauchen, um das zu verwenden??




Telekom Tropo – Nummer zur App zuordnen


[Update: Wir haben diesen Prozess erheblich vereinfacht. Werde in Kürze einen neuen Artikel dazu veröffentlichen!!!]

ich hatte ja bereits zum Thema Tropo kurz mal was geschrieben. Jetzt machen wir mal weiter und klären wie ich denn jetzt eine entsprechende Telefonnummer zugeteilt bekomme.

Das Alles läuft auf dem Developer Center der Telekom. Hier werden alle Dinge gemacht, die direkt APIs betreffen.


Für eine deutsche Telefonnummer braucht man den Scan eines amtlichen Lichtbild-Ausweises.

Schritt 1: Nach dem Einloggen, oben auf den Reiter Telekom Tropo API klicken. Dann auf Neue Anwendung erstellen.

Schritt 2: Die Anwendung braucht einen Namen (hier DemoDemo) und eine URL. ACHTUNG: Das http:// vorne nicht vergessen! Unter dieser URL wird dann der JSON Code abgefragt, wenn jemand Eure Nummer wählt. Die Umgebung kann Entwicklung oder Produktion sein. Bei Produktion gibt es keine Einschränkungen, es werden aber Kosten abgerechnet. Bei Entwicklung gelten 10 Minuten Grenzen. Dann auf Speichern.

Schritt 3: Ihr landet auf diesem Formular. Hier könnt Ihr bereits einige wichtige Dinge sehen: Die SIP Adresse, Tokens für ausgehende Verbindungen. In der Mitte ist ein Hyperlink zum Beantragen einer neuen Telefonnummer. Da klicken wir jetzt mal drauf…

Schritt 5: Im oberen Drop-Down-Feld kann man sich aussuchen, in welchem Land Eure Nummer beheimatet sein soll. Jedes Land auf der Welt ist eigentlich danach ganz easy, nur Deutschland nicht 😉

Also wählen wir mal Deutschland (GERMANY) aus. Daraufhin könnt Ihr eine Stadt auswählen. ACHTUNG: Diese Stadt muss mit Eurem Wohnsitz übereinstimmen!! Dies ist keine Schikane sondern deutsches Gesetz. Wohnt Ihr auf dem platten Land oder wollt Eure Vorwahl da nicht drin haben, dann bitte +49 3222 auswählen. Dies ist eine Vorwahl, die nicht mit einem konkreten Ort verbunden ist. Dann klicken wir mal weiter…

Schritt 6: Mit jeder Telefonnummer in Deutschland MUSS eine Person und Adresse verbunden sein. Daher muss auch ein Bild des Personalausweises (bei juristischen Personen ein entsprechender Nachweis) angehängt werden. Gesetz ist Gesetz und ich verstehe immer besser, was Rene Obermann meint, wenn er sagt, der Telekommunikationssektor sei überreguliert.

Also im folgenden Feld den Scan der entsprechenden Papiere hochladen.

Schritt 7: Call me maybe…

Sobald Euch die Nummer zugewiesen wurde, findet Ihr diese auf der Applikationsübersicht. Dazu einfach im Developer Center – Telekom Tropo API – Eure Applikation anklicken.

Happy calling…