Fire all managers… well, better not so radical…


I saw a lot of discussion recently in the manager versus leader thing. I would not go so far as he does but you need to have a balance. From what I see, business becomes less integrated and more of supply chain management. Here I see the major field for managers today. It will be less the classical management as it is written in the standard MBA books. What is sure is, you need leaders or intrapreneurs!!

My personal impression is that still a lot of company cultures do not reflect this fact. Those intrapreneurs or leaders are not easy to handle with. They show a lot of energy, they tend to have ideas which explode the status quo. Then there are articles that you should not tolerate divas in teams. Sorry for my French: Bullshit!!!

You need to have a few of them. They need to be treated with care and respect. And you as their manager need to make sure they treat their environment with respect. Sometimes you need to let them run ahead and then make sure they come back lead the crowd to the new fields they discovered. You need to encourage people to become a leader in their field. And you need to train them that everybody can be leader and will a leader when the time comes. It is all about taking leadership and giving it to others to follow.

This means that you accept (1) that there is not the universal expert; (2) everybody is leader and a follower; (3) this includes the upper ranks; (4) this can only work if you have a clear communicated and widely supported vision; (5) learn, coach, teach…



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: Working with Partners


I just saw a blog post by our friends of bluevia where they argued that building a brand new thing from the scratch is the best way to go. Well, I have a somewhat different opinion. Let me explain how this comes.

Our product concept is a mixed one: We build own stuff internally and provide it via APIs – such as the Global SMS API. But we also partner with companies large and small to build joined products. Examples are our IVR system or App Monitor.

We established a process for this. It starts by looking into the marketplace and thinking on extensions to our current product line that make sense. For App Monitor, we discovered the problem of an extremely diversified Android marketplace and the hassle developers have to ensure quality. Another observation was that quality already is of some importance but will become of major importance in the near future. Next step was to look around and find a suitable technology to help us and we found an Israel based company that worked in this fields for some years. Exactly for this we have a tech scout. The solution was not exactly what we needed but it was a good starting point. Therefore, we added what we as Deutsche Telekom have: New business model, some missing features, hosting and operations, data privacy, access to a large test pool of devices, and what not. We have specialists here, we have access to partners, we have architects knowing what carrier grade software means. After some months of work, we were able to launch App Monitor and are now working jointly to increase quality, add features, and sell it.

The same comes true for our IVR system. We searched for a partner and found it. But I can point out lots of things we added or changed in conjunction with the partner. We are now about to add some features… well, by adding another partner technology.

The point behind this is twofold: On the one hand, we want to be agile and innovative. Doing this all ourselves would be nice but is simply naïve to expect. There are groups within Deutsche Telekom that have the idea of looking 7+ years into the future – namely T-Labs. Our goal is differently in providing useful products within months.

On the other side, it is not that we are a supply chain in buying products and reselling them. We add goodness by means of what we can do as a large, multi-national corporation. This comes in many forms and shapes. Technically, we know what it means to operate large infrastructures in a reliable manner. We know what security means. We are providing an onboarding platform which enable partners to easily integrate into our current offers. And we can span all kinds of platforms. From an operations perspective, we do customer identity management, invoicing, and support. From a go to market perspective, we do marketing and sales. And last but not least, we have product managers who keep an eye on the market and help to shape and drive the product.

So, if you are using one of our products, you get it all: Innovation, solid technology and operations, and a reliable partner. I think this is a good offer to go for.



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.



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??






