Bound in Space - Skizze der Kommunikation in einem Application Space

Komponenten verteilen, Komponenten parallel arbeiten lassen und überhaupt Software aus Komponenten aufbauen sollte viel, viel einfacher werden. Denn nur dadurch würden sich diese Konzepte breiter durchsetzen. Und nur dadurch würde Software in größerer Menge performanter, skalierbarer, testbarer, evolvierbarer. Dafür habe ich in meinem gestrigen Posting eine Lanze gebrochen.

Heute möchte ich zu dieser Vision eines Application Space (AppSpace) ein Bild zeichnen. Ich stelle mir vor, dass Software in Zukunft sehr einheitlich und ganz grundsätzlich so organisiert sein sollte:

Die Grundbausteine von Software sind Komponenten. (Klassen sind auch wichtig, aber unterhalb der Wahrnehmungsschwelle von Softwarearchitekten.) Definieren wir sie einfach mal als binäre Codeeinheiten mit separater Leistungsbeschreibung (Kontrakt). Wenn Sie jetzt "Assembly" denken, liegen Sie nicht falsch.

Diese Komponenten "leben und arbeiten" in etwas, das ich mal Compartment nennen. Solche "Abteile" teilen einen Raum, deshalb finde ich den Begriff ganz passend in Bezug auf die Raum-Metapher, die hinter Application Space steht.

Wie diese Komponenten in den Abteilen aufgehängt sind, ist zunächst einmal nicht so wichtig. Hauptsache, sie haben erstmal ein "Zuhause", in dem manche "zusammen leben" und andere eben in anderen "Zuhauses". (Hm... vielleicht wäre "Appartment" besser als "Compartment"? Dann könnten Komponenten in einer WG leben :-)

Innerhalb der Compartments können Komponenten direkt miteinander kommunizieren, einfach über Methodenaufruf. Sie liegen im selben "Abteil" dicht beisammen (im selben Adressraum) und können daher den Stack nutzen. Alles ist, wie Sie es kennen und lieben. Einzig, die Verbindung zwischen zwei Komponenten wird durch einen DI Framework bzw. Microkernel hergestellt. Den bietet das Compartment als komponentenumfassender Kontext; das ist eine seiner Infrastrukturleistungen.

Wie Sie Compartments auf Prozesse oder Maschienen oder gar Netzwerke verteilen, ist zunächst einmal unerheblich. Das sind Feinheiten des Deployments. In einem AppSpace gilt: Was in einem Compartment gehostet wird, liegt nah beieinander in einem Adressraum, der direkte Kommunikation erlaubt. Deshalb können Sie auch entscheiden, ob Compartments das noch durch eigene AppDomains unterstreichen sollen. Kann sein, muss aber nicht.

Fangen Sie mit 3 Compartments in einem Prozess an und verteilen Sie sie später auf 3 Prozesse. Oder führen Sie Redundanz ein, indem Sie sie auf 7 Prozesse verteilen. Welcher Art die Prozesse sind - also IIS oder NT Service oder Console EXE usw. - ist dabei nicht so wichtig. Diese Compartment Hosts müssen einfach zum Zweck der darin "lebenden" Komponenten passen.

Wegen dieser Flexibilität fehlen im obigen Bild auch Prozesse und Maschinen und Netzwerke. Denn das Credo des AppSpace ist, dass diese Deploymenteinheiten zweitrangig sind. Erstrangig ist hingegen, ob eine Komponente synchron und nah bei anderen läuft oder asynchron und fern von anderen. Darüber gibt ein AppSpace-Diagramm jedoch Auskunft.

Synchrone Komponenten sind einfach - selbst wenn Sie DI benutzen. Asynchrone Komponenten jedoch... da wird es knifflig. Wie sollen die miteinander kommunizieren? Die Asynchronizität beginnt schon, wenn zwei Objekte auf separaten Threads laufen. Sie wird schlimmer, wenn diese Objekte in verschiedenen AppDomains hängen und noch übler wird´s, wenn sie durch Prozesse, Maschinenen oder Netzwerke getrennt sind.

Heute stehen dafür eine Reihen unterschiedlicher Technologien zur Verfügung. Da gibt es eine Pallette von Möglichkeiten, Parallelität einzuführen. Wenn Ihre Anwendung in mehrere Prozesse zerlegt ist, ergibt sich die ganz natürlich. Ansonsten können Sie Threads aber auch von Hand auf die eine oder andere Weise erzeugen. Aber Achtung: nicht zuviele, sonst ist die ganze Asynchronizität kontraproduktiv.

Vielfältiger sind die Möglichkeiten für die Kommunikation zwischen den Threads. Die kann über´s Dateisystem laufen oder gemeinsame Objekte (shared memory), rohe TCP Sockets funktionieren genauso wie WCF.

