Quelle: "Conways Gesetz"

Anmerkung des Autors 42 Jahre nach Veröffentlichung:

Vielleicht am bemerkenswertesten in diesem Artikel wurde es aufgrund der im dritten Absatz beschriebenen Aussage vom Ende veröffentlicht. Um die Schwierigkeit der Überwindung der vorherigen 45 Absätze zu erleichtern, werde ich sie jetzt in freier Form aussprechen:

Jede Organisation, die ein System entwirft (hier mehr als nur ein Informationssystem), erstellt zwangsläufig ein Modell, das die Kommunikationsstruktur der Organisation selbst wiederholt.

Es stellt sich heraus, dass dieses Prinzip nicht nur in der Softwareentwicklung beobachtet wird, auf die häufig Bezug genommen wird.

Ich schlage vor, Sie machen sich mit dem Material vertraut und schauen sich dann um und suchen es in anderen Bereichen.

Derzeit ist mein Lieblingsbeispiel der Komplex sozialer Probleme im Zusammenhang mit Armut in Amerika: Zugang zum Arbeitsmarkt, Wohnen, Bildung und Gesundheitsversorgung. Überlegen Sie nach dem Lesen des Artikels, wie die Strukturen unserer verschiedenen Regierungen ihre Einstellung zu solchen Themen beeinflussen.

Wie schaffen Komitees neue?

Melvin E. Conway
Original PDF .

Intellektuelle Aktivitäten, bei denen ein Ganzes aus unterschiedlichen Teilen entsteht, können als Systemdesign bezeichnet werden. Sei es die Vorbereitung eines großen Militärkomplexes, Empfehlungen zur Lösung sozialer Probleme oder eine Liste von Computerprogrammen. Ein typisches Ziel einer Designorganisation ist die Erstellung eines Dokuments mit einer kohärent strukturierten Informationsmenge. Wir nennen diese Informationen das Systemmodell. In der Regel ist der Initiator ein Kunde, der das Modell verwenden möchte, um weitere Aktionen bereitzustellen. Zum Beispiel beabsichtigt ein Staatsmann, einen Gesetzentwurf vorzuschlagen, um das Wiederauftreten einer jüngsten Katastrophe zu verhindern. Dazu stellt er ein Team ein, um die Ursachen der Katastrophe herauszufinden. Oder der Hersteller benötigt ein neues Produkt und ernennt Verantwortliche, um das neue Produkt zu bestimmen und dessen Freigabe zu planen.

Die Entwurfsorganisation kann an der Implementierung des entworfenen Systems beteiligt sein oder nicht. Oft gibt es bei Regierungsbemühungen Normen, die die Gruppe daran hindern, gemäß ihren eigenen Empfehlungen zu handeln, während im privaten Sektor die umgekehrte Situation herrscht. Es ist anzunehmen, dass diese Bedingung den Systemdesignprozess beeinflusst, zusammen mit anderen Vorstellungen des Entwicklers über seine eigene Zukunft. Wie wir später sehen werden, können die Anreize, die in einem traditionellen Managementumfeld bestehen, den Zielen des Kunden zuwiderlaufen. [1]

Entwurfsphasen

Die anfängliche Entwurfsphase bezieht sich mehr auf die Strukturierung des Prozesses selbst als auf die Entwicklung des Systems [2]. Der vollständigen Entwicklung gehen bestimmte vorläufige Maßnahmen voraus, nämlich:

1. Definieren der Grenzen der Projektaktivitäten und des vom Kunden festgelegten Endergebnisses und der vorhandenen Realitäten.
2. Erste Bewertung der Struktur des Systems mit dem Ziel einer ausgewogenen Bildung von Entwicklungsteams.

In Zukunft werden wir detailliert erklären, dass die Organisationsstruktur des Teams bereits direkt oder indirekt die Umsetzung des Projekts beeinflusst. Selbst die Unfähigkeit, ideale Bedingungen für die Suche nach Mitarbeitern zu schaffen, wird die Bildung des Teams nicht absolut objektiv erfolgen. Und nach der Bildung des Teams werden die Verantwortlichkeiten an Untergruppen delegiert, was den Forschungsumfang einschränkt und gleichzeitig die Anzahl der Optionen für die Entwicklung des Systems verringert.

Nach der Zuweisung von Verantwortlichkeiten stehen die Manager vor dem Problem der Koordinierung auf der Ebene der Arbeitsgruppen, was sich negativ auf die Konsolidierung der Bemühungen jeder Gruppe auswirkt, um ein einheitliches System zu schaffen. Trotz der möglichen Abnahme dieser Rolle eines Individuums.

