Software Development

Fachlich voneinander getrennte Services, die eine bestimmte Businesslogik kapseln und voneinander unabhängig deployed werden können. Die Services stellen Schnittstellen bereit und implementieren einen bestimmten Anwendungsfall, der fachlich von anderen Services getrennt gesehen kann. Man spricht hierbei von einem Bounded Context, im Sinne des Domain-Driven Designs.

Unter API-first wird verstanden, dass ein Dienst in der Cloud (SaaS) alle Features über ein Application Programming Interface (API) zur Verfügung stellt. Es gibt also keine Features, welche nur über eine proprietäre UI gesteuert werden können. Alle Features und Einstellmöglichkeiten sind über die API erreichbar.

Ziel von Cloud-native ist, skalierbare Systeme zu betreiben, welche sich automatisch an die Nutzerzahl anpassen: Sind wenige Nutzer auf dem System, sollen auch weniger Ressourcen verwendet werden. Sind sehr viele Nutzer auf dem System, sollen viele Ressourcen zur Verfügung gestellt werden, damit das System immer schnell und adäquat reagiert. Erreicht wird das unter Verwendung von Services in der Cloud, sogenannten Software-as-a-Service-Lösungen, welche diese Möglichkeit meist out of the box bieten, oder durch die Verwendung von Diensten, welche die entsprechenden Cloud Provider anbieten (Platform as a service (PaaS)).

Bei diesem Architekturansatz wird die Businesslogik für alle Clients in einer Schnittstelle (API) zur Verfügung gestellt. Das Backend System sorgt nicht mehr für die Aufbereitung der Daten für spezifische Frontends, sondern durch intelligentes API Design können sich die verschiedenen Clients für jeden Kanal von dieser Schnittstelle bedienen.

Wir setzen alle unsere Projekte mittels agiler Methoden um.

Siehe hierzu auch alle Infos unter Agiles Projektmanagement.

Ziel des MVP-Ansatzes ist, das kleinst funktionsfähige Produkt zu erstellen, um dieses schnell dem Kunden zur Verfügung zu stellen und somit umgehend Nutzerfeedback zu erhalten. Dieses Nutzerfeedback ist enorm wichtig, um die nächsten Schritte, die Weiterentwicklung des Produktes, zu priorisieren. Um die Kundenbedürfnisse bestmöglichst zu erfüllen und die Time-to-Market zu reduzieren.

Nicht-funktionale Anforderung sind Merkmale eines Softwaresystems, welche den Anspruch an die Softwarequalität beschreiben. Diese sind in dem ISO/IEC 9126 Standard zu finden und werden anhand folgender Oberbegriffe definiert: Änderbarkeit/Wartbarkeit, Benutzbarkeit, Effizienz, Funktionalität, Übertragbarkeit und Zuverlässigkeit. Die Anforderungen eines Systems, etwa wie zuverlässig es bereitgestellt werden soll, beschreiben wir mittels Szenarien. Es gibt für jeden Use Case unserer Kunde ganz andere Ansprüche an die Softwarequalität, auch sind die Kosten für die verschiedenen Qualitäten sehr verschieden. Wir kennen uns damit aus und finden den richtigen Weg für die Gesamtarchitektur in diesen verschiedenen Dimensionen!

Damit ist die Möglichkeit gemeint bestimmte Businesslogik auf der Plattform eines bestimmten Cloud-Anbieters (z. B. Microsoft Azure oder aws) zur Verfügung zu stellen, ohne sich um die Skalierbarkeit und Hochverfügbarkeit des Systems kümmern zu müssen. Dass diese Funktion verfügbar ist, wenn sie gebraucht wird, garantiert der Cloud-Anbieter.

Unter resilientem Software Design versteht man den Umgang mit Fehlerzuständen im Livebetrieb eines Softwaresystems. Das heißt: Wenn ein bestimmter Dienst nicht zur Verfügung steht, wird nicht das ganze System in Mitleidenschaft gezogen. Die User werden entsprechend informiert, dass ein bestimmter Dienst gerade nicht zur Verfügung steht, beispielsweise die Produktbestandsführung, aber ein Produkt ist trotzdem bestellbar.

Informationen dazu gibt es hier.

