100 Leute haben wir gefragt … – W-Jax 2015

Im Artikel Quo vadis Microsoft? berichtete Hendrik Lösch über seine Erkenntnisse einer Umfrage unter den Teilnehmern der Entwicklerkonferenz Basta. Wir haben bei der W-JAX eine ähnliche Umfrage durchgeführt, um das Meinungsbild der Java-Community einzufangen.

Von den über 1000 Konferenzteilnehmern beantworteten knapp 150 Besucher unsere Umfrage. Damit können wir zumindest ein repräsentatives Bild für die Besucher der W-JAX zeichnen. Rückschlüsse auf die Softwareentwicklungsbranche im Java-Umfeld sind ob der geringen Teilnehmermenge der Umfrage jedoch mit Vorsicht zu genießen.

Die erste Frage lautete: „Welche Frameworks verwenden Sie in Ihrem aktuellen Hauptprojekt?“ Ein Großteil der Teilnehmer gab an, mit Java Enterprise oder Spring Framework zu arbeiten. Darüber hinaus wurden JSF und JSP jeweils von einem Drittel der Teilnehmer als Antwort genannt. Swing und JavaFX als Desktoptechnologien wurden hingegen weniger verwendet. Damit wird deutlich, dass Java nach wie vor seine Stärken im Backend großer Unternehmensanwendungen hat. Für grafische Benutzeroberfläche greifen die Entwickler auf die Webtechnologien zurück, die der Java-Enterprise-Stack mitliefert. Interessant ist dieses Ergebnis auch im Vergleich zur Umfrage auf der Basta: Dort gaben die meisten Teilnehmer an, in ihrem Projekt mit Desktoptechnologien wie Windows Forms oder WPF zu arbeiten.

Welche Frameworks verwenden Sie in Ihrem aktuellen Hauptprojekt?

eingesetzte Frameworks in den Hauptprojekten
Abbildung 1: eingesetzte Frameworks in den Hauptprojekten

Zwei weitere Punkte lassen sich aus den Antworten herauslesen: Zum einen werden in nicht wenigen Projekten Technologien eingesetzt, die ihren Zenit längst überschritten haben und mittlerweile von neuen Technologien abgelöst wurden. So arbeiten weit mehr Personen in ihrem Projekt mit Swing als mit dem Nachfolger JavaFX. Zum anderen fällt auf, dass moderne Single-Page-Webanwendungen mit Javascript-Technologien wie AngularJS in der Java-Community Fuß gefasst haben. Dieser Trend wird sich mit Hinblick auf die aktuellen Neuerungen wie Angular 2 oder EcmaScript 2015 vermutlich fortsetzen.

Die Bedeutung von Webtechnologien wird in der nächsten Frage deutlich: „Welche Sprachen verwenden Sie in Ihrem aktuellen Hauptprojekt?“ Nicht überraschend gaben fast alle Teilnehmer an mit Java zu arbeiten. Jedoch antworteten auch über zwei Drittel der Befragten, dass sie HTML und JavaScript in ihrem Projekt verwenden.

Welche Sprachen verwenden Sie in Ihrem aktuellen Hauptprojekt?

Verwendete Programmiersprachen in den Hauptprojekten
Abbildung 2: Verwendete Programmiersprachen in den Hauptprojekten

Andere Sprachen wie Groovy, Scala oder Ruby fristen eher ein Nischendasein. Obwohl diese Sprachen viele nützliche Features mitbringen, die man bei Java vermisst oder dort erst sehr viel später eingebaut werden (Stichwort: Lambdas), scheuen viele Projekte den Umstieg und bleiben beim Altbewährten. Wenn man berücksichtigt, dass Java hauptsächlich im Umfeld großer Unternehmensanwendungen eingesetzt wird, ist dies auch durchaus verständlich.

Planen Sie in nächster Zeit mit einer der folgenden Technologien zu arbeiten?

Zukünftig eingesetzte Technologien
Abbildung 3: Zukünftig eingesetzte Technologien

