KomplexIm Beitrag mit Matthias Schrader hatte ich schon kurz anklingen lassen, dass ich eine spannenden wissenschaftlichen Ansatz gefunden habe, der das Versagen großer (alter) Organisationen bei digitalen Geschäftsmodellen erklären könnte. Einen ähnlichen Erklärungsversuch gab es auch im Artikel “Die ergebnislose Suche nach einem CTO”. Darin habe ich das Portersche Modell der Wertschöpfungsstufen verwendet, um zu zeigen, dass klassische Unternehmen gar nicht für digitale Modelle gemacht sind. Nun habe ich aber mit dem Gesetz von Conway einen viel schöneren Ansatz gefunden, der seinen Ursprung in der Informatik hat. Das Gesetz besagt:

Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.”

Das klingt etwas kompliziert, ist aber einfach zu übersetzen: Systeme (Software, Geschäftsmodelle…) sind ein Spiegelbild der Kommunikationsstrukturen ihrer erstellenden Unternehmen. Stark verkürzt würden große Unternehmen deren Abteilungen sich permanent streiten per se Geschäftsmodelle bauen die nicht effizient funktionieren. Die Idee großer Unternehmen die besten Köpfe verschiedener Abteilungen (Marketing, Vertrieb + IT) an neuen Geschäftsmodellen arbeiten zu lassen, würde sich damit zerschlagen. Das Gesetz ist bisher nur in wenigen Fällen getestet worden, aber die verfügbaren Studien dazu sind sehr vielversprechend. Ein Forscherteam hat sich die Entwicklung von Windows Vista angeschaut und kann das Gesetz bestätigen.

In our case study, the organizational metrics when applied to data from Windows Vista were statistically significant predictors of failure-proneness. The precision and recall measures for identifying failure-prone binaries, using the organizational metrics, was significantly higher than using traditional metrics like churn, complexity, coverage, dependencies, and pre-release bug measures that have been used to date to predict failure-proneness. Our results provide empirical evidence that the organizational metrics are related to, and are effective predictors of failure-proneness

Diese Beobachtungen haben ihren Ursprung in der Informatik und sind aus meiner Sicht auf “digitale” Geschäftsmodelle übertragbar, weil die gleichen Regeln für sie gelten. Große Organisationen haben das Problem erkannt und versuchen nun ihre IT Abteilungen neu zu sortieren. Immerhin ein Anfang, auch wenn die Neusortierung im Vorstand anfangen müsste. Live verfolgen kann man das zur Zeit im Refactoringsprojekt bei Galeria Kaufhof, die mit den Möglichkeiten von SAP Hybris nicht mehr zufrieden waren.

Die einzelnen Domänen werden dabei von externen, spezialisierten Teams zusammen mit Galeria Kaufhof-internen Programmierern entwickelt. Dabei ist jedes Team für eine einzelne Domäne verantwortlich. Für das Zusammenspiel zwischen den Systemen (Makroarchitektur) gibt es einige Regeln: Um eine lose Kopplung zu gewährleisten darf es z.B. kein fachliches Code Sharing (für vermeintlich gemeinsame Datenklassen) geben, genausowenig eine gemeinsame Datenhaltung. Die Kommunikationen zwischen den Systemen erfolgt ausschliesslich über REST-Schnittstellen.

Dieses Vorgehen lässt sich zur Zeit bei vielen großen Unternehmen beobachten, weil man anders die “EDV” nicht mehr in den Griff zu bekommen scheint. Was aber auf den ersten Blick modern erscheint – die komplette Hingabe an das Prinzip Microservices – ist aus Sicht einiger vorausdenkender Informatiker schon wieder veraltet. Martin Fowler, bei dem ich auch zuerst über Conway gelesen habe, schreibt in einem sehr spannenden Beitrag, dass eine Architektur mit vielen Schnittstellen (Microservices), einem gut designten Monolithen hinsichtlich ihrer Leistungsfähigkeit mittelfristig unterlegen ist.