Diese Vielfalt der Kommunikationsmedien, so verständlich sie ist, halte ich nun inzwischen für nachteilig. Niemand kennt sich mehr aus. Ich plädiere daher für eine radikale Vereinfachung durch Vereinheitlichung, mit der sich vielleicht 80% aller verteilter Kommunikation lösen lässt. Nein, nicht 100%, aber ich sag mal optimistisch 80%. Mir liegt daran, Asychronizität "den Massen" nahezubringen und nicht wirklich jedem zu jeder Zeit die Entscheidung zwischen vielen Optionen aufzubürden.

Die Technologievielfalt kann und soll also erhalten bleiben - unter der Haube. Wer sie braucht, um im Einzelfall mal performanter zu sein, hat sie dann. Aber der allgemeine Fall wird durch Abstraktion einfacher. So wie es schon viele Male in der Geschichte der Softwareentwicklung geschehen ist. Beispiel SQL, Beispiel O/R Mapping, Beispiel GDI+ usw. usf.

Wie soll nun diese Vereinfachung der Kommunikation zwischen asynchronen Komponenten aussehen? Das obige Bild zeigt es: Neben der direkten Kommunikation innerhalb eines Compartments gibt es die indirekte (!) zwischen Compartments. Indirekt ist sie immer, wenn Komponenten asynchron zu anderen laufen. (Insofern kann auch innerhalb desselben Compartments indirekt kommuniziert werden.)

Indirekte Kommunikation bedeutet, dass eine Client-Komponente nicht (!) direkt mit einer Service-Komponente spricht. Client und asynchroner Service sind vielmehr immer (!) durch einen Vermittler verbunden. Im einfachsten Fall ist dieser Vermittler eine Warteschlange, eine Queue. Aber das ist nur der einfachste oder übliche Fall. Ein AppSpace ist nicht darauf beschränkt. Zwischen Client und Service können alle möglichen Vermittlerformen stehen: Queue, Stack, Baum, relationale Tabelle, Liste, Array, Dictionary... you name it.

Gemeinsam ist allen Vermittlern nur, dass sie Datenstrukturen sind. Die eine Komponente manipuliert sie, die andere beobachtet sie. Und dann können die Rollen wechseln. Beobachtung ist entweder aktiv (polling) oder passiv (Ereignisgesteuert, Stichwort: EDA).

Diese Datenstrukturen existieren virtuell im AppSpace und sind für alle Komponenten in allen Compartments grundsätzlich zugänglich. Deshalb liegen die Winkel der asynchronen Kommunikation im obigen Bild im Space.

Implementationstechnisch sieht das jedoch anders aus. Da liegen die Vermittlerdatenstrukturen ebenfalls in Compartments, sozusagen in einem Gürtel um sie herum.

Letztlich ist es aber egal, wo genau diese Datenstrukturen, die Container hängen. Sie können nach dem Prinzip "write remote, read local" immer beim asynchronen Service angesiedelt sein (also im Compartment der Pfeilspitze einer Verbindung zwischen zwei Komponenten). Oder sie können auch in einem ganz anderen Compartment liegen:

Container werden im AppSpace gegenüber Anwendungscode nicht durch eine Adresse repräsentiert, sondern durch einen AppSpace-globalen Namen.

Der AppSpace macht Komponenten insofern nicht nur durch DI implementationsunabhängig voneinander, sondern auch unabhängig in Bezug auf Ort und Zeit. Durch Container als Vermittler stehen Komponenten nicht mehr direkt in Kontakt, d.h. beide müssen nicht mehr gleichzeitig "anwesend" sein im AppSpace. Und AppSpace-weite Containernamen verbergen den genauen Ort (Compartment, AppDomain, Prozess, Maschine, Netzwerk), an dem eine asynchrone Komponente "lebt".

Nach der grundlegenden Entscheidung, ob Komponenten synchron oder asynchron kommunizieren sollen, kann die Topologie sich bei asynchronen Komponenten sehr weitreichend ändern, d.h. wechselnden Bedürfnissen anpassen, ohne dass Client-Anwendungscode davon betroffen wäre.

Der AppSpace soll also die Vorteile von EDA verallgemeinern (nicht nur Queues, sondern auch andere Datenstrukturen, auf die man lauschen kann) und mit Komponentenorientierung wie Computing in/via the Cloud verschmelzen. Ich sehe ihn als Aggregat vieler existierender Technologien, die er unter einer Abstraktionsdecke versteckt.

Insofern bietet ein AppSpace einen schönen Migrationspfad: Ich kann mit ihm anfangen und erstmal nur Komponenten in einem Compartment verbinden. Dann kann ich in die Asynchronizität klein einsteigen, indem ich mal im selben Compartment eine Komponente asynchron mache. Und dann kann ich die Asynchronizität ausdehnen auf mehr Komponenten. Und dann kann ich diese Komponenten verteilen. Schließlich laufen sie auf vielen Rechnern übers LAN oder gar Internet verteilt. Ohne, dass mein Applikationscode davon etwas merken würde. Denn sobald ich einmal mit der asynchronen, containervermittelten Kommunikation angefangen habe, skaliert die von der cross-thread bis zur cross-firewall Kommunikation. Das Geheimnis liegt darin, dass sie nicht nur nachrichtenorientiert, sondern eben datenstrukturvermittelt ist.

