Abstract

One of the key aspects of the software architectures is the choice of the decomposition principle – how the software is divided into parts and via which interfaces these parts communicate to each other. There are several factors influencing the decomposition of software, some of them are technical or logical by nature, others are not related to computer science (such as politics, time and budget constraints, etc). In this post, I’m discussing yet another factor influencing the software architectures.

Prior Work

M. Conway stated in 1967:

Organizations are to produce software architectures which are copies of the communication structures of these organizations.

Before reading this law, I didn’t know that software architecture can be influenced by factors not related to its purpose (stated in technical and business terms). Even after reading it, I was sure that it was just some cynical rant and in reality, most of architectures are not influenced by it. I was wrong and you were right, Mr. Conway.

Still, I think I have noticed yet another non-CS factor influencing architectures – unrelated to politics and organizational charts.

The Law

Software architectures are decomposed using the same interfaces between the modules, that the software developers are using to communicate with their computers.

Examples

The punch cards generation

Software developers who have used punch cards as the primary user interface to their computers, tend to think in terms of memory maps. You can in fact visualize the memory map of computer code by putting several stacks of punch cards on top of each other in the right order. So, the typical interface between the modules either uses some well known RAM address location to pass parameters and to receive the results, or uses concepts like stacks or decks or ring buffer, which can also easily be modeled using the punch cards.

Typical programming language: Assembly.

Typical architecture decomposition tool: a big piece of paper hanging on the wall representing the memory map, with pencil marks on it defining the usage of each memory cell.

The command line generation

Software developers who worked with terminals in the command line see their computers as something accepting a command with some parameters. So their typical programming language is C – a C function is more or less a command with some parameters. In the UNIX world it is indeed often the case that an API C function and the command line executable bear the same name, so having learned how to use it in the shell you could easily use it exactly the same way in your C program.

Typical programming language: C

Typical architecture decomposition tools: structured programming, functions, modules with several related functions, ony some of them are publicly available to other modules and build the formal “interface” of the module that can be statically checked by the linker.

The GUI generation

Software developers who think about computers as something having a GUI, tend to think in terms of objects and containers of objects. The desktop is a container of windows, and each window is a container for other UI elements, and an UI element is a container of methods that are to be executed on mouse click.

Typical programming language: Smalltalk, C++, Java, C#, a lot of others

Typical architecture decomposition tools: OOP, polymorphic classes with virtual methods and inheritance. The modules can now contain several classes, and only some of them are publicly available to other modules. There is a granular control of what parts of software are visible to whom and what can be overridden. One or several modules can be put together in a package, and be installed and managed by package managers. They are versioned, have explicit dependency tracking, and semi-automatic documentation.

The web generation

Software developers who spend most of their time in the web browser or in the mobile apps like chats and social networks, tend to think in terms of hosts and resources available on that hosts.

Typical programming language: NodeJs, PHP, but actually they don’t matter that much any more

Typical architecture decomposition tools: RESTful web services (like web pages) and Message Busses (like Chats). Just like the computer device doesn’t matter for the web generation (as they interact not with their device, but with some web site somewhere in the cloud), their software can both run in a 1 inch by 1 inch small device on their wrist, or have its parts running in 10 different countries all around the globe – without changing anything in the architecture.

The generation Future

Observing the exponential growth of artificial intelligence and virtual reality, we could assume that the next generation of software developers will neither interact with a computer, nor interact with some internet resource. Instead, their own cognitive abilities will be augmented by silicon-based intelligence and some combination of local and global information networks. We can imagine that this augmentation could be seamless, so that they don’t even recognize, whether their order of a salad instead of a burger was their own decision, or an advice of their health monitor, worried by the blood sugar levels. The will not interact with any hardware, software or resource – these things will be just parts of the peoples personalities.

Typical programming language: actually, not a programming language, but a machine learning framework. Probably, something implementing the Neural Turing Machine.

Typical architecture decomposition tools: something from the areas related to AI psychology, AI parenting, AI training, education, self-control, self-esteem etc.

Ich habe schon mal gehört, wie einige deutsche Betriebe als Zombieland bezeichnet werden. Früher habe ich immer gedacht, die Bezeichnung würde nur darauf anspielen, dass zu viele Vorruheständler beschäftigt sind und dass alles so langsam und tollpatschig abläuft.

Je mehr Unternehmen ich aber detailliert kennenlerne, desto mehr weitere Ähnlichkeiten ich finde.

Einheitlichkeitszwang

