Einleitung

Im ersten Teil meiner Einführungspost-Reihe ging es um meinen persönlichen Entwicklungsweg, vom Diplom-Maschinenbauingenieur zum selbstständigen Softwareentwickler mit dem Ziel, Ingenieurwissen und moderne Softwareentwicklung zusammenzuführen. Ein zentrales Element dieser neuen beruflichen Phase ist die heat-conduction-app, die als Demo-Anwendung und Architektur-Referenzprojekt dient.

Im zweiten Teil habe ich den physikalischen Hintergrund beleuchtet, vom Fourierschen Gesetz bis zur Frage, wie sich eine technische Formel systematisch in Softwarelogik übersetzen lässt. Dabei habe ich ein zentrales Denkmodell eingeführt: die funktionalen Bausteine. Sie dienen als eine Art Übersetzer zwischen der physikalisch-technischen Problemstellung und den Anforderungen an eine Softwarelösung. Unabhängig vom konkreten Technologie-Stack strukturieren sie, was eine Anwendung fachlich leisten muss: Domänenmodell, Berechnungslogik, Ein- und Ausgabe sowie deren Orchestrierung.

In diesem dritten Teil schließt sich nun der Kreis. Der Fokus liegt auf der Softwarearchitektur und dem daraus abgeleiteten Technologie-Stack. Die im ersten Teil vorgestellten vier Entwicklungsphasen bilden dabei die methodische Grundlage. Sie helfen die Komplexität einer Anwendung kontrolliert zu steigern. Von einem schnellen, lauffähigen Prototyp bis hin zu einer modularen, erweiterbaren Web-Applikation.

Der gewählte Stack soll diese Philosophie widerspiegeln, leichtgewichtig, modular und skalierbar. Denn gerade bei Berechnungs- und Simulationstools ist es entscheidend, nicht mit einem überdimensionierten Framework zu starten, sondern mit einem System, das mit den Anforderungen wachsen kann.

Softwarearchitektur - eine grundlegende Entscheidung

Bevor ich auf konkrete Technologien eingehe, lohnt sich ein Blick auf Systemebene: Um was für eine Art von Software handelt es sich hier eigentlich?

An dieser Stelle hilft der Rückgriff auf die funktionalen Bausteine aus Teil 2. Aus der physikalischen Aufgabenstellung ergeben sich klare fachliche Anforderungen: ein Domänenmodell für Materialien und Parameter, eine zentrale Berechnungslogik, strukturierte Eingaben, nachvollziehbare Ausgaben sowie eine übergeordnete Orchestrierung, die diese Elemente verbindet.

Eine geeignete Softwarearchitektur sollte für diese fachlichen Bausteine passende technische Entsprechungen bieten. Aus meiner Sicht eignet sich dafür besonders gut eine webbasierte Applikation mit klarer Trennung von Backend, Frontend und Datenhaltung.

Die fachliche Logik, also Rechenkern, Validierung und Orchestrierung, liegt dabei im Backend. Das Frontend übernimmt die Eingabe und Darstellung der Ergebnisse. Während die Datenbank als persistente Wissensbasis dient, etwa für Materialdaten oder gespeicherte Berechnungen. Diese Struktur erlaubt es Verantwortlichkeiten sauber zu trennen und die Anwendung schrittweise weiterzuentwickeln, vom einfachen, monolithischen Server-Side-Rendering-Ansatz über eine API-zentrierte Architektur bis hin zu stärker entkoppelten Systemen.

Ein entscheidender Vorteil dieses Ansatzes ist der Zugriff über den Browser. Die Anwendung ist unabhängig vom Betriebssystem und Endgerät, muss nicht lokal installiert werden und kann zentral bereitgestellt und gepflegt werden. Gerade in technischen Umgebungen, in denen Berechnungswerkzeuge häufig als lokale Skripte oder Excel-Dateien existieren, schafft eine solche Architektur einen deutlich niedrigeren Zugang und eine bessere Verfügbarkeit des Wissens.

Diese grundlegende Architekturentscheidung bildet das Fundament für alle weiteren technischen Schritte und bestimmt letztlich auch, welcher Technologie-Stack sinnvoll ist und warum.

Software-Stack oder die Qual der Wahl

Wer sich einmal mit der Entwicklung von Web-Applikationen beschäftigt hat, weiß dass es unzählige Wege gibt, eine Anwendung zu realisieren, von Java mit SpringBoot über Python mit Flask und Django, Ruby on Rails bis hin zu JavaScript mit Express und vielen weiteren.

In meiner bisherigen beruflichen Laufbahn war ich klar in der Java-Welt zu Hause. SpringBoot ist ein mächtiges Framework, das sich in großen Unternehmensumgebungen hervorragend bewährt hat. Parallel habe ich über viele Jahre Python genutzt, vor allem zur Datenanalyse und Automatisierung.