Der Systemdesignprozess umfasst die folgenden Phasen:

1. Grenzen nach den Grundregeln definieren.
2. Entwicklung eines vorläufigen Systemkonzepts.
3. Organisation der Entwurfsarbeit und Delegation von Aufgaben gemäß dem Konzept.
4. Koordination auf der Ebene der delegierten Aufgaben.
5. Subsysteme zu einem System kombinieren.

In einer einzelnen Entwurfsarbeit können möglicherweise nicht alle Phasen verfolgt werden. Es kann vorkommen, dass dabei ein neues, perfekteres Projektkonzept gefunden wird. Dies ist natürlich kein sehr günstiger Moment, da die anschließende Einstellung der Arbeit schmerzhaft und teuer sein wird. Natürlich wiederholt sich aus Sicht des Historikers alles.

Warum bleibt in diesem Fall nicht genug Zeit, um alles richtig zu machen, aber es bleibt immer genug Zeit, um etwas zu wiederholen?

Systemdesign

Jedes serielle System besteht aus miteinander verbundenen Subsystemen. Die Beschreibung der internen Struktur des Systems sollte seine Beziehung zur externen Umgebung und die Beziehung seiner Subsysteme widerspiegeln. Wenn wir auf eine niedrigere Ebene gehen, können wir dasselbe über das Subsystem sagen, wenn wir es als System betrachten. Und so weiter bis hin zu einem solchen Subsystem, das extrem einfach und unteilbar sein wird.

Beispiele

Das staatliche transkontinentale Verkehrssystem besteht aus Bussen, Zügen, Flugzeugen, Taxis, Parkplätzen, Terminals usw. Dies ist ein sehr heterogenes System, was bedeutet, dass seine Subsysteme sehr unterschiedlich sind. Wenn wir zum Beispiel auf eine niedrigere Ebene gehen, werden wir die Subsysteme sehen: Rahmen, Motor, Energieverteilung, Kommunikation, Nutzlast. Das Motorsystem umfasst solche Subsysteme wie Kraftstoff, Zündung usw.

Nicht so offensichtlich, aber die Theorie ist auch ein System. Es bezieht sich auf die äußere Umgebung, auf die beobachteten Ereignisse, die es erklären oder zumindest nicht widersprechen sollte. Es besteht aus Teiltheorien, die sich auf ähnliche Weise aufeinander beziehen. Beispielsweise wurde im Verlauf der Crash-Untersuchung eine Theorie erstellt, die die Flugbahn des Flugzeugs, seine Kommunikation, Beschädigung und Interaktion mit anderen Objekten während des Unfalls beschreibt. Jedes dieser Elemente ist für sich eine eigene Geschichte und kann bis zu einzelnen Informationseinheiten auch in Unterelemente unterteilt werden.

Schemata

In Abb. In 1 ist das System in Form eines Diagramms - ähnlich einer Rassel - mit Verbindungen (Zweigen) in Form von Linien und Hauptknoten (Knoten) in Form von Kreisen dargestellt. Jeder Knoten symbolisiert ein Subsystem, das mit anderen Subsystemen kommuniziert, die auf ähnliche Weise dargestellt werden können. Der Begriff Schnittstelle, der bei Entwicklern immer beliebter wird, bezieht sich auf die Interaktion von Subsystemen, die durch Linien gekennzeichnet sind.



Das grafische Bild zeigt deutlich die identische Form der beiden Konzepte, die wir betrachten: das System und die Organisation, die es entwirft. Versuchen Sie zu ersetzen:

1. "System" zu "Ausschuss"
2. "Subsystem" an den "Subausschuss"
3. "Schnittstelle" zu "Koordinator"

Wie bei Systemen sehen wir, dass Designorganisationen unter Berücksichtigung mehrerer Komplexitätsebenen berücksichtigt werden können. Die Bundesregierung ist ein hervorragendes Beispiel für eine Designorganisation mit einer Komplexität, die jeden Ingenieur zufriedenstellen kann. Dies ist ein besonders interessantes Beispiel, das die Ähnlichkeit der beiden von uns betrachteten Konzepte zeigt, da die Bundesregierung sowohl eine Designorganisation (entwickelt Gesetze, Verträge, Richtlinien) als auch eine Designorganisation (mit der Verfassung als primärer Designdokumentation) ist.

Primäre Interaktion

