Software Architecture

Nicht mehr Open-Source

Was kann man tun, um sich vorab dagegen zu wappnen, plötzlich für eine wichtige Technologie einem Anbieter ausgeliefert zu sein? Kann es auch eine valide Entscheidung sein, das Risiko bewusst in Kauf zu nehmen? Und sind die Risiken, die sich bei Verwendung von Open-Source-Technologien ergeben, per se geringer als bei kommerziellen Alternativen? Wie geht man damit um, wenn eine Technologie, die man verwendet, plötzlich nicht mehr Open-Source ist? Ist es sinnvoll, zu einem Fork zu wechseln, und welche Risiken bestehen dabei?

Fundamentals of software architecture: Part 5

In this (fifth) installment of the mini-series on software architecture, we leave behind the realm of small to medium-sized systems and take a look at large, risky, and complex projects. In other words, we examine the “scaling” of the role of software architecture.

Technologies for the Integration of Services

In the course of an internal study, we asked a number of INNOQ consultants about their experiences in current or past development projects. One interesting topic here was the integration of microservices and self-contained systems (SCS). Asynchronous communication is frequently used in distributed systems to enable better scalability, greater resilience, and looser coupling. In this article, you will read what insights we learned in our conversations.

Fundamentals of software architecture: Part 1

Welcome to the first part in the mini-series on software architecture. We start by examining the original source of the term – since the word architecture presumably conjures in most people thoughts of buildings.

Rate Limiting with Spring Boot

Let’s implement rate-limiting protection for your Spring Boot server without the need for any additional dependencies beyond those included in the Spring Boot Starter package.

Mit Reviews in Legacy-Situationen orientieren

In diesem Post möchte ich ein paar meiner Erfahrungen mit Legacy-Software teilen. Wir von INNOQ kommen meistens dazu, wenn die Entwicklung irgendwie stecken geblieben ist oder es unklar ist, wie es weiter gehen soll. Reviews, die in Zusammenarbeit von Beratern und Kunde durchgeführt werden, können in einer solchen Situation effektiv und schnell für Klarheit sorgen.

Evolving software like an orchardist

Software systems are usually larger, overgrown structures that developers need to bring back into shape after some time. However, creating an overview of the sprawling conglomerate of software components is challenging, let alone developing a clear plan for moving on. This blog post uses analogies from pruning apple trees to show developers how to evolve their software systems using a value-based approach.

Shortcomings of ISO 25010

Published in 2011, the ISO 25010 standard on software product quality lacks pragmatism and practical applicability. Terms like scalability, deployability, energy efficiency, safety, or code quality are missing. This article explains these shortcomings and shows that even the (draft) update from 2022 still needs polishing…

Frontend integration options

The integration of data and functionality in the frontend is a powerful topic that is still rarely discussed. This article aims to try and show established patterns of frontend integration and briefly name possible advantages and disadvantages.

Sparsame Dokumentation

Ich weiß – Dokumentation ist nicht Ihr Lieblingsthema. Deswegen bekommen Sie hier ein paar Tipps für schmerzfreie Dokumentation. Die hier vorgestellten Ideen sparen Ihnen wertvolle Zeit, sowohl bei Erstellung als auch Pflege der Dokumentation. Sie funktionieren für jede Art von Softwaresystem, unabhängig von Werkzeugen, Technologien und Entwicklungsansätzen.

Documenting software architecture with arc42

arc42 is a template for architecture communication and documentation. It is a proven, practical and highly pragmatic approach and takes the pain out of documentation.

Data Mesh to Go: How to Get the Data Product

You know what a data mesh is? You understand its basic principles? But you don’t know how on earth to get the data product? Then I will show you how to extract your data product from your Domain-driven Design (DDD) artifacts.

What’s in a name: Legacy

The term “legacy” has a negative connotation in IT, and stands for an old, somehow bad piece of software. In real-life, legacy has a completely different and often positive meaning.

Innovation on steroids - Teil 1

Immer mehr Firmen setzen auf die Innovationskraft von Machine Learning und KI. Aber nicht jedes Problem lässt sich mit dem Einsatz von ML-Technologien lösen. Wie also kann man geeignete ML Use Cases identifizieren?

Domain-driven Design und Bounded Context

