Remember ASP???


do you remember ASP or Application Service Providing? It was one of those hype topics in IT before SOA, IaaS, or the thing you are just thinking about came into the headlines. The idea was to host your applications no longer on your local box but to put it in the cloud (which was not named that way back then). On your local machine you would only see the UI. So, all data and installation efforts would recide on the hosters side.

Well, it never came to real popularity. I guess the technology was simply to clunky, the network bandwidths to shallow. I know quite a selection of companies founded around this which died off againi or do something completely different now.

All of sudden, our architect Richard Droscher mentioned Amazon Work Spaces ( I had a kind of a deja vu. But it all makes sense now. If you combine it with Intel’s announcement to support Chrome OS with every fiber of its heart (at least sounds like And the Android robot (which looks like a swing top recycling bin – sorry) is present at any Intel booth between here and Alpha Centaury. Sometimes my impression was that not Google but Intel owns Android.

Combining a workplace for US$ 280 as the Dell Chromebook 11 with this Amazon offer sounds interesting, doesn’t it? Those devices are actually cheap and rigid enough to be used in nearly any environment – not only as a PC replacement. Say goodbye to cash registers and what not.

They also have a bit of local storage to let them survive some network glitches in a single usage scenario…

Will we see the revival of ASP??




60 days into it…


Exactly 60 days ago I started my new life as VP Engineering in the Dun Karm Street. Maybe it is time to talk a bit about what we did so far.

I think, one of the major additions to the daily life in Uniblue that I was able to do, are the fancy project names. I will talk about some of them but not all. We started some research projects which I cannot unveil here (sorry). But I will some time later when things matured to a certain state…

Project AngryBirds: Following the future vision of Uniblue, we started to lay out a backend system that will carry this vision. It will contain of a messaging mechanism able to push messages as well as offering a polling interface. It also offers a central mechanism to collect customer feedback, usage and statistical data. The third step will be to detach the website from the processes and data persistence by means of a RESTful API. Yes, you could call this big data and yes, we will use NoSQL and stuff. Within this project we can rely on the enormous knowledge Uniblue has in the backend arena. As usual, the complexity of the system in place to supply an integrated e-commerce experience over a multitude of markets, languages, partners etc. is not seen on the surface. We are currently in the phase of architectural design of the first two parts.

Project  Gravity: Just as gravity is one of the four basic forces of nature, Gravity will provide a very important part of our future. Uniblue already relies on Python, HTML/CSS, JavaScript for its products. Ten years ago, this was a very brave decision. In the light of today, it looks like more than prophetic. So already build our product pretty much in a hybrid way for a decade. But we need to expand and react on new currents on the market. So, Gravity will build the base of our client infrastructure. Gravity has its requirements collected and sees now the phase of looking into different implementation options.

Everything we do needs to support the long term vision that our company has. It also needs to align to the bullhead of VP asking for cloud thinking: Loosely coupling, atomic small parts that can grow and shrink dynamically, ability to survive the chaos monkey…

So much for today while I could talk on for hours sometimes doing things is more interesting than talk about it 😉 Only one more thing: If you would like to be part of this, shoot me a line 😉




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.




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.



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…



DG Code Analyzer your software…


wie komme ich zum Code Analyzer?? Klarer weise beginnt alles auf der Website des Developer Gardens. Dort findet man einen LogIn-Button:

Step1_LoginDort erstmal mit seinem Konto anmelden. Danach erscheint dort der neue Link My Account. Wenn ich dem folge, kann ich Dienste ein-/ausschalten.

Step2_AccountManagementDort auf API-Management. Als neues Element seit Gestern erscheint Code Analyzer:

Step3_Code AnalyzerDamit kann ich den Dienst ein-/ausschalten. Wie man sieht, ich habe ihn bereits eingeschaltet (you guessed). Über den Link Config kann ich meinen Plan wählen. Ich arbeite derzeit auf dem freien Angebot.

Step3_ConfigDort findet sich auch der Hyperlink zum Dashboard, über das man Code hochlädt nd die Scan-Ergebnisse ansehen kann. Der Link lautet

Viel Spaß damit…



Man kann alles aus mindestens 5 Richtungen betrachten…


gerade gelernt:


Jedes Thema kann aus mindestens 5 Richtungen betrachtet werden:

E wie Economic – Die betriebswirtschaftliche Seite, Gewinne, Verluste, Kosten…

T wie Technical – Die technische Machbarkeit, Aufwände, Notwendigkeiten…

H wie Human – Die zwischenmenschliche Seite, Gefühle…

O wie Organizational – Wie muss meine, die andere Organisation aufgestellt sein, um dies erfüllen oder genießen zu können

S wie Social – Auswirkung auf Umwelt, Gesellschaft, Konkurrenten, Komplementäre…

Denkt mal drüber nach…




Web Summit in Dublin


ich bin derzeit auf dem Web Summit in Dublin. Es werden eine unglaubliche Menge an Startups vorgestellt – es könnte einem wirklich schwindelig werden.

Eine sehr interessante Beobachtung sind die vorherrschenden Themen: Payment, Gamification, Social Networks für alles mögliche…

Morgen darf ich auf die Bühne und werde ein wenig darüber sprechen, welche Erfahrungen wir gemacht haben beim Thema Web APIs.

So, jetzt gehe ich mal den Gründer von Skype kucken…




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