Asynchrone Architekturen einfacher machen - Umriss eines Application Space

In meiner vorherigen Posting habe ich ja eine Lanze für mehr Asynchronizität gebrochen. Die halte ich für wünschenswert und notwendig - aber einfach herzustellen ist sie heute noch nicht. Man kann es, es gibt viele "Splittertechnologien", aber die sind nicht "at our fingertips".

Bezüglich asynchroner Architekturen sind wir noch in einer "vor-bequemen Zeit", also etwa wie bei der Persistenz so um 2002 herum. Da gab es noch keine O/R Mapper für .NET und kein noch einfacher zu nutzendes db4o oder Persistor.Net.

Der ThreadPool, der AsyncOperationManager, die CCR, WCF... diese und andere Technologien machen es uns heute schon einfacher, asynchron sowohl lokal wie verteilt zu arbeiten. Dennoch: insgesamt sind sie mir noch zu kompliziert. Das liegt zum Teil an den APIs - die wollen jeder für sich one-size-fits-all Lösungen sein -, andererseits liegts am Konzept dahinter. WCF mag zwar nachrichtenorientiert sein - sehen tut man das aber nicht wirklich. Da helfen auch keine Data Contracts.

Um die gläserne Decke der Synchronizität nicht zu durchbrechen, sondern sie schlicht auf dem Weg zu mehr Performance und Skalierbarkeit zu umgehen, wünsche ich mir deshalb eine Infrastruktur, die Asynchronizität viel einfacher macht. Hier mal ein paar Punkte, die sie für mich minimal erfüllen müsste:

• Einfache lokale Kommunikation zwischen Komponenten; Stichworte: Contract-first Design, Dependency Injection und Microkernel
• Einfache verteilte Kommunikation; Stichworte: Nachrichtenorientierung, Event-Driven Architecture, "Datenstrukturorientierung" statt Serviceorientierung
• Einfache Änderung der Topologie von Netzen verteilter Komponenten; Stichworte: Service Discovery, Unterstützung verschiedener Transportprotokolle, location transparency
• Einfache Verteilung "in the cloud"; Stichworte: Tunnelung von NAT und Firewalls
• Einfaches Hosting von Komponenten in unterschiedlichen AppDomains
• Einfache Verteilung der Arbeit auf mehrere Threads

Dahinter stehen für mich ein paar Ansprüche, wie ich arbeiten/denken können möchte:

- Ich glaube, dass echte Komponentenorientierung durch Infrastruktur unterstützt werden muss. Sie stellt sich nicht von allein ein, sondern muss quasi durch Technologie "nahegelegt" werden. Visual Studio oder der .NET Framework tun das bisher nicht.

- Eine komponentenorientierte Infrastruktur soll das Laden von Komponenten einfach machen und auch die Kommunikation zwischen Komponenten.

- Bei der Komponentenorientierung möchte ich zunächst nicht zwischen lokalen und entfernten Komponenten unterscheiden. Beide sollten also durch dieselbe Infrastruktur unterstützt werden.

- Für die Kommunikation zwischen Komponenten glaube ich allerdings fest daran, dass sie erstens zwischen lokalen und verteilten Komponenten ganz anders (!) aussehen sollte (s. dazu auch meinen Beitrag in "SOA Expertenwissen"). Und zweitens glaube ich, dass sie für verteilte Komponenten viel einfacher und einheitlicher werden sollte, als mit .NET Remoting oder auch WCF der Fall. Diese Einheitlichkeit und Einfachheit mag dann nicht 100% aller Probleme lösen, aber 80% sollten damit viel leichter zu erschlagen sein.

- Verteilte Komponenten möchte ich genauso einfach auf verschiedenen Threads wie in verschiedenen AppDomains oder auf verschiedenen Rechnern laufen lassen. Selbst wenn das Internet - the cloud - zwischen ihnen stehen sollte, darf sich nichts an ihrer Kommunikation ändern.

- Für einfache Verteilung ist es auch wichtig, dass ich die Wahl habe zwischen Push und Pull, um an Informationen zu kommen. Ich möchte selbst Last ganz einfach verteilen können, also nicht auf eine Cluster-Infrastruktur angewiesen sein. Warum kann ich nicht einfach heute einen Rechner als Server irgendwo in der Welt hinstellen und morgen 2, 3, 4 weitere irgendwo anders in der Welt - und alle teilen sich die Last? Klar, das geht schon... aber nicht so einfach. Da kann ich nicht nur schnell mal 'nen Service Contract mit WCF aufsetzen. Solche Flexibilität möchte ich aber haben.

Bottom line: Für mich müssen "Komponentendenke", Verteilung auf kurze und weite Distanz und Parallelität in einem einfachen 80%-Werkzeug zusammenkommen. Dabei gehts nicht darum, ein Rad neu zu erfinden, sondern vorhandene Ränder (endlich) zu einem Auto für jedermann zusammenzustecken. Bekanntes, Vertrautest, Bewährtes soll in Synergie zusammenarbeiten und in der Summe mehr sein, als die Teile vermuten lassen.