Zombies werden ja von einem Nekromanten gesteuert und bewegen und verhalten sich also einheitlich. So auch in einem Zombieland-Betrieb: es wird auf Teufel komm raus dafür gekämpft, dass alles einheitlich ist. Und das trotz des gesunden Menschenverstandes, denn es ist ja offensichtlich, dass je flexibler man auf persönliche Befindlichkeiten und Anforderungen jedes einzelnen Mitarbeiters eingeht, desto produktiver und motivierter sie sind. Als Scheinbegründung wird entweder vorgegeben, dass es zu viel Aufwand sei, jeden persönlich zu managen. Das zählt nicht, weil große Teams immer in kleinere aufgeteilt, und die Zuständigkeiten delegiert werden können. Oder es wird behauptet, dass die Einheitlichkeit von Prozessen, Abläufen und Zielen das einzig faire wäre. Das widerspricht dann aber nicht nur dem normalen Menschenverstand, sondern allen Best Practices, die in der Rechtswissenschaft existieren. Das Gesetz soll für alle gleich sein, nicht die Rechte und Pflichten! Die Gesetzgebung bemüht sich nämlich sehr wohl darum, dass Menschen in unterschiedlichen Ausgangssituationen auch unterschiedliche Ansprüche und Verpflichtungen haben.

Das aggressive Zombiewerden

Zombies greifen gesunde Menschen an, damit daraus weitere Zombies entstehen. Das ist im Interesse des Nekromanten, denn er bekommt eine Situation, in der seine Macht automatisch größer wird. Für gewöhnlich geht die Zombie-Gefahr von einer Abteilung oder einem Standort aus. Gesunde Teile des Unternehmens, die mit Zombies zusammenarbeiten müssen oder wollen, werden nach und nach zombiesiert. Das passiert zum Beispiel auf Terminen mit 20 Beteiligten, die mehrere Tage dauern und wo eine Fragestellung diskutiert wird, die innerhalb einer Stunde von 3 Menschen beschlossen werden kann. In Wirklichkeit geht es auf solchen Terminen darum, dass Zombies die Gehirne von ihren gesunden Kollegen auffressen.

Üblicherweise gibt es auch keine Möglichkeit, einen Zombie zu heilen – zumindest so lange der Nekromant an der Macht ist. Gesunde Menschen wehren sich, entweder indem sie sich von den betroffenen Teilen der Firma abschirmen, oder indem sie die Firma verlassen.

Unfreiheit

Zombies treffen niemals ihre eigene Entscheidungen, sondern setzten die Entscheidungen von den Vorgesetzten um. Damit Zombies unter Kontrolle gehalten werden können, bekommen sie keinerlei wichtigen Informationen darüber, was im Betrieb passiert. Jegliche wichtigen Änderungen und Entscheidungen werden unter vorgehaltenen Hand, geheim, von einem kleinen Gremium von führenden Nekromanten beschlossen.

Fehlende Produktivität

Niemand kann einen Zombie vorstellen, der mal etwas konstruktives oder produktives tut – ein Haus baut, eine Straße sauber macht oder einen wissenschaftlichen Experiment durchführt. Die meiste Zeit verbringen Zombies damit, die gesunden Abteilungen anzugreifen, sich von ihrem Nekromanten indoktrinieren lassen, oder mit Vortäuschung einer produktiven Tätigkeit.

Wenn eine Webseite innerhalb einer Woche entwickelt und live genommen wird, sprechen wir über eine normale Produktivität. Wenn es 4 Wochen dauert, kann es daran liegen, dass das Team zu wenig kompetente Mitarbeiter hat oder ständig von anderen Aufgaben abgelenkt wird. Wenn man aber die gleiche Seite 12 Monate baut, dabei Tonnen von Dokumentation und Tests produziert, Dutzend Male quer durch Deutschland zu notwendigen Abstimmungen fährt, und dann trotzdem nicht live geht, weil noch die Zuarbeit von 8 weiteren Teams nötig ist, und die Software-Architektur der gesamten Firma angepasst werden müsste – dann weißt man, was man hat.

Ausweg

Wir in IT Bereich haben vergleichsweise viel Glück damit, dass nur wenige Menschen sich damit abfinden können, Zombie zu werden. Es ist in unserem Job normal zu erwarten, dass man jeden Tag etwas Produktives tun kann – zum Beispiel eine Software erstellen, die der Firma ein bisschen hilft und die auch die Welt etwas besser macht.

Und obwohl ich meinen aktuellen Arbeitgeber nicht schönreden möchte und wir auch hier und da Zombie-Befall haben, muss ich ehrlich sagen, dass ich letzte Woche viel Spaß an sehr kreativen Arbeit in einem gesunden Team hatte, und es nicht abwarten kann, morgen wieder zur Arbeit zu kommen, um mein kleines Projekt abzuschließen und mit den Kollegen zu besprechen.

Shameless Plug: we’re hiring

Deutschland steuert auf seinen Untergang zu, weil hier die Digitalisierung scheinbar nur aus diesen zwei Teilen besteht:

• flächendeckendes schnelles Internet,
• mehr PC in den Schulen.

Und das Problem besteht nicht einmal darin, dass es zunehmend weniger Bedarf an Internet auf dem Land gibt, weil mehr und mehr Menschen in die Stadt ziehen. Und nicht darin, dass es nicht mehr zeitgemäß ist, PC als öffentliche Kommunikationsmitteln anzusehen: sie sind mittlerweile so persönlich wie Zahnbürste, so dass man die Nutzung von eigenen PCs und Handys in der Schule zulassen sollte, statt das Geld von Steuerzahler für schuleigene PCs auszugeben.

