Gebrauchsfertige Application Blueprints für digitale Services

Starter-Projekte sind heute bei vielen Software-Komponenten Standard: Es handelt sich dabei um den Quellcode von kompletten, meist kleinen Anwendungen, die exemplarisch die jeweilige Komponente einbinden. Solche Starter-Projekte erleichtern Entwicklern die Einarbeitung, da sie zeigen, wie die jeweilige Komponente ordnungsgemäß genutzt wird. Für das industrielle Software-Engineering mit featurewerk hat it factum dieses Prinzip auf die Ebene kompletter Business-Anwendungen gehoben. Was es damit auf sich hat, beschreibt dieser Artikel.

Von der Referenzarchitektur zum Application Blueprint

Die Referenzarchitektur von featurewerk macht Vorgaben, wie Architektur und Design von digitalen Services nach Industriestandards und Best-Practices gestaltet werden können. Da diese Referenzarchitektur technologie-neutral gehalten ist, muss sie vor einem praktischen Einsatz in konkreten Projekten in die jeweiligen Zieltechnologien ausgeprägt werden.

Das bedeutet, für alle Elemente der Referenzarchitektur müssen konkrete Komponenten für die jeweilige Zielarchitektur ausgewählt und miteinander integriert werden.

Diese Aufgabe ist nicht trivial, denn für eine einzelne technologieneutrale Komponente in der Referenzarchitektur gibt es je nach Zieltechnologie eine Vielzahl von konkreten Komponenten oder Frameworks, die die geforderte Funktionalität – wie beispielsweise Logging oder Authentifizierung – bereitstellen. Bei der Auswahl von Komponenten liegt ein Best-of-Breed-Ansatz nahe: die auszuwählenden Komponenten sollen technologisch möglichst aktuell und breit akzeptiert sein und idealerweise einem Industriestandard oder einer allgemeinen Best-Practice entsprechen. Andererseits muss bei allen Komponenten auf eine reibungslose Interaktion untereinander geachtet werden – denn die Authentifizierungskomponente muss beispielsweise gut mit dem Logging-Framework zusammenarbeiten. Gerade bei Open-Source-Komponenten rückt zudem die Frage nach der Stabilität von Komponenten und der sie unterstützenden Community in den Fokus – schließlich möchte man zu einer einmal ausgewählten Komponente auch in der Zukunft Updates bekommen können.

Oft zu beobachten: historisch-inkrementelle Auswahl von Komponenten

Da dieser Auswahlprozess – wenn er ordentlich durchgeführt wird – recht aufwändig ist, wird in vielen Projekten mit einer erprobten, in der Regel historisch gewachsenen Architektur gestartet. Diese hat den Nachteil, dass sie in der Regel keinen „großen Wurf“ darstellt. Bei ihr sind die einzelnen Komponenten nicht methodisch ausgewählt und abgestimmt, sondern in der Regel ausgehend von einem stabilen Kern werden bei Bedarf weitere Komponenten hinzugefügt. Solche Lösungen können aber leicht suboptimal werden, da in der Regel beim Hinzufügen von neuen Komponenten bereits vorhandene Komponenten nicht hinterfragt werden, da diese auszutauschen als zu aufwändig eingeschätzt wird.

Bei größeren Projekten ist oft der Wunsch nach einer optimalen Architektur vorhanden, dem man mit einer Technologie-Evaluierungsphase vor dem eigentlichen Projekt begegnet. Diese erfordern – wenn sie wirklich gute Ergebnisse bringen sollen – jedoch nicht unerheblichen Aufwand sowie echtes Expertenwissen. Zudem sorgt eine solche Evaluierungsphase meist zu spürbaren Verzögerungen im Projektablauf. So können während der laufenden Evaluierung keine Features umgesetzt werden. Im Nachgang muss sich das Entwicklungsteam zudem dann erst mit der zusammengestellten Architektur vertraut machen, was weitere Zeit in Anspruch nimmt.

Gebrauchsfertige Application Blueprints als Assets im Entwicklungsprozess

Diese gezeigten Probleme beim Erstellen einer Architektur für Anwendungen löst featurewerk durch die sogenannten Application Blueprints, die it factum auf der Basis der technologieneutralen Referenzarchitektur entwickelt hat. Dabei handelt es sich um vollständig ausdetaillierte Anwendungsrahmen, also komplett lauffähige Anwendungen, die über den gesamten Technologiestack alle Komponenten enthalten. Zudem sind alle Elemente einer auf dieser Auswahl hin optimierte Projektinfrastruktur (Build-Prozesse, Entwicklungsumgebung, Continuous-Integration, DevOps Pipelines) in den Blueprints vordefiniert.