Die Konzepte von DDD und Bounded Context sind in der Praxis komplizierter, als es auf den ersten Blick erscheint.

Gut gesiebt

Für die komplexe Infrastruktur großer Microservice-Umgebungen versprechen Service Meshes eine einfache Lösung. Aber nur mit dem Blick für die richtigen Eigenschaften lässt sich der beste Ansatz für die eigene Architektur finden.

Wenn Customizing zur Legacy wird

In diesem Blog-Post visualisiere ich ein regelrechtes Schlamassel mit Hilfe von Wardley Maps und Elementen aus dem strategischem Domain-driven Design.

Kubeless - FaaS auf Kubernetes

Kubernetes und Serverless sind zwei der bedeutendsten Trends beim Betrieb von Software. Kubeless verspricht sogar, beides zu vereinen, und lohnt daher eine nähere Betrachtung.

Glücklich ohne Service Mesh

Es muss nicht immer ein Service Mesh sein. Auch Microservices sind nicht per se eine gute Idee. Für gute Entscheidungen müssen wir uns das Problem genau anschauen.

Identification of quality requirements with Quality Storming

Quality Storming is a workshop for the identification of quality requirements based on a quality model, for example ISO 25010, using methods and ideas of Collaborative Modeling, which is popular in the Domain-driven Design Community. An important aspect in this context is a cross-collaboration of different stakeholders and skill sets.

Brauchen asynchrone Microservices und SCS ein Service Mesh?

Service Meshes heben viele Randfunktionen von Microservices wie Monitoring, Routing und Sicherheit in die Infrastruktur und sind entsprechend beliebt in Microservice-Architekturen - doch schaffen sie diesen beachtlichen Mehrwert auch bei asynchroner Kommunikation oder in Self-contained Systems?

JavaScript? Yes, but in moderation

The benefits of classic architecture decisions for web applications.

Cloud-native, Microservices, Domain-driven Design, Kubernetes

Software-Entwicklung unterliegt schon immer Hypes. Im Moment reden alle über Microservices und Cloud-native. Aber helfen diese Ansätze wirklich weiter?

Pragmatisch zum Praxiseinsatz von Machine Learning in der Cloud

Die Anzahl von Publikationen zu Computer Vision, Natural Language Processing (NLP) oder Reinforcement Learning ist heutzutage gewaltig. Dabei widmen sich die meisten ausschließlich dem Training. Doch oft müssen Data Scientists auch beim Betrieb ihrer Modelle mitwirken. Dafür braucht es einen pragmatischen und unaufwändigen Weg.

Cooking with Onions: Inward-Pointing Arrows

The onion architecture is an established approach to structuring applications.

Technologien für Microservices

Microservices führen zu neuen Herausforderungen und machen neue technologische Ansätze notwendig. Microservices-Frameworks sind zwar ein Teil der Lösung, aber sicher nicht der wichtigste. Welche Technologien spielen eine entscheidende Rolle?

Serverless - The Vendor Is Not Your Enemy

Argumente für und gegen Serverless gibt es viele. Dieser Post behandelt konkret das Thema Vendor-Lock-in, welches bei der Entscheidung für oder gegen Serverless häufig diskutiert wird.

Prinzipien zur Entwicklung von unabhängigen Systemen

Viele Systeme werden aktuell mit einer Microservice-Architektur geplant und umgesetzt. Da jede Architektur Vor- und Nachteile aufweist, muss die gewählte jedoch auch zum Problem passen. Dieser Artikel zeigt, welchen primären Vorteil eine Microservice-Architektur hat und welche Prinzipien bei der Entwicklung beachtet werden sollten, um diesen Vorteil nicht zu neutralisieren.

Was ist ein Domain-driven Design Architektur-Kata?

Architektur-Katas sind ein sehr interaktives Trainingsformat. Sie eignen sich hervorragend, um Domain-driven Design (DDD) zu vermitteln.

Technical Debt Just Happens

“Technical debt” is a great metaphor to reason about the quality of a software project. But a closer look also reveals some problems and shows approaches how to deal with software quality even better.

Domain Exceptions?

