Was es braucht, um eine erfolgreiche Lösungsarchitektur zu entwickeln

Die Architektur eines Software-Systems ist sein Rückgrat, und je nach der Art der Gestaltung dieser Architektur kann sie entweder das System unterstützen oder es zum Absturz bringen. Ein Lösungsarchitekt sollte eine ganzheitliche Sicht auf die Transformation der Geschäftsziele und -anforderungen in eine stabile Architektur haben. Schließlich ist es die Architektur eines Projekts, die sie vorantreibt. Die Wahl des Technologiestacks, Nicht umgekehrt.

Der Solution-Architect hat ein breites Verantwortungsfeld. Wir werden nur die wichtigsten Aspekte behandeln, vor allem im Hinblick auf den geschäftlichen Aspekt der Projektumsetzung. Außerdem werden wir auf Besonderheiten der gängigen Architekturen eingehen.

Um eine detaillierte und strukturierte Lösungarchitektur zu gewährleisten, müssen Sie mit einem Fachmann zusammenarbeiten und wissen, wie Sie dessen Arbeit bewerten können. Lassen Sie uns die Rolle und die Kompetenzen eines Solution Architects definieren.

Der Softwarearchitekt kann je nach Größe und Dauer des Projekts an allen Projektphasen teilnehmen. Dennoch sind die Presale- und Entdeckungsphasen hinsichtlich der Auswahl einer Softwarearchitektur und der Erstellung einer Architekturlösung von entscheidender Bedeutung. In diesen Phasen arbeitet der Softwarearchitekt gemeinsam mit einem Businessanalysten daran, Softwaresysteme ordnungsgemäß zu organisieren. Weitere Informationen zu dieser Partnerschaft finden Sie hier. Unser ausführlicher Artikel über die Rolle des Business Analysts.

Im Vorverkaufsprozess definiert ein Softwarearchitekt:

• Anforderungen des Projekts, d. h. worum es das Projekt geht
• Geschäftsziele, z. B. die Entwicklung eines neuen Produktes, um die Umsätze zu steigern
• Funktionale und technische Anforderungen, d. h. die Funktionalität, die die Software haben wird
• Nichtfunktionale Anforderungen, d. h. Produktattribute wie Zuverlässigkeit, Wartungsfreundlichkeit und Skalierbarkeit
• Risiken Dies kann während des gesamten Projekts berücksichtigt werden, etwa bei Problemen mit der Skalierung der Dienste.
• Sorgen wie beispielsweise, ob die geschäftlichen Anforderungen des Kunden machbar sind
• Technische Einschränkungen, z. B. die Notwendigkeit, von der On-Premises-Software in die Cloud-Architektur zu migrieren
• Geschäftliche Einschränkungen, z. B. die Einhaltung der HIPAA-Anforderungen für Gesundheitsprodukte und der PCI-Anforderungen für FinTech

Im Entstehungsprozess eines Softwarearchitekten:

• Teilt sich an der Vorbereitung eines Angebots für den Auftraggeber mit
• Erstellt die architektonische Vision und das Softwarearchitekturdesign
• Arbeiten an der Roadmap und dem Projektbudget
• trägt zur Auswahl des Teams bei

Versuchen Sie außerdem, unseren Artikel über Digitale Bankenarchitektur.

Mark Richards, ein erfahrener Softwarearchitekt und Autor zahlreicher Bücher über Softwarearchitektur, beschreibt die Soft Skills und Kenntnisse, die ein Solution Architect besitzen sollte wie folgt:

• Führung und Kommunikation. Ein Architekt mit guten Kommunikationsfähigkeiten weiß, wie er seine Architekturentscheidungen auch ohne technische Hintergrundkenntnisse an alle Projektbeteiligten erklären und begründen kann.
• Technisches Wissen. Offensichtlich sollte ein Softwarearchitekt eine fundierte Kenntnis der Technologien besitzen, mit denen er täglich arbeitet. Aber ein echter Architekt sollte auch eine Wachstumsmentalität haben und sich mit neuen Technologien vertraut machen, die ständig entstehen. Das bedeutet nicht, ein Experte in allen neuen Technologien zu werden, sondern lediglich sich dessen Möglichkeiten bewusst zu sein kann einem Softwarearchitekten dabei helfen, bessere architektonische Entscheidungen zu treffen.
• Wissen über das Geschäftsfeld. Jede Branche hat ihre eigene Sprache, Begriffe, Trends und Konkurrenten. Ein Solution Architect sollte sich diese Bereiche des Geschäfts ansehen, mit denen er arbeitet. Nur durch das Bewusstsein für die spezifischen Geschäftsdetails kann ein Solution Architect eine zuverlässige und relevante Architektur liefern. Außerdem vereinfacht das Verständnis des Geschäfts die Kommunikation zwischen den Stakeholdern und dem Solution Architect und verleiht diesem einen vertrauenswürdigeren Eindruck.

Ein Softwarearchitekt ist ein technischer Experte mit umfassender Kenntnis des Geschäfts. Und Geschäftsanforderungen sind das Bindeglied bei der Softwarearchitektur-Entwicklung (SAD). 

Lesen Sie auch: Wie wir den Entwicklungsprozess von Apps bei Yalantis umsetzen

Die Erstellung und Verarbeitung von Anforderungen ist einer der ersten Schritte, die ein Softwarearchitekt vor dem Entwurf einer Software durchführt. 

Ein Softwarearchitekt zerlegt die Geschäftsanforderungen für Ihr Projekt in folgende Komponenten:

• Funktionalität
• Begrenzungen
• Qualitätsattribute

Qualitätsattribute sind Eigenschaften, die eine Software haben sollte. Hier sind einige Beispiele: Die häufigsten Qualitätsattribute:

• Funktionaler Nutzen. Deckt die Systemfunktionalität die Ziele und Bedürfnisse Ihrer Benutzer ab?
• Leistungsfähigkeit. Wie lange dauert es, bis die Software startet und die wichtigsten Funktionen abläuft?
• Kompatibilität. Kann das System Daten problemlos mit anderen Systemen, Produkten oder Systemkomponenten austauschen?
• Verwendbarkeit. Können die Benutzer das System einfach navigieren?
• Zuverlässigkeit. Ist das System fehlerverzeihlich? Können die Benutzer jederzeit darauf zugreifen?
• Sicherheit. Ist das System sicher genug und kann es die Daten der Nutzer sicher speichern?
• Verfügbarkeit. Wie einfach ist es, das Softwareprodukt zu modifizieren, zu testen oder zu verbessern?
• Portabilität. Ist das System an verschiedene Umgebungen anpassbar? (z. B. Kann es auf verschiedenen Betriebssystemen funktionieren?)

Jedes Softwareprodukt hat seine entscheidenden Qualitätsattribute. So ist die Sicherheit bei einer FinTech-Business-App beispielsweise am wichtigsten, während sie bei einer App, die nicht rund um die Uhr verfügbar ist, weniger kritisch ist. Genau wie man nicht sein gesamtes Kleidersortiment in eine einzige Kofferpackung packen kann, kann man auch nicht alle Qualitätsattribute eines einzelnen Produkts gewährleisten, da jedes Produkt seine Grenzen hat. Man muss Prioritäten setzen.

Ein Softwarearchitekt verwendet die folgenden Methoden, um Qualitätsattribute zu verarbeiten: 

• A Qualitätsattribute-Workshop (QAW) hilft bei der Erstellung und Priorisierung von Qualitätsmerkmalen und beinhaltet eine Diskussion mit allen Projektbeteiligten.
• Attribute-gesteuerte Gestaltung (ADD) ermöglicht es dem Softwarearchitekten, die Art der Softwarearchitektur und das Modell der Software anhand der Qualitätsattribute des Projekts zu definieren.
• Die Methode zur Analyse von Architektur-Trade-Offs (ATAM) evaluiert das aus der ADD-Methode resultierende Architekturdesign

Darüber hinaus hilft Ihnen ATAM bei der Überprüfung, ob ein Architekturdesign die geschäftlichen Ziele und Qualitätsanforderungen erfüllt. Diese Methode wird auch als Risikoidentifizierungsmethode bezeichnet, um Risiken in den frühen Phasen des Softwareentwicklungsprozesses (SDLC) zu identifizieren und zu verhindern. 