So my primary guideline would be don’t even consider microservices unless you have a system that’s too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don’t try to separate it into separate services. The complexity that drives us to microservices can come from many sources including dealing with large teams, multi-tenancy, supporting many user interaction models, allowing different business functions to evolve independently, and scaling. But the biggest factor is that of sheer size – people finding they have a monolith that’s too big to modify and deploy.

productivity

Ja was denn nun? Monolith, kein Monolith, agile Teams vs. ein eng gesteuertes Team…. und es gibt doch auch erfolgreiche Open Source Software die in der Regel in stark verteilten Teams erstellt wird. Das stimmt alles, aber welche führende E-Commerce Firma weltweit ist als Open Source Projekt entstanden? Und wer genau hat behauptet, dass es bei Google & Co. so läuft? Es kommt halt drauf an was man will, wie es Sam Newman richtig zusammenfasst.

Organizations for a few years now have understood this link between organizational structure and software they create, and have been embracing new structures in order to achieve the outcome they want. Netflix and Amazon for example structure themselves around multiple small teams, each one with responsibility for a small part of the overall system. These independent teams can own the whole lifecycle of the services they create, affording them a greater degree of autonomy than is possible for larger teams with more monolithic codebases. These services with their independent concerns can change and evolve separately from one another, resulting in the ability to deliver changes to production faster. If these organizations had adopted larger team sizes, the larger monolithic systems that would have emerged would not have given them the same ability to experiment, adapt, and ultimately keep their customers happy.

Wie halten das die großen und erfolgreichen Digitalunternehmen? Bonkersworld hat sich die Mühe gemacht die Organisationsstruktur von Google, Amazon und Co. aufzumalen. Man beachte die Kommunikationskultur zwischen den Microsoft Teams. Das erklärt für mich durchaus, warum MS Office und die Cloudwelt noch nicht wirklich gut zusammenpassen.

Orgchart

Wenn man dem Gesetz von Conway folgt, dann dürfte gemäß diesen Orgcharts insbesondere Apple in der Lage sein wenige, aber schlagkräftige Applikationen zu entwickeln, aber das ist ggf. etwas zu viel hineininterpretiert. Die grundsätzliche Idee hinter dem Gesetz finde ich sehr spannend und je stärker Unternehmen auf Technologie als Wertschöpfungstreiber setzen, desto stärker dürften sich auch die Organisationen dahinter nach deren Prinzipien ausrichten. Unser CTO Fabian schwört bei Spryker auf die Einhaltung der SOLID Prinzipien. Dabei geht es um die Optimierung von Software Qualität und je mehr ich darüber nachdenke, desto interessanter wird die Übertragung dieser Prinzipien auf unser Unternehmen. Das “L” in SOLID steht zum Beispiel für das Liskovsche Substitutionsprinzip, das sich um die Vererbungseigenschaften von Klassen in der objektorientierten Programmierung kümmert. Ich werde das bei der nächsten Mitarbeiterbesprechung als Vorschlag einbringen. Man kann ja nie wissen.

Das E-Commerce BuchMehr zu den Themen Organisation, E-Commerce Strategie und zur Bewertung diverser digitaler Geschäftsmodelle finden sich im Juni 2015 erschienenen „Das E-Commerce-Buch“ von Holger Schneider und Alexander Graf. Bereits nach kurzer Zeit führt das Buch diverse Bestseller Listen bei Amazon an und wurde im Schnitt mit 5 Sternen bewertet. 39,90€ Euro, 305 Seiten, 20 Jahre E-Commerce Know How.

[jetpack_subscription_form show_subscribers_total=1 subscribe_text=“Aktuelle Beiträge werden sofort nach Erscheinen per E-Mail versendet. Abmeldung jederzeit möglich.“ subscribe_button=“Jetzt anmelden“]

Neue Beiträge per E-Mail abonnieren.

Deine Anmeldung konnte nicht gespeichert werden. Bitte versuche es erneut.
Danke! Bestätige deine Anmeldung bitte in der Mail, die wir dir soeben geschickt haben.