Project Holarchy

The Starting Situation

I was the engineering lead and had a pretty decent team of developers, architects, and UX designers around me. The company had an unhealthy love affair with SCRUM, so productivity and employee satisfaction was low, but we fixed that.
The company was an established one. It had products on a market which were sold using ecommerce at its best. Online ad campaigns and affiliate partners drove traffic, the fulfilment chain was all online and highly automated. From a performance marketing point of view, we lacked the latest and greatest in comparison to what mobile apps using Flury or comparable tools were able to do but this was a solvable problem.
The major problem was the shrinking overall market that made some competitors react in interesting ways: Some of them simply abandoned it. The products targeted on Windows clients only and its features got implemented into new Windows releases aka the software got obsolete.
The vision of the company – also never formulated in this way – could be summarized to “help consumers manage and organize their digital environment”. When it started, the digital environment pretty much was the PC. But this is no longer true.

The Vision

Today it starts from your smartwatch, over mobile phones and tablets, notebooks, PCs, TVs, up to your cleaning robots, the car and home. All of them are digital and smart in their own respect but function only in silos. It was obvious that the industry would form working groups to enable communication between these silos as happened with Google Weave for example. But it was also obvious that this would take a long time and competitive standards would exist for a long time which is the rationale behind Deutsche Telekom’s Qivicon. On top comes the move towards the economy of share.
Our vision was to build a holarchy – aka the project name Holarchy. A holarchy is a system of diverse systems that react as a whole more intelligent and capable than its parts alone. A typical biotope is an example. As such the holarchy provides some interesting aspects such as adaptability to environment changes or ability to grow and shrink.
The vision here was that each device is part of your personal holarchy as well as pure cloud based services. The holarchy would treat devices as sensors, actors and agents while cloud services would have been agents alone. The holarchy would act as biological systems act in playing with new systems to learn their capabilities as well as cross function between each other. The holarchy would have been a distributed system by nature that would survive the drop off of single members. Members would have had a trust level within the holarchy meaning that some highly individual and personal devices such as a mobile phone would have been higher trusted as a vehicle from the car sharing which was obviously only temporarily part of the holarchy. So the ability to issue certain requests into the holarchy or holding certain data points belonged to the trust level of the device.
This was a brave vision and while all parts for its implementation were on the horizon (e.g. IBM Watson was just announced), it was a big thing. So we started to work towards it while extending our current product base. We did a platform that spanned several clients. We developed features using machine learning. We build a data collection mechanism that would help us to understand our customers better. Lots of stuff we did.
But the owners decided otherwise.

Not Brave Enough??

The vision was dropped due to financial issues with the current product set. The strategy was to fix this by concentrating on what had worked for decades. In a way I can totally understand this strategy and while it would not have been mine I helped executing it as far as I was needed.
But it nagged me. I was legally and morally bound not to pursue with this idea. I made some suggestions on different ways to save the team. In the end it did not turn out.
So, I see now companies like or projects like and think, this could have been us. Some of it are building blocks for our idea, some are comparable long term in their vision and got founded. But I did not go this route…

My Thinking

I was not brave enough to do this because…

  1. No way of bootstrap. For this, my personal wealth was by no means big enough. I would have needed external investment. But I would have been a large chunk of this investment as my monthly personal cash flow would have been significant.
  2. I had no network within the VC scene and no time to build it.
  3. Malta. It is a great place to live and has a lot of talent. Prices are affordable but the investments available are simply magnitudes too small to drive something like that. These types of investments you only get in London, Silicon Valley, maybe Berlin…

So, I decided not to go for it…

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