Neue Anwendungen entwickeln wir konsequent als Microservices mit Microfrontends und betreiben diese Cloud Native. Wie wir das machen, haben wir in unseren vergangenen Blogposts berichtet. Neben dieser “neuen Welt” haben wir als Unternehmen mit bald 50-jähriger Historie aber natürlich auch Anwendungen in Betrieb, die noch nicht dieser neuen Architektur folgen. Die relevanteste Anwendung in diesem Kontext ist unser DVAG Online System. Mit dieser als Fat Client/Server Architektur konzipierten Anwendung haben unsere VermögensberaterInnen heute u.

Wie bereits in den vergangenen Blogposts erläutert, optimieren wir durch den Einsatz von Web- und Cloud-Technologien sowie mittels Standards und Automatisierung die nachhaltige Effektivität und Effizienz im Umgang mit unserer zukünftigen Anwendungslandschaft. Eine fachliche Anforderung, die mit dieser Zielsetzung hervorragend vereinbar ist, war der Relaunch des Corporate Designs der Deutschen Vermögensberatung im Jahr 2020, der zum Ziel hatte, ein neues und einheitliches Markenbild im digitalen Umfeld einzuführen sowie kontinuierlich und zentral zu managen.

Auf der kontinuierlichen Suche nach sinnvollen Optimierungs- und Standardisierungsmöglichkeiten für unsere Anwendungsentwicklung beschäftigen wir uns unter anderem mit dem Thema Serverless Computing. Während wir die Backends unserer Mission Critical Systeme derzeit mit Spring Boot entwickeln und in Azure Kubernetes Services deployen, tun sich mit Serverless Computing derzeit neue potenzielle Vereinfachungen für unsere Software Development Teams auf. Wie Ihr aus unseren anderen Blogposts bereits erfahren habt, setzen wir hinsichtlich unserer Cloud-Strategie auf Microsoft Azure.

In unseren letzten Blogposts haben wir über verschiedene Aspekte unserer Anwendungslandschaft und unseren damit verbundenen Zielen berichtet. In diesem Post wollen wir auf unsere Lösung zur Authentifizierung unserer AnwenderInnen als ein zentrales Element dieser Ziel-Anwendungslandschaft eingehen. Es handelt sich für uns hierbei um ein Anwendungsgebiet, in dem die vorhandenen Branchen-Standards unseren Anforderungen weitgehend gerecht werden. In diesem Gebiet entwickeln wir also nicht von Grund auf selbst, sondern wollen Best-In-Class-Lösungen von Drittanbietern einsetzen, die zur Erfüllung aller unserer Anforderungen flexibel erweitert werden können.

Im Blog-Post zu unseren Objectives & Key Results (OKR) haben wir die geplanten Maßnahmen an unserer Anwendungslandschaft bereits näher erläutert. Wir arbeiten an neuen Web- und Cloud-Applikationen und wollen mittels Standards und Automatisierung für eine höhere Effektivität sorgen. Dabei ist es wichtig, den Überblick über die IT-Landschaft zu behalten und auch zukünftige Entwicklungen mit ihren jeweiligen Konsequenzen darstellen und bewerten zu können. Zu diesem Zweck haben wir uns entschieden, die Lösung “LeanIX Enterprise Architecture Management” übergreifend und einheitlich einzusetzen.

In unserem Blogartikel GitHub Reusable Workflows haben wir bereits geschildert, wie wir als Cloud-/Plattform-Team CI/CD-Pipelines in der Cloud vereinheitlichen und aus wiederverwendbaren Bausteinen zusammensetzen, um unseren EntwicklerInnen die Nutzung unserer GitHub Services so einfach und effizient wie möglich zu gestalten. Vor dem Hintergrund weiterer Vereinfachungen für unsere EntwicklerInnen haben wir uns mit GitHub Codespaces beschäftigt. Die Codespaces adressieren hierbei ein Problem, das sicherlich vielen Entwicklerteams bekannt sein wird: Der Aufbau der lokalen Entwicklungsumgebung ist meist kompliziert und zeitaufwändig.

Wie bereits in den Blogposts zu unserem Cloud-Plattform-Team erwähnt, sehen wir uns mit unseren gebündelten Services (Cloud Services, K8S, Source Control System & CI/CD) als zentraler Dienstleister für unsere EntwicklerInnen. Ein zentrales Thema ist dabei die grundsätzliche Heranführung unserer EntwicklerInnen an unsere angebotenen Cloud-Lösungen. Neben der reinen Wissensvermittlung zur Azure Cloud in Form von Schulungen und Tutorials sollte man in unseren Augen manche Lösungen und Produkte einfach mal anschauen und ausprobieren können, um festzustellen, welche Cloud-Komponenten für die Umsetzung in einem Projekt geeignet sind.

Über unsere Erfahrungen mit GitHub haben wir bereits in unserem Tech Blog berichtet. GitHub haben wir zur Verwaltung unseres Quellcodes und zur Implementation unserer CI/CD-Pipelines eingeführt. Aktuell läuft die Migration unserer bisherigen Lösungen in das neue System und wird im Laufe des Jahres abgeschlossen sein. Zuvor haben wir unseren Quellcode in Atlassian Bitbucket verwaltet und unsere CI-Pipelines haben wir mittels Jenkins automatisiert. Jenkins ist insbesondere im Java-Umfeld vielen ein Begriff, denn es war jahrelang “die” Open-Source-Lösung für automatisierte Builds, Tests und Deployments.

In unserem Tech Blog haben wir bereits mehrfach über die fünf Handlungsfelder berichtet, auf die wir uns im Zuge unserer OKRs in 2022 konzentrieren. Für unsere Arbeit als moderne Entwicklungseinheit spielt das Handlungsfeld “Web First” eine sehr prominente Rolle. Wie bereits dargestellt, entwickeln wir marktdifferenzierende Anwendungen grundsätzlich selbst, mit einer Vielzahl an EntwicklerInnen. Als Produkt- und Tarifierungsplattform mit einem umfangreichen Portfolio für unsere Kunden arbeiten wir dabei meist Seite an Seite mit den EntwicklerInnen unserer zahlreichen Produktpartner an der entsprechenden Integration.

Kürzlich haben wir in unserem Tech Blog über die fünf Handlungsfelder berichtet, auf die wir uns im Zuge unserer OKRs in 2022 konzentrieren werden. Als Cloud-/Plattform-Team in der Anwendungsentwicklung ist “Cloud First” definitiv das relevanteste Handlungsfeld. Marktdifferenzierende Anwendungen entwickeln wir grundsätzlich selbst, mit einer Vielzahl an EntwicklerInnen, und setzen Web- Frameworks und Programmiersprachen wie bspw. Kotlin, Spring Boot und Angular ein. Um unsere hohen Qualitätsstandards flächendeckend zu gewährleisten, forcieren wir die Entwicklungsarbeit in immer kürzeren Zyklen und in Form automatisierter Releases.