es gibt sie, die API Evangelisten (siehe hier Sie singen das hohe Lied von JSON, was erkennbar ist am Signet: {“logo”:”API Evangelist”}

Zunächst einmal sind APIs ja eine pur technische Sache, würde man meinen. Nicht mehr, meine Freunde. Ich darf mal platt auf diesen interessanten Blog-Eintrag referenzieren: David Chiu macht da eine sehr interessante Beobachtung. Immer mehr Firmen entdecken APIs als ein Modell, ihre Angebote einem breiteren Publikum bekannt zu machen. Ganz erstaunlich, weil das teilweise sogar gegen Teile ihres eigenen Geschäftsmodells laufen kann. Nehmen wir Amazon, die ihren Marktplatz anderen Anbietern geöffnet haben. Wohlwissend, dass sie dann eben nicht mehr immer selber den Verkauf machen werden. Aber auch wohlwissend, dass sie damit immer mehr Kunden anziehen, weil es eben alles zu immer recht guten Preisen gibt.

Damit kreuzen sich plötzlich zwei Ströme. Es geht nicht mehr nur darum technische Funktionen zur Nutzung bereit zu stellen. Es geht auch darum, die richtigen Funktionen zu haben. Nämlich die und die dann eben so, dass ich sie für Business nutzen kann. Damit heißt das auch wegkommen von low-level Techie-Techie-Funktionen und hin zu Business.

Holla, damit wird es aber auch heikel. Da sind wir nämlich mitten in einem uralten Schlachtfeld: Technik und Business. Ein Thema, das in so vielen Filmen porträtiert wurde: Die zwei, die ohne einander nicht können, aber richtig miteinander auch nicht. Noch schlimmer, denn in unserem Fall müssen beide auf einander Rücksicht nehmen. Der sicherste und performanteste Webservice nutzt nix, wenn ihn schlicht weg keiner haben will. Der beliebteste Service auf diesem Planeten bleibt nicht lange, wenn er unsicher ist und keine Last ab kann.

Falls irgendjemand seinen Eltern verkaufen muss, warum man unbedingt Wirtschaftsinformatik in Darmstadt studieren muss, referenziert mich. Weil genau das Spannungsfeld aus Wirtschaft und Informatik sehr energiereich ist…




Hätte ich nicht besser sagen können…


bin gerade über diesen Artikel gestolpert:

Ich hätte es nicht besser sagen können. Ich kenne keinen Vortrag zum Thema Zukunft, der ohne mobiles Internet auskommt. Soweit sind wir uns einig. Woher kommt dieses Internet? Auch klar.

AT&T befindet sich in exakt dem gleichen Problem wie sich eine Deutsche Telekom befindet: Man ist groß, man bewegt sich in einem sehr regulierten Markt, man hat es mit agilen Konkurrenten zu tun, von denen die meisten vor 15 Jahren noch nicht existierten oder was ganz anderes gemacht haben und – zu guter letzt – man hat die allerbeste Startposition.

Für mich sind auch APIs ein Schlüssel zum Glück. Offensichtlich für Rene Obermann auch 😉



PS: Erste Schritte sind gemacht


Innovation ist nicht nur technisch…


Derzeit wühle ich mich durch deutsche Literatur zum Thema Entrepreneurship und Innovation. Ich bin auf das gestoßen:

Darin habe ich einen spannenden Absatz gelesen: Für Unternehmen gibt es zwei Formen von Kraft, wenn es darum geht Produkte am Markt zu haben. Die eine Kraft braucht man um bestehende Produkte am Markt zu halten und seine Marktanteile zu verteidigen. Die andere Kraft, wenn man neue Produkte an den Markt bringt und erfolgreich macht. Letztere ist die einfachere. Es ist anstrengender Produkte am Markt erfolgreich zu halten als neue Herausforderer einzubringen. Interessanter Gedanke.

Weiter meinte der Autor, dass man sich endlich vom Gedanken der dringend notwendigen technischen Innovation verabschieden sollte. Als Beispiele werde eigentlich alle herausstehenden Neugründungen der letzten Jahrzehnte genannt: Google (Suchmaschine ist nett, aber der eigentliche Hit war die Idee mit der indirekten Finanzierung per Werbung), Starbucks (Kaffee gab es vorher, die Idee ihn so zu verkaufen war neu), Amazon (auch nicht die Erfinder von Katalogverkäufen), Apple (MP3 Player und Musikläden im Internet gab es vorher, Smartphones gab es vorher, Tablet gab es vorher). Ich kann mir jetzt lebhaft vorstellen, wie manch einer den Satz „MP3 Player schon, aber doch nicht so einen“ an den Bildschirm schreit. Right, aber hier liegen die Innovationen immer weniger im technischen mehr im Design- oder Business-Bereich. Das soll nicht heißen, man kann ganz auf technische Innovation verzichten. Aber man muss klar die Priorität anders setzen, als wir das bei Produkten der 80er und 90er gemacht (möglichst viele Knöppe dran und Funktionen, die man nur als Elektrotechniker zwar verstehen dann aber für Firlefanz halten würde).
Faszinierend sind die Gedankengänge, weil ich gerade im Bereich Enablement arbeite. Für uns wäre also die Frage, wie können wir anderen helfen derartiges aufzubauen, um am Ende per Netzwerk-Effekt selbst davon zu profitieren!?!?!