Und dann spreche ich am selben Tag mit Ivan Engler, dem Regisseur des Sci-Fi Spielfilms “Cargo”, der kein Problem mit Wissensinseln zu haben scheint. Im Gegenteil! Sie machen für ihn einen Teil der Effizienz einer Spielfilmproduktion aus.
Ja, was denn nun? Sind (Wissens)inseln “gut” oder “böse”?
Natürlich gibt es da keine pauschale Antwort. Es kommt immer darauf an, auf den Kontext. Deshalb könnte ich das Thema auch zu den Akten legen und einfach sagen: Beim Film sind Wissensinseln ok, bei der Softwareentwicklung hingegen sind sie unakzeptabel. So ist das halt.
Doch ich mag mich noch nicht von den Wissensinseln in der Softwareentwicklung verabschieden. Der Begriff suggeriert Kontraproduktivität – aber den kann ich ja austauschen. Wenn ich stattdessen Spezialisierung sage, dann ist die Konotation schon ganz anders.
Wenn Wissensinseln pauschal “böse” sein sollten, dann ist Spezialisierung pauschal “gut”. Spezialisierung ist schließlich das Ergebnis einer komplizierten Welt, in der nicht mehr jeder alles können kann (oder will). Damit meine ich nun nicht die seelenlose Spezialisierung eines seiner Produkte entfremdeten Fließbandarbeiters. Nein, ich meine eine Spezialisierung wie die einer Maskenbildnerin oder eines Kameramannes oder eines Motoringenieurs oder eines Kommunikationselektronikers.
In der Softwareentwicklung allerdings geht die Angst um. Der truck factor scheint quasi immer bei 1 zu sein, sobald sich eine Spezialisierung entwickelt. Das scheint mir der Befindlichkeit in vielen anderen Branchen zu widersprechen. Ich ahne eine Überempfindlichkeit der Softwareentwicklung.
Natürlich kann ich Jens Coldeweys grundsätzlichen Gedanken zustimmen. Es gibt Wissensinseln, die “böse” sind. Und man sollte sie sich auch nicht unbewusst entwickeln lassen. Praktiken wir Reviews und Pair Programming sind probat, um dem entgegen zu wirken. Kein Problem. Ich bin für diese Praktiken und Wissensaustausch im Team.
Und dennoch… Ich bin auch weiterhin der Überzeugung, dass es illusorisch ist anzunehmen, alle Entwickler könnten gleichermaßen Experten in all den Technologien sein, die in einer größeren Anwendung zum Einsatz kommen. Alle sind Silverlight-, WCF-, NHibernate-, WF-, Azure-, InRule-, Oracle-Profis usw.? Das ist Quatsch.
Im Umkehrschluss bedeutet das: Solange der Wille besteht, alle auf dem gleichen Level zu halten, kann dieses Level nur mittelmäßig at best sein.
Soweit die beiden Positionen: Wissensinseln sind “böse”, Spezialisierung ist für Höchstleistung unvermeidbar.
Lässt sich da noch eine Brücke schlagen?
Ja, mir scheint, das geht. Dazu müssen wir aber die Architektur in den Blick nehmen. Auch Jens Coldewey hat Conway´s Law erwähnt: Organisationsstrukturen spiegeln sich in Produktstrukturen wider. Da hake ich mal ein und frage: Wenn denn nun die Organisation dazu führt, dass eben keine Grenzen mehr zu sehen sind – alle sind in ihrem Wissen gleich –, wie soll denn dann die Software aussehen, die so eine Organisation produziert?
Vor dem Hintergrund von Conway´s Law bezweifle ich, dass eine Organisation, in der alle gleich sein sollen, Software herstellen kann, die wahrhaft modular ist, d.h. in der es ganz klare Verantwortlichkeiten gibt. Collective Code Ownership widerspricht insofern sauberer Architektur. Oder anders: Collective Code Ownership tut nichts dafür, dass es zu einer evolvierbaren Architektur durch Grenzziehung in Form von Entkopplung kommt. Wenn die hergestellt werden soll, dann muss ganz bewusst an anderer Stelle Kraft aufgewandt werden. Es gibt aus der Haltung zur Vermeidung von Wissensinseln heraus kein Bedürfnis, in Komponenten (oder gar “Services”) zu denken.
Und jetzt die Umkehrung: Ich setze voraus, dass Architektur modular (komponentenorientiert, serviceorientiert, entkoppelt usw.) sein soll. Punkt. Daran geht für mich nichts vorbei. Soviel ist der Langlebigkeit von Software geschuldet. Es geht ums pure Überleben des Produktes. Das bedeutet – im Sinne von Conway´s Law –, dass die Organisation ebenfalls “irgendwie” modular sein muss. Andernfalls reibt sie sich immer wieder auf, um Strukturen herzustellen, die ihr nicht entsprechen.
Unverbrüchliche Architekturprinzipien sollen also die Organisation treiben!
Daraus folgt für mich, dass z.B. eine grundlegende Trennung von Infrastruktur und Domäne in der Organisation zu sehen sein sollte. Domänenlogik ist etwas ganz anderes als ein Frontend, die Persistenz, die Sicherheit, die Kommunikation usw.
Nun die Masterfrage: In welchem dieser Bereiche sind Wissensinseln ein Problem? Aus meiner Sicht nur bei der Domäne. Software wird sehr sensibel überall dort, wo Domänenlogik im Spiel ist. Und das waren auch die Beispiele, die Jens Coldewey gebracht hat. Domänenlogik ist so sensibel, weil die Experten, die sich mit Softwareentwicklung und (!) Domäne auskennen, so dünn gesät sind.
Das ist übrigens auch der Fall im Filmbusiness. Kameramann und Regisseur und Schauspieler sind nicht so leicht auszutauschen wie eine Maskenbildnerin oder ein Mikrofongalgenhalter. Jene sind mit dem Thema des Films, der Vision eng verwoben; das ist die Domäne einer Produktion. Alles andere ist “Beiwerk” – wichtig, aber ohne Domänenbindung. Maskenbildner etc. haben generische Kompetenz.
Übertragen auf die Softwareentwicklung meine ich daher, dass wir dahin kommen müssen, architektonische Prinzipien ernst zu nehmen. Alles, was mit Infrastruktur zu tun hat, ist domänenunabhängig von der Architektur so zu kapseln, dass es von Experten mit generischer Kompetenz realisiert werden kann. Das mögen – je nach Anwendung – 5%, 10% oder 30% der Code sein. Immer bleibt der Löwenanteil jedoch in der Domäne.
Dennoch ist das ein Gewinn. Es ist nun ganz klar, welche Funktionalität grundsätzlich ohne truck factor realisierbar ist. Denn fällt der Silverlight-Experte aus, wird der nächste angeheuert. Der braucht nur wenig Einarbeitung, weil er keine Ahnung von der Domäne haben muss. Das hochspezialisierte Wissen für optimalen Technologieeinsatz macht kein Wissensinselproblem, weil es breit verfügbar ist (oder zumindest sein könnte). Hier kommt es vor allem auf Erfahrung mit nicht-funktionalen Anforderungen an. Die sind aber quasi in jedem Projekt zu gewinnen.
Es bleibt übrig der Bereich der Domäne. Hier werden die Experten in jedem Team individuell herangezüchtet. Und tatsächlich darf es in Bezug auf die Domäne im Team keine Wissensinseln geben. Domänenwissen ist so breit wie möglich verfügbar zu machen im Team. Denn dort sitzen die quasi einzigen Experten weltweit.
Von Domänenexperten dann aber auch noch Hochleistungen in technologischer Hinsicht zu erwarten, halte ich für eine Überforderung. Natürlich darf, kann, soll jeder Domänenexperte über eine Domänenkenntnis und gute “Programmierkenntnisse” der Plattform hinaus auch noch technologische Spezialgebiete haben. Nur sollte sich ein Projekt darauf nicht verlassen. Und es sollte nicht versuchen, solche technologischen Kompetenzen breit zu streuen. Das funktioniert nicht.
Stattdessen ist es Aufgabe der Architektur, Spezialgebiete (oder Belange) deutlich zu trennen. Die Domäne ist ein solches Spezialgebiet, Persistenz, Frontend etc. sind andere. Und für jedes Spezialgebiet ist Redundanz in Bezug auf die Kompetenzen herzustellen.
Redundanz in der Domäne ist Aufgabe des Projekteams, Redundanz bei Infrastrukturtechnologiekompetenzen ist Aufgabe des Marktes.
Die Filmindustrie hat das hinbekommen. Maskenbildern, Tischler, Bühnenbildner gibt es zuhauf. Bei der Domäne ist es dort aber naturgemäß schwierig. Dafür sind die Projekte auch zu kurz und personengebunden. Deshalb gibt es Versicherungen. Fällt der Hauptdarsteller wegen Unfall aus, kompensiert eine Versicherung den Verlust.
Das könnte auch in der Softwareindustrie funktionieren – wenn denn ein Team nachweisen kann, dass es Wissensinseln vermieden hat, soweit das möglich ist. Aber das ist ein anderes Thema…
An dieser Stelle ich mir wichtig, die Vereinigung aus Spezialisierung und Vermeidung von Wissensinseln herzustellen. Die liegt darin, die architektonisch saubere Separation of Concerns auf das Team zu übertragen. Daraus folgt, dass das Team bzw. Kernteam vor allem die Verantwortung für die Domäne bekommt. Darin sollen dann alle im Team Experten werden; Wissensinseln sind zu vermeiden, weil es außerhalb des Teams kaum Ersatz gibt.
Alle anderen Belange sollte das Kernteam aber nicht auch noch exzellent abdecken. Stattdessen sollte es sie strukturell isolieren und von externen Experten aufsetzen lassen. Im Team muss dann nur noch Pflegekompetenz existieren. Teammitglieder müssen damit arbeiten und nur noch verstehen, was da gemacht wurde und hier und da korrigierend eingreifen können. Falls tiefere Kenntnis nötig werden sollte, wird wieder ein Experte “eingekauft”.
Damit vermeiden Teams den unmöglichen Spagat zwischen hoher Domänenkompetenz auf der einen Seite und technologischer Exzellenz auf der anderen Seite. Und so entsteht auch ein Markt für technologische “Söldnerexzellenz", die öfter als bisher in unterschiedlichen Projekten eingesetzt wird.
Anders, so glaube ich, kommen wir nicht heraus aus dem ewig mittelmäßig bis schlechten Einsatz von Technologien. Wissensinseln sind also tatsächlich zu vermeiden; das bedeutet jedoch nicht, wir müssen auf eine Spezialisierung verzichten. Spezialisten sind nötig, dürfen nur nicht unersetzbar sein. Deshalb darf der Anspruch nicht sein, alle Spezialisten “selbst herzustellen”. Das ist die Herausforderung.
Natürlich ist es einfacher, “alle sollen möglichst gleich sein” zu denken. Das macht weniger Planungsaufwand. Und das ist auch ok. Nur darf ein Team dann nicht erwarten, wenn es in vielen Disziplinen “gleichgeschaltet ist”, in allen auch Höchstleistungen zu erbringen. Das Prinzip “Wissensinseln vermeiden” sollte daher nicht pauschal allein Anwendung finden.
11 Kommentare:
Ich trenne also sauber Infrastrukturaspekte von Domainlogik und dann entwerfe ich als Domainspezialist das Modell und sage dem NHibernate Fachmann: „Mach mal, dass wir das in die Datenbank bekommen“ und brauch mich um nichts mehr zu kümmern. Fällt der NHibernate Fachmann aus, dann besorge ich mir den nächsten und weil ich darauf geachtet habe, die Aspekte sauber getrennt zu halten, kann mir dieser schon nach kurzer Einarbeitungszeit helfen.
Ach, wie wäre das schön.
Je intensiver ich eine Technologie einsetze, desto schwieriger wird es, von deren Implementierung zu abstrahieren. Bei Anwendungen, die intensiv NHibernate einsetzen, wird ist es nahezu unmöglich eine scharfe Trennung herzustellen: sobald ich anfange das Laden von Objektgrafen zu optimieren, vermische ich Aspekte.
Wenn ich Bild und Bunte konsultiere, scheint mir das auch für die Filmindustrie zu gelten: Mariah Carry lässt sich garantiert nicht von jedem Maskenbildner bemalen und die deutsche Fußballnationalmannschaft wird sicherlich ihren eigenen Koch mit nach Südafrika nehmen.
Im Übrigen halte ich den Umkehrschluss Deiner These für gefährlich: Wenn ich ein NHibernate Spezialist bin, dann brauche ich mich nicht in die Problemdomäne einzuarbeiten.
Ja, die Vorstellung von solchen "austauschbaren" Wissensträgern ist schön, aber in der Praxis selten anzutreffen.
Interessanter weise hatte ich am Freitag ein langes Gespräch zu diesem Thema mit unserem Management: Das Problem ist extrem inhomogene Verteilung von Wissen im Entwicklungsteam. Der Einsatz von Technologien, Methoden und Praktiken wird dadurch verhindert – mit der Begründung, dass die Austauschbarkeit von Personen im Projekteinsatz erhalten bleiben muss. Das ist einerseits verständlich, andererseits führt es zum Stillstand: das schwächste Glied der Kette schränkt die Belastbarkeit des Systems (Entwicklungsteams) ein.
Noch eine zum Thema passende Anekdote fällt mir auf: Ihr .NET-isten habt es leicht – es gibt keine Diskussion über unterschiedliche Plattformen. Wir hingegen haben (bislang) den Einspruch mehrere Plattformen (Windows, verschieden Unix-e, Linux) unterstützen zu müssen und zwar mit gleicher Code-Basis! Hier zeigt sich in den letzten Jahren genau das Gleiche, was für den Wissensstand der Teammitglieder gilt: das schwächste Glied der Kette bestimmt die Leistung! Das führt inzwischen zu absurden Auswüchsen, bei denen irgendein uraltes, selbst vom Hersteller vernachlässigtes Unix-Derivat bestimmt was wir machen dürfen und was nicht…
Noch eine Bemerkung zur unerwünschten Bildung von Wissensinseln in der Domäne. Nach meiner Erfahrung ist dies in unserer Branche unvermeidbar. Es ist nicht realistisch, bestimmte Arten von hochspezialisiertem Wissen in die Breite zu streuen. Typischerweise handelt es sich um klassisches "akademisches" Wissen, dass von Spezialisten für eine bestimmte Domäne angesammelt wurde und nur von ihnen effektiv eingesetzt werden kann. Beispiele aus meinem Alltag sind Numerik, inverse Kinematik, spezialisierte Gleichungslöser, Kollisionsrechnung... Alles Gebiete die ein langes Studium und langjährige Erfahrung bedürfen. Normalerweise kann man es sich (a) nicht leisten viele von solchen Leuten anzuheuern (b) den Rest der Mannschaft auf das gleiche Niveau zu bringen. Hier ist auch bei uns der truck factor gleich 1 bis 3 bei einer Besatzung von ca. 20. Ab einem bestimmten Stadium kann man dann natürlich die Resultate der Arbeit von solchen Domain-Experts zur Infrastruktur "degradieren" und wie Infrastruktur-Software gleichgestellt mit z.B. NHibernate behandeln. Aber der Weg dorthin ist schwer und wenn Erweiterungen bzw. neue Funktionalität gewünscht sind geht das Spiel von vorne los.
Gruß,
Paul
@Carsten: Ich sage nicht, dass sich ein Technologiespezialist gaaar nicht in die Problemdomäne seines Auftraggebers eindenken soll. Auch Maskenbildner tun das.
Die Einarbeitung sollte aber nicht zu weit gehen. Denn sonst wird die Austauschbarkeit gefährdet.
Du sagst: "Je intensiver ich eine Technologie einsetze, desto schwieriger wird es, von deren Implementierung zu abstrahieren. Bei Anwendungen, die intensiv NHibernate einsetzen, wird ist es nahezu unmöglich eine scharfe Trennung herzustellen: sobald ich anfange das Laden von Objektgrafen zu optimieren, vermische ich Aspekte."
Und du meinst damit nicht nur eine Beschreibung dessen, wie es bei euch ist, sondern wie es erstens allgemein ist und zweitens sogar nicht anders sein kann.
Dem setze ich entgegen: Die Geschichte der Softwareentwicklung widerlegt deine Position.
Ich vergleiche deine Rede mal mit der eines C Programmierers von 1974. Der hat Stein und Bein geschworen, dass es unverzichtbar sei, bei der Softwareentwicklung auf die Hardwareressourcen Rücksicht zu nehmen. "Jedes Byte zählt!" war sein Credo.
Und heute? Wir haben 4+ GB in einem Laptop, die IDE verschlingt hunderte MB, ich hab grad 250 GB SSD gekauft... Wir haben uns von vielen (nicht allen) Hardwareressourcen emanzipiert. Auch wenn es 1974 nicht so aussah, geht das.
Und dasselbe behaupte ich auch für dein Beispiel oder ähnliche. Wer beim Objektmodell noch darauf Rücksicht nehmen muss, wie der ORM funktioniert, der macht etwas falsch.
Allemal solange wir behaupten, das ginge nicht anders, statt immer und immer wieder danach zu suchen, wie und dass es anders geht, solange befreien wir uns nicht aus diesen Banden und kommen zu keiner besseren Organisation.
Wenn du es also ernst meinst mit "Ach, wie wäre das schön", dann strebe danach. Jede Minute. Bei jeder Designentscheidung. Lass das Bild der Unabhängigkeit dein Leitstern sein. Das Ergebnis wird Software sein, die anders ist als heute. Modularer, vielleicht aufbauend auf anderen Technologien, vielleicht asynchroner.
Wir sollten uns nicht immer noch unentwegt von (überkommenen) technologischen Magneten anziehen lassen.
-Ralf
@Paul: Ja, Austauschbarkeit soll sein. Dafür bin ich auch.
Aber ich glaube, ihr Preis sollte eben nicht technologische Mittelmäßigkeit sein. Das ist heute vielfach noch der Fehlschluss.
Es gibt mehr Stellräder in der Entwicklung. Wie von mir argumentiert, kann saubere Architektur helfen, Austauschbarkeit herzustellen. Dafür muss man aber natürlich für Architektur erstmal ein Bewusstsein entwickeln. Auch das fehlt in vielen Teams. Denen scheint es dann einfacher, Gleichmacherei zu betreiben.
Wissensinseln halte ich nicht für unvermeidbar. Und Spezialistentum ist zwangsläufig.
Wie auch sonst im Leben braucht es dafür aber Soft Skills, um damit gut umzugehen. Wenn die in unserer Branche notorisch mau sind... dann ergibt sich daraus natürlich Inflexibilität oder gar die Rationalisierung des schlechten Zustands. Was irgendwie nicht sein kann, das darf dann auch nicht sein.
Wir tun uns keinen Gefallen, wenn jeder Entwickler immer auch Domänenexperte werden muss. Und wenn umgekehrt jeder Domänenexperte immer auch Technologiespezialist sein soll. Oder - und das ist der Normalfall - auf beiden Seiten eher mittelmäßiges Verständnis herrscht.
Eine Branche die nach Höchstleistungen ruft, muss auch konsequent über die Bedingungen für Höchstleistungen nachdenken. Alles andere ist Kinderkram.
-Ralf
Ralf, jetzt mal raus aus dem engstirnigen Schubladendenken.
Nur weil ich meine, dass es sehr schwierig sei, von einer intensiv genutzten Technologie zu abstrahieren, heißt das nicht, dass ich Lochkarten programmieren möchte.
„Every abstraction is leaky“ (http://www.joelonsoftware.com/articles/LeakyAbstractions.html) und das beste Beispiel lieferst Du selbst: Deine SSD wirst Du sicherlich so verwenden, dass Du häufige Schreibvorgänge auf dieser vermeidest. Von außen mag die SSD wie eine ganz normale Festplatte aussehen, ist sie aber nicht. Vertraue dieser Abstraktion nicht und wenn Du Dich nicht mit der SSD Technologie beschäftigen möchtest, dann gibt sie schnell wieder zurück und bleib bei Deiner alten Festplatte.
Carsten, einer „Abstraktion nicht zu vertrauen“ ist schon mal das erste Problem – einer mit dem ich oft zu kämpfen habe. Im SSD-Fall ist der richtige Weg eine Abstraktion „Datenträger“ zu schaffen, dessen Implementierung „SSD“ die Besonderheiten des Mediums berücksichtigt.
Meine These ist: Erst die Existenz von solchen Abstraktionen (denen man aber vertrauen muss) macht es überhaupt möglich, eine vernünftige Verteilung von Wissen und Zuständigkeiten in einem Team zu realisieren.
Wenn die Abstraktion „leaky“ ist, muss man das Problem kommunizieren, anstatt (was bei uns bei leider traditionell der Fall ist) den Debugger anzuwerfen, stunden- oder tagelang die konkrete Implementierung analysieren und dann indirekt gegen die Implementierung anstatt gegen die Schnittstelle zu programmieren. Ich bin dann als Autor dazu verdammt, den Spagat zwischen Anwendungen die existierende „Leaks“ ausnutzen und einer Korrektur oder Redesign zu meistern…
Hm, ich verspüre große Lust, den letzten Absatz aus Ralfs post auf ein DIN-A1 Poster zu drucken und diesen des Nachts an die Eingangstür zu unserer Entwicklungsabteilung zu kleben… : Eine Branche die nach Höchstleistungen ruft, muss auch konsequent über die Bedingungen für Höchstleistungen nachdenken. Alles andere ist Kinderkram.
@Anonym: Abstraktionen zu vertrauen, wie Du sagst, halte ich für grob fahrlässig. Machst Du wahrscheinlich auch nicht. Stattdessen wirst Du umfangreiche Tests vorhalten, die Dir sicherstellen, dass eine Komponente so funktioniert, wie Du es erwartest.
Die Tatsache, dass „abstractions leaky“ seien, ist zunächst einmal nichts weiter als eine empirische Beobachtung. Dass beispielsweise die Abstraktion „Garbage Collection“ leaky ist, habe ich bereits schon einmal schmerzlich erlebt.
Architektur oder Abstraktion schafft Organisation. Viel Organisation ist aber nicht gleich viel gut. Denn an den Schnittstellen der Organisationseinheiten habe ich Integrationsaufwände. Das ist jetzt gar nicht mal technisch gemeint: unserer Rechnungswesenabteilung abstrahiert nur zu einem bestimmten Grad vom unserem eigentlichen Geschäftszweck. Die Abstraktion „Rechnungswesen“ ist leaky; wir müssen uns permanent mit denen abstimmen, haben also Integrationsaufwände.
Erst die Akzeptanz der Tatsache, dass „abstractions leaky“ und mithin das Wissen um die Beschränktheit von Architekturen/Organisationen, versesetzt uns in die Lage Umstände zu verbessern. Im Beispiel „Garbage Collection“ hat es dazu geführt, dass wir umfangreiche Belastungstests eingeführt haben.
Du kannst dies natürlich auch ignorieren und Zettel mit schlauen Sprüchen an die Wand kleben. Es kann dann aber sein, dass dann keiner mehr mit Dir sprechen will. Oder ist das vielleicht jetzt schon so und das ist das Problem?
@Carsten: Abstraktionen nicht trauen? Das klingt am Ende nach Mikromanagement.
Aber einerlei. Hier gehts ja um zweierlei.
1. Eine Abstraktion trauen, die man vorgesetzt bekommt.
2. Abstraktionen selbst bauen.
Wenn du eine neue Abstraktion vorgesetzt bekommst (z.B. GC) und keine Ahnung hast, wie weit du der vertrauen kannst, dann musst du erstmal Vertrauen schaffen. Das ist normal.
Wer sollte dieses Vertrauen aber aufbauen? Der Technologieexperte, d.h. der, der sich mit diesem Teil der Infrastruktur am besten auskennt.
Und dann? Dann schafft genau dieser Technologieexperte aufgrund seines Vertrauens eine Abstraktion im Sinne der Domäne. Wie die aussehen soll, sagen die Domänenexperten. "Wünsch dir was" ist das Spiel, so wie mit allen Kontrakten.
Da kann der Technologieexperte natürlich Einspruch erheben und sagen, dies oder das sei schwer zu machen. Aber am Ende sieht der Kontrakt der domänenspezifisch geschaffenen Abstraktion so aus, wie die Domänenexperten es wollen. D.h. der Technologieexperte muss keine (großartige) Ahnung haben von der Domäne.
Umgekehrt müssen die Domänenexperten keine großartige Ahnung haben von der gekapselten Technologie.
Sie müssen sich verständigen können; aber sie bleiben Experten in ihren je eigenen Bereichen.
So ist das überall in der Welt. Und niemand behauptet, dass die Abstimmung immer einfach ist. Wer allerdings Höchstleistungen will, kommt nicht drumherum.
Da kann sich die Softwareentwicklung natürlich gekränkt in die Ecke stellen und ewig behaupten, sie sei ja soooo anders und bei ihr funktioniere dererlei Arbeitsteilung nicht. Doch bis mir das mal einer "bewiesen" hat, behaupte ich, dass es doch funktioniert. Das bin ich auch gern bereit zu demonstrieren.
-Ralf
PS: Bis zum Beweis des Gegenteils behaupte ich übrigens auch, dass es dafür weltweit schon sehr viele Beispiele gibt. Das sind nämlich größere OSS Projekte. Man glaube doch nicht, dass darin dieselben Leute aller Orte herumfuhrwerken. Nein, nein, da sucht sich vielmehr jeder die Bereiche raus, in denen er Experte ist. Einer der TCP/Socket Experte ist wird bei Linux kaum einen Beitrag zu sed leisten usw. Und niemand zwingt ihn dazu.
Ja, ja, jetzt höre ich wieder die Einwände, dass das alles mit kleinen Teams ja nicht ginge. Stimmt - bis zu einem gewissen Grad. In kleinen Teams muss jeder einzelne breiter aufgestellt sein als in großen.
Ohne dass jedoch kleine Teams mal demonstriert haben, dass sie eine vernünftige Architektur planen können, gibt es ja auch keine Alternative.
Mein Argument ist ja gerade, dass gute Architektur die Voraussetzung ist für eine bessere Organisation. Den Spieß sozusagen umdrehen. Architektur treibt Organisation, nicht umgekehrt, wie es heute der Fall ist.
Ich kann keinen großen Widerspruch erkennen.
Ich verstehe aber nicht „Den Spieß sozusagen umdrehen. Architektur treibt Organisation, nicht umgekehrt, wie es heute der Fall ist.“
Dass Architektur Organisation treibt, verstehe ich. Der Rest ist mir nicht klar.
Kannst Du das erläutern?
@Carsten: Normalerweise ist Architektur das Ergebnis einer Organisationsstruktur. Das sagt Conway´s Law. Organisationen spiegeln sich in ihren Produkten.
Deshalb glaube ich auch, dass die immer wieder geforderten wahrhaft modularen Architekturen nicht (einfach) möglich sind, solange die Organisationen, die sie fordern, nicht selbst eine Haltung der Modularität an den Tag legen.
Und jetzt umgekehrt: Wenn denn eine Arbeitsteilung das ziel ist, also Modularität in der Organisation, vielleicht könnte es ja doch funktionieren, sich da von der Architektur leiten zu lassen. Also in einer größeren Kraftanstrengungen die Architektur schon richtig machen - so dass die Organisation folgen kann.
Henne und Ei mal vertauschen :-) Versuchsweise.
-Ralf
Eine Organisation hat ein Leitmotiv, einen Zeck. Softwarearchitektur muss sich an diesem Zweck orientieren, sie muss bereit sein, Organisation zu veraendern. Damit bin ich einverstanden.
Für den Bereich Business Software sind aber viele Architekturen rein technisch getrieben. Die Austauschbarkeit von NHibernate Fachleuten ist eine Aspekt (oder kann einer sein), für die Architektur ist sie aber nachrangig.
Kommentar veröffentlichen