In Frage 3 kommen wir noch einmal auf Webanwendungen zurück. Obwohl Java-EE-Webtechnologien wie JSF oder das mit Java EE 8 kommende MVC 1.0 weiterhin eine große Rolle spielen, werden Single-Page-Apps mit JavaScript-Frameworks wie AngularJS zunehmend interessant. Während man in den letzten Jahren jede Menge JavaScript-Frameworks kommen und gehen sah, scheint sich das Angebot mittlerweile etwas zu stabilisieren. Darüber hinaus wird sich in den kommenden Versionen von JavaScript (EcmaScript 2015) und AngularJS (Angular 2.0) vieles wesentlich vereinfachen, was bisher als Einstiegshürde in die Welt der JavaScript-basierten Single-Page-Apps galt. Mit Web Components steht außerdem ein weiterer vielversprechender Standard bereit, und Polymer bietet die passende Library dazu. Wir wollten also wissen, mit welchen Webtechnologien sich die Konferenzteilnehmer in nächster Zeit beschäftigen werden.

50 Teilnehmer, und damit ein Drittel der Befragten, gab an, demnächst mit AngularJS arbeiten zu wollen. Bei der Umfrage auf der .NET-fokussierten Basta erzielte AngularJS ähnlich hohe Werte. Auch wenn die Fragestellung keine Unterscheidung in AngularJS 1.x und Angular 2.0 anbot, darf man vermuten, dass das Interesse dem bald erscheinenden Angular 2.0 gilt. Die fehlende Rückwärtskompatibilität mit AngularJS 1.x scheint nicht weiter zu stören. Mittlerweile hat es Angular 2.0 in die Beta-Phase geschafft, so dass man nicht mehr mit größeren Änderungen rechnen muss. Das erste Feedback ist positiv und die Erwartungen groß, und es ist davon auszugehen, dass Angular der Platzhirsch unter den JavaScript-Frameworks sein wird.

Polymer, wie Angular aus dem Hause Google, ist etwas komplett Neues und stößt bei den Befragten auf weit weniger Interesse. Es stellt sich auch die Frage, welche Strategie Google mit Angular und Polymer verfolgt. Hieß es zunächst, Angular 2.0 würde auf Web Components aufbauen, hatte man sich später doch dagegen entschieden. Inwieweit sich Angular und Polymer ergänzen werden, ist also völlig offen.

Etwa jeder achte Befragte plant, in nächster Zeit mit Reactive Technologien zu arbeiten. Hier ist zweifellos das von Facebook entwickelte React Vorreiter. Der Umstieg auf Reactive bedeutet gleichzeitig einen Paradigmenwechsel, wodurch die Hürden für einen Wechsel zweifelsohne höher sind. Viele Kollegen, die den Schritt in die Reactive-Welt getan haben, schwören aber darauf und möchten nichts anderes mehr machen. Auch wenn Angular 2.0 demnächst der Stern am Web-Himmel sein wird, könnte ich mir vorstellen, dass der Hype eines Tages durch React oder ähnliche Frameworks überholt wird.

Verwenden Sie in Ihrem Hauptprojekt Cloud-Technologien?

Einsatz von Cloud-Technologien im Hauptprojekt
Abbildung 4: Einsatz von Cloud-Technologien im Hauptprojekt

Ein weiteres Thema unserer Umfrage ist die „Cloud“. Auf die Frage, ob sie in ihrem Hauptprojekt Cloud-Technologien verwenden, antworteten 15 % der Teilnehmer mit Ja. Ein ähnlicher Wert wurde bei der Befragung auf der Basta ermittelt. Zugegebenermaßen ist „Cloud-Technologien“ ein dehnbarer Begriff, den jeder etwas anders versteht. Dennoch war bei der Befragung oft zu hören, dass hauptsächlich IAAS-Dienste (Infrastructure As A Service) in Anspruch genommen werden. Überwiegend vertraut man dabei auf Amazon AWS. Weitere Erkenntnisse lassen sich bei der geringen Anzahl der Befragten nicht ableiten. Nur eines: Die eher mageren 15 % zeigen, dass dem Thema in der Java-Community weit weniger Bedeutung zukommt, als man bei dem gefühlten Hype um Cloud-Technologien zunächst vermuten könnte.

Was behindert Sie am meisten in Ihrem aktuellen Hauptprojekt?

Hindernisse in den Hauptprojekten
Abbildung 5: Hindernisse in den Hauptprojekten