Alles beginnt dabei mit... Einfachheit. Wir brauchen heute nicht leistungsfähigere Technologien, sondern vor allem einfachere. Sonst bleiben zuviele Entwickler zurück. Sie haben nicht die Zeit, sich in Kompliziertes einzuarbeiten. Kommen die Aspekte Komponentenorientierung, Verteilung und Parallelität nicht zusammen, dann nutzen nur wenige das Potenzial, das in Multi-Core Prozessoren und dem universalen Internet steckt.

Mit einem Application Space (AppSpace) wie oben skizziert, sähe das jedoch anders aus. (Ich könnte ihn auch Integration Space oder Component Space nennen. Application Space klingt für mich aber im Augenblick handlicher, weniger out-spaced ;-) Er wäre für komponentenorientierte, asynchrone Software das, was db4o für die Persistenz ist: ein "Ermöglicher" (enabler), der für viele erstmals etwas in Reichweite rückt, was ihnen bis dahin akademisch oder schwierig erschienen oder gar unbekannt war.

Synchronizität - Die gläserne Decke der Softwareentwicklung

Im Grunde kann man alle Probleme durch synchrone und sequenzielle Verarbeitung lösen. Das dauert dann manchmal zwar ein wenig, aber es geht. So bringt es uns auch jeder Programmierkurs bei. Ein Befehl folgt auf den anderen. Ein Unterprogramm ruft das nächste und wartet auf dessen Ergebnis, bevor es selbst weitermacht. Unterprogramme sind insofern fast nur syntactic sugar, denn ihr Code könnte auch am Aufrufort eingesetzt stehen. Compiler tun auch genau das, wenn es ihnen angemessen erscheint. Das heißt dann Inlining.

Was aber, wenn so eine sequenzielle Verarbeitung zu langsam ist? Na, dann macht man sie halt schneller, indem man den Algorithmus verbessert (z.B. Quick Sort statt Bubble Sort) oder einen schnelleren Prozessor kauft. Das ist dann so, als würde man einen schmächtigen Maurer ins Fitnessstudio schicken, damit er in Zukunft schneller Steine schleppen kann. Oder man ersetzt ihn gleich durch ein Förderband.

Wie effizient kann eine Implementation aber werden? Irgendwann ist der beste sequenzielle Algorithmus implementiert. Wie schnell können Prozessoren werden? Irgendwann ist da eine physikalische Grenze erreicht - wie es gerade so um die 3-6 GHz zu sein scheint.  Genauso ist es mit der Kraft bei Maurern und der Schnelligkeit von Föderbändern. Da gibt es einfach ein Ende der Fahnenstange. Dann hilft nicht mehr Quantität. Nein, dann muss sich die Qualität ändern.

Angekommen ist das in der Programmierausbildung aber eher noch nicht, würde ich sagen. Denn es herrscht immer noch das Denken in synchronen und sequenziellen Abläufen vor, die man eben versucht durch quantitative Einflussnahme zu beschleunigen. Weniger Instruktionen oder schnellere Prozessoren stehen als Wunschvorstellung hinter den Klagen darüber, dass mal wieder der Aufbau eines Fensters zu lange dauert oder die Datenbank zu langsam ist.

Dabei wussten schon die alten Ägypter, dass man Pyramiden nicht schneller baut, indem man die Arbeiter erstmal ins Bodybuilding-Studio schickt. Die Pyramiden wurden von normalen Einwohnern Ägyptens gebaut. Genauso wie der Otto Versand vor allem Durchschnittsmenschen zur Bewältigung aller durch Menschen durchzuführenden Tätigkeiten einstellt. Sowohl die Ägypter wie der Otto Versand müssen halt damit leben, dass es vor allem normale Menschen gibt. Das liegt in der Definition von normal. Exzeptionelle Menschen - besonders starke, schnelle oder kluge - gibt es nur vergleichsweise wenige. Man kann sie daher nicht in größerer Menge rekrutieren und schon gar nicht bezahlen.

Die Lösung für Geschwindigkeitsprobleme liegt daher nicht im scale-up, in der Effizienzsteigerung von etwas Einzelnem, d.h. einem Arbeiter, einem Förderband, einem Rechner.

Die wahre Lösung liegt vielmehr in der Parallelisierung. "Normale" Ressourcen gleichzeitig an einer Aufgabe arbeiten zu lassen - z.B. viele normale Ägyptische Bauern an einer Pyramide oder Hamburger Bürger beim Otto Versand -, ist letztlich der weiter führende Weg, um dauerhaft schnell zu sein.

Beim scale-out stehen viele billige Ressourcen nebeneinander und arbeiten parallel an der Bewältigung einer Gesamtaufgabe. Statt viel Zeit in die Optimierung von Algorithmen zu stecken oder viel Geld in eine noch schnellere Hardware, sollten Sie überlegen, inwiefern die abzuarbeitenden Schritte in Ihrer Software parallelisierbar sind.

