Keine IT-Konferenz kommt ohne das Schlagwort „DevOps“ aus. Man hört von Continuous Integration and Deployment, Automatisierung, Infrastructure as Code, Telemetrie und vielen anderen Tools und Technologien. DevOps auf technische Fragen zu reduzieren, ist aber ein folgenschwerer Fehler.
Wenn ich an meine ersten beruflichen Jahre in der Softwareentwicklung zurückdenke, dann waren zu dieser Zeit Versionsnummern im Wesentlichen ein Marketinginstrument. Eine große Vertriebsmesse rückt näher? Wir brauchen unbedingt einen neuen Major-Release! Man will den Kunden Stabilität vermitteln? Dann lieber einen Minor-Release herausgeben.
Wer sich heute in Richtung SaaS und Cloud wagt, der hat sich zwangsläufig mit dem Thema Web-APIs beschäftigt. Niemand käme mehr auf die Idee, in einer solchen Umgebung einen Two-Tier Fat Client mit direktem Datenbankzugriff zu entwickeln.
In den letzten Monaten hatte ich Beratungsengagements in mehreren Projekten, bei denen es um die Analyse bestehender Softwarelösungen ging. Ein Projekt war eine Cloud-basierte SaaS-Lösung, ein zweites stand am Beginn der Transformation in Richtung SaaS und ein drittes war eine klassische Individualsoftware für den Betrieb im eigenen Rechenzentrum. In allen Fällen war es meine Aufgabe, die bestehenden Softwaresysteme hinsichtlich ihrer Architektur zu analysieren und Aussagen über Stärken, Schwächen und dringend notwendige Investitionen zu machen.
Künstliche Intelligenz (AI) und Machine Learning (ML) beflügeln die Fantasie vieler SaaS-Anbieter. Wäre es nicht schön, wenn wir komplizierte Eingabemasken durch einen einfach zu bedienenden Bot ersetzen könnten?
Viele, die den Weg von On-Premises-Software zu Cloud-basierten SaaS-Lösungen gehen, müssen eine Lektion auf die harte Tour lernen: Benutzer sehen und beurteilen die von uns Technikerinnen und Technikern erstellte Software ganz anders als wir.
So wie viele andere Personen in der Softwareentwicklung auch, habe ich das Programmieren mit Sprachen wie C++, Java und vor allem C# gelernt. Ich mag daher typisierte Sprachen, und mir sind die Vorteile einer vollwertigen IDE im Vergleich zu einem leichtgewichtigen Editor mit Konsole bewusst.
Immer wieder werde ich gefragt, wie sich Softwarearchitekturen bei SaaS in der Cloud von klassischer Software für den Betrieb bei Endkunden unterscheidet. Ein Aspekt ist die Wichtigkeit des Design-to-Cost-Ansatzes. Damit ist gemeint, dass die Betriebskosten einer SaaS-Lösung von Anfang an als wichtige, nicht funktionale Anforderung berücksichtigt werden.
Offene Software und Daten – in der öffentlichen Wahrnehmung sind diese Begriffe durchweg positiv besetzt. Mit Offenheit verbindet man, dass jederzeit mit jeder Technologie und von jeder Plattform aus mit Softwaresystemen interagiert und auf Daten zugegriffen werden kann.
Das Internet ist angesichts der Datenschutz-Grundverordnung (DSGVO) in Aufruhr. Jeden Tag flattern E-Mails in mein Postfach, in denen mir von allen möglichen Organisationen in blumigen Worten versichert wird, wie sehr ihnen Datenschutz am Herzen liegt und dass ich mit nur einem Klick dafür sorgen kann, dass mir keine wichtigen Informationen in den diversen Newslettern entgehen.
Wenn es um den immer weiter steigenden Automatisierungsgrad in der Wirtschaft geht, denken die meisten an Autofabriken, in denen kaum Menschen, aber viele Maschinen arbeiten. Oder an den Haushaltsroboter, der die weniger angenehmen Arbeiten in den eigenen vier Wänden übernimmt. In der Softwareindustrie allerdings sind es die Softwareroboter in der Cloud, die längst begonnen haben, unsere Arbeit zu revolutionieren.
Das gängige Paradigma in den frühen Jahren der Cloud war, dass die Cloud unsicher, unberechenbar (z. B. hinsichtlich der Kosten) und unkontrollierbar ist. Die Server im eigenen Rechnerraum waren greifbar. Die Tür des Rechnerraums konnte man persönlich absperren, und das vermittelte ein Gefühl von Sicherheit.