ATAM umfasst die folgenden Komponenten:

• Risiken sind ineffiziente oder unüberlegte architektonische Entscheidungen für ein bestimmtes Projekt
• Kompromisse oder die Prioritäten der Qualitätsattribute bedeuten, dass wir beispielsweise die hohe Leistungsfähigkeit der Software auf Kosten der Sicherheit gewährleisten können
• Empfindlichkeitspunkte sind die Ergebnisse günstiger architektonischer Entscheidungen, die zur Realisierung der gewünschten Qualitätsmerkmale führen

Mit Hilfe der oben genannten Methoden weiß ein Softwarearchitekt, wie man die richtige Softwarearchitektur wählt.
 
Lesen Sie auch: Sichere Anwendungsentwicklung: Von der Planung bis zur Produktion

Es gibt viele Arten von Softwarearchitekturen, die alle möglichen Geschäftsziele erfüllen. Wir werden uns die häufigsten ansehen, deren Vor- und Nachteile erläutern und festlegen, für welche Unternehmen jede Art von Architektur am besten geeignet ist.

Monolithische Architektur

Dieses Architekturmuster ist hinsichtlich vieler Attribute – insbesondere hinsichtlich Wartbarkeit, Skalierbarkeit und Flexibilität – eines der unpraktischsten. In einer monolithischen Architektur werden alle Softwarekomponenten in einer einzigen Codebasis zusammengefasst.

Vorteile der monolithischen Architektur:

• Schneller Entwicklungsprozess 
• Hohe Leistungsfähigkeit des Software-Systems
• Gut für Start-up-Projekte

Nachteile der monolithischen Architektur:

• Es ist schwierig, die Software-Frameworks, Bibliotheken und Sprachen der verschiedenen Systemkomponenten zu ändern.
• Es ist schwierig, die Kapazitäten zu skalieren, wenn das Projekt wächst und weitere Funktionen hinzugefügt werden.
• Ein Fehler einer einzelnen Dienstleistung kann zu einem Fehler des gesamten Systems führen.
• Probleme bei der Arbeitskoordination, wenn die Entwicklungsgruppe groß ist

Wo Sie es verwenden können: Eine monolithische Architektur funktioniert am besten bei kleinen Projekten mit relativ kleinen Entwicklungsteams, die den Projekterfolg schnell zeigen müssen. Zum Beispiel verfügen Flickr und Etsy über kleine Entwicklungsteams und können für ihre Websites eine gute monolithische Architektur implementieren.

Mehrschichtige Architektur

Eine mehrschichtige Architektur kann verschiedenen Softwareprodukten gerecht werden. Mit dieser Architektur wird die Codebasis der Anwendung in drei Hauptschichten aufgeteilt, die jeweils ihre spezifische Funktion übernehmen:

• Die Präsentationsebene, Die Front-End-Software, oder das Frontend des Software-Produkts, ist dafür verantwortlich, den Nutzern Informationen zu präsentieren.
• Die Geschäfts-Ebene, Die Back-End-Software, also das hintere Ende des Softwareprodukts, ist dafür verantwortlich, alle Anwendungskompetenzen und die Geschäftslogik zu steuern.
• Die Datenbankebene enthält alle Daten, mit denen das Produkt arbeitet

Alle Softwareanforderungen in dieser Architektur fließen von der Präsentationsebene in die Datenbankebene ab. Jede Ebene ist abgeschlossen, was bedeutet, dass jede Anfrage alle Ebenen einzeln durchlaufen muss, um zur letzten zu gelangen. Daher kann eine Anforderung aus der Präsentationsebene die Geschäftsebene nicht überspringen und Daten direkt aus der Datenbank abrufen. Eine solche Struktur wird auch als Isolierung der Ebenen bezeichnet und vereinfacht die Entwicklung jeder Ebene, sodass Sie bei Bedarf isolierte Änderungen an jeder Ebene vornehmen können.