In jedem Softwaresystem kommt es zu Ausnahmesituationen. In der Regel handelt es sich um technische Ausnahmen, die in Java als Exceptions auftreten und behandelt werden. Gibt es aber auch fachliche Ausnahmen, also quasi “Domain Exceptions”? Und ist es sinnvoll, diese in Java als Exceptions zu modellieren? Einige Beispiele aus einem Kundenprojekt zeigen, dass dies häufig nicht der Fall ist.

FaaS und Kubernetes

Inzwischen gibt es bei den meisten Cloudanbietern die Möglichkeit kleine Codeteile als sogenannte Functions zu hinterlegen. Da kein expliziter Server existiert, dort spart das Kosten. Aber auch sonst bieten Functions eine interessante Abstraktion, deren Vorteile man ebenso gerne innerhalb eines Kubernetes Clusters nutzen möchte.

The language of maths is not the language of your business

Abstractions from category theory can be powerful. But there are reasons why you may want to keep your domain model free of them.

Evolution statt Verschlimmbesserung

Erweitern, ändern und korrigieren bestehender Software - meistens unter Zeitdruck – führt in vielen Fällen zu schleichendem Verfall. Dadurch werden Änderungen einerseits immer schwieriger, andererseits auch immer teurer und riskanter. Das Open-Source Projekt aim42 (architecture improvement method) setzt genau dort an – mit Praktiken und Patterns für systematische Verbesserung – technologieneutral und leichtgewichtig.

What’s in a Name: Evaluate

The term evaluation is often used in the context of system and architecture reviews. In my opinion, this term is often misleading and such activities should be named differently.

Warum wollen Sie Microservices einführen?

Mit diesem Artikel möchte ich Ihnen die Frage stellen, warum Sie eigentlich Microservices einführen wollen. Denn es ist immens wichtig, sich der Gründe und Ziele bewusst zu sein. Leider habe ich zu oft erlebt, wie die glänzenden, neuen Technologien die eigentlichen Ziele des Unternehmens in Vergessenheit geraten lassen und zum Selbstzweck werden.

Implementierung einer einfachen Zustandsmaschine (state machine) in Java

Eine simple Zustandsmaschine (state machine) in Java

arc42 - die Siebte

Das bewährte arc42 Template ist gerade in Version 7 erschienen - mit deutlichen Erweiterungen im Ökosystem. Grundsätzlich bleibt arc42 V7 kompatibel mit den Vorgängerversionen, ist insgesamt noch kompakter und pragmatischer geworden.

Microservices à la Netflix

Netflix hat in den letzten Jahren sehr interessante Open Source Frameworks wie beispielsweise Eureka, Hystrix oder Zuul via GitHub publiziert. Parallel dazu hat das Spring Team mit Spring Boot und Spring Cloud zwei hoch interessante Module für Cloud basierte Microservice Architekturen veröffentlicht. Wie passen diese beiden Dinge nun zusammen?

Microservice-Infrastruktur

Die Cloud und darauf aufbauend Microservices haben in den letzten Jahren die Softwareentwicklung stark beeinflusst. Vor allem im Bereich der Infrastruktur tut sich hier auch heute noch einiges. Dabei wird man den Eindruck nicht los, dass jede Woche ein neues Produkt veröffentlicht wird. In diesem Artikel versuche ich, Ihnen durch diesen Dschungel zu helfen.

Spring Boot für Microservices

Die Implementierung von Microservices stellt im Vergleich zu monolithischen Anwendungen Entwickler vor einige Herausforderungen. Spezialisierte Technologien wie Spring Boot unterstützen die Umsetzung von Microservices und machen so den Projekten das Leben leichter.

Microservices - eine Bestandsaufnahme

Kaum ein Thema ist im Moment so ein Hype wie Microservices. Welche Gründe gibt es dafür? Und wie kann man Microservices gewinnbringend einsetzen? Welche Herausforderungen gibt es? Dieser Artikel gibt einen Überblick über den Architektur-Trend und beantwortet die wichtigsten Fragen.

What’s in a Name: Architecture

The term architecture is used with slightly different meanings throughout the IT industry. This post clarifies what (software) architecture is all about - and which misunderstandings might linger on your way to common understanding.

ROCA vs. SPA