Zu Beginn meiner Vertiefungsphase habe ich mir bewusst einen Überblick über verschiedene Web-Frameworks verschafft. Mir ging es darum, meinen Blick zu weiten und ein Framework zu finden, das sich besonders gut für technische Berechnungs-Applikationen eignet. Der Fokus lag bald auf dem Microframework Flask, mit seiner schlanken, modularen Basis und der Möglichkeit, Architektur und Komplexität schrittweise wachsen zu lassen.

Diese Entscheidung ist eng mit Phase 1 des Entwicklungsmodells verknüpft. Ziel ist eine vollständig lauffähige, aber bewusst einfache Web-Applikation, die den fachlichen Kern abbildet, ohne frühzeitig unnötige technische Komplexität einzuführen.

Flask - das richtige Backend für Phase 1

Im Rahmen meiner Vertiefungsphase habe ich mich intensiv mit Flask, Jinja und SQLAlchemy beschäftigt. Flask ist ein leichtgewichtiges, modulares Framework, mit dem sich sehr schnell eine funktionierende Anwendung aufsetzen lässt. Der Einsteig ist erstaunlich einfach, mit wenigen Zeilen Code steht bereits eine lauffähige Web-App.

Sobald jedoch eine strukturierte, erweiterbare und produktionsreife App entstehen soll, steigt der Aufwand im Projekt-Setup deutlich an. Dennoch bleibt Flask auch dann eine schlanke Lösung, die dem Entwickler viel Freiheit lässt. Im Gegensatz zu SpringBoot und Django, die als vollumfängliche Frameworks viele Funktionen mitbringen, liefert Flask zunächst nur das Grundgerüst. Was fehlt, lässt sich gezielt durch Extensions ergänzen, etwa für Datenbankanbindung, Formularverarbeitung, Authentifizierung oder Internationalisierung.

Gerade für technische Berechnungswerkzeuge, die häufig intern, mit klar abgegrenztem Funktionsumfang eingesetzt werden, ist das ein großer Vorteil. In Phase 1 geht es nicht darum, alle Eventualitäten abzudecken, sondern eine stabile Basis zu schaffen, auf der sich die fachliche Logik sauber entwickeln lässt. Flask erlaubt das, klein starten, klar strukturieren und die Anwendung bei Bedarf Schritt für Schritt erweitern.

Auch auf der Sprachebene passt diese Entscheidung gut in das Konzept. Python ist in vielen Bereichen nicht zwingend “besser” als Java, aber häufig direkter, flexibler und schneller in der Umsetzung. Während Java mit Typisierung, Stabilität und Performance punktet, überzeugt Python für mich durch Einfachheit, Lesbarkeit und Entwicklungsgeschwindigkeit, ideale Eigenschaften für Phase 1 eines Berechnungstools.

Langfristig wäre es durchaus spannend, die gleiche App einmal mit SpringBoot umzusetzen, um architektonische Unterschiede sichtbar zu machen. Für den Einstieg und die frühe Evolutionsstufe ist Flask jedoch die passendere Wahl.

Ciao csv - eine Datenbank als Fundament

Ein wesentlicher Bestandteil moderner Applikationen ist eine saubere Datenhaltung. Auch wenn zu Beginn oft nur wenige Daten anfallen und vieles mit Listen und CSV-Dateien umgesetzt werden kann, wie ich es selbst häufig in Skripten gesehen habe, stößt man damit schnell an Grenzen. Spätestens wenn die Anwendung wächst ist ein stabiles Datenfundament entscheidend.

Hier ist der Einstieg erstaunlich einfach. Mit Flask-SQLAlchemy steht eine leistungsfähige, aber zugleich gut zugängliche Erweiterung zur Verfügung, die auf dem etablierten SQLAlchemy ORM basiert. SQLAlchemy erlaubt es, Datenbanktabellen als Python-Modelle zu definieren. Abfragen, Änderungen und Beziehungen lassen sich damit über eine klare, Python-nahe Syntax formulieren, ohne direkt SQL schreiben zu müssen.

In Phase 1 setze ich bewusst auf SQLite als leichtgewichtige Datenbank. Sie ist lokal, einfach zu handhaben und ideal für frühe Entwicklungsstufen. Gleichzeitig bleibt die Architektur offen, der spätere Wechsel zu PostgreSQL oder einer anderen produktiven Datenbank ist mit minimalem Aufwand möglich. Genau diesen Übergang plane ich zwischen Phase 1 und Phase 2 exemplarisch zu zeigen.