Das geht nicht, glauben Sie, weil Sie keine riesige ERP-Software für komplexe Geschäftsprozesse schreiben? Sie entwickeln doch nur ein kleines CRM - bei dem allerdings der Programmstart und auch der Wechsel zwischen Bearbeitungsmaske und Suchdialog an Performance zu wünschen übrig lassen.

Aber warum soll den nicht auch in solcher Software, die scheinbar nur aus sequenziellen, synchronen Verarbeitungsschritten besteht, etwas Parallelität möglich sein?

• Beispiel Programmstart: Alles, was beim Programmstart nicht visuell ist (z.B. das Laden von Lookup-Daten), kann parallel zur Anzeige eines ersten Dialogs im Hintergrund passieren.
• Beispiel Suchen: Abfragen können im Hintergrund laufen, während das User Interface weiterhin bedienbar bleibt. Abfrageergebnisse können häppchenweise ans UI geliefert werden; niemand sollte darauf warten müssen, dass auch noch der tausendste Datensatz dem Grid hinzugefügt ist, bevor er weiterarbeiten kann.
• Beispiel Bearbeitungsende: Wenn am Ende der Bearbeitung Daten zu speichern sind, dann kann das parallel zur weiteren Bedienung geschehen. Warum sollte ich als Anwender darauf warten, dass die Daten auch vollständig und korrekt in der Datenbank angekommen sind? Das ist doch selbstverständlich.

Falls Sie diese Beispiele nicht überzeugen, biete ich an, dass ich Ihre Anwendung daraufhin untersuche, wo es Parallelisierungspotenzial gibt. Ich bin sicher, da gibt es einiges zu entdecken.

Warum nutzen wir das große scale-out Potenzial denn aber nicht in unseren Anwendungen? Gelegentlich mag es daran liegen, dass sich ein Algorithmus nicht so leicht parallelisieren lässt. Das halte ich aber für ein Detailproblem. Vor allem sehe ich den Grund nämlich in einem Mangel an 1. Bewusstsein und 2. einfacher (!) Technologie.

Sie können Programmteile heute selbstverständlich parallel machen. Asynchronizität ist natürlich möglich. Aber sie ist trotz aller Bemühungen der .NET-Framework-Entwickler noch nicht wirklich, wirklich einfach. Auch sind die Lösungen verteilt: ein bisschen steckt in System.Threading, ein bisschen in der CCR, ein bisschen in WCF usw.

Ich halte daher eine Konsolidierung für geboten. Das, was an Technologieschnipseln vorhanden ist, sollte unter einem intuitiven, einfach einzusetzenden Dach zusammengefasst werden. Dazu müsste dann aber wohl noch etwas Theorie kommt. Wir müssen Software erstmal aus grundsätzlich asynchronen Bausteinen zusammengesetzt denken.

Aber ich sehe Licht am Horizont... :-) Mit einem Architekturansatz wie "Systemorientierten Programmierung" (SOP) und einer Zusammenführung von DI Frameworks mit Enterprise Service Bus (ESB) und Space Based Computing/Architecture (SBC/SBA) könnte es besser werden. Bei SOP stehen Softwarezellen als asynchrone und verteilte Codeeinheiten am Anfang, so dass das Denken in Richtung mehr Parallelität und flexibler Architekturen geleitet wird. Und eine Vereinigung von EDA-Konzepten (Event Driven Architecture) könnte das Hosting und die Kommunikation von Softwarezellen vereinfachen - im Großen wie im Kleinen (innerhalb von Prozessen).

Aber davon ein andermal... Einstweilen Achtung vor der gläsernen Decke "Synchronizität"! Synchrone Verarbeitung durch scale-up zu beschleunigen, führt nicht immer so weit, wie Sie denken mögen.

Neues Blog zum Thema Softwarearchitektur - The Architect´s Napkin

So, nun kann ich es nicht länger aufschieben. Ich muss einfach mal meine Ideen zum Thema Softwarearchitektur zusammenfassen. Immer wieder fragen mich meine Beratungskunden, ob ich nicht ein Buch für sie hätte, in dem sie das, worüber wir sprechen und was wir gemeinsam üben, nachlesen könnten.

Nicht, dass ich nicht schon über meine Ideen oder gar meine "Methode" geschrieben hätte. In meinem englischen Blog hatte ich die Softwarezellen eingeführt, hier im deutschen Blog dann "Software als System". In der dotnetpro beschreibe ich auch immer wieder Aspekte der Softwarearchitektur. Allein ein Ort, an dem alles gesammelt zu finden ist, fehlte bisher. Das soll nun mit meinem neuen Blog The Architect´s Napkin - "Des Architekten Serviette" anders werden. (Sorry, ich sah mich genötigt, es auf Englisch zu verfassen, da ich nur so die Chance habe, eine größere Leserschaft zu finden, die vielleicht mit mir auch über dieses wichtige Thema und meinen Ansatz diskutiert.)

