Sterben Programmierer aus?

Die Stellenausschreibungen für Entwickler sind rar geworden. Findet in Anwenderfirmen keine Programmierung mehr statt? Ersetzen Software-Integratoren die Programmierer? Ein Blick in die USA, dem gelobten Land der IT, nimmt möglicherweise die Entwicklung hierzulande vorweg: Hier war das Jahr 2002 das erste in der IT-Geschichte, in dem die dortige Software-Industrie Arbeitsplätze abbaute. Rund 150.000 verloren ihren Job. Im Silicon Valley bedeute das einen Stellenschwund von 10 Prozent. Derzeit meldet der Valley-Index eine Verlangsamung des Stellenabbaus auf 5 Prozent.
Woran liegt das? Bloßes Codieren ist out, heißt es oft, doch Software-Entwicklung findet in und außerhalb von Anwenderunternehmen statt. IT- und Softwareunternehmen geben sich immer noch Mühe, die Code-Cracks für die eigenen Technologien zu gewinnen. Auch auf der diesjährigen OOP, der Münchner Konferenz für objektorientiertes Programmieren, versammelte sich in München die Crème de la Crème europäischer und amerikanischer Software-Evangelisten. Doch wohin genau soll die Entwicklergemeinde künftig gelenkt werden?

Peter Kürpick, bei SAP als Senior Vice President für das Server Technology Development zuständig, warb für die  Webservices-basierte ‘Enterprise Service-Architektur’. Deren Bestandteil ist ein Framework, das neben der Funktionalität einzelner Web-Services, Semantik, standardisierte Interfaces und Richtlinien für die Granularität der Services anbieten soll. Dazu gehört auch das Entwicklungswerkzeug WebDynpro, das wiederum auf Eclipse, dem offenen Entwicklungs-Framework von IBM basiert. Ziel der Architektur ist es, aus vorhandenen Anwendungen neue zu erstellen ohne die existenten umzuschreiben. Composite Applications heißt das Schlagwort, das andeutet, wie Entwicklungs- und Integrationsaufgaben verschmelzen.

Generieren: Nein Danke

SAP habe sich jahrelang ausschließlich um das Management in Anwenderunternehmen gekümmert, erläutert Ivo Totev, Technologie-Evangelist bei SAP. Das ändere sich nun, weil die SAP-Produkte selbst technisch umgestaltet würden. Deshalb sei die Präsenz auf einer solchen Entwicklerkonferenz wichtig für das Unternehmen.

Der SAP-Auftritt verdeutlicht zwar wie wichtig es ist, Software-Entwickler für sich einzunehmen, um Verständnis für neue Techniken und Produkte zu erwecken; andererseits dokumentiert er auch, dass Entwicklung heute nicht mehr mit Anwendungsprogrammierung gleichzusetzen ist. Kürpick setzt auf die Model Driven Architektur (MDA), ein Standard der Object Management Group (OMG). Dieser erlaubt, aus Modellen, die in unterschiedlichen Graden von jeder IT-Infrastruktur abstrahiert sind, Code zu generieren. “Auch für unsere 8000 Entwickler gilt: Die Erstellung neuer Anwendungen funktioniert nur so. Eine Codierung findet zu einem großen Teil nur transparent im Hintergrund statt”, so der SAP-Entwicklungschef.

Marc Chanliau, Senior Product Manager bei Netegrity und OASIS-Veteran, pflichtet bei, wenn es um die Veränderung der Aufgaben von Software-Entwicklern geht. Doch das automatische Generieren von Code hält er für ein Hirngespinst: “Das funktioniert nie, weder in den veralteten CASE-Tools (CASE = Computer Aided Software Engineering) noch mit irgendwelchen Modellen.” Ein Zurück zur Assembler-Programmierung sei dennoch höchst unwahrscheinlich. Heutige Entwicklungsumgebungen nähmen den Programmierern, “Gott sei Dank”, viele Routine-Aufgaben ab.