Statische Webseiten? Bewusste Entscheidung für Phase 1

Neben dem Backend und der Datenbank ist das Frontend der dritte zentrale Bestandteil einer Web-Applikation. Für den Einstieg setze ich bewusst auf Jinja in Kombination mit klassischen HTML-Seiten, also Server Side Rendering (SSR).

Auf den ersten Blick wirkt das vielleicht wie ein Schritt zurück, tatsächlich ist es eine sehr bewusste Entscheidung im Sinne von Phase 1. In frühen Entwicklungsstadien ist es entscheidend, schnell sichtbare Ergebnisse zu erzeugen: Eingaben, Berechnungen und Ausgaben sollen unmittelbar erlebbar sein.

Jinja bietet dafür ein äußerst mächtiges aber zugleich einfaches Werkzeug. Mit Variablen, Kontrollstrukturen, Template-Inheritance, Subtemplates und Macros lassen sich dynamische Inhalte ohne JavaScript abbilden.

Für Layout und Gestaltung setze ich ergänzend auf Bootstrap, was die Erstellung funktionaler, responsiver Oberflächen erheblich vereinfacht. So lassen sich in kurzer Zeit klar strukturierte Seiten umsetzen, die auch visuell überzeugen, ideal für interne Tools oder technische Applikationen, bei denen Funktionalität im Vordergrund steht.

Nicht jede App muss von Beginn an als Single Page Application (SPA) umgesetzt werden. Ein früher Einstieg in komplexe Frontend-Architekturen führt häufig zu unnötigem Overhead. Der SSR-Ansatz erlaubt es, Funktionalität und Benutzerführung schrittweise zu entwickeln und bildet zugleich eine solide Basis für spätere Evolutionsstufen.

Damit ist Phase 1 abgeschlossen: Eine vollständige, leichtgewichtige Web-Applikation mit Backend, Datenbank und Frontend, die den fachlichen Kern abbildet und bewusst Raum für Weiterentwicklung lässt.

Mehr Flexibilität mit REST-API (Phase 3)

Die bisherige serverseitig gerenderte Frontend-Lösung ist ideal für den schnellen Einsteig und klar strukturierte Anwendungen. Sie erlaubt es, Berechnungen, Datenflüsse und Ergebnisse früh sichtbar zu machen. Mit zunehmendem Funktionsumfang und wachsender Integration in bestehende Systeme stößt dieser Ansatz jedoch an natürliche Grenzen.

An dieser Stelle markiert Phase 3 einen bewussten architektonischen Einschnitt: die Einführung einer REST-API. Sie bildet das Rückgrat vieler moderner Web-Applikationen und entkoppelt die fachliche Logik von der Darstellungsschicht. Berechnungen, Eingaben und Ergebnisse werden über klar definierte Schnittstellen als JSON-Daten bereitgestellt.

In der Demo-App wird die bestehende Flask-Anwendung daher um eine REST-Schnittstelle erweitert. Anwender können die App weiterhin über die Browser-Oberfläche bedienen, gleichzeitig ist es aber möglich, Berechnungen direkt aus eigenen Skripten, anderen Web-Anwendungen oder Engineering-Tools anzusteuern.

Damit wird aus einer isolierten Berechnungs-App eine flexible, integrierbare Lösung, die sich gut in bestehende technische Workflows einfügen lässt und somit Teil eines vernetzten Engineering-Tools sein kann.

Optional: Single-Page-Application als Phase 4

Mit der Einführung der REST-API ist die fachliche Logik vollständig vom Frontend entkoppelt. Damit ist prinzipiell der Weg frei für eine Single-Page-Application (SPA), etwa auf Basis von React. Dies würde eine möglich Phase 4 darstellen, nicht als zwingender Schritt, sondern als optionale Weiterentwicklung.

Eine SPA ermöglicht hochgradig interaktive, dynamische Benutzeroberflächen und eine klare Trennung zwischen Backend-Services und Frontend-Anwendung. Gleichzeitig ist der Aufwand nicht zu unterschätzen. Eine bestehende, funktionierende SSR-Oberfläche müsste entweder ersetzt oder parallel weiterentwickelt werden.

Für mich persönlich ist dieser Schritt vor allem als Lern- und Vergleichsprojekt interessant. Während ich mich in Flask und den Backend-Technologien mittlerweile sicher bewege, eröffnet React eine neue Denkweise rund um Komponenten, State-Management und reaktive Oberflächen. Ob und wann dieser Schritt sinnvoll ist, hängt stark vom Einsatzzweck der Anwendung ab.

Wichtig ist, die Architektur der vorherigen Phasen ist so ausgelegt, dass dieser Schritt möglich, aber nicht notwendig ist.