Das eigentliche Problem ist, dass die Digitalisierung eine Revolution der Gesellschaft ist – viel größer, als die Erfindung von Buchdruck war – und dass die Politiker in Deutschland das nicht begreifen.

Die Erfindung von Buchdruck spaltete die Kirche (was so “nebenbei” den 30-jährigen Krieg mit 6 Mio. Toten verursachte) und war eine Voraussetzung für die nachfolgende Bürger-Revolutionen und Untergang von Monarchien, weil Menschen durch die Alphabetisierung und Entstehen vom Massen-Bildungswesen nicht mehr so leicht regierbar geworden sind. Die Wissenschaft entwickelte sich, was die enorme Weiterentwicklung von Medizin und Technik zur Folge hatte. Viele etablierten Geschäftsmodelle und Berufe gingen unter, weil im Prinzip jeder alles lernen konnte, sobald es ein Lehrbuch dazu gab.

Bücher gab es auch vor dem Buchdruck. Der Buchdruck hat nur die Verbreitung von Büchern billiger gemacht. Die Digitalisierung ist gewaltiger. Nicht nur ist die Verbreitung von Informationen praktisch kostenlos geworden. Sondern auch das Erstellen von der Information hat sich verbilligt. Viele Informationen lassen sich automatisch durch Algorithmen, teilweise auch mit K.I. oder neuerdings mit IoT erstellen. Wir steuern auf die Welt zu, wo jeder Zugriff auf alles haben kann, was überhaupt möglich zu erfahren ist.

Und das wird alles noch einmal umkrempeln (oder, wie man in Silicon Valley sagt, disrupten).

Nein, die Digitalisierung von Massenmedien ist nicht, die Web-Seiten mit elektronischen Kopien von Zeitungen zu erstellen. Eine Zeitung als solche ist nur deswegen entstanden, weil es billiger war, mehrere Artikel auf einem großen Blatt Papier zu drucken und zu liefern, als die Artikel einzeln zu verbreiten. Das ist nicht mehr so. Somit abonniert man keine Zeitungen mehr, sondern einzelne Autoren. Und ja, man tut es auf Facebook oder Youtube, und nicht auf faz.de.

Nein, die Digitalisierung vom Finanzamt heißt nicht, dass man die gleichen Formulare auch online abschicken kann. Sondern, dass man die Werbungskosten und die außergewöhnliche Belastungen direkt in seinem Online-Banking an das Finanzamt weiterleitet. Und dass man Sekunden später eine Steuererstattung hierzu überwiesen bekommt.

Nein, die Digitalisierung von Bildung besteht nicht darin, Schulen zu digitalisieren, sondern sie abzuschaffen! Nichts ist schlimmer für die Kinder, als eine Massenausbildung. Millionen von Menschen regen sich wegen Massentierhaltung auf, schicken aber ihre Kinder artig in die Schulen, wo ihr Gehirne mental vergewaltigt werden. Das aktuelle Schulsystem ist schlimm für die schnelldenkenden Schüler, die sich zu Tode langweilen müssen. Es ist aber viel schlimmer für die langsamdenkenden Kinder und für Legastheniker, die ständig frustriert sind und irgendwann anfangen, sich zu schämen und sich als vermeintlich “minderwertig” abzuschreiben. Stattdessen wird jedes schulpflichtige Kind an MOOC Kursen teilnehmen, in dem Tempo und Umfang, die für es am optimalsten ist, und die digitale Nachweise dessen an die Jugendämter schicken. Das Erlernen von praktischen Fertigkeiten und die Beherrschung von dem eigenen Körper (Sport, Tanzen, Malen, Hobeln, Dechseln, Mauern, Radfahren, Reitern usw) gehört meiner Meinung nach nicht zur Allgemeinbildung und kann auf Kursen oder ggf. auf Praktika in den Firmen erlernt werden.

Nein, die Digitalisierung von privaten Unternehmen besteht nicht nur aus papierlosem Büro und Verteilung von Informationen über Slack statt mit einem Aushang. Stellt euch vor, die Arbeitnehmer würden die Möglichkeit erhalten, vor der Einstellung sowohl in die Firmenbücher zu schauen, als auch zu lernen, wie ihre zukünftige Chefs ihre Entscheidungen treffen und sich generell verhalten. Mit nur ein wenig mehr Transparenz würden wir all die Office-Politiker dort schicken, wo sie hin gehören – in die Geschichtsbücher.

