Home Texte / Essays Muss sich die Software-Entwicklung selbst abschaffen?

Main Menu

Home
Veröffentlichungen
Texte / Essays
Programmierung
------------------
Kontakt
Impressum
Datenschutz
------------------
Muss sich die Software-Entwicklung selbst abschaffen?

Folgender Essay entstand als Diskussionsbeitrag zu einer Frage im XING Netzwerk:

 

Das Postulat, wonach sich Software-Entwicklung abschaffen müsse, taucht ja immer wieder mal auf; gerne auch im Zusammenhang mit graphischen Software-Entwicklungswerkzeugen oder Rapid Application Tools.
Dies ist meines Erachtens weltfremd. Die Wirklichkeit widerlegt das Postulat.

Software zu bauen bedeutet, Werkzeuge zu schaffen. Dazu muss man den Organisations-Zweck oder den Zweck der Abteilung gut kennen. Das tun die Mitarbeiter der Fachabteilungen. Was sie hingegen kaum können, ist "Modellbildung", die für die Softwareentwicklung notwendig ist. Das erfordert Abstraktionsvermögen. Wer Anwendungssysteme kennt, weiß, dass selbst Systemanalytiker und Entwickler oft schlecht abstrahieren, inkonsequent designen und inkosistente Modelle bauen; oft, weil es wenig Möglichkeiten für iteratives und inkrementelles Vorgehen gibt, man also die Lernkurve nicht einbauen kann, indem man das System zweimal baut oder Anwendungsfälle zwei mal (neu)implementiert.
Wie soll fachliche Abstraktion besser werden, wenn Fachvertreter mit Tools selbst etwas zusammenklicken?
Was sie so bekommen werden, ist vor allem eines: ein Vielfaches von Systemaußengrenzen, eine Verinselung der IT-Infrastruktur und eine Heterogenität von fachlichen Terminologien --weil diese lokal definiert werden!
Fachliche Logik kann komplex und schwierig sein. Das weiß jeder, der schon einmal Fachvertreter für ein Systemdesign interviewt hat.
Es gibt noch weiter Kritikpunkte. Viele Fachabteilungen sind einfach heillos schlecht geführt. Führungskräfte kennen oft nicht die grundlegendsten Management-Disziplinen. Von Scorecards oder Kennzahlen will ich garnicht sprechen. Wenn nicht einmal die Geschäftsprozesse sinnvoll definiert sind, oder die Kosten pro Vorgang bekannt sind, --wie soll ein solches "Ad-Hoc arbeiten" oder "durchwursteln" dann in ein Software-Werkzeug gegossen werden? Dann bilden SIe ineffiziente Prozesse in Software nach. Oder sie bekommen lauter kleine undokumentierte Access-Lösungen, bei denen der Begriff "Wartbarkeit" nicht mal mehr ein Lachen auslöst. Von Grenzfragen der "Security" (bei nach außen offenen Systemen) oder "Datenschutz-Compliance", bei denen einfach das Fachwissen fehlt, ganz zu schweigen!
Wenn Sie als Analyst in eine Fachabteilung kommen, und beim Erstellen eines Anwendungsfall-Diagramms erst einmal Diskussionen bei den Fachvertretern zur Arbeitsteilung in der Organisationseinheit auslösen oder gar in ratlose Gesichter blicken, dann wissen Sie, dass sie hier deshalb mit Software-Entwicklung schwierige Voraussetzungen haben, weil grundlegende Führungsaufgaben nicht wahrgenommen wurden.
Dies sollten wir alle nach SOA gelernt haben --oder zumindest diejenigen, die große Stücke daruaf hielten. Dezentralisierung, lokale Service-Definitionen, sind dann gut handhabbar, wenn Fachabteilungen hervorragend geführt und hoch-strukturiert arbeiten. Das tut aber nur eine Minderheit. Und wir reden bei Software-Entwicklung für Wirtschaftsunternehmen ja nicht nur von den Groß-Konzernen, die sich Geschäftsprozess-Management leisten und das Know How zukaufen können.
Ich schreibe dies ohne jede Bitterkeit, es reflektiert jedenfalls meine Erfahrung in großen und auch in mittleren Unternehmen.
Wer produktive Softwareentwicklung will, soll lieber auf den Einsatz funktionaler Sprachen drängen, Bewusstsein für die Voraussetzungen vom Werkzeug-bauen schaffen und ausreichend in die Analyse und Dokumentation investieren.
Alle anderen sollten sich vielleicht mit Standard-Software anfreunden und ihre Prozesse darauf ausrichten.

(Sebastian K. Glas, November 2011)