Jetzt sind wir bereit für die Hauptausgabe dieses Artikels. Gibt es eine vorhersehbare Beziehung zwischen der Struktur der Designorganisation und dem von ihr entworfenen System? Die richtige Antwort lautet Ja, und diese Verbindung ist so einfach, dass sie oft konstant ist. Betrachten Sie die folgenden "Beweise".

Wählen wir das System und die Organisation, die es entwickelt hat, willkürlich aus und wählen zufällig den Komplexitätsgrad des entworfenen Systems aus, skizzieren wir es (unsere Wahl ist willkürlich, denn wenn wir interessante Beziehungen beobachten, können wir sie auf jede Entwurfsorganisation und Komplexitätsstufe ausweiten). In Abb. Abbildung 2 zeigt (zur Verdeutlichung) eine Struktur, für die die folgende Aussage zutrifft.



Für jeden Knoten x im System können wir die Arbeitsgruppe der Entwurfsorganisation identifizieren, die ihn entwickelt hat (bezeichnen Sie ihn mit X). Auf diese Weise,

Zusammenfassend haben wir für jeden Knoten im System eine Regel, um die entsprechende Arbeitsgruppe zu finden. Bitte beachten Sie, dass das Verhältnis 1: 1, d.h. Zwei Subsysteme können von derselben Entwurfsorganisation entworfen werden.

Interessanterweise können wir eine ähnliche Aussage in Bezug auf Branchen machen. Nehmen Sie zwei beliebige Knoten desselben Systems, x und y. Sie können verbunden sein oder nicht (d. H. Entweder sie interagieren in irgendeiner Weise miteinander, die für das Funktionieren des Systems wichtig ist, oder nicht). Wenn eine Verbindung zwischen ihnen besteht, mussten sich die beiden Arbeitsgruppen X und U, die zwei Datenknoten entwickelten, auf die Merkmale der Schnittstelle einigen, um die Möglichkeit der Kommunikation zwischen Knoten zu realisieren. Wenn keine Verbindung zwischen x und y besteht, kommunizieren die Subsysteme nicht miteinander, was bedeutet, dass die Arbeitsgruppen nicht miteinander interagierten (da keine Verbindung zwischen X und Y besteht). [3]

Was haben wir gerade gezeigt? Mit einfachen Worten haben wir gezeigt, dass ein enger Zusammenhang zwischen der Struktur des Systems und der Struktur der Organisation besteht, die an seinem Entwurf beteiligt ist. Wenn jedes Subsystem eine eigene Arbeitsgruppe hat, können wir beobachten, dass die Strukturen (Schemata) der Arbeitsgruppe und des Subsystems identisch sind. Wenn mehrere Arbeitsgruppen ein Subsystem entwickeln, sieht die Entwurfsorganisationsstruktur wie eine Systemstruktur aus, jedoch mit weniger Subsystemen (Knoten im Diagramm).

Eine ähnliche strukturerhaltende Beziehung zwischen zwei Objekten wird als Homomorphismus bezeichnet. In der mathematischen Sprache gibt es einen Homomorphismus zwischen dem Systemdiagramm und dem Organisationsprojektionsdiagramm.

Das System spiegelt die Organisation wider, die es entworfen hat

Viele erfahrene Systemdesigner glauben, dass jeder jemals ein Systemdesign besser machen kann. Mit anderen Worten, es ist falsch und falsch, über die Entwurfsaufgabe zu sprechen, außer im Zusammenhang mit Ort, Zeit, Wissensstand und Technologie. Dies sollte von denen in Erinnerung bleiben, die die Geschichte der Arbeit beim Entwerfen eines Objekts lesen oder sich an ihre Arbeit erinnern und sie analysieren.

Die Entwicklung von Computerübersetzern für Programmiersprachen wie FORTRAN und COBOL ist ein hervorragendes Beispiel. Mitte der 1950er Jahre, als Prototypen dieser Sprachen auftauchten, waren ihre Compiler noch umständlicher als die Computer selbst, gigantisch in jenen Tagen, die Befehle ausführen sollten. Heute sind diese Übersetzer nur historische Wunder, die mit modernen Compilern nichts gemein haben. (Es ist erwähnenswert, dass ein großer Durchbruch bei der Entwicklung von Compilern mit der Entstehung neuer Personengruppen in dem Bereich verbunden war, der zuvor als Erbe der Computerhersteller galt - dies war zunächst eine kleine zusammenhängende Gruppe von Forschern der Universität, gefolgt von unabhängigen Softwareentwicklern).