Zu guter Letzt widmen wir uns einem technologieunabhängigen Thema: Wir wollten von den Teilnehmern wissen: „Was behindert Sie am meisten in Ihrem aktuellen Hauptprojekt?“ Der mit Abstand am häufigsten genannte Grund waren unklare Anforderungen. Hier zeigt sich, wie entscheidend eine gute Analyse und ein ausgereifter Entwicklungsprozess ist. Was scheinbar selbstverständlich klingt, ist durchaus etwas, worauf man bewusst hinwirken muss. In einem Kundenprojekt habe ich selbst erlebt, welchen Gewinn die Hinzunahme eines Analysten ins Projekt für alle Beteiligten gebracht hat, obwohl dessen Kosten-Nutzen-Verhältnis anfangs in Frage gestellt wurde. In einem anderen Projekt, das nach Scrum arbeitet, konnte ich sehen, wie unklare Anforderungen durch eine Reihe von bewussten Maßnahmen auf ein Minimum reduziert werden können: Dazu gehören beispielsweise klare Abnahme- und Ausschlusskriterien sowie Plannings und Groomings, bei denen frühzeitig Unklarheiten geklärt werden können.

In der Zusammenfassung unserer Umfrage auf der W-JAX möchte ich zwei Dinge hervorheben: Nach wie vor bilden Enterprise-Technologien wie Java EE oder Spring die Basis für Softwareentwicklung im Java-Umfeld. Dabei werden auch in die Jahre gekommene Technologien eingesetzt – ein Umstand, der Potenzial für Migrationsprojekte birgt. Ungeachtet der verwendeten Backend-Technologien besteht ein hohes Interesse an JavaScript-basierten Webframeworks für die Benutzeroberfläche. Besondere Beachtung kommt dabei dem mit Spannung erwarteten Angular 2.0 zu.

Quo vadis Microsoft? – Basta 2015

Betrachtet man was uns Technologieradare, Anbieter für Weiterbildungsmaßnahmen oder diverse Konferenzagenden zeigen, scheint es zurzeit nur die Wege „Mobile“ und „Web“ zu geben, wenn man mit einem neuen Softwareprojekt starten möchte. Dieser Einschätzung möchte ich nicht gänzlich widersprechen, unkommentiert lassen kann ich sie jedoch auch nicht.

Gerade für ein Beratungsunternehmen wie die Saxonia Systems AG (seit 03/2020 ZEISS Digital Innovation) ist nicht nur ein Blick nach vorn wichtig. Wenn man nicht weiß wo eine Reise beginnt, ist es nur schwer einzuschätzen, ob die Richtung, die man einschlägt, tatsächlich die Richtige ist. Ganz zu schweigen davon, dass man als Berater keinen größeren Fehler begehen kann als zwanghaft etwas einführen zu wollen, dass vielversprechend erscheint, jedoch die bestehende Infrastruktur des Kunden komplett außer Acht lässt.

Aus diesem Grund befragen wir bei Konferenzen immer auch unsere Gesprächspartner welche Technologien sie einsetzen und warum sie ggf. von diesen wechseln wollen. Dies gipfelte dieses Jahr in gezielten Umfragen bei der Basta und W-JAX, von denen ich zumindest die Ergebnisse der Basta für meine folgende Argumentation verwenden möchte. Die Ergebnisse der W-JAX überlasse ich an dieser Stelle meinem Kollegen Stefan Bley, der weit mehr Erfahrung im Java-Umfeld hat als ich.

Die Fragestellung an die Teilnehmer lautete: „Welche Frameworks und Technologien setzen Sie in Ihrem Hauptprojekt ein.“ Als Hauptprojekt wurde das Projekt bestimmt, an welchem die Befragten den größten Teil ihrer Zeit arbeiten. Auf diese Weise erhalten die Aussagen eine deutliche Wertung und mögliche Gehversuche mit einzelnen Technologien wurden herausgefiltert. Zugegeben, bei etwa 150 Teilnehmern an der Umfrage auf der Basta ergibt sich kein repräsentatives Bild unserer Industrie. Man kann aber zumindest von einer Repräsentanz für die Konferenz selbst und ihre ca. 1000 Teilnehmer ausgehen.

Abbildung 1: Typische desktopbasierte Technologien & Frameworks