Nein, die Digitalisierung von Demokratie ist nicht, dass jede Partei eine Web-Seite mit ihrem Programm erstellt. Die Parteien sind nur deswegen entstanden, weil die Wahl-Kampagnen für Einzelpersonen zu teuer sind. Sie sind zu teuer, weil a) es für die Wähler so kompliziert und aufwendig ist, wählen zu gehen und b) weil die Wähler für mehrere Jahre eine Wahl treffen müssen. Das erste Problem ist mit Online-Wahlen bereits gelöst. Das zweite Problem könnte gelöst werden, wenn man nicht mehr jede 4 Jahre, sondern täglich jeden Politiker (ab)wählen kann. Das klingt kompliziert für den Wähler, ist es aber nicht, weil er nicht mehr riesige mehrjährige Programme lesen muss, sondern nur noch das Geschehen der letzten Woche bewerten muss. Die Wahlen sind deswegen so selten, weil es früher zu teuer war, die Wahlzettel zu drucken, sie zu verteilen, dann sie wieder einzusammeln, zu zählen, die Wahlprogramme zu drucken, und verteilen usw. Das alles ist heute kostenlos möglich.

Und weil unsere Politik und unsere Gesellschaft gar nicht begreifen können (begreifen wollen???), wie gewaltig die Digitalisierung ist, die überall in der Welt passiert und von manchen Global Players auch entsprechend umfassend umgesetzt wird (z.B. in China), denke ich, dass wir uns auf die schlimme Zeiten und mehrjährige hybride Kriege einstellen müssen. Ja, irgendwann geht die heutige Generation von Politikern und kommt die nächste, die ihre Pubertät online ausgelebt hat. Aber dann wird es unaufholbar zu spät.

Und es hilft nichts, Milliarden von Steuergelder für Förderung von K.I. auszugeben. Denn das Hauptproblem ist bei uns nicht, dass wir zu wenig K.I. haben, sondern dass niemand unter den Entscheidern bereit ist, es auch wirklich disriptiv einzusetzen.

Ich mag es nicht, wenn Begriffe falsch verwendet werden. Menschen, die sorglos mit Wörter ungehen, sind auch sorglos in ihrem Denkprozess, ziehen deswegen häufiger falsche Rückschlüsse und bringen sich und ihre Umgebung (also auch mich) unnötig in Gefahr.

Heute möchte ich über das MVP sprechen (Minimum Valiable/Viable Product).

Zunächst einmal ist es ein Product – also etwas, für was Kunden Geld oder Geld-Ersatz (z.B. Informationen, Leads, Traffic usw) bezahlen können. Also nicht etwas, wo die Kunden nur sagen können, sie hätten dafür sogar Geld bezahlt. Und nicht etwas, was die Kunden lieben, oder was sie gut finden oder den Freunden empfehlen. Nein. Ein MVP muss von den Kunden tatsächlich gekauft werden können – und wird dann auch tatsächlich geliefert und seiner Bestimmung nach verwendet. Wir merken uns: Fake Doors sind kein MVP, weil sie nicht gekauft und nicht geliefert werden. A/B Tests sind meistens auch kein MVP, weil sie kein Produkt, sondern nur eine Seite oder ein Feature des Produkts testen. Nur wenn man einen A/B Test so durchführt, dass man selbst ein eigenes Bier braut und es neben einem Markenbier in einen Ladenregal stellt und verkauft, und danach die Conversion berechnet, kann man über einen MVP sprechen.

Eine weitere Konsequenz, die wir uns merken sollten: wenn eine Organization zu viele Produkt-Managers beschäftigt, was meiner Erfahrung nach des Öfteren der Fall ist, verantwortet nur ein Bruchteil von denen ein Produkt. Solche Sachen wie Startseite, Login, Payment, Detail-Seite sind alle keine Produkte, weil sie von den Kunden nicht gekauft werden. Somit werden die Produkt-Managers zu den Feature-Managers degradiert und können eigentlich nur in seltensten Fällen MVPs entwickeln.

Dann gibt es auch dieses “Minimum Valuable”. Das Produkt Auto hat einen Motor, Räder und einen CD-Player. Ohne CD-Player wird dieses Produkt zu einem MVP. Ohne Räder oder Motor, wird das Auto womöglich auch verkauft (das ist dann die Frage des Preises), ist aber kein MVP, weil das Produkt hiermit nicht die Masse der Kunden trifft. Anders gesagt, wenn die Kundenbedürfnisse als eine mehrdimensionale Gauß-Kurve vorstellbar sind, beinhaltet das MVP die Features innerhalb einer Standardabweichung von dem Mittelwert – also nicht so viele Features, dass die Mehrheit der Kunden zufrieden sind (das wäre dann das klassische Produkt), sondern nur die Features, mit denen man mit dem geringsten Aufwand eine erhebliche Kundengruppe erreichen kann. Wir merken uns: wenn wir weniger Sprints haben, als nötig wäre, um etwas Vernünftiges sinnvoll zu entwickeln, wird das Ergebnis nicht automatisch zu einem MVP. Sondern womöglich zu einem Auto ohne Räder – etwas, was 0,3% der Menschen kaufen würden und ist somit kein valides MVP.