Wenn wir davon ausgehen, dass es für eine Systemanforderung eine Reihe von Systemprojekten gibt, die diese Anforderung erfüllen, müssen wir auch fragen, ob die Auswahl der Entwurfsorganisation den Auswahlprozess eines Systemprojekts aus dieser Reihe beeinflusst. Wenn wir an unseren Homomorphismus glauben, werden wir den Einflüssen zustimmen. Da die Organisation keine flexible Kommunikationsstruktur hat, wird diese Organisation in jedem Projektprodukt eine Kopie von sich selbst stempeln. Je größer die Organisation ist, desto weniger flexibel ist sie und desto mehr manifestiert sich diese Eigenschaft.

Beispiele

In einer Forschungsorganisation gab es acht Personen, die die COBOL- und ALGOL-Compiler erstellen sollten. Nach einer ersten Bewertung der Komplexität und möglicher Fristen wurden fünf von ihnen für die Arbeit mit COBOL und drei für die Arbeit mit ALGOL bestimmt. Infolgedessen arbeitete der COBOL-Compiler in fünf Durchgängen und der ALGOL-Compiler in drei Durchgängen.

Zwei Militärdienste unter der Führung ihrer Oberbefehlshaber haben ein Waffensystem für ihre Bedürfnisse entwickelt. Danach erstellten sie nicht ohne Aufwand eine Kopie ihrer Organisationsstruktur (siehe Abb. 3a).



Achten Sie auf das an dieser Aufgabe beteiligte Computerbetriebssystem. Nachdem wir es im Detail untersucht haben, sehen wir, dass es aus drei Teilen besteht: Hardware, Software und Anwendungen (siehe Abb. 3b). Ihre Entwickler entsprechen diesen Subsystemen: Ingenieure des Computerherstellers, seine Systemprogrammierer und Entwickler kundenspezifischer Anwendungen (dieser seltene Fall, wenn Hardware- und Softwarespezialisten zusammenarbeiten und sich nicht nur schwer ertragen).

Systemverwaltung

Die Struktur großer Systeme neigt dazu, während ihrer Entwicklung zu verfallen. Diese Beobachtung wird besonders deutlich, wenn man große militärische Informationssysteme der letzten zehn Jahre betrachtet. Sie sind die komplexesten Objekte aller zuvor vom Menschen geschaffenen Objekte. Eine Aktivität namens "Systemmanagement" ist entstanden, auch aufgrund der Tendenz von Systemen, sich in ihre Bestandteile zu trennen. Lassen Sie uns die Praktikabilität des Systemmanagements im Kontext der Hauptidee dieses Artikels betrachten.

Warum fallen große Systeme auseinander? Dieser Prozess durchläuft drei Stufen, von denen die ersten beiden steuerbar sind, und die dritte Stufe ist eine direkte Folge unseres Homomorphismus.

1. Erstens können die Entwickler, die die Größe des projizierten Systems erkannt haben, der Versuchung nicht widerstehen, so viele Leute wie möglich einzustellen, um es zu erstellen.
2. Zweitens wird bei der Anwendung des üblichen Managementmodells für die Umsetzung eines solchen Großprojekts dessen Kommunikationsstruktur in separate Teile zerlegt.
3. Drittens treten die Zerfallsprozesse, die in der Struktur des Organisationsdesigners auftreten, in der Struktur des Systems gemäß dem Phänomen des Homomorphismus auf.

Betrachten Sie zunächst die Situation mit "Überbevölkerung". Der natürliche Wunsch des Entwicklers, Aufgaben zu delegieren, ist durchaus verständlich, wenn sich die Komplexität des Systems den Grenzen seines Verständnisses nähert. Dies ist ein Wendepunkt im Entwicklungsprozess. Entweder kämpft er um die Vereinfachung des Systems und gewinnt, oder er verliert die Kontrolle darüber. Das Ergebnis ist angesichts des Zeit- und Budgetdrucks nahezu vorhersehbar.

Wenn die Frist verloren geht, ist der Manager genau schuld, wenn er nicht alle Ressourcen verwendet hat, um dies zu verhindern. Daher wird er versuchen, den Entwickler zu beeinflussen, der es vielleicht vorziehen würde, sich mit der Komplexität des Systems zu befassen und keine Aufgaben an andere zu delegieren. Infolgedessen wird die Anzahl der beteiligten Ressourcen zunehmen.

