Software als System I - Motivation

Alle reden von Objektorientierung oder Serviceorientierung – aber was ist Software eigentlich? Da gibt es Quellcode und Maschinencode… Aber Software ist ja nicht das eine oder das andere, sondern alles gehört irgendwie zusammen.

Ich finde dieses „Durcheinander“ zunehmend störend oder gar kontraproduktiv. Es kommt mir manchmal so vor, als würden unterschiedliche Parteien auch über komplett Anderes reden. Da bin ich als Moderator oder Diskussionsteilnehmer auf SOA-orientierten Veranstaltungen wie dem ASG Workshop oder dem CITT Expertengespräch und habe den Eindruck, das ist eine ganz, ganz andere Welt als die von Entwickerevents wie der prio Konferenz der dotnetpro oder der VSone. Als „normaler“ Entwickler ist es schwer, der Servicediskussion zu folgen – und die Vertreter der Serviceorientierung interessieren sich nicht mehr für die „Niederungen“ der „normalen“ Programmierung.

Wissenschafts- oder gesellschaftstheoretisch ist es natürlich verständlich, wenn Fachgebiete ab einer bestimmten Größe Regionen unterschiedlicher „Kultur“ und Sprache ausbilden. Ab einer bestimmten Größe zerfällt das Ganze in Teile, die dann unabhängig von einander weiterwachsen, und später wiederum zerfallen können usw… Jeder dieser Bereiche ist dann ein Spezialgebiet, das mit anderen Berührungspunkte hat, aber ansonsten eben etwas klar unterscheidbar Eigenständiges darstellt. Das hat in anderen Branchen womöglich Jahrhunderte gedauert, bei Software dauert es nur wenige Jahrzehnte und geht immer schneller.

Das ist kein aufzuhaltender, sondern ein ganz natürlicher Prozess. Man kann ihn aber bewusst erleben oder unbewusst. Man kann ihn begrüßen und nutzen oder unter ihm leiden. Ich versuche, ihn bewusst wahrzunehmen, soweit es mir möglich ist, und ihn nutzen bzw. mitgestalten.

Ein Ansatz dabei ist der Versuch, den entstandenen und entstehenden „Regionen“ der Softwarelandschaft (wieder) eine gemeinsame Grundlage zu geben. Ich möchte sie kommunikationsfähig halten. Die Entwicklung zu immer größerer Differenzierung ist nicht aufzuhalten und auch gut – aber darüber sollte nicht der gemeinsame Ursprung vergessen werden. Ich meine daher, dass es an der Zeit ist, einmal zurückzutreten von der Geschäftigkeit in den Spezialgebieten und zu überlegen, wie Software für eine möglichst große Gemeinschaft von Entwicklern definiert werden kann, um ein Ziel zu erreichen: ihre Planung und den Austausch über sie zu erleichtern.

Während meiner Beraterarbeit treffe ich ausnahmslos Entwickler mit Kompetenz in ihrer Fachdomäne, Kompetenz in der konkreten Programmierung einer konkreten Aufgabe – die sich aber mit der Planung oder Beschreibung von Software schwer tun. Objekte stecken ihnen im Blut; sie zeichnen Klassendiagramme und jonglieren mit Entwurfsmustern; sie können in Visual Studio Projekten denken, kennen Infrastrukturprodukte und APIs… Aber wie das alles zusammenhängt und ein Gesamtbild formt, davon haben sie wenig Vorstellung. UML & Designer aller Art helfen ihnen dabei auch nicht.

Es fehlt ihnen – so mein Eindruck – ein Grundgerüst. Und nicht nur ihnen! Denn auch ich fühle mich immer wieder überwältigt von der Vielfalt an Konzepten und Technologien in unserer Branche.

Insofern beginne ich hier eine Reihe von Postings unter der Überschrift „Software als System“ nicht einfach, um der Community etwas mitzuteilen, was ich schon meine zu wissen, sondern vielmehr für mich selbst. In dieser Postingserie möchte ich im Sinne Kleists daher eher schreibend mir selbst darüber klar werden, was ich denke und das zu verfeinern, als „gesichertes Wissen“ weiterzugeben.
Diese Serie stellt mithin den Versuch dar, quasi im Selbstgespräch ein allgemeines Bild von Software zu entwickeln. Mein Ausgangspunkt sind dabei Begriffe aus der neueren Systemtheorie, die ich versuchen werden, zum Nutzen der Softwareentwicklung auf unsere Branche zu übertragen. Mal schauen, was dabei herauskommt. Über Kommentare und Mitdenken von Bloglesern freue ich mich natürlich.

Die Leitfrage in den kommenden Postings ist also: Was ist Software eigentlich so ganz allgemein? Und wie kann uns das helfen, Software ganz konkret zu realisieren, ohne uns in einer babylonischen Sprach- und Denkverwirrung zu verlieren? Ich bin gespannt, auf was ich da so komme ;-)

[Nächster Artikel der Serie] [Alle Artikel]