Das bedeutet, anstatt eine Technologieevaluierung zu betreiben oder mit einer historisch gewachsenen Architektur zu starten, reicht es bei featurewerk aus, zu Beginn eines Engagements den passenden Application Blueprint mittels eines Checklisten-basierten Verfahrens auszuwählen und dann in einem Sizing-Schritt auf das aktuelle Projekt anzupassen.

Die featurewerk Application Blueprints stehen für die wesentlichen Technologiefamilien wie Java und .NET zur Verfügung.

Kuratierte Komponentenauswahl

Bei it factum kümmert sich ein eigenständiges Team darum, am Markt verfügbare Softwarekomponenten für die in featurewerk angebotenen Zieltechnologien zu sichten und auf ihre Eignung für die Application Blueprints hin zu untersuchen und erproben. Dabei werden alle Komponenten in einem Kuratierungsprozess nach einer festgelegten Methodik hinsichtlich einer Reihe von Kriterien wie technische Qualität, Reifegrad, Stabilität, Zukunftsaussicht oder Community-Verankerung bewertet.

In einem weiteren Schritt werden die ausgewählten Komponenten dann technologisch verprobt, um eventuelle Kompatibilitäts- oder Interoperabilitätsprobleme mit anderen Komponenten zu ermitteln, bevor sie dann schließlich in den Blueprint aufgenommen werden.

Projektstart ohne Rüstzeit

Die gebrauchsfertigen Application Blueprints erlauben dann einen Projektstart ohne Rüstzeiten. Mittels automatisierter Prozesse werden – wenn die Blueprint-Auswahl und das Sizing abgeschlossen sind – ohne manuelles Zutun komplette Projektinfrastrukturen aufgesetzt. Diese beinhaltet neben den Anwendungsrahmen sämtliche Build- und Paketverwaltungskomponenten sowie die Einbindung in die automatische Qualitätssicherung (beispielsweise SonarQube).

Somit wird neben einer standardisierten Architektur durch die Application Blueprints auch eine standarisierte Projektumgebung geschaffen, was sowohl für durchgängige Qualität als auch für Entwicklerproduktivität positiv ist. Denn die Standardisierung erlaubt eine zielgerichtete Schulung der Entwickler a priori, so dass diese ab Projektbeginn mit den ihnen vertrauten Komponenten arbeiten können.

Pflege und Weiterentwicklung der Application Blueprints

Die Application Blueprints von featurewerk unterliegen einem kontinuierlichen Update- und Pflegeprozess. Das heißt, es steht bei Projektbeginn immer ein Anwendungsrahmen mit möglichst aktuellen Komponenten zur Verfügung.

Durch das sorgfältige Design in den Application Blueprints ist es zudem leicht möglich, zu einem späteren Zeitpunkt die in den Blueprints verwendeten Dritt-Komponenten in einem Projekt zu aktualisieren. Somit können Komponenten-Updates entweder komplett automatisiert oder mit minimalem händischem Aufwand umgesetzt werden.

So profitieren Anwendungen auch während ihrer Betriebs- und Wartungsphase von dem Einsatz der Application Blueprints, da die verwendeten Dritt-Komponenten jederzeit aktuell gehalten werden können.

Vorteile durch Application Blueprints

Durch den Einsatz der Application Blueprints von featurewerk ergeben sich bei der Realisierung von digitalen Services die folgenden Vorteile:

• In allen Projekten, auch kleinen, stehen qualitativ hochwertige Anwendungsrahmen zur Verfügung, die sich an Standards orientieren und dem aktuellen State-of-the-Art entsprechen.
• Projektteams können ohne Rüstzeit bei Projektbeginn mit der Umsetzung von Fachlichkeit beginnen, da Projektumgebungen automatisch aufgesetzt sind und die Entwickler mit den eingesetzten Technologien und Komponenten vertraut sind.
• Die Application Blueprints werden von erfahren Experten kuratiert. Durch das Design der Blueprints können verwendete Dritt-Komponenten in Anwendungen auch später mit geringem Aufwand aktualisiert und die Anwendungen somit aktuell gehalten werden.