Currently, a lot of companies are migrating from Desktop applications (mostly written in Java) to Web applications for their products as well as for their internal tooling. When they start with this process they often ask themselves: Which technologies should we use to build our Web application? Should we use Angular.js or React? Or should we go with recommendations like ROCA instead of a Single Page Application?

Java-Web-Frameworks von innen?

Web-Frameworks für Java gibt es nun bereits seit fast 20 Jahren. Diese nehmen dem Anwendungsentwickler eine Menge Arbeit ab und sorgen dafür, dass dieser sich nicht auf Infrastruktur konzentrieren muss, sondern die Anwendungslogik im Vordergrund steht. Doch was genau tut so ein Web-Framework eigentlich? Dieser Artikel zeigt, was heutige Web-Frameworks leisten und wo diese sich dann doch in Nuancen unterscheiden.

Microservices - Agilität durch Modularisierung

Docker - Perfekte Verpackung von Microservices

Die Microservice-Bewegung ist mit viel Schwung gestartet und in großen Unternehmen angekommen. Überall werden Monolithen zerschlagen und durch eigenständige, fachlich definierte Microservices ersetzt. Entwicklungsteams können eigenverantwortlicher und autonomer agieren und damit deutlich schneller Ergebnisse ausrollen. Aus Sicht des IT-Betriebs bringen sie aber auch eine Menge Herausforderungen: Statt weniger großer und etablierter Unternehmensanwendungen, existieren plötzlich Landschaften mit einer Vielzahl an kleinen, sich schnell ändernden Services, die alle konfiguriert und überwacht werden wollen. Eine Container-Technologie wie Docker kann das ideale Mittel sein, um diese Services zu verpacken und auszurollen. Aber welche Probleme löst Docker genau und welche neuen Herausforderungen bringt es mit? In diesem Artikel zeigen wir, für welche Software-Architekturen Docker geeignet ist und wie ein Einsatz von Docker dabei helfen kann, Microservice-Architekturen zu kontrollieren.

Gegen die dunkle Macht

Ein ganz normaler Tag: Morgens frage ich mich, welche Katastrophe mich heute erwartet. Ich bin einiges gewohnt, aber die letzten Monate wurde es immer schlimmer: Früher gab es nur Fehler im Test oder Schwierigkeiten bei der Entwicklung. Jetzt kommen auch noch Laufzeitfehler dazu, die den Betrieb im Rechenzentrum stören und unsere Endkunden massiv irritieren. Als hätte sich die dunkle Macht gegen uns verschworen – dabei haben wir doch nur ganz normale Anforderungen. Aber sicherlich das schlechteste Softwaresystem der Welt …

Apache Cassandra

In dieser Kolumne stellen wir Cassandra vor und zeigen, warum die Datenbank quasi beliebig skaliert und höchst performant ist. Cassandra wirkt für Kenner von relationalen Datenbanken auf den ersten Blick recht vertraut, weil hier auch von Tabellen und Spalten die Rede ist und die Abfragen einfachen SQL-Abfragen ähnlich sehen. Dennoch unterscheidet sich Cassandra konzeptionell von relationalen Datenbank-Management-Systemen (RDBMS).

Why You Should Avoid a Canonical Data Model

As an enterprise architect, you might be tempted to strive for a canonical data model for your systems’ interfaces. That’s not a good idea.

Kanonische Architektur-Evolution

Mit dem Entwurf der Softwarearchitektur wollen wir noch vor der Umsetzung die Tragfähigkeit der Software sicherstellen. Wie gut wir die Trägfähigkeit einschätzen können, hängt neben Erfahrungswerten und Kenntnis der eingesetzten Technologien auch davon ab, wie konsistent wir unsere Konzepte tatsächlich implementieren. Wir brauchen also mehr als bloße Wunschvorstellungen über das System; wir benötigen Mechanismen für die konsequente Umsetzung der funktionalen und qualitativen Eigenschaften des Systems.

Warum Soft Skills für Softwarearchitekten wichtig sind

Der Projekterfolg hängt viel stärker von den am Projekt beteiligten Menschen und den Rahmenbedingungen ab als von den eingesetzten Technologien. Erfolgreiche Projektleiter und Softwarearchitekten haben ein Gespür für die Menschen, mit denen sie Projekte machen, und erreichen mit ihnen gesteckte Ziele. Was erfolgreiche Anführer gemein haben, worauf es in der Zusammenarbeit ankommt und wie man selbst so etwas erlernen kann, stellt dieser Artikel vor.