Und zu guter Letzt, gehört zu jedem Begriff auch die bestimmungsgemaße Verwendung. Wann setzt man ein MVPs ein? Man hat eine Produktidee und möchte testen, ob sie gut ankommt, ohne dabei Geld und Zeit für Marketing-Research und Umfragen, oder vollwertige klassische Produkte ausgeben zu wollen – in der Situation, wo Fake Doors keine aussagekräftige Testergebnisse liefern. Wir merken uns: wenn ein Fake Door ausreichend ist, soll man lieber es machen, weil MVP teurer ist, denn es muss gebaut und geliefert werden. Fake Doors können aber z.B. dann nicht eingesetzt werden, wenn Kunden zuerst eine kostenlose Version nutzen müssten, um überhaupt für sich das Bedürfnis zu entwickeln, so ein Produkt zu verwenden – bevor sie zu einer kostenpflichtigen Version geführt werden.

Es ist wichtig zu verstehen: MVP ist deswegen ein Produkt, weil man eben eine Produkt-Idee damit testet. Soll eine Feature-Idee getestet werden, gibt es dafür andere Möglichkeiten: der klassische A/B Test oder eben die Fake Doors. Und anders herum: muss die Produkt-Idee nicht getestet werden (weil sie z.B. von der Konkurrenz bereits benutzt wird), braucht man auch kein MVP – nicht jede Produktentwicklung soll unbedingt eine MVP-Phase beinhalten.

Warum ist es mir wichtig, zwischen A/B Test und MVP zu unterscheiden? Wenn ein A/B Test erfolgreich ist, wird ein bestehendes Produkt um 3% bis 10% verbessert. Wenn ein MVP erfolgreich ist, bekommt man einen weiteren Standbein – ein weiteres Core-Business, was im Idealfall sogar unabhängig von den bestehenden Produkten funktioniert und so die Marktrisiken diversifiziert. Auch wenn 100% von einem MVP in Euro ausgedruckt weniger sein können, als die 3% von dem Core-Business, sprechen wir hier um ganz unterschiedliche Entwicklungen. Im ersten Fall will man mit viel Aufwand von 99,99% auf 99,999% aufsteigen. Im zweiten Fall geht man in die Breite und macht quick wins.

Die traurige Realität ist in Deutschland so, dass MVP sich fast zu einem Kargo-Kult avanciert hat. Man sieht sich nur so gerne als der zweite Steve Jobs, und möchte mit den gleichen Toys spielen, wie die Big Boys in Silicon Valley. Der beste Weg zur Besserung wäre, zunächst einmal mit sich selbst ehrlich zu sein und aufzuhören, seine eigene Deliverables als MVPs zu bezeichnen.

Five years ago I’ve written my definition of a software architecture and have compared two alternative architectural designs: Monolyth vs SOA. For each design, I gave its advantages and disadvantages.

Now, five years later, I’ve learned a little more and want to amend this topic.

It has turned out, that in the organizations in the Enterprise Autumn phase, many decisions are made not out of best fit for the situation, but purely due to political reasons. Besides, due to Murphy’s Law, some implementors of the architecture have achieved their level of incompetency.

This can lead to a situation when additional disadvantages (for the enterprise) can emerge, which are not intinsic to the chosen architecture, but are just results of a wrong practical implementation strategy or political processes. Therefore, when describing and comparing possible advantages and disadvantages of some architectural design, for a proper decision, you also have to take into account its possible atrocities.

Atrocities of a Monolyth

1. One usual atrocity of a monolytic application is the insisting on full re-test of the whole application on each and every release. Even though it is possible to retrieve the list of changed files and therefore exclude large parts of the application unaffacted by the change from retesting, people could reject that idea, thereby forcing many parallel developments to wait for a long time to be released,  as well as wasting the time of testers.
   To be able to decide about skipping some parts of the app from retesting, you need a) to know exactly what code is reused where, that is, you need to be able to know the source code of the whole app and be able to read code diffs quickly – not a skill that is completely impossible to learn (look at Linus Torvalds as an example) and b) want to take some minor risks (below 1% of chance) in order to facilitate more product lauches per year – something that people are told not to do, especially in the Enterprise Autumn phase, where the fear of the founders to damage the flywheel overweights their need to innovate.
2. Another atrocity of the Monolyth is reusing it for any other software made by the company. You want to develop a new product, quite different from the first one, to become a second flywheel? No problem, we will put it inside of the existing Monolyth, because well, we can reuse some unimportant code from there (like the “about us” page and the ORM framework). Thus, a chance is missed to create a completely new project, which is not dependent on the first one and therefore that can be deployed independently.

A properly implemented Monolyth tends to be eagerly and on every suitable occasion splitted into several interdependent Monolyths. Creating a copy of the app in another language? New Monolyth. Creating a new area of the app not tightly interconnected with the other parts? New Monolyth. Besides, a properly implemented Monolyth would aggresively defend all opinions asking for full re-test on each update.

Atrocities of SOA

1. M. Conway has stated the following law in 1967: “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” In case of the microservices, people would assign sub-teams to own one or several services. Because services are usually designed to be very small, as a result, changing one simple thing on the web site, requiring changing of several services, would make from it a huge project including very slow and expensive coordination of 3 teams (eg. 15 developers).
   This atrocity alone would lead to even longer time-to-market cycles compared to the monolyth. In a properly implemented SOA, every developer can develop any (or most) of the microservices, therefore, it is normal, for one team to change several services in just one week.
