Business Technology 4.15

Conway's Law

Erhältlich ab: November 2015
Umfang: 66 Seiten
Autoren / Autorinnen:
Matthias Heiler, Malte Unger, Richard Attermeyer, Waldemar Kaus, Stefan Toth, Carsten Sensler, Michael Heinke, Matthias Bohlen, Gerrit Beine, Gianluca De Lorenzis, Prof. Dr. Manfred Rössle, Thomas Löw, Jan-Peter Finke, Dr. Gernot Starke, Dr. Carola Lilienthal, Peter Hruschka

18,80 28,80 

Abonnement Typ
Auswahl zurücksetzen

4,90 

Heft bestellen

Highlights dieser Ausgabe

Conway 2.0: Wie Architekturstile agile Zusammenarbeit fördern
oder behindern

Schulden – weniger ist mehr: Neue Betriebswirtschaftslehre für Softwareentwicklung

 

Prozessplanung

Die BizDev-Architektur
Gelebtes Prozessmanagement mit BPMN und der prozessgesteuerten Architektur
Matthias Heiler

Kampf gegen künstliche Barrieren
Schwach strukturierte Prozesse besser organisieren
Malte Unger

Datenzentrale für DevOps
Logmanagement: aktuelle Treiber, Lösungen und Praxis
Richard Attermeyer und Waldemar Kaus

Conways Erben

Conway 2.0
Wie Architekturstile agile Zusammenarbeit fördern oder behindern
Stefan Toth

Technik ist einfach, Strukturen schwierig
Probleme und Lösungen bei einer SOA
Carsten Sensler und Michael Heinke

Skalieren zum nächsten Level
Wachstum jenseits von zehn Leuten und 100 000 Zeilen Code
Matthias Bohlen

Vorsorgemaßnahmen

Schulden – weniger ist mehr
Neue Betriebswirtschaftslehre für Softwareentwicklung
Gerrit Beine

Von der Kommandozentrale in die IT
Wie Militärtechnik die Cybersicherheit im Unternehmen erhöht
Gianluca De Lorenzis

Eine Sprache für Kunde und Dienstleister
Outsourcingschnittstellen nach ITIL
Prof. Dr. Manfred Rössle, Thomas Löw und Jan-Peter Finke

Gegen die dunkle Macht
Verbessern – aber richtig!
Dr. Gernot Starke, Dr. Carola Lilienthal und Peter Hruschka

Liebe Leserin, lieber Leser,

Conway’s Law erlebt gerade eine Renaissance. Das hat weniger mit der unbestreitbaren Tatsache zu tun, dass Melvin E. Conway in seinem Aufsatz „How Do Committees Invent?“ schon 1968 eine sehr weitsichtige Beobachtung gemacht hat, sondern mehr mit dem aktuellen Zustand des Verhältnisses von IT und Business und der allgemeinen Entwicklung.

Zur Erinnerung, das Gesetz sagt in der Zusammenfassung durch den Autor selbst Folgendes: „Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure. This turns out to be a principle with much broader utility than software project management, where references to it usually occur.“

Unter bit.ly/1M3MiUx finden Sie auch den vollen Wortlaut des Artikels.

Danach gilt zum Beispiel: Wer auf ein traditionelles Großunternehmen mit hierarchischer Siloorganisation schaut, wird in der Regel auch eine ähnlich strukturierte IT-Architektur vorfinden. Und es gilt auch: Wer auf ein kleines Start-up mit kurzen Kommunikationswegen zwischen zwei Büroräumen schaut, wird eine entsprechend leichtgewichtige und konsistente Architektur vorfinden. Jeder von uns kennt aus eigener Erfahrung zahlreiche gesetzestreue Unternehmen dieser Art. Und solange es keine Notwendigkeit zur Veränderung gibt, können diese auch brav so weitermachen.

So weit, so gut, doch warum nehmen aktuell immer wieder Artikel und Vorträge Bezug darauf? Was ist der Auslöser dafür bzw. zu welchem Zweck wird Conway’s Law zitiert?

Was treibt Conways Erben?

Die Antwort ist vorderhand relativ einfach: Weil viele Systeme durch die veränderten Marktbedingungen an ihre Grenzen kommen. Die Gründe dafür können so unterschiedliche sein, wie die Unternehmen mit ihren spezifischen Systemen, aber die Konsequenz ist die gleiche: Sie brauchen entweder neue Kommunikationsstrukturen oder neue Architekturen. Und egal von welcher Seite man es betrachtet, dem Gesetz folgend hat das Auswirkung auf die jeweils andere Seite. Ein Start-up, das wächst, mehr Leute einstellt und umfangreichere Software produziert, wird nicht mehr alles zwischen Tür und Angel in der Kaffeeküche klären können. Ein Großunternehmen hat keine Zeit mehr, dutzende von Planungskomitees zunächst auf der Fachseite und dann auf IT-Seite einzurichten, um Monate später eine Änderung umzusetzen, die auf die Lösung eines Start-ups reagiert, die im Wettbewerb um die Kunden plötzlich und überraschend eine Bedrohung darstellt.

Reden Sie mit Ihren Kollegen, und nicht nur mit denen

Das Problem liegt also offen vor uns, weil die Umstände sich verändern und damit auch die Strukturen und Systeme. Und es zeigt sich schnell, dass die technischen Hürden nicht das Hauptproblem sind. Diese lassen sich in der Regel einfach lösen. Viel schwieriger ist es, das Verhältnis von Kommunikationsstruktur und Systemstruktur zu analysieren und dann die richtigen Schritte zu wählen, um beides zu verändern.

Die Artikel dieser Ausgabe beschreiben einige Lösungsszenarien, um sich dieser Herausforderung zu stellen. Überraschend ist dabei, dass die Werkzeuge wieder einmal bereits zur Verfügung stehen, aber die Kunst darin liegt, sie richtig einzusetzen. Denn das, was heute unter Schlagworten wie DevOps, DevBiz und Microservices oder kunden- und mitarbeiterzentrierter Kommunikation beschrieben wird, ist im Detail nicht neu. Die eigentliche Herausforderung liegt darin, im offenen Austausch das richtige Kommunikations- und Architekturdesign zu entwickeln – und hierbei ist Conway’s Law ein guter Prüfstein.

Mirko Schrempp, Redakteur


Weitere Ausgaben

X
- Gib Deinen Standort ein -
- or -