In dem Blog entwickle ich meine Ideen nochmal von Grund auf, fasse zusammen, was ich bisher schon geschrieben habe und füge dann natürlich auch Neues, Unveröffentlichtes hinzu. Die Reihenfolge ist dort lose - Theorie und Praxis werden sich abwechseln -, aber der Fokus ist klar. Ich habe sozusagen meine Blog-Aktivitäten ein weiteres Mal partitioniert bzw. refaktorisiert. So steigt die Kohäsion, die thematische Nähe in den jeweiligen Blogs.

Unmittelbaren Anstoß für diese Aktion war die Lektüre von "The Back of the Napkin", das mit klar gemacht hat, wie wichtig Visualisierungen sind und wie wichtig darüber hinaus einfache Visualisierungen sind. Denn Architektur scheint auch immer schwieriger als nötig wahrgenommen zu werden, weil eine diffuse Angst herrscht, ob man denn auch alle Darstellungsansprüche erfüllen kann.

Dem und jedem anderen Nimbus von Softwarearchitektur als Elfeinbeinturmkunst werfe ich deshalb mit einer sehr konsequent minimalistischen Darstellungsweise entgegen: alle Architekturdiagramme finden Platz auf einer Serviette.

Das sieht dann z.B. so aus

oder so

Des Gedanke dahinter: Wenn etwas nicht auf eine Serviette in übersichtlicher Weise passt, dann ist es schon zu kompliziert. Architekturdiagramme sollen nicht nur gezeichnet, sondern vor allem verstanden werden. Deshalb sollten Softwarearchitekten darauf achten, ihre Gesprächspartner nicht mit visuellen und konzeptionellen Details zu überfordern.

So meine These, die ich versuchen werde, mit meinem Blog zu bestätigen. Ich würde mich freuen, wenn Sie mitlesen und mitdiskutieren würden. Bis bald bei...

The Architect´s Napkin

Ich würd so gern, aber... - 4 Gründe gegen das "aber" zum Schreiben

Auf mein gestriges Posting für mehr Klarheit und Nutzen bei Zeitschriftenpublikationen hat mir ein allseits bekannter "Community Thought Leader" betroffen und zerknirscht wie folgt geschrieben:

... die alte Leier... wie gerne würde ich mehr schreiben - ich (und andere freilich auch) habe so viel zu erzählen (Bezug nehmend auf dem Kommentar von Haggy).
Nur fehlt inmitten der Projekte einfach die Zeit qualitativ hochwertiges Material zu produzieren. Und mit dem (auch von Dir angesprochenen) Vergütungsmodell haut das eh' nicht hin.

Und die Artikel bzw. Autoren, die derzeit schreiben (also ich überfliege die dnp derzeit nur), kann man leider echt in der Pfeife rauchen (prominente Ausnahmen bestätigen diese Regel ;)).
Warum? Weil die "anderen", etablierteren scheinbar damit beschäftigt sind, Licht ins Dunkel all dieser auftretenden Fragen zu bringen - und zwar vor Ort in den Projekten, nicht im WORD Doc.

Glaube, ich denke oft drüber nach, wie man hier einen Kompromiss finden könnte - ich bin (noch) zu keiner Lösung gekommen.

Mich hat es sehr gefreut, dass da jemand sofort reagiert hat, den ich also Kompetenzträger und auch als Autor sehr schätze. Das ist doch schonmal ein Ansatz. Ihm ist die Situation nicht egal, aber er sieht keinen Ausweg. Das System scheint unveränderbar. Eine sehr nachvollziehbare Haltung. Wenn sich alles so schnell bewegt, wie soll man da innehalten und den Kurs neu bestimmen. Schon das, geschweige denn zu schreiben, kostet wertvolle Projektzeit.

Nachstehend meine Antwort an den Experten, mit der ich ihm in dieser eingefahrenen Situation einen Impuls geben möchte, um etwas zu verändern. Ich publiziere sie nun auch hier, weil ich denke, dass andere ebenfalls ein solches Dilemma spüren. Vielleicht kann ich auf diese Weise mehr Experten ermuntern, es mit der Publikation (wieder) zu versuchen. Und auch mehr ist möglich. Wir können uns auch zusammen tun, um konzertierter etwas zu bewegen. Mag altmodisch klingen, so nach 19. Jahrhundert ;-) Aber ist in Zeiten von Web und Flash Mob eigentlich hoch aktuell.

Also, hier meine Gedanken als Antwort auf die obige Email:

Freut mich, dass du dir diese Gedanken machst.
Und glaub mir, ich kann verstehen, dass du immer wieder so entscheidest, wie du es tust: für das Projekt, gegen den Artikel.

Aus mehreren Gründen halte ich das dann aber doch für die zweitbeste Entscheidung :-)

1. Erfolg: Publikationen bringen Sichtbarkeit. Sichtbarkeit bringt Aufträge.
Nun kannst du sagen, dass du mehr Aufträge nicht gebrauchen kannst. Aber deine Firma ist ein Unternehmen, dass früher oder später wachsen will und/oder muss.
Das ist dann leichter, wenn alle oder wichtige Mitglieder von deiner Firma breit sichtbar sind.