2. Another atrocity is the wish to make everything to be a RESTful microservice. Some reusable modules, cloud services and databases have other interfaces, be it RPC, Protobuf, AMPQ or proprietary protocols. These communication protocols are carefuly designed, sometimes in the course of several decades, to provide imporant run-time properties (eg. automatic failover and cluster management, reduced overhead on serialization and connection establishing, coonection pooling etc). There is not so many reasons to implement a REST wrapper around them.
   In a properly implemented SOA, RESTful services are usually introduced only due to these two reasons: a) we want to communicate to “fat clients” (eg. mobile apps, modern HTML5/jQuery apps) over the public Internet, or b) we have some important business logic, which cannot or should not be encapsulated in the database (eg. using stored procedures or views), so that we need to develop and host a separate service process anyway.
3. Yet another atrocity is that some teams would consider a microservice to be a deliverable (a completed piece of work, even a product), whereas a service is similar to one OOP class or package / module / assembly, that is a technical module, just a part of a product. You will never start creating a product with a service. In a properly implemented SOA, you will conceive and develop the UI and UX first, derive the API for the service according to the calls the frontend needs to made, and then use or develop the corresponding service or services.

Common atrocities

1. Over-Engineering. If you imagine quality to be a number from 0 to 100%, some people are unable or unwilling to deliver any given quality level. They can just give the level 0% or the level 100%. What real world business situation usually requires is the level of 60%, sometimes being dropped to 30%. A properly run software development organization can deliver any required level of quality.
2. Death by Security. If you imagine security to be number from 0 to 100%,… see above.
3. Checklist-oriented development. Some people do things described in the checklists, formal quality criterias or common conventions, without checking first whether these things matter in the particular situation, do they add up to some desired property of the software, or maybe even counter-productive?
4. Mandated Architecture. In the year 2018, it is impossible to mandate software architecture by a HiPPO, nor enforce it using architectural nazis running around with whips. If tried to do so, the architecture will invariably mutate to some of the atrocities described above, when implemented by the people who either a) don’t agree with it or b) don’t understand how exactly this architecture is going to solve their pains. A proper architecture is always something everybody unanimously (100%) agree to be The Good Thing to do, and usually it can only evolve from the trenches, not mandated from above.

Summary

In the year 1975 when I was just born, Frederick P. Brooks has already learned about software development enough to write his essay “There is no silver bullet”. Applying this principle to the architectures, one could say, any theoretical advantage of any architecture can be missed by a poor execution. Or, like Derek Sievers uses to say, idea is nothing, execution is everything.

Making decisions is important part of life. Good decisions can improve, bad decisions can ruin life. Historically, people have used their intuition to make decisions.

With the improvement of computing and data processing, people have gradually started to use data to measure decision quality and to improve it. In business setting, this is known as business intelligence. Some people are also using it to decide about their personal life.

With the raise of Big Data and AI, data is not only feed to humans to assist them making good decisions, but also AI systems, trained according to goals set by humans, have started to make decisions on their own, either without or with some very limited human involvement.

This all has changed the role of data and increased its value. Suddenly, we have to consider, how our own data is collected and processed. While nobody would mind sharing the fact they are smoking to the whole world only 100 years ago, people today would object against it, because they worry their health insurance company would use this data to make a decision and to increase the insurance fee.

If we want to infuence data-based decisions made about us, we have three ways:
1) not sharing relevant data about us,
2) having law preventing the use our data to make specific decisions, or
3) use our own data and make our own counter-decisions

In the example above, we either
1) stop sharing the fact we’re smoking to the world, or
2) we vote for law makers who will pass a law prohibiting health insurance companies to vary their fee from person to person, or
3) we use the data about the insurance company to find out that the surplus of extra fees gathered from smokers was spent to pay bigger bonuses to the management, and left this company to a competitor. This option would require laws forcing companies and governments to be reasonably transparent about their data, as well as availability of competition on the market.

Now, it is important to understand that data-based decisions don’t need to be always bad for us. As a non-smoker, I like the idea to charge them more than average for health insurance, and as an overweight person I’m ready to pay more than average myself. And I like that people with small income pay much less taxes. And it would be nice if the fee in my wrong parking ticket would consider the fact that in the 99,9% of cases I pay for parking my car. And I have stopped watched TV because I can’t stand this annoying, un-personalized and sometimes insulting advertisement – I really like the advertisements Facebook and Google are showing me.

So, to benefit from this kind of decision making, I need to share my data. Therefore I find it pity that current european law-making in this area is mainly focused on making sharing of data more harder and complicated.

If nobody would share data, nobody would get hurt by some data-based decision. But also nobody would benefit from it. So our digitalization level will remain to be blantantly low and our decisions will still be made by some guts feeling like in the stone age.