Diese Art von Architektur ermöglicht außerdem die Anbringung offener Ebenen zwischen geschlossenen Ebenen, um das Anti-Sinkhole-Prinzip in der Architektur zu umgehen. Dieses Prinzip kann auftreten, wenn beispielsweise eine Geschäftsebene keine wesentliche Funktion erfüllt, sondern lediglich Anfragen an die darunterliegende Ebene weiterleitet. In diesem Fall kann ein Softwarearchitekt diese Geschäftsebene öffnen. Eine offene Ebene kann übersprungen werden, sofern sie für bestimmte Anfragen nicht erforderlich ist. Offene Ebenen haben jedoch Auswirkungen auf die gesamte Isolierung der Ebenen und können dazu führen, dass bestimmte Ebenen in einer einzigen Codebasis zusammengefasst werden.

Vorteile der geschichteten Architektur:

• Einfach zu entwickeln, zu testen, zu skalieren und zu warten, dank der Lagenisolation
• Mit unterschiedlichen Technologien können verschiedene Ebenen aufgebaut werden, sodass Änderungen an einer Ebene vorgenommen werden können, ohne dass andere beeinträchtigt werden.

Nachteile der geschichteten Architektur:

• Stellt sich weiterhin als nicht optimal und skalierbar dar, wie das Projekt sich weiterentwickelt.
• Der zeitaufwändige Ablauf jeder Benutzeranforderung über alle Ebenen verlangsamt die Systemleistung.
• Je mehr Ebenen im System vorhanden sind, desto schwieriger wird die Aufrechterhaltung des Systems.

Wo Sie es verwenden könnenEine schichtweise Architektur eignet sich für neue Softwareprodukte, die nur wenige Benutzeranforderungen verarbeiten und keine hohe Performance erfordern.

Lesen Sie auch: Erfahren Sie mehr über die erfolgreiche Architektur, die wir für ein Energiemanagementsystem entwickelt haben

Ereignisgesteuerte Architektur

Dies ist ein asynchrone und dekoppeltes Architekturmuster. Eine Ereignisgesteuerte Architektur (EDA) verarbeitet Ereignisse (Staatsschwankungen), die im Softwaresystem ungleichmäßig auftreten. Beispielsweise kann es sich um ein Ereignis handeln, wenn ein Patient einen Termin bei einem Arzt auf einer Krankenhauswebsite bucht oder wenn ein Nutzer ein Produkt auf einer E-Commerce-Website kauft.

Eine Ereignisgesteuerte Architektur umfasst Ereignisgeneratoren, Ereignisübertragung und Ereignisempfänger. In einer Webanwendung für den Einzelhandel könnten beispielsweise ein Kassenservice als Ereignisgenerator und Inventar-, Versand- und Kontaktdienstleistungen als Ereignisempfänger fungieren. Ein Generator veröffentlicht ein Ereignis im Ereignistransport, das wiederum das Ereignis an den Empfänger weiterleitet.

Vorteile der event-driven Architektur:

• Hohe Verteilung und hohe Skalierbarkeit, da die Veranstalter und Verbraucher von Ereignissen getrennt voneinander arbeiten und es einfach ist, neue Verbraucher und Veranstalter in das System aufzunehmen.
• Die Existenz von Ereignistransport eliminiert die Notwendigkeit von direkter Kommunikation und Abhängigkeiten zwischen Produzenten und Verbrauchern.
• Sorgt für hohe Leistung und verarbeitet Echtzeitdaten schnell, da Verbraucher sofort auf Ereignisse reagieren können

Nachteile der event-driven-Architektur:

• Es ist schwierig, den Ereignisverlauf nachzuverfolgen (z. B. erhalten Event-Consumer keine Daten darüber, welcher Produzent ein Ereignis ausgelöst hat), ohne eine entsprechende Dokumentation.
• Das unklare Ereignisverlauf erschwert die Testung dieser Architektur.
• Wenn ein Ereignistransport fehlschlägt, fehlschlägt das gesamte System.

Wo Sie es verwenden können: 