Die zentrale Verwaltung von Nutzer:innen und Zugriffsrechten ist gerade bei verteilten Systemen mit sehr unterschiedlichen Diensten von entscheidender Bedeutung. Wir sind Expert:innen in verschiedenen IAM-Systemen und deren Features, sei es Single Sign On (SSO) oder Zwei-Faktoren-Authentifizierung. Wir kennen Open-Source-Produkte wie Keycloak, kommerzielle Produkte oder auch die Lösungen, welche von unseren Cloud-Provider-Partnerunternehmen zur Verfügung gestellt werden (Microsoft Azure und aws). So wählen wir mit unseren Kund:innen daraus die passende Lösung aus.

Unter Represential State Transfer (REST) versteht man ein Paradigma, welches vor allem für Webservices zum Einsatz kommt. Hierbei gilt es, nach bestimmten Regeln die Schnittstelle (API) aufzubauen und auch die Möglichkeiten des HTTP-Protokolls voll auszunutzen. Das bedeutet, dass man HTTP-Statuscodes für den Erfolgs- und Fehlerfall sowie Medientypen unterstützt, um einerseits dem Client zu signalisieren, was er von der Schnittstelle für eine Antwort erwarten kann, aber auch auf Serverseite festzulegen, wie auf bestimmte Zustände zu reagieren ist.

GraphQL ist eine Abfragesprache für APIs, welche den Clients die Möglichkeit bietet, die Daten anzufordern, die sie zur Darstellung des aktuellen Use Cases benötigen. Dadurch werden im Backend die Daten entsprechend selektiert und nur die wirklich benötigten Informationen werden an den Client übertragen.

MACH geht noch einen Schritt weiter als eine reine Architektur aus Microservices. Hierbei gilt es, verschiedene Servicelösungen miteinander zu kombinieren im Zusammenspiel mit individuellen Microservices. Auch müssen die eingesetzten Produkte gewisse Voraussetzungen mitbringen. Der API-first Ansatz gibt vor, dass die Produkte komplett über die API steuerbar sind. So hat beispielsweise ein E-Commerce-System keine versteckten Features, welche man nur mit einer gesonderten Admin-UI einstellen kann. Wichtig ist auch der Cloud-native Ansatz. Die Systeme sind für die Cloud konzipiert, skalieren vollautomatisch nach oben und unten. So sparen sie also Kosten bei Unterlast und stellen Ressourcen zur Verfügung, wenn viele Nutzer:innen das System gleichzeitig verwenden wollen. Hinzu kommt der Headless-Ansatz. Schnittstellen zur Darstellung des User Interfaces werden für alle Clients bereitgestellt – ein modernes Frontend, eine PWA oder eine native mobile App kann den Anforderungen entsprechend das Interface mit derselben Schnittstelle darstellen.

Ob das Nutzen der MACH-Architektur ein Vorteil ist oder doch eine Enterprise Lösung besser passt, das entscheiden wir gemeinsam. Wir können beides! Für viele unserer Kund:innen ist die Enterprise Lösung genau die richtige Entscheidung. Andererseits haben wir aber auch sehr viele Anfragen mit sehr speziellen Anforderungen. Das Customizing einer großen Enterprise Lösung muss man dann gegen die individuellen Stärken einer MACH-Architektur abwägen, bei welcher dann leichtgewichtige SaaS-Lösungen mit individuell erstellten Microservices kombiniert werden und gegebenenfalls schneller und kostengünstiger zum Ziel führen.

Time-to-Market ist entscheidend. Je schneller ein wichtiges Feature nutzbar ist, desto besser. Ein neues Feature birgt aber stets die Gefahr, dass es zu Fehlerzuständen kommen kann. Durch den Einsatz agiler Methoden ist in unserer DNA eine hohe Testabdeckung für alle Features bereitzustellen. Bei jeder Integration von Features werden automatisierte Unit/Integrations und bei Bedarf Oberflächentests ausgeführt. Auch das Deploymentszenario wird entsprechend der Anforderungen individuell aufgebaut. Unterbrechungsfreies Deployment ist für uns selbstverständlich. Natürlich besteht auch die Möglichkeit, nur mittels A/B-Tests auszuprobieren, wie ein bestimmtes Feature angenommen wird.

Durch resiliente Architekturen ermöglichen wir, dass beim Ausfall eines bestimmten Dienstes nicht das ganze System betroffen ist. Der User wird in dem Fall informiert, dass ein bestimmter Dienst nicht zur Verfügung steht, er aber den Großteil der Features weiterhin verwenden kann.