I don’t think it is reasonable trying to stop data sharing. They say, when the first cars hit the roads of the cities, and the first car accident deaths happened, the law makers have issued a law requiring a person with a red flag and drums to march in front of the car, to warn people and horses. I could imagine this could prevent deaths efficiently, but this has undermined the whole idea of driving cars.

Today, we as a society have accepted many thousends of car accident deaths and injuries per year, because the benefits cars provide to the people and to the economy have far overweighted the risks. I think, the same process will happen with our data.

We will be sharing our data, in the future, much more than we’re doing it now, willingly or unwilligly, and we will have to learn how to deal with it. Our law today prevents collection and storage of the data. The future law will concentrate instead on regulating the decisions that are being made based on the data, making it is illegal to make unfair decisions, and making the data of the decision-making entities reasonably transparent to the public.

Another issue I want to point out in the current EU legislation is the definition of so-called personal data. As we all know it is the data that identifies or can identify a person. Let’s say, an email address. If a website would store email addresses entered by their users, this information is considered to be personal data and is thoroughly regulated. But what is the risk of storing some email address in some database? If nothing else is stored there, the worst thing that could happen is that somebody would send some spam to this email address, or try to phish corresponding password.

But let’s now say, for instance, besides of the email address we would store the person’s income. Income is not personal data per se, so that no additional regulations would apply in this case. But the risk of abusing or leaking this information is much greater!

Another example: let’s now replace the email with the ip address, so now we have a table of ip addresses and their salaries. According to the German regulators (this is not in the GDPR itself) the ip addresses are personal data. But leaking of this information would lead to virtually no risk. Neither bad web site owners nor hackers have enough capacity to map ip addresses to real persons, at least not in a scalable way for massive amounts of the data. Still, according to the law, this data will be protected in the same way as the data containing email adresses.

My suggestion to that is to abandon the “personal” from the future regulations. There are just data owners, who share their data to somebody else, and this somebody else will have to comply to some set of rules (for example, must disclosure all the data used to make a specific decision), no matter what kind of data has been stored and processed.

These are the levers to open subway car doors:

If you pull them during the move, nothing happens, because they are locked for safety. Also, no indication to you as a user will be displayed. Also, there is no indication about whether they are currently locked or unlocked. If you are an experienced subway car doors user though, you can hear the sound of unlocking and then understand that you can now pull the levers.

And this is the button to open doors of the new subway car:

They have added a visual indication of whether the doors are locked or unlocked, the LEDs around the button. But there is more in it, the feature that I would argue belong to the new generation of the Smart UX, a combination of Smart Data and UX.

If you look at the old lever system from the data perspective, the user is giving you the signal about his intention to open the door. If the door is locked, safety of the user is ensured by not opening the doors, but also his signal is not used and it gets lost.

As for the new button, you can push it also when the car is moving and the door is locked. The door will use this signal to understand your intention, to remember it, to indicate to you using a special combination of the lighting LEDs that it knows you want to exit, to wait until the car stops at the next station, and then to unlock itself automatically.

Not only the Smart UX is more comfortable for the user because it reduces the amount of interaction required to open the doors, as well as the amount of knowledge about the current lock state required to be able to operate the doors successfully. But also the robotic system shows more respect to its human user by acknoledging his presence, remembering that the user wasn’t successful at the last interaction, and being polite and helpful by trying to predict his next actions.

I’m not saying that the new button is in any aspect better than the old levers. It could be that the levers are easier to understand by people who maybe arrive from 3rd countries, never have seen round buttons before and don’t come to the idea that they can be pressed. And the levers are more similar to usual door handles and thus easier to understand by that category of people. Also, in case of a malfunction, the doors have to be unlocked and pushed aside manually and mechanically – operating the levers could be easier than trying to open the doors without any handles.

What I’m saying is that a modern, Smart UX considers any user interaction as a data signal, exposing the true user intention, and it doesn’t waste any single bit of this signal, but uses it to build up a mental model of the user intention and to act according to it.

In my previous post I’ve explained why I think you should learn machine learning and promised to share my experiences with its unsupervised part.

The unsupervised machine learning has a mystical attraction. You don’t even bother to label the examples, just send them to the algorithm, and it will learn from them, and boom – it will automatically separate them to classes (clustering).

When I was studying electrical engineering, we’ve learned about the so called optimal filters, which are electrical circuits that can extract the useful signal from the noise, even though the noise is 100 times stronger than the signal, so that a human eye cannot even see the signal. This was like a magic, and a similar magic I have expected in this case: I would pass the examples to the clustering algorithm, and it will explore the hidden relationships between the data and give me some new, unexpected and useful insights…

Today, having tried it, I still believe that some other algorithms (maybe deep learning?) are able to produce such a magic (because well, you should never stop believing in magic), but my first impression was somewhat disappointing.

The very first thing the clustering algorithm wanted to know from me, is how many clusters it should look for. Pardon me? I’ve expected that you will find the clusters and tell me, how many clusters are there in my data? If I have to pass the number of clusters beforehand, it means I have to analyse the data to find out its inherent clustering structure, and it means I have to perform all that work what I’ve expected to be performed magically by the algorithm.