Oder ein anderes Beispiel, das einen ähnlichen Konfliktfall des Managers und die Integrität des entworfenen Systems demonstriert. Der Manager muss den kritischen und komplexen Teil der Arbeit für die Implementierung angeben. Er kann einen von zwei Künstlern auswählen: ein neues kleines Unternehmen, das sich durch einen kreativen Ansatz und niedrige Löhne auszeichnet, oder ein seriöses Büro, das sich etabliert hat und „realistischere“ Preise hat. Er weiß, dass ein kluges junges Unternehmen, das die Aufgabe nicht bewältigt, schuldig ist, das Projekt gestört zu haben. Wenn eine bekannte Organisation ausfällt, zeigt dies nur an, dass die Aufgabe wirklich schwierig ist.

Was ist der Haken hier? Grundsätzlich bei der traditionell verwendeten Methode zur Bewertung und Zuweisung von Ressourcen. Die Einheit der Ressource ist also der Dollar, daher werden alle Ressourcen in Dollar ausgedrückt. Wenn es sich bei der Ressource um menschliche Arbeit handelt, sind die Kosten für eine Arbeitsstunde multipliziert mit der Anzahl der Arbeitnehmer die Maßeinheit.

Der Irrtum dieses Ansatzes besteht darin, dass die Arbeit von zwei Personen während des Jahres auf die gleiche Weise bewertet wird wie die Arbeit von Hunderten von Personen während der Woche. Da jedoch die Organisationsstruktur der Arbeit von zweihundert und hundert aufgrund des Homomorphismus unterschiedlich sein wird, kann argumentiert werden, dass sie unterschiedliche Systeme schaffen, sodass Sie die Kosten ihrer Arbeit nicht vergleichen sollten. Aus Erfahrung wissen wir, dass zwei richtig ausgewählte Personen, wenn sie damit fertig werden, das beste Ergebnis zeigen. Annahmen, die für das Schälen von Kartoffeln oder das Verlegen von Ziegeln zutreffen könnten, sind im Systemdesign falsch.

Das Parkinson-Gesetz [4] ist für die Umverteilung der Arbeitsressourcen bei Projektaktivitäten von großer Bedeutung. Solange der Ruf des Managers von der Größe des Budgets abhängt, ist er an einer Erweiterung seiner Organisation interessiert. Dies ist keine geeignete Motivation zur Lösung von Systementwicklungsproblemen. Sobald eine Organisation existiert, wird sie natürlich verwendet. Der vielleicht zwingendste Grund für die Existenz so vieler schlecht gestalteter Systeme liegt heute in der Anwesenheit von Designorganisationen, die Arbeit suchen.

Zweitens beginnt sich der Grund für den Zusammenbruch des Systemdesignprozesses - die Fragmentierung der Kommunikationsstruktur der Designorganisation - mit dem Beginn der Delegation von Aufgaben zu manifestieren. Nach der Theorie der Elementarwahrscheinlichkeit entspricht die Anzahl der möglichen Kommunikationen dem halben Quadrat der Anzahl der Mitarbeiter der Organisation. Selbst in kleinen Organisationen müssen Sie die Kommunikation einschränken, damit die Mitarbeiter ihre Arbeit beenden können. .

. , . . , .

Fazit

— , ( ) , . , . : , , . , . , , , , , - , .

, . , , . . .

Anmerkungen

[1] . « » (John Kenneth Galbraith's The New Industrial State). VI, «».

[2] C. « » (.J. Middleton, «How to Set Up a Project Organization,» 1967, . 73).

[3] . , . , , .

[4] .. « » (C. Northcote Parkinson, Parkinson's Law and Other Studies in Administration, 1957)

:

Noch

• «How do Committees Invent?»
• Exploring the Duality between Product and Organizational Architectures: A Test of the «Mirroring» Hypothesis
• Does Conway's Law apply to Linux?
• Conway's Law [Framework of the Day]
• One-on-one with Mel Conway and Mike Amundsen

«»

«Augmenting Human Intellect:
A Conceptual Framework» , .

«» — « », «» , , () .

— ( , ! , .) — , , , , , , , , WikiPedia, Web Archive, Knol, Quora, Cybersyn, Xanadu, DARPA, IARPA.

— 50 . Die Mutter aller Demos

Wenn Sie NLS wirklich verstehen wollen, müssen Sie die heutige Realität vergessen. Vergessen Sie alles, was Sie über Computer wissen. Stellen Sie sich vor, Sie wissen immer noch nicht, was ein Computer ist. Rückkehr nach 1962. Und dann lesen Sie, was er vorhat .
- Bret Victor, ein paar Worte zu Douglas Engelbart