Die Liste der Ankündigungen auf der Azure-Webseite war zu Beginn des Jahres bereits zweieinhalb Seiten lang. Security, Data Platform, Web APIs, IoT – das Themenspektrum der allein in den ersten beiden Monaten dieses Jahres neu erschienenen Azure-Komponenten ist enorm breit.
Die SaaS-Lösung Office 365 bietet viele sogenannte Productivity-Lösungen, die den Anwendern im täglichen Einsatz die Arbeit erleichtern. Viele Funktionen wie Workflows, Formulare und Zusammenarbeit, die früher in komplexen Plattformen wie SharePoint oder Dynamics untergebracht waren, lassen sich nun einfach auf individuelle Anforderungen anpassen und überall nutzen. Wenn man aber nun Enterprise-Lösungen wie Line-of-Business-Prozesse oder anwenderübergreifende Abläufe mit diesen Tools abbilden möchte, gibt es diverse Herausforderungen in Bezug auf Governance und Compliance, die man beachten sollte.
Viele Teams, mit denen ich in SaaS-Architekturprojekten zusammenarbeite, kommen auf die Idee, ein allgemeingültiges HTTP-basierendes Web-API zu entwickeln, das von allen Frontends (z. B. Mobile, Web) sowie von externen Partnern verwendet wird. Diese Vorgehensweise hat allerdings nicht nur Vorteile.
Gute Softwarearchitektur setzt klare Ziele voraus - logisch, oder? Rainer Stropek aber weiß aus eigener Erfahrung, dass Teams wichtige Hausaufgaben oft nicht machen - und hat zehn Aspekte gesammelt, die in keinem Fall vernachlässigt werden sollten.
Entwicklerinnen und Entwickler lieben Abstraktionsschichten. Schnittstellen und abstrakte Basisklassen, Dependency Injection, Factories – diese Liste an Mechanismen zur Entkopplung von Komponenten und zum Abstrahieren von konkreten Implementierungen könnte man lange fortsetzen. Wie bei Zwiebeln stapeln sich Schichten über Schichten, damit alles im Fall des Falles ausgetauscht werden kann.
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.