• IoT-Systeme. Im IoT sind Ereignisse die Messwerte der Sensoren, und sobald die Ereignisempfänger diese erhalten, werden die Benutzer benachrichtigt, um eine bestimmte Aktion durchzuführen. In einem Lager beispielsweise können die Logistikmanager benachrichtigt werden, wenn Sensoren, die die Temperatur überwachen, einen Temperaturrückgang erfassen.

Lesen Sie auch: Warum sollten Sie erwägen IoT-Testdienstleistungen?

• Systeme für die Supply Chain-Management. Logistikunternehmen, die E-Commerce-Bestellungen verarbeiten, können ebenfalls von der Integration einer event-driven-Architektur profitieren. Wenn beispielsweise ein Nutzer eine Bestellung in einem E-Shop aufgibt (d. h. ein “neues Bestelldatum”-Ereignis erstellt), kann ein mit einer event-driven-Architecture (EDA) entwickelten Warehouse Management System (WMS) dieses Ereignis über den Event-Transport empfangen und den Bestand der angeforderten Waren umgehend aktualisieren.
• Chat-Funktionen in Echtzeit. Eine Ereignisgesteuerte Architektur eignet sich auch gut für eine Messaging-Mobile-Applikation mit häufigen Aktualisierungen in Echtzeit.

Lesen Sie auch: So erstellen Sie eine wirklich gute RESTful-API

Mikroservices-Architektur

Die Mikroservices-Architektur ist ein moderner Architekturansatz in der Softwareentwicklung. In einer Mikroservices-Architektur sind alle Dienste des Softwaresystems lose miteinander verknüpft und unabhängig voneinander. Als Beispiel sei hier der Artikel von Das Liefer- und Logistikprojekt, das wir mit einer Mikroservices-Architektur entwickelt haben. Für Einblicke zu Strategien für die Förderung des digitalen Handels, Erfahren Sie mehr in unserem speziellen Artikel über die Optimierung von Werbekampagnen.

Vorteile der Mikroservices-Architektur:

• Skalierbar. Mit der Mikroservices-Architektur können Sie entscheiden, wie sich Softwareanwendungen skalieren lassen. Skalierbarkeit ist auf Dienstleistungsniveau möglich, da Sie die Funktionen einer Dienstleistung erweitern können, andere jedoch wie bisher belassen werden.
• Änderbar. Diese Art von Architektur ermöglicht außerdem Änderungen an einzelnen Diensten, ohne dass dies die anderen beeinträchtigt, wie zum Beispiel die Implementierung neuer Technologien oder Änderungen am Framework, der Bibliothek oder der Sprache eines Dienstes.
• Verwaltungssicher. Die Mikroservices-Architektur vereinfacht den Prozess der Problembehandlung und die Serviceoptimierung. Wenn beispielsweise Ihre E-Mail-Dienste repariert werden müssen, können Sie dies schnell erledigen, ohne andere Dienste beeinträchtigen zu müssen. Wenn also eine Ihrer Komponenten fehlschlägt, ist das nicht der Fall für das gesamte System. 
• Geeignet für große Entwicklungsteams. Mit Mikroservices können verschiedene Teams an verschiedenen Diensten arbeiten und sich auf verschiedene Systemfaktoren konzentrieren. Diese Arbeitsstruktur vereinfacht die Projektkoordination und macht die Zusammenarbeit von zu Hause aus effizienter.

Nachteile der Mikroservices-Architektur:

• Das Testen einer ganzen Reihe von Diensten kann umständlich sein.
• Die Softwareleistung kann beeinträchtigt sein, insbesondere wenn in dieser Architektur viele Dienste vorhanden sind.

Sam Newman, der Autor berühmter Bücher über Softwarearchitektur wie Die Entwicklung von Microservices und Monolith zu Microservices Gibt drei Gründe für die Wahl von Microservices (und einen Anwendungsfall für jeden Grund) in seinem Interview mit Martin Fowler.

Grund #1. Unabhängige Bereitstellung der Dienste ohne Unterbrechungen

Eine Mikroservices-Architektur eignet sich beispielsweise für SaaS-Unternehmen, die ihre Systeme konsequent nutzen und keine Fehler tolerieren können. Diese Art von Architektur funktioniert jedoch auch hervorragend in allen Branchen, in denen Zuverlässigkeit oberste Priorität hat.