Auch wenn die Daten nicht repräsentativ sind, so fällt auf dass wesentlich mehr Teilnehmer für Desktop als für Webtechnologien abgestimmt haben. Interessant ist auch die breite Nutzung von Windows Forms gegenüber WPF. Diese erklärt sich in vielen Fällen nicht nur dadurch, dass Windows Forms schon länger existiert. Vielmehr ist es vergleichsweise schnell und bietet alle Steuerelemente, die für gängige Businessanwendungen benötigt werden. Dazu kommt noch der geringere Lernaufwand aufgrund einer sehr flachen Lernkurve im Gegensatz zu WPF. Nachteile wie das schwierige Styling der Oberflächen oder die größeren Herausforderungen in Bezug auf die Architektur der Anwendung wiegen scheinbar nicht so schwer, wie zumindest ich es erwartet hätte.

Damit sind wir dann auch schon bei einer Besonderheit von Microsoft Technologien. Wollte man in der Vergangenheit auf einfache Weise Desktopsoftware für Windows entwickeln, so war die dazugehörige Entwicklungsinfrastruktur von Microsoft aufgrund der guten Nutzung von betriebssystemeigenen Features, die Integration der Werkzeuge in das Gesamtsystem und dem gewohnten Look & Feel, auch häufig die erste Wahl für Entwickler. Gerade mit JavaFX wird an diesem bisherigen Selbstverständnis jedoch deutlich gekratzt, wozu dann noch die schwächelnden Verkäufe im Desktopumfeld und das Abwandern der Nutzergruppen auf mobile Endgeräte hinzukommen, welche Microsoft seinerseits mit der Universal App Plattform wieder einzufangen versucht.

Im Webumfeld hat Microsoft dahingegen – zumindest in Europa – keinen schlechten, aber einen schwierigeren Stand als sie es auf dem Desktop haben. Entwicklungswerkzeuge der Redmonder, angefangen beim fast schon obligatorischen Visual Studio oder dem Team Foundation Server, sind vergleichsweise teuer in der Anschaffung. Dazu kommen dann noch Lizenzkosten für Server u.ä. zum Betrieb der Dienste, die regelmäßig zu entrichten sind. Stellt man diese rein monetär den kostenlosen Alternativen mit günstigem Hosting aus der Java, PHP oder Ruby Welt gegenüber, so offenbart sich ein schwerwiegender Nachteil. Diesen kann man natürlich versuchen mit Planbarkeit, Produktivität u.ä. zu relativieren. Er sorgte in der Vergangenheit aber dennoch dafür, dass Microsoft in vielen Fällen nicht unbedingt die erste Wahl war, wenn es darum ging eine Weblösung zu schaffen.

Abbildung 2: Typische webbasierte Technologien & Frameworks

Auch im Webumfeld zeigt sich ähnlich wie beim Desktop, dass das Abschneiden von scheinbar alten Zöpfen nicht immer simpel, vielleicht aber auch gar nicht notwendig ist. Anders als bei der Entscheidung zwischen Windows Forms und WPF entscheidet man bei der Wahl zwischen Webforms und MVC auch zwangsweise über ein Architekturvorgehen. Das ASP.Net MVC dabei ein weitaus strukturierteres Vorgehen zulässt als die WebForms, dürfte jedem bewusst sein, der beides schon einmal eingesetzt hat. Inwieweit also tatsächlich neue WebForms Projekte starten, ist aufgrund der vielen damit verbundenen Nachteile nicht auszuschließen, aber zumindest fraglich. Viel mehr neigen die bestehenden Systeme dazu, weitere Frameworks einzusetzen, um jene Nachteile zu kompensieren.

Welche Ableitung ergibt sich nun aber generell aus den Zahlenverhältnissen? Einer der Gründe, warum Microsoft auf dem Desktop so stark geworden ist, war die nahtlose Integration ihrer Werkzeuge. Windows war lange Zeit die Plattform, auf der die Internetwelt beim Endnutzer angekommen ist. Mit Azure arbeitet Microsoft nun aber schon viele Jahre an einer ähnlichen Plattform, bei der man schnell das Gefühl bekommt, dass sie nichts weniger werden soll als die Plattform für das Internet selbst.

Damit erklärt sich dann auch, warum Microsoft sehr viele seiner Frameworks open source stellt und zum Beispiel mit .Net Core sowie Visual Studio Code Werkzeuge  bereitstellt, die es uns Entwicklern ermöglichen, nicht mehr nur auf Windows und für Windows zu entwickeln. Mit den Zielen die Microsoft verfolgt, macht es keinen Sinn starrsinnig den eigenen Bergfried „Windows“ zu verteidigen. Es sollen Entwickler gewonnen werden, die die neue Infrastruktur und die damit verbundenen Werkzeuge nutzen.