Trotzdem könnten diese Tool-immanenten Hilfen unmöglich dazu führen, dass Software-Designer und -Architekten Programmierung erübrigten. Vielmehr bewegten sie sich auf anderen Ebenen als die Programmierer, denen die Aufgabe zufiele, ihre Entwürfe zu implementieren. “Die Gattung Programmierer wird niemals aussterben”, ereifert sich Chanliau. “Schauen Sie sich unser Unternehmen an. Wir programmieren.” Im Übrigen finde natürlich auch herkömmliche Anwendungsentwicklung statt, “nur nicht hier oder in den USA, weil das zu teuer käme, sondern in Indien, in den großen Softwarefabriken von Tarta und Infosys.”

Chanliau spricht durchaus einen Trend an. So beabsichtigt der IT-Riese IBM offenbar, noch in diesem Jahr 3000 Stellen in Billiglohn-Länder zu verlegen; Oracle und SAP hatten schon zuvor ähnliche Outsourcing-Absichten kundgetan. Einige mittelständische IT-Häuser wie Elsag Solutions machen es den Konzernen bereits nach.

Offshore ist eine Einbahnstraße

Georg Heeg, Chef des gleichnamigen mittelständischen Softwarehauses, bringt es auf den Punkt: “Können wir uns Software-Entwicklung in Deutschland noch leisten?” fragt er ketzerisch. Seine Antwort erweist sich aber als glühendes Plädoyer für Software-Projekte in Deutschland – und nebenbei für eine der ältesten objektorientierten Programmiersprachen: Smalltalk. Er verweist auf eine Studie über die Software-Entwicklung in Deutschland, die im Januar 2001 vom Fraunhofer-Institut für Systemtechnik und Innovationsforschung (ISI), Karlsruhe, und dem Fraunhofer IESE, Kaiserlautern, gemeinsam mit der Gfk Marktforschungs GmbH, Nürnberg, veröffentlicht wurde. Demnach haben damals rund 175.000 Personen hierzulande Software entwickelt und angepasst. Sie erzielten eine Wertschöpfung von mehr als 50 Milliarden Mark. Es gab rund 20.000 Softwarehäuser.

Laut Heeg und Bitkom dürfte sich zwar die Situation in den vergangenen drei Jahren kaum geändert haben, die Wahrnehmung aber schon: “Aus der Wertschöpfung im damaligen Sprachgebrauch wurden Kosten”, so der agile Smalltalk-Experte. Das aber habe fatale Folgen. Outsourcing in Billiglohnländer bewirke die Arbeitslosigkeit auch Hochqualifizierter. Die Wirtschaft baue ihre eigene Kundschaft ab. Deutschland drohe schließlich die “Verslummung”, Verelendung.

Heeg bemüht zur Verdeutlichung seiner Argumentation ein historisches Beispiel, den Untergang der Textilindustrie im westlichen Münsterland. Als die Produktion zu teuer erschien, hätten die Firmen Rettung in der Offshore-Produktion gesucht und ihre alten Maschinen etwa nach Brasilien exportiert. Das Ende vom Lied: “Heute ist die Region textilfrei”, so Heeg.

Modelle taugen mehr als Bit und Bytes

Ganz anders sei dagegen die Entwicklung im östlichen Münsterland verlaufen. Dort habe man einen Qualitätsstandard ‘Made in Germany’ gesetzt. Die Textilfirmen gebe es noch heute und die Beispiele Brax, Eterna und Falke bewiesen, dass eine Qualitätsoffensive das bessere Handlungsmodell sei als andauernde Preisreduktionen und Offshore-Programmierung.

Übertragen auf die Software-Entwicklung bedeute Qualität: Verstehen, was die Anwender wollen. Dazu aber müssten die Entwickler lernen, wie ihre Kunden zu denken. “Weg von Bits und Bytes, von Speicher und CPU, von Datenstrukturen und Algorithmen!” fordert Heeg. Die Maxime laute nicht: “Wie bringe ich es meiner Maschine bei, sondern worüber reden wir?” Gefragt seien Modellierer, die lernten wie ihre Anwender zu denken, nicht die in der Technik verhafteten Programmierer. Unter der Bedingung, dass IT-Dienstleister, zumindest wenn sie Smalltalk einsetzten, die Denkweise der Anwender verstehen lernen, ist für Heeg das Fazit klar: “Entwicklung in Deutschland ist bezahlbar, denn wir denken.”