Well, it seems that the state of the art of current clustering algorithms indeed cannot find clusters autonomously and fully unsupervised, without any hint or input from the user. Some of them don’t require the number of clusters, but need some equivalent parameter, like the minimum number of examples needed in the neighborhood to establish a new cluster. But well, on the other case, this still allows for some useful applications.

One possible use case could be automatic clustering per se: if your common sense and domain knowledge tell you that the data has exactly N clusters, you can just run the data through the clustering algorithm, and there is a good chance that it will find exactly the clusters you’ve expected: no need to define all the rules and conditions separating the clusters manually. Besides, it will define centroids or medoids of each cluster, so that if new, unclastered objects are added daily, you can easily assign them to existing clusters by calculating distances to all centroids and taking the cluster with the shortest distance.

Another use case would be, if you don’t really care about the contents of the clusters and the clusters aren’t going to be examined by humans, but rather use clustering as a kind of lossy compression of the data space. A typical example would be some classical recommendation engine architectures, where you replace the millions of records with some smaller number of clusters, with some loss of recommendation quality, just to make the computation task at hand to be feasible for available hardware. In this case, you’d just consider how many clusters, at most, your hardware can handle.

Yet another approach, and I went this way, is to ask yourself, how many clusters is too little and how many clusters is too many? I was clustering people, and wanted to provide my clusters to my colleagues and to myself, to be able to make decisions on them. Therefore, due to well-known human constraints, I was looking for at most 7 to 8 clusters. I also didn’t want to have less than 5 clusters, because intuitively, anything less in my case would be underfitting. So I’ve played with parameters until I’ve got a reasonable number of clusters, and clusters of reasonable (and understandable for humans) content.

Speaking of which, it took a considerable amount of time for me to evaluate the clustering results. Just like with any machine learning, it is hard to understand the logic of the algorithm. In this case, you will just get clusters numbered from 0 to 7, and each person will be assigned to exactly one cluster. Now it is up to you to make sense of the clusters and to undestand, what kind of people were grouped together. To facilitate this process, I’ve wrote a couple of small functions returning to me the medoids of each clusters (i.e. the single cluster member who is nearest to the geometrical center of the cluster, or in other words, the most average member of the cluster), as well as average values of all features in the cluster. For some reason, most existing clustering algorithms (I’m using scikit-learn) don’t bother of computing and giving this information to me as a free service, which, again, speaks about the academic rather than industrial quality of modern machine learning frameworks.

By the way, another thing that was not provided for free was pre-scaling. In my first attempts, I’ve just collected my features, converted them to real numbers, put them in a matrix and fed this matrix to the clustering algorithm. I didn’t receive any warnings or such, just fully unusable results (like, several hundreds of clusters). Luckily for me, my previous experience with supervised learning had taught me that fully unusable results normally mean some problem with the input data, and I’ve got to the idea to scale all the features to be in the range of 0 to 1, just like with the supervised learning. This had fixed this particular problem, but I’m still wondering, if the clustering algorithms usually cannot meaningfully work on unscaled data, why don’t they scale data for me as a free service? In the industrial grade software, I would rather needed to opt-out of the pre-scaling by setting some configuration parameter, in case I wanted to turn it off in some very unique and special case, than having to implement scaling myself, which is the most common case anyway. If it is some kind of performance optimization, I’d say it is a very, very premature one.

But I digress. Another extremely useful tool helping to evaluate clustering quality was the silhouette metric (and a framework class implementing it in scikit-learn). This metric is a number from 0 to 1 showing how homogeneous the cluster is. If a cluster has silhouette of 0.9, it means that all members of this cluster are very similar to each other, and unsimilar to the members of another clusters.

Least but not last, clustering algorithms tend to create clusters for many, but not for all examples. Some of the examples remain unclustered and are considered to be outliers. Usually, you want the clustering algorithm to cluster the examples in a such way that there will me not too many outliers.

So I’ve assumed the following simple criteria:

• 5 to 8 clusters
• Minimal silhouette of 0.3
• Average silhouette of 0.6
• Less than 10% of all examples are outliers

and just implemented a trivial grid search across the parameters of the clustering algorithm (eps and min_samples of the DBSCAN, as well as different scaling weights for the features), until I’ve found the clustering result that suited all of my requirements.

To my astonishment, the results corresponded very well to my prior intuitive expectations based on some domain knowledge, but also have created a very useful quantitative measure of my previous intuitive understanding.

All in all, unsupervised learning can be used to gain some benefits from the data, if you don’t expect too much from it. I think, to gain more business value, we have to make the next step and to start a project including deep learning. In USA and China it seems to be that virtually everyone is doing deep learning (I wonder if Bitcoin farms can be easily repurposed for that), but it Germany it is rather hard to find anyone publicly admitting doing this. Although the self-driving cars of German manufacturers, already existing as prototypes, would be impossible without some deep learning…