Nur wie passt dies nun zur Situation in Deutschland? Microsofts Zukunft ist eng mit dem Web und der Cloud verbunden. Die deutschen Unternehmen sind aber eher Cloud-Skeptiker und setzen scheinbar im großen Maße eher auf Desktopanwendungen als Webanwendungen, wenn sie im Kontext der Microsoft Technologien arbeiten.

Abbildung 3: Setzen Sie schon Cloud-Technologien ein?

Befragt, ob sie schon Cloud Technologien einsetzen, sagten zumindest fast 18% der Beteiligten „ja“. Dies sind weit weniger als die von Pb7 ermittelten 31%. Ursache dafür könnte sein, dass Softwareentwickler im genannten Kontext eher Plattform as a Service und Infrastructure as a Service Angebote als Cloud werten, nicht aber Software as a Service Angebote. Darüber hinaus kann aber auch genau hier wieder eine Unschärfe aufgrund der geringen Stichprobe und dem darüber hinaus auch geringeren Anteil von Webprojekten vorliegen.

Zugegeben ist die Menge der Cloudnutzer trotz allem noch immer weitaus nüchterner als das, was uns die gängigen Whitepaper versprechen. Es zeigt aber, dass ein zunehmender Einzug der Cloud in die aktuellen Softwareprojekte auch bei pessimistischen Bewertungen absolut unbestreitbar ist. Dies dürfte sich dank der Kooperation zwischen Microsoft und der deutschen Telekom dann auch zukünftig noch weiter in Deutschland verstärken.

Zusammenfassend lässt sich also sagen, dass der Anteil derer, die mit Microsofttechnologien entwickeln, immer auch stark davon abhing, wie groß Microsofts Marktstellung im entsprechenden Bereich war. Wandelt sich Microsoft nun zu einem Dienstanbieter, bei dem Windows nur noch eines von unterschiedlichen Zielsystemen der gebotenen Dienste ist, kann dies für die ursprüngliche Entwicklerbasis und die aktuell bestehenden Systeme tatsächlich bedrohlich wirken, da es zumindest teilweise einer Grundannahme dieser Projekte wiederspricht und zwar, dass mit Windows immer auch eine sehr große Nutzerbasis Zugriff auf die Software erhält.

Dies erklärt für mich dann auch sehr gut die Reflexe, die ich wahrnehme, wenn ich mit manchem Kunden über neue Projekte spreche. So liegt die Grundannahme bei vielen Gesprächspartnern vor, dass sie am besten jede Software als Webapplikation bereitstellen. Leider wird dabei häufig vergessen, dass sich damit auch neue Herausforderungen ergeben, von denen die Browserkompatibilität nur eine der Offensichtlichsten ist.

Ich möchte an dieser Stelle also etwas beruhigend wirken. Es ist aktuell nicht abzusehen, dass bei all den Neuankündigungen von Microsoft die ursprüngliche Entwicklerbasis und damit auch die bestehenden Projekte vernachlässigt werden. Durch Kooperationen mit SAP sowie die Pflege der .Net Basistechnologien wie WPF, sind Investitionen im Bereich von Desktopanwendungen nicht zwangsläufig gefährdet. Auch wenn Microsoft es hier gern sähe, wenn man die nächste Businessanwendung eher für die Universal App Plattform umsetzt, so sollte eine Entscheidung für die ausgereifte WPF einen sicheren Unterbau darstellen und eher davon abhängig gemacht werden, welche Nutzergruppe von der Anwendung zukünftig adressiert werden soll und welche Probleme es zu lösen gilt. Ein Ende des Supports für Windows Forms sowie WPF ist nicht absehbar und bei der aktuellen Nutzerbasis wird sich Microsoft auch in naher Zukunft nicht erlauben an diesem Umstand etwas zu ändern.

Sollte also die Frage bestehen womit man sich als nächstes am besten auseinander setzt, so kann ein Blick in die Webtechnologien für Desktopentwickler sicher nicht schaden. Um adäquate Aussagen für ganze Projekte zu treffen, bedarf es aber einer ausgiebigen Analyse der spezifischen Ist- und Soll-Situationen, weil der Desktop trotz aller Unkenrufe noch immer seine Berechtigung hat.