Von Anfang an mitgedacht: Deployment und Betrieb

Wenn Backend, Datenbank und Frontend ineinandergreifen, stellt sich früh die Frage nach dem Betrieb der Anwendung. Für die Demo-App setze ich bereits ab Phase 1 auf Container-Technologien wie Docker und Podman. Sie erlauben es, die Anwendung inklusive aller Abhängigkeiten in einer definierten Umgebung zu betreiben. Für Phase 1 bedeutet dies, die App läuft containierisiert, nutzt SQLite und kann lokal oder auf einem einfachen Server gestartet werden.

Der Vorteil liegt in der Reproduzierbarkeit. Egal ob Entwicklung, Test oder späterer Betrieb, die Umgebung bleibt konsistent. Updates lassen sich klar versionieren und mit wenigen Befehlen ausrollen. Genau diese Eigenschaften fehlen häufig bei klassischen Excel- oder Skriptlösungen, die an einzelne Rechner gebunden sind.

Themen wie externe Datenbank, Cloud-Deployment, CI/CD-Pipelines oder automatisierte Tests gehören für mich zu späteren Evolutionsstufen. Sie stehen auf der Roadmap, sind aber bewusst nicht Teil er ersten Phase. Auch hier gilt, die Architektur ist von Anfang an so angelegt, dass diese Schritte jederzeit ergänzt werden können.

Stack-Fazit

Damit schließt sich der Kreis um meinen gewählten Software-Stack: Flask → SQLAlchemy → SQLite/PostgreSQL → Jinja/REST/optional React → Docker/Podman.

Jede dieser Komponenten ist bewusst einer oder mehreren Entwicklungsphasen zugeordnet und erfüllt dort eine klar definierte Rolle. Der Stack erlaubt es, mit einer überschaubaren, leichtgewichtigen Architektur zu starten und diese Schrittweise, fachlich wie technisch, weiterzuentwickeln.

Natürlich existieren unzählige Alternativen und Kombinationen, Mit Blick auf die Anforderungen kleiner und mittlerer Berechnungs- und Simulationstools sehe ich hier jedoch eine sehr ausgewogene Lösung. Modular, nachvollziehbar und skalierbar, ohne von Beginn an unnötige Komplexität einzuführen.

Gesamt-Fazit

Nach dem persönlichen Einstieg im ersten Teil und dem physikalisch-technischen Kern im zweiten Teil, bildet dieser dritte Teil den Abschluss der Einführungspost-Reihe. Im Mittelpunkt stand die Frage:

Wie lässt sich Ingenieurwissen in eine moderne, nachhaltige Softwarelösung überführen?

Meine Antwort darauf ist kein einzelnes Tool oder Framework, sondern ein Zusammenspiel aus Denkmodellen und Strukturprinzipien: den funktionalen Bausteinen als Übersetzer zwischen Ingenieurproblem und Software, einer passenden Softwarearchitektur, einem bewusst gewählten Technologie-Stack und dem klar strukturierten 4-Phasen-Modell, das die Entwicklung von der ersten Berechnung bis zur produktiv nutzbaren Web-Applikation begleitet.

Aus meiner bisherigen Laufbahn, von Matlab und Excel/VBA über Python-Skripte bis hin zu Java/SpringBoot-Backends, weiß ich, wie viel Potential in ingenieurgetriebenem Softwaredesign steckt. Leichtgewichtige, modulare Web-Applikationen bieten aus meiner Sicht die beste Möglichkeit, Berechnungs- und Projektierungswissen zentral, transparent und langfristig nutzbar zu machen. Sie fördern den Wissensaustausch im Unternehmen, sichern wertvolle Erfahrungen und stärken ganz nebenbei das Verständnis für moderne Softwareentwicklung.

Mit der heat-conduction-app möchte ich zeigen, dass der Weg zur eigenen technischen Web-Applikation keine Raketenwissenschaft ist. Er ist ein machbarer, klar strukturierter Prozess und in vielen Fällen eine deutlich nachhaltigere Alternative zu isolierten Excel-Lösungen oder geschlossenen, kommerziellen Tools.

Mit diesem Artikel ist der konzeptionelle Rahmen gesetzt. In den kommenden Beiträgen geht es nun weg von Modellen und Prinzipien hin zur konkreten Umsetzung der heat-conduction-app.

Als Nächstes folgen

• Meilenstein 1: Applikationsstruktur - Vom Konzept zur konkreten Implementierung
• Meilenstein 2: Erste Berechnung läuft - Die Formel als Service-Modul

Ich freue mich, wenn du mich bei dieser Umsetzung begleitest.

Feedback, Fragen oder Anregungen sind jederzeit willkommen, gerne per Email oder auch auf LinkedIn.