Grund #2. Isolierung von Prozessen um Daten herum

In diesem Zusammenhang ist eine Mikroservices-Architektur vorteilhaft. Gesundheitsorganisationen Diese Dienste müssen den Anforderungen von GDPR, HIPAA oder anderen Gesetzen und Vorschriften entsprechen. Mit dieser Architektur können Dienste, die geschützte Gesundheitsinformationen (PHI) verarbeiten, strenger verwaltet werden als andere Dienste. Andererseits können Dienste, die keine PHI verarbeiten, weniger streng verwaltet werden und nicht einmal Daten mit Diensten austauschen, die PHI verarbeiten.

Lesen Sie auch: Checkliste zur HIPAA-Konformität: Schritte, um HIPAA-konform zu werden

Grund #3. Hoher Grad der organisatorischen Autonomie

Die Mikroservices-Architektur eignet sich auch gut für Unternehmen, die selbstverwaltete Teams bilden möchten, die die volle Verantwortung für ihre Arbeit übernehmen. Diese Herangehensweise zielt darauf ab, die erforderliche Koordinierung zwischen einem Entwicklungsteam und dem Rest der Organisation zu reduzieren. Zum Beispiel fördert Atlassian die Autonomie in ihren Teams und bezeichnet sie als “locker verbunden, aber eng aufeinander abgestimmt”. Hinter diesem organisatorischen Ansatz steht der Glaube daran, dass selbstdisziplinierte und autonome Teams einen bedeutenden Beitrag zum Fortschritt des Unternehmens leisten können. 

In diesem Artikel haben wir die wichtigsten Eigenschaften der häufigsten Architekturtypen zusammengestellt, damit Sie entscheiden können, welche Architektur am besten zu Ihrem Projekt passt. Im Folgenden finden Sie eine Tabelle, die diese Softwarearchitekturmodelle anhand des hohen (↑) oder niedrigen (↓) Ausmaßes der häufigsten Projektattribute vergleicht.

Wenn sich Ihre Geschäftsidee oder Ihre Ziele ändern, kann sich auch Ihre Architektur ändern. Zunächst kann eine monolithische Architektur ausreichen, um Ihre Ziele zu erfüllen. Wenn Sie jedoch erkennen, dass Ihr Unternehmen diese nicht mehr erfüllen kann, können Sie zu einer event-driven- oder microservices-basierten Architektur wechseln. Es ist auch möglich, dass Ihr Solutionsarchitekt eine hybride Architektur für Ihr Projekt entwickelt, um Ihre Geschäftsanforderungen besser abzudecken.

Um die richtige Softwarearchitektur umzusetzen, müssen Sie eng mit Ihrem Lösungsfachmann zusammenarbeiten. Je detaillierter Sie die Projektanforderungen angeben, desto besser kann Ihr Architekt die passende Softwarearchitektur für Sie entwerfen. Die Erfahrung eines Softwarearchitekten trägt natürlich auch zum Erfolg Ihres Projekts bei.

Bei Yalantis legen wir großen Wert auf die Fachkenntnisse und Erfahrung unserer Lösungsarchitekten, um sicherzustellen, dass sie Projekten einen Mehrwert verleihen (wir arbeiten jährlich an über 72 Projekten). Bislang haben unsere Architekten unseren Kunden geholfen:

• Verwandeln Sie ein 20-jähriges monolithisches Projekt in Mikroservices
• Mit einer Refactoring-Strategie erfolgreich von der On-Premise-Umgebung in die Cloud migrieren
• Eliminieren Sie Kernsystem-Engpässe, die die Leistung einschränkten
• Reduzieren Sie die Betriebskosten

Diese Liste könnte erweitert werden, da wir jedes Projekt als eine eigene Geschichte betrachten und stets nach einer maßgeschneiderten Lösung suchen. Mehr erfahren Die Dienstleistungen, die wir anbieten Um Softwareprodukte zu entwickeln, die die Geschäftsergebnisse verbessern.