Zertifizierung für Fortgeschrittene

Wer sich als Softwareentwickler oder Softwarearchitekt stets auf dem Laufenden hält, bleibt auch langfristig attraktiv für den Arbeitsmarkt. Das erfordert genauso fundierte Kenntnisse gängiger Technologien und Frameworks wie methodische Fähigkeiten. In diesem Beitrag stellen wir das modulare Curriculum für fortgeschrittene Softwarearchitekten des iSAQB e.V. vor, das verschiedene notwendige Kompetenzbereiche für Softwarearchitekten abdeckt.

Skalierbare Softwaresysteme

Skalierbarkeit ist eines der klassischen Qualitätsmerkmale von IT-Systemen. Wenn wir diesen Begriff hören, denken wir üblicherweise sofort an die Skalierung des Systems “nach oben”. Es scheint also meistens darum zu gehen, inwieweit unser System durch das Hinzufügen von mehr RAM, CPU oder zusätzlichen Maschinen auch entsprechend mehr Durchsatz erreicht oder mehr Last vertragen kann. Oft ist aber auch die Skalierbarkeit “nach unten” interessant, also die Lauffähigkeit des Systems bei sehr wenig verfügbaren Ressourcen. Eine solche Flexibilität ist zum Beispiel sehr hilfreich, wenn ein komplexes System automatisiert durch viele unterschiedlich dimensionierte Entwicklungs-, Test- und Abnahmeumgebungen wandern muss, bevor es in der Produktivumgebung ankommt.

Large Scale Business Process Integration

Geschäftsprozesse werden heutzutage vielmals unternehmensintern im Rahmen von BPM-Initiativen oder Projekten mit Geschäftsprozessmanagementsystemen, unter anderem auf der Basis von BPEL oder BPMN, automatisiert und eingeführt. Im Rahmen des Projekts Terravis entsteht eine schweizweite Plattform für elektronische Geschäfte zwischen Grundbuchämtern, Banken, Notaren und Handelsregistern, die im Endausbau bis zu 1 000 Umsysteme miteinander verbinden und die Prozesse mit den Beteiligten koordinieren wird. Da wir glauben, dass solche Projekte in Zukunft in der einen oder anderen Facette häufiger vorkommen werden, stellen wir in diesem Artikel die Architektur für solche Projekte vor und berichten über unsere Erfahrungen.

Early-Design Reviews

Sie erfahren in diesem Whitepaper, wie Kunden der innoQ in unterschiedlichen Projektphasen von der Umsetzungs- und Architektur-Expertise von innoQ profitiert haben. Sie lernen die notwendigen Voraussetzungen für erfolgreiche Review-Projekte kennen.

Auf Nummer sicher

Neue Projekte im Geschäftsprozess-Umfeld stehen häufig vor der Herausforderung, Prozesse zu automatisieren. Dabei müssen Prozesse so formal beschrieben werden, dass ein Computer sie, wie andere Software auch, interpretieren und ausführen kann. Dieses High-Level-Programming verlangt aber auch die Qualitätssicherung, insbesondere von kritischen Prozessteilen. In diesem Artikel werden Möglichkeiten für das Testen der verschiedenen Komponenten von ausführbaren Geschäftsprozessen (Prozess, Datentransformationen) und für das Review (Prozess, Servicedefinitionen) sowie Erfahrungen aus einem Projekt vorgestellt.

Vom Sinn und Unsinn einer Zertifizierung für Softwarearchitekten – CPSA-F

Da Softwarearchitekt keine geschützte Berufsbezeichnung ist, können in einem Projektkontext erworbene Fähigkeiten oder Erfahrungen vom nächsten Arbeit- oder Auftraggeber schlimmstenfalls als ungenügend betrachtet werden. Solche Überraschungen wünscht sich weder der Softwarearchitekt noch der Arbeitgeber. Ein gemeinsames Verständnis würde helfen, dieses Risiko zu vermeiden. Um überprüfen zu können, ob jemand den Anforderungen an das Berufsbild Softwarearchitekt gerecht wird, gibt es verschiedene