Doch auch in anderen Sprachen wird entwickelt. Rund 2,5 Millionen Java-Entwickler soll es geben und nicht viel weniger Cobol-Tüftler. So zählt Micro Focus, Hersteller von Cobol-Compilern, alleine weltweit rund 130.000 Entwickler, die mit seinen Tools arbeiten. Die Cobol-Programmierer beschäftigt zu einem Großteil die Migrationen von einer Plattform zu anderen, die Anpassung von Cobol-Programmen in Verbindungen mit Web-Applikationen oder die Integration in Dotnet.

Ohne Integration keine Innovation

Das zeigt: Die Trennung zwischen Integration und Anpassung von Legacy sowie Standardsoftware für die ‘Langweiler’ auf der einen Seite und Neuentwicklung für die ‘Innovativen’ gilt nicht mehr. Das beweist auch die Hypovereinsbank. Deren Vertreter präsentierten jüngst ein EAI-Projekt (Enterprise Application Integration).

Andererseits zeigt sich, dass auch die Eigenentwicklung von Werkzeugen für die Programmierung keinesfalls aus den IT-Abteilungen verschwunden ist. So stellten Frank Derichsweiler von Audi, Matthias Wandert von der Volkswagen AG und Thomas Stahl von der B + M Informatik AG auf der OOP ein MDA-gestütztes Architektur-Management für den VW-Konzern vor. Ausgangspunkt war es, ein Architektur-Management einzuführen, das konzernweit die Arbeit von Software-Ingenieuren erleichtern soll.

Zum Projektumfang gehört das Definieren von Begriffen und deren Beziehungen, festzustellen, welche Unternehmensstandards und wiederverwendbare Module es gibt und nach welchen Kriterien sie ausgemustert und ersetzt werden sollen und können. Ziel ist es, Wissen, Modelle und Templates  besser wieder verwenden zu können und so die Produktivität in IT-Projekten zu steigern. Von diesen hat der VW-Konzern eine Menge. Im vergangenen Jahr gab es allein 400 E-Business-Projekte, verrät Wandert.

Überraschende Erkenntnisse

Schon kurz nach Beginn der Arbeitsaufnahme mussten die Beteiligten feststellen, dass jede Menge Papier zusammenkam. So entstand die Idee, die Erkenntnisse zum Architektur-Management in ein Modell zu gießen. “Ein Modell ist transparent und für alle eindeutig”, so Wandert. Zugleich schaffe es Möglichkeiten, die Informationen zielgruppengerecht aufzubereiten. Da lag es nahe, den neuen OMG-Standard MDA auszuprobieren. “Wir wollten in Erfahrung bringen: Wie schmeckt MDA? Wie fühlt sie sich an? Wie komplex kann der Umgang mit dem Standard werden?”

Schon steckte das Team in einem Software-Entwicklungsprozess, denn es entstand ein Architektur-Repository. Dieses sei von außen mit einem semantischen Netz vergleichbar, in dem etwa Begriffe als Datensätze (Records) vorliegen. Die Architekturinformationen sind navigierbar und recherchefähig. Software-Designer, Architekten und sogar Manager sollen mit dem Tool in Erfahrung bringen können, welche Elemente es für ihren Fall bereits gibt, wer mit dem Framework bereits arbeitet. Die notwendigen Bestandteile sollen konfigurierbar sein.

Ergebnis der MDA-Evaluierung war übrigens eine “sehr angenehme Überraschung”, wie Wandert erläuterte. Trotzdem habe man nicht auf Anhieb alle 1400 IT-Mitarbeiter des Konzerns mit der Einführung belasten wollen, schließlich weise die eigene Arbeit einen hohen Abstraktionsgrad auf und es gebe noch nicht genügend Tools, die den OMG-Standard ausreichend unterstützten. Derzeit befinde sich das Projekt in der Feedback- und Verbesserungsphase, um recht zügig den flächendeckenden Einsatz des Frontends voran zu treiben.