2. Effektivität und Skalierbarkeit: Publikationen verbreiten die Frohbotschaft. Sie nutzen dem guten Thema.
Wenn du von einem Thema überzeugt bist und gar noch denkst, dass andere darüber ungenügend berichten, dann kann dir nur am Herzen liegen, darüber zu publizieren. Du erreichst einfach mehr Menschen. Publikation ist effektiver als referieren oder gar in einem Projekt zu sitzen.
Solltest du also ein Sendungsbewusstsein haben, dann kommst du an Publikationen nicht vorbei, um es zu befriedigen.

3. Qualitätssicherung: Publikationen dienen nicht nur dem Lehren, sondern auch dem Lernen.
Wie in meiner letzten dotnetpro Sandbox ausgeführt, lernst du bei Publikationen immer selbst etwas. Du selbst wirst durch das Publizieren besser. Du denkst nach, du ordnest, du forschst. In projekten oder für vorträge tust du das auch. Publikationen sind aber ein Mittel, mit dem du dich noch weiter bringen kannst. Darin formulierst du aus, du legst dich also mehr fest, als in einem Vortrag. Das hat Wert für die Sicherheit deiner Aussagen. Du gehst nämlich bewusster mit ihnen um. In einem Vortrag mal etwas ausprobieren und "so daher sagen" ist gut. In einer Publikation "gewählter sprechen" ist aber auch gut. Der Mix machts.

4. Ganzheitlichkeit: Schreiben führt zu einer ausgewogeneren persönlichen Entwicklung Der Mensch ist mehr als Körper und Arbeit. Deshalb lieben wir die Romantik und die Freizeit. Aber auch innerhalb der Arbeit ist der Mensch mehr als Technik. Wenn du dich durch Lesen und Ausprobieren und Projekte weiterbildest, dann ist das gut und unverzichtbar. Du nimmst auf und produzierst. In Vorträgen und Diskussionen gibt du dann weiter. Ohne Bilder oder Texte bleibt das aber doch recht einseitig. Du arbeitest vor allem linkshemisphärisch. Das funktioniert wie wir sehen ;-) Mit einem Ausgleich würde es aber - so meine These - noch besser sein. Es würde sich besser anfühlen, befriedigender sein. Du wechselst ja auch zwischen Schreibtisch, Sport, Familie. Warum nicht auch zwischen analytischer und kreativer Arbeit wechseln? Programmieren ist auch kreativ. Aber Bilder finden - gezeichnete oder beschriebene - wie bei der Arbeit an einem Text, das ist noch anders kreativ. Das ist eher rechtshemisphärische Arbeit. Mit mehr Publikationen würdest du also auch innerhalb deiner Arbeit ganzheitlicher leben. Das kann nur von Vorteil sein, meine ich. (Ist es nicht verwunderlich, dass viele (oder gar die meisten?) Exzellenten in ihrem technischen/abstrakten Fach auch eine ausgeprägte musische Seite unterhalten (haben)? Schreiben gehört auch auf diese musische Seite.)

Na, wie ist das als Motivation, doch mal wieder mehr zu schreiben? Wir alle würden uns freuen.

Und was das Finazielle angeht... ja, das ist vergleichsweise unmotivierend. Aber auch da lässt sich was machen:

a. Wenn du die obigen Vorteile in Anschlag bringst, ist ein monetärer Lohn der Mühe vielleicht nicht mehr sooo ausschlaggebend, um dir das Schreiben schmackhaft zu machen. Vielleicht kannst du (erstmal) mit einem Kompromiss leben.

b. Die Autorenhonorare sind unterschiedlich und verhandelbar. Bücher werden schlechter als Zeitschriftenartikel bezahlt. Also dann vielleicht mehr in Magazinen als in Büchern publizieren? Und Zeitschriftenhonorare sind verhandelbar. Vielleicht also mal verhandeln.

c. Jenseits einer individuellen Verhandlung kann sich das System ja auch vielleicht verändern. Autoren könnten sich zusammen tun und mehr Honorar fordern. Leser könnten bessere und mehr Autoren fordern und bereit sein, mehr zu zahlen (statt immer nur wieder nach Gratisangeboten zu googlen). Feedback könnte zu Publikationen erfragt werden, um Honorarforderungen zu rechtfertigen oder zu entkräften.

Ich denke, das Honorarsystem muss nicht so bleiben, wie es ist. Bis zum Beweis des Gegenteils glaube ich, dass Leser bereit sind, guten Content auch zu bezahlen. Produziere also gute Publikationen, dann bekommst du auch ein angemessenes Honorar. Früher oder später ;-) Lass uns gern mal über Strategien reden.

Irrweg Advertorial oder: Wo bleiben Nutzen und Klarheit?

Grad hab ich das aktuelle dot.net Magazin 7/8 2008 gelesen und will meine Verstimmung doch einmal äußern. Verstimmt hat mich nämlich der Artikel "Geschäftsregeln für alle" auf Seite 110. Sein Thema ist die Rules Engine ILOG Rules 3.0. Autor ist Jochen Reinelt. Und Jochen Reinelt ist... Angestellter des Herstellers von ILOG Rules, der Firma ILOG.

Nicht, dass das dot.net Magazin diesen Umstand verheimlicht hätte. Die Autorenbeschreibung zeigt das Eigeninteresse des Autors an einer positiven Produktdarstellung auf. Dennoch verstimmt mich der Artikel. Das hat mehrere Gründe:

• Zum einen ist die Darstellung eines Produktes durch den Hersteller immer Werbung. Werbung ist ansonsten in Publikationen immer klar erkennbar oder zumindest gekennzeichnet. Wo sie die Grenze zum redaktionellen Inhalt überschreitet - was legitim ist -, ist sie sonst gewöhnlich mit "Advertorial" überschrieben. Im OBJEKTspektrum gibt es dafür viele Beispiele. Gegen solche Inhalte vom Hersteller ist erstmal auch nichts zu sagen - nur eben halte ich sie für kennzeichnungspflichtig. Der flüchtige Leser bekommt sonst den falschen Eindruck sowohl von der Produktdarstellung wie von der Publikation.
  
• Dann ist da noch der Hub. Grundsätzlich finde ich es nicht schlimm, wenn Hersteller über ihre Produkte sprechen. Wir alle hören gern Microsoft O-Töne. Warum also nicht von anderen Herstellern auch O-Töne? Es verstimmt mich deshalb auch nicht ein O-Ton von ILOG, sondern die Art des O-Tons. Er ist nicht gekennzeichnet - aber vor allem addiert er nichts zu einem Prospekt des Produkts hinzu. Das, was in dem Artikel steht, kann ich auch online lesen. Der Artikel hat damit keinen Hub; er hebt mich nicht über das hinaus, was ich mir auch ohne Probleme anderweitig an Informationen beschaffen kann. Ein kleiner Kasten mit zwei Links zu schon vorhandenem Material auf den ILOG-Seite hätte denselben Effekt gehabt. Und das halte ich für symptomatisch bei Advertorials.

Wenn ich ein unabhängiges Medium wie das dot.net Magazin, die dotnetpro, iX oder OBJEKTspektrum lese, dann wünsche ich mir Klarheit und Nutzen. Ich möchte klar wissen, welche Interessen die Autoren haben, warum sie also sagen, was sie sagen. Bei einem Autor aus dem Hause des Herstellers lese ich dann anders als bei einem unabhängigen.

Vor allem wünsche ich mir aber Nutzen durch die Lektüre. Der ist aber bei Advertorials gewöhnlich und womöglich sogar absichtlich gering. Advertorials sind und bleiben Werbung. Da hilft auch kein längerer Text im Vergleich zu einer herkömmlichen Werbung.

Liefert mir ein Advertorial keinen Nutzen, dann verschwendet es meine Zeit. Je weniger kenntlich der Werbecharakter - wie im aktuellen dot.net Magazin - desto schlimmer. Eine Werbung überblättere ich und wenn nicht, brauche ich 15 Sekunden, um zu entscheiden, ob ich am Produkt interessiert bin. Das Advertorial kommt anders daher.

Wie gesagt, ich bin nicht gegen herstellereigene Aussagen. Wenn z.B. Andreas Kerl in der dotnetpro 6/2008 über den Windows Installer schreibt, dann ist das auch eine Herstelleraussage, denn Andreas ist Angesteller bei Microsoft. Das macht aber nichts, weil er mit seinem Artikel echten Nutzen über übliches Marketing hinaus bietet. Oder beim Professional Developer College ist der Hersteller O-Ton sogar Programm: in der Seminarreihe "Straight from the Horse´s Mouth" kommen nur Chefentwickler und Erfinder von Technologien zu Wort. Ganz bewusst, denn dort liefern sie Insiderinfos. Sie bieten also sehr großen Hub.

Ein Advertorial jedoch, das Nutzen bietet, habe ich noch nicht gelesen. Nicht im dot.net Magazin, nicht im OBJEKTspektrum. Die dotnetpro ist natürlich auch nicht ganz frei von solcherlei. In Ausgabe 7/2007 schrieb Daniel Zientek von InterSystems über das hauseigene Produkt Caché. Der Artikel ist für mich an der Grenze. Er liest sich nicht ausschließlich wie ein Marketingprospekt, auch wenn er daraus Abbildung bezieht. Die Menge an Code spricht für seinen Willen, anwendbaren Nutzen zu bieten. Dennoch ist zu kritisieren, dass auch hier nicht klar sichtbar gemacht wurde, wer Urheber ist.

Unterm Strich: Advertorials halte ich per se für einen Irrweg. O-Töne sind legitim und sogar wichtig - aber dann bitte schön mit echtem Nutzen und auch ein wenig Distanz. Selbstreflektion und auch Selbstkritik stehen dem Hersteller einer Technologie immer gut zu Gesicht. In jedem Fall sollten O-Töne als solche gekennzeichnet sein. Dann kann es nicht zu Missverständnissen kommen.