Software-Architektur für regulierte Märkte
Architektur ist kein Qualitätsmerkmal, sondern eine normative Anforderung.
Domain-Driven Design: Fachdomänen-Grenzen, die zur Risikoanalyse passen
Clean Architecture: Fachlogik bleibt unabhängig von Framework und Datenbank
Architektur-Review vor dem ersten Commit – ab SIL 2 normative Pflicht
Schnittstellen-Spezifikation nach IEC 62304: eindeutig, vollständig, nachweisbar
Security by Design: Threat Modeling als fester Bestandteil der Architekturphase
Softwarearchitektur: Das Fundament für Qualität, Sicherheit und Nachhaltigkeit
Software-Architektur und Design von infoteam für Hersteller in regulierten Märkten: Wir entwerfen modulare, dokumentierte und auditfähige Architekturen, die die Anforderungen aus IEC 62304 und IEC 61508 erfüllen. Mit Domain-Driven Design, Clean Architecture und Threat Modeling entsteht ein Fundament, das Audits besteht und über Jahre wartbar bleibt.
Warum ist Software-Architektur so entscheidend?
Eine durchdachte Softwarearchitektur ist in regulierten Märkten weit mehr als ein Qualitätsmerkmal – sie ist eine normative Anforderung. Standards wie IEC 62304 und IEC 61508 verlangen eine strukturierte Architektur sowie den Nachweis, dass diese den jeweiligen Sicherheitsanforderungen entspricht.
Architektur als Fundament langfristiger Softwarequalität
Wer Softwarearchitektur erst nach der Implementierung berücksichtigt oder aus einem schnellen Proof of Concept ableitet, verursacht Nacharbeitsaufwand. Eine tragfähige Architektur bildet die Grundlage für Testbarkeit, Wartbarkeit und Auditierbarkeit über den gesamten Software-Lebenszyklus.
Früh investieren, später erfolgreich und nachhaltig profitieren
Eine saubere Architektur reduziert technische Risiken und schafft die Basis für eine nachhaltige Softwareentwicklung. Entscheidungen, die früh getroffen werden, lassen sich später deutlich einfacher nachvollziehen und anpassen – aufwendige Korrekturen im weiteren Projektverlauf werden so vermieden.
Vertrauen über alle regulierten Märkte hinweg
Unsere Referenzprojekte und ausgewählten Kunden zeigen, wie wir innovative Ideen in erfolgreiche digitale Lösungen verwandeln – partnerschaftlich, praxisnah und branchenübergreifend.
Domain-Driven Design als Grundlage für
regulierte Software
Domain-Driven Design (DDD) ist ein praxisbewährter Ansatz, der besonders in regulierten Projekten Vorteile bietet. Durch die klare Abgrenzung von Fachdomänen entstehen Softwaremodule, deren Grenzen mit Risiko- und Anforderungsanalyse übereinstimmen. Das vereinfacht die Risikoklassifizierung einzelner Komponenten und macht die Impact-Analyse bei Änderungen präziser. Betrifft eine neue Norm oder Anforderung eine Fachdomäne, lässt sich schnell nachvollziehen, welche Module, Schnittstellen und Testfälle betroffen sind – und welche nicht.
Clean Architecture: Wartbarkeit über mehrere Produktgenerationen
Software in regulierten Märkten hat lange Lebenszyklen. Medizinprodukte und industrielle Steuerungssysteme müssen über viele Jahre zuverlässig betrieben und gewartet werden. Clean Architecture unterstützt dies durch klar definierte Abhängigkeiten: Die Fachlogik bleibt unabhängig von Frameworks, Datenbanken und Benutzeroberflächen. Das bietet entscheidende Vorteile bei der Weiterentwicklung. Müssen Betriebssysteme, Middleware oder Oberflächen ausgetauscht werden, bleibt die Fachlogik unverändert. So lassen sich Änderungen dokumentiert und mit deutlich geringerem Aufwand umsetzen.
Nehmen Sie Kontakt zu uns auf!Architektur-Review vor dem ersten Commit
Ein formales Architektur-Review vor der Implementierung zählt zu den wirksamsten Maßnahmen der Qualitätssicherung. Dabei prüfen unabhängige Experten, ob die Architektur funktionale und nicht-funktionale Anforderungen, Sicherheitsaspekte und die gewählten Designmuster vollständig erfüllt.
In sicherheitskritischen Projekten ab SIL 2 ist ein unabhängiges Architektur-Review keine Empfehlung, sondern eine normative Anforderung. Die Ergebnisse werden nachvollziehbar dokumentiert und bilden eine belastbare Grundlage für alle weiteren Design- und Implementierungsentscheidungen.
1
Architektur-Review
vor der Implementierung
100 %
Prüfung funktionaler Anforderungen
SIL 2+
Normative Anforderung
in kritischen Projekten
1
Belastbare Grundlage für Designentscheidungen
Schnittstellen und Sicherheit: Unterschätzt, bis sie fehlen
Schnittstellen-Design: Wo Architekturfehler am teuersten werden
Fehlerhafte oder undokumentierte Schnittstellen zählen in komplexen Softwaresystemen zu den häufigsten Ursachen für Integrationsprobleme, Seiteneffekte und schwer reproduzierbare Fehler. In regulierten Projekten kommen zusätzliche Anforderungen hinzu: IEC 62304 verlangt eine explizite Spezifikation der Schnittstellen zwischen Software-Einheiten, damit Abhängigkeiten transparent bleiben und Änderungen kontrolliert umgesetzt werden können.
In der Praxis benötigt jede Schnittstelle eine eindeutige Bezeichnung, vollständige Parameterbeschreibung sowie definierte Vor- und Nachbedingungen. Zusätzlich sollte der erfolgreiche Integrationstest nachvollziehbar dokumentiert werden. Was zunächst wie zusätzlicher Aufwand wirkt, reduziert langfristig Risiken und Nacharbeiten deutlich. Denn schlecht dokumentierte Schnittstellen führen häufig zu teuren Late-Stage-Bugs, aufwendigen Fehleranalysen und vermeidbaren Audit-Befunden – und erschweren gleichzeitig Wartung, Erweiterung und sichere Weiterentwicklung der Software.
Architektur für Security by Design: Sicherheit von Anfang an einbauen
Cybersecurity ist in regulierten Märkten kein nachträglicher Zusatz, sondern bereits in der Architekturphase ein zentraler Bestandteil. Der Cyber Resilience Act, IEC 62443 und die MDR verlangen, Sicherheitsanforderungen systematisch aus Bedrohungsanalysen abzuleiten und direkt in der Softwarearchitektur zu berücksichtigen. Dadurch werden Risiken früh sichtbar und können gezielt adressiert werden.
In der Praxis gehören Threat Modeling, geeignete Security Controls und eine nachvollziehbare Dokumentation fest zum Entwicklungsprozess. Sicherheitsmaßnahmen werden so nicht isoliert ergänzt, sondern mit Architektur, Schnittstellen und Tests abgestimmt. Von Beginn an integrierte Sicherheit ist dadurch robuster, besser nachvollziehbar und wirtschaftlicher als nachträgliche Schutzmaßnahmen. Security by Design reduziert Anpassungsaufwand, vermeidet spätere Schwachstellen und schafft eine belastbare Grundlage für sichere, wartbare und auditierbare Software.
Kundenstimmen aus Engineering-Praxis seit 1983
Wir wollen mehr über unsere Produkte erfahren und verstehen, wo wir sie verbessern können. Gleichzeitig wollen wir Aufgaben besser und schneller bewältigen können. Das ist unser Ansporn. Mit infoteam haben wir einen technologisch großartigen Partner an unserer Seite, der sich in unseren Alltag hineindenkt und uns mit innovativen Ideen und Lösungen dabei hilft, unsere Ziele zu erreichen.
Dr. Michael Gloger – Technical Lead Product Quality @ your fingertips, Siemens Healthineers
Bei der Realisierung der Software-Prüfplattform erweiterten wir unser internes, agiles Entwicklungsteam um Softwareentwickler der Firma infoteam. Hierbei entstand eine partnerschaftliche, harmonische Zusammenarbeit, die durch Effizienz, Kreativität und sich ergänzendes Fachwissen geprägt war. Eine solche Kooperation mit infoteam kann ich nur weiterempfehlen.
Uwe Gera – Leiter Entwicklung Prüftechnik, Maschinenfabrik Reinhausen
Die infoteam Software AG ist für uns ein wertvoller und vielseitiger Partner für regulierte Softwareentwicklung. Dank ihrer langjährigen Expertise und ihrem routinierten Umgang mit den normativen Anforderungen an Medizinprodukte liefert infoteam einen zentralen Baustein, damit wir unseren Kunden und deren Patienten Produkte auf höchstem Niveau bieten können.
Projektleiter – Technolas Perfect Vision GmbH
Dank der langjährigen vertrauensvollen Partnerschaft mit infoteam können wir Anforderungen und Softwareprojekte auf höchstem Niveau zukunftssicher umsetzen, die ansonsten außerhalb unserer Kernkompetenzen liegen.
Kai Stursberg – Head of Application Software, Hamilton Bonaduz AG – Robotics
Damit Software in regulierten Märkten erfolgreich produktiv geht, muss sie mehr leisten als nur funktionieren.
Sie bestehen ein Audit nur dann, wenn Ihre Software …
performant ist (Echtzeit-fähig)
ergonomisch bedienbar ist
auditierbar dokumentiert ist
modular ist (austauschbare Komponenten)
echten Geschäftsmehrwert liefert
auf die jeweilige Norm zugeschnitten ist
„Der Zweck des Software Engineerings ist es, Komplexität zu beherrschen, nicht sie zu erschaffen.“ – Pamela Zave
Software-Modernisierung: Bewährtes erhalten, gezielt erneuern
Warum ein Neubau von Grund auf selten die richtige Antwort ist
Ein zehn Jahre altes System neu zu schreiben klingt nach dem sauberen Schnitt – ist in regulierten Märkten aber oft der teuerste und riskanteste Weg. Bereits zertifizierte Funktionen verlieren ihren Nachweis-Status und müssen erneut durch Risikoanalyse, Verifikation und Validierung. So wird nicht nur Neues zertifiziert, sondern bereits Bewiesenes erneut nachgewiesen.
Das Strangler-Fig-Muster: ablösen statt ersetzen
Der belastbarere Ansatz ist das Strangler-Fig-Pattern: Neue Module übernehmen schrittweise Funktionen des Alt-Codes, während das bestehende System parallel weiterläuft. So wird die Software kontrolliert Stück für Stück ersetzt, ohne riskanten Komplettumstieg. Jede abgelöste Funktion kann gezielt verifiziert und bewertet werden, statt das gesamte System neu prüfen zu müssen. Das reduziert Risiken, erleichtert die Nachweisführung und macht die Modernisierung in regulierten Märkten besser beherrschbar.
Nachweisführung während der Übergangsphase
Der eigentliche Architekturaufwand liegt nicht im neuen Code, sondern in der sauberen Trennung zwischen Alt und Neu: klar definierte Schnittstellen, eine lückenlose Traceability während der Migration und ein Testkonzept, das nachweist, dass bereits abgenommene Funktionen ihr Verhalten nicht verändern. Genau hier entscheidet sich, ob eine Modernisierung auditfest umgesetzt wird oder selbst zum Risikofaktor wird.
Wann sich der Aufwand tatsächlich lohnt
Eine Modernisierung lohnt sich vor allem dann, wenn Änderungen am Alt-System unverhältnismäßig teuer werden, Plattformen oder Bibliotheken abgekündigt sind oder neue Anforderungen – etwa aus dem Cyber Resilience Act – im bestehenden Code nicht mehr sauber umsetzbar sind. Umgekehrt gilt: Ein stabiles, gut dokumentiertes System ohne absehbaren Änderungsbedarf muss nicht neu gebaut werden. Ein kurzes Architektur-Assessment zeigt, welche Teile sich zuerst lohnen und wo Aufwand und Nachweisrisiko in keinem Verhältnis stehen.
Sechs Architekturprinzipien, einmal ausformuliert
Was hinter den Begriffen auf dieser Seite steckt – konkret, mit Beispielen aus regulierten Projekten.
1
Domain-Driven Design
Wie sich Fachdomänen so abgrenzen, dass Risikoklassifizierung und Impact-Analyse nicht zur Detektivarbeit werden – mit einem durchgerechneten Beispiel aus der Praxis.
2
Clean Architecture
Warum Fachlogik unabhängig von Framework und Datenbank bleiben sollte – und was das konkret für den Austausch einer Middleware nach fünf Jahren bedeutet.
3
Architektur-Reviews
Ab SIL 2 ist das unabhängige Review keine Kür mehr, sondern Pflicht. Wie ein solches Review abläuft und was am Ende dokumentiert sein muss.
4
Schnittstellen-Design
IEC 62304 verlangt die explizite Spezifikation jeder Schnittstelle. Was das in der Praxis heißt – und warum undokumentierte Schnittstellen die teuersten Audit-Befunde verursachen.
5
Security by Design
Threat Modeling, Security Controls und SBOM: Wie Anforderungen aus Cyber Resilience Act und IEC 62443 schon in der Architektur landen – statt als Nachrüstung kurz vor dem Audit.
6
Systemintegration & Konnektivität
OPC UA, Feldbusse, Cloud-Anbindung: Wie Schnittstellen zu Fremdsystemen so entworfen werden, dass die Integration testbar bleibt und jede Änderung nachvollziehbar ist.
Unser Prozess: Wie Sie mit uns an den Start gehen
1
Erstgespräch & Software-Audit
Im Rahmen eines strategischen Erstgesprächs lernen Sie uns als Ihren Trusted Partner für AI-powered Secure Solutions kennen. Wir verstehen uns als technologischer Sparringspartner auf Augenhöhe: Gemeinsam analysieren wir Ihre Unternehmensziele, technologischen Visionen und regulatorischen Anforderungen, um Potenziale frühzeitig zu erkennen und eine fundierte Basis für die weitere Zusammenarbeit zu schaffen.
2
Architektur- &
System-Assessment
In einer initialen Evaluierung analysieren unsere Experten Ihre bestehenden Systeme oder Konzepte hinsichtlich Architektur, Security, Skalierbarkeit und Normenkonformität. Im Rahmen einer kompakten Videokonferenz spiegeln wir Ihnen unsere fundierten Beobachtungen: Wir validieren technologische Stärken, identifizieren gezielt Optimierungspotenziale und zeigen konkrete, maßgeschneiderte Lösungsstrategien.
3
Bereit für den nächsten Schritt?
Vereinbaren Sie jetzt Ihren persönlichen Beratungstermin mit unseren Experten für AI-powered Secure Solutions. Sie erreichen uns telefonisch unter +49 9131 78 00-0 oder per E-Mail an info@infoteam.de. Die infoteam Software AG mit Hauptsitz in Bubenreuth steht seit vielen Jahren für exzellentes Software Engineering, technologische Innovationskraft und partnerschaftliche Zusammenarbeit.
Was entscheidet über den Erfolg?
Die meisten Softwareprojekte scheitern nicht an der Technologie, sondern an späten oder unstrukturierten Architekturentscheidungen. Fehler, die im Review übersehen werden, kosten nach der Implementierung ein Vielfaches – und schlecht geplante Architekturen erzeugen technische Schulden, die Teams langfristig ausbremsen.
Ein unabhängiges Architektur-Review vor der Umsetzung ist deshalb die wirksamste Maßnahme, um Kosten, Verzögerungen und Qualitätsprobleme früh zu vermeiden. Die von Beginn an klar strukturierte und umgesetzte Architektur entscheidet also über den Erfolg.
Quellen: heise online / Branchenanalyse Golo Roden · Wikipedia „Technische Schulden“ / Zusammenfassung mehrerer Studien · NIST / NASA / Capers-Jones-Analyse von über 12.000 Projekten · Wikipedia „Technische Schulden“
75%
Projekte verfehlen Zeit, Budget oder Zielsetzung
23–42%
der Zeit werden durch Design-Schulden verloren
10–100
mal teurer werden Fehler je später erkannt
15x
mehr Fehler bei schlechter Architektur
Persönlicher Zugang statt Vertriebsfunnel – 60 Minuten Engineering-Sparring
Ihre Anforderungen aus IEC 62304, ISO 13485, IEC 61508 oder MDR sind Engineering-Aufgaben. Sprechen Sie deshalb direkt mit Daniel Blümel über Ihre konkrete Roadmap. Sie erhalten eine ehrliche Einschätzung, ob und wie wir Sie als Engineering-Partner unterstützen können.
Was Sie aus dem Gespräch mitnehmen:
Norm-spezifische Einschätzung Ihrer Roadmap (IEC 62304 / ISO 13485 / IEC 61508 / MDR)
2-3 konkrete Hebel, die Sie mit oder ohne uns nutzen können
Klare Empfehlung: passt infoteam – oder eher ein anderer Partner?
Softwareentwicklung für regulierte Märkte: Unsere Expertise im Überblick
Unsere Expertise verbindet regulatorische Sicherheit, technologische Exzellenz und langfristige Verlässlichkeit – entscheidende Faktoren für erfolgreiche Audits und anspruchsvolle Ausschreibungen.
100 % Mitarbeiter-Eigentum
Als vollständig mitarbeitergeführtes Unternehmen stehen wir für außergewöhnliche Kontinuität, minimale Fluktuation und langfristige Verantwortung – unabhängig von externen Investoren oder kurzfristigen Renditeinteressen.
Normative Souveränität:
ISO 13485 & IEC 61508
Wir entwickeln sicherheitskritische Software nach ISO 13485 und IEC 61508 und integrieren Functional Safety sowie Cyber Security in einen durchgängigen Engineering-Prozess. Entwickelt für regulierte und sicherheitskritische Märkte.
Interdisziplinärer
Technologietransfer
Durch den Transfer bewährter Engineering-Methoden zwischen MedTech, Industrial Applications, Transportation und Public Service reduzieren wir Entwicklungsrisiken und beschleunigen Innovationen in regulierten Märkten.
Häufige Fragen zur Software-Architektur in regulierten Märkten
?
Warum ist Software-Architektur in
regulierten Märkten besonders wichtig?
In regulierten Märkten ist Software-Architektur weit mehr als eine technische Qualitätsfrage. Sie bildet die Grundlage für Sicherheit, Wartbarkeit, Testbarkeit und Nachweisführung. Normen wie IEC 62304 und IEC 61508 verlangen eine strukturierte Architektur und nachvollziehbare Designentscheidungen. Eine belastbare Architektur hilft dabei, Risiken früh zu erkennen, Anforderungen eindeutig abzubilden und spätere Änderungen kontrolliert umzusetzen.
?
Welche Anforderungen stellt IEC 62304
an die Software-Architektur?
Die IEC 62304 fordert eine nachvollziehbare Strukturierung von Software-Systemen und die Beschreibung relevanter Software-Einheiten und Schnittstellen. Abhängigkeiten, Verantwortlichkeiten und Interaktionen müssen so dokumentiert sein, dass sich Anforderungen, Risiken und Tests nachvollziehen lassen. Besonders wichtig ist eine eindeutige Schnittstellen-Spezifikation, damit Integration, Verifikation und spätere Änderungen kontrollierbar bleiben.
?
Welche Vorteile bietet Domain-Driven Design
in regulierten Softwareprojekten?
Domain-Driven Design (DDD) strukturiert Software entlang klar abgegrenzter Fachdomänen. In regulierten Projekten können diese Grenzen mit Risiko- und Anforderungsanalysen abgestimmt werden. Dadurch lässt sich leichter nachvollziehen, welche Komponenten, Schnittstellen und Testfälle von einer Änderung betroffen sind. Das vereinfacht Risikoklassifizierung, Impact-Analyse und Nachweisführung und reduziert Abhängigkeiten zwischen einzelnen Bereichen des Systems.
?
Warum eignet sich Clean Architecture für
langlebige Softwaresysteme?
Clean Architecture trennt Fachlogik konsequent von technischen Abhängigkeiten wie Frameworks, Datenbanken, Middleware oder Benutzeroberflächen. Dadurch bleibt die zentrale Geschäfts- und Fachlogik auch dann stabil, wenn einzelne Technologien ausgetauscht werden. Gerade bei Medizinprodukten, industriellen Steuerungen und anderen langlebigen Systemen reduziert das technische Schulden und Migrationsrisiken und erleichtert die Wartung über mehrere Produktgenerationen.
?
Was wird bei einem
Software-Architektur-Review geprüft?
Bei einem Architektur-Review wird geprüft, ob die geplante Architektur funktionale und nicht-funktionale Anforderungen, Sicherheitsanforderungen und regulatorische Vorgaben angemessen berücksichtigt. Dazu gehören unter anderem Modulgrenzen, Abhängigkeiten, Schnittstellen, Designentscheidungen, Testbarkeit und Security-Aspekte. Die Ergebnisse werden dokumentiert und dienen als belastbare Grundlage für weitere Design-, Implementierungs- und Verifikationsschritte.
?
Wie müssen Schnittstellen in regulierten
Softwareprojekten dokumentiert werden?
Schnittstellen sollten eindeutig bezeichnet und vollständig beschrieben werden. Dazu gehören Parameter, Datenformate, Verantwortlichkeiten sowie definierte Vor- und Nachbedingungen. Zusätzlich muss nachvollziehbar sein, wie die Schnittstelle getestet und verifiziert wurde. Eine saubere Schnittstellen-Spezifikation reduziert Integrationsprobleme und ermöglicht eine belastbare Traceability zwischen Anforderungen, Architektur und Testnachweisen.
?
Was bedeutet Security by Design
in der Software-Architektur?
Security by Design bedeutet, Cybersecurity bereits während der Architekturphase zu berücksichtigen und nicht erst nachträglich zu ergänzen. Dazu gehören Threat Modeling, die Ableitung geeigneter Security Controls und deren Integration in Architektur, Schnittstellen und Testkonzepte. Anforderungen aus beispielsweise IEC 62443, Cyber Resilience Act oder MDR können dadurch frühzeitig berücksichtigt und Sicherheitsrisiken systematisch reduziert werden.
?
Wie lässt sich bestehende Software
in regulierten Märkten modernisieren?
Bestehende Systeme müssen nicht zwangsläufig vollständig neu entwickelt werden. Häufig ist eine schrittweise Modernisierung sinnvoller, bei der neue Module gezielt einzelne Funktionen übernehmen. Ansätze wie das Strangler-Fig-Pattern ermöglichen es, Alt- und Neusystem während der Migration parallel zu betreiben. Entscheidend sind dabei klar definierte Schnittstellen, durchgängige Traceability und gezielte Verifikation, damit bereits nachgewiesene Funktionen nicht unnötig vollständig neu bewertet werden müssen.
Autor: Tim S. Tabrizi – Group CEO & Vorstandsvorsitzender
Tim S. Tabrizi führt die infoteam Software Gruppe als Group CEO und Vorstandsvorsitzender. Er begann als Fachinformatiker und verantwortete in 28 Jahren in Medizintechnik, Telekommunikation und Software – über 20 davon in Führung – Aufgaben bei Siemens, Unify, Sivantos und WS Audiology. Sein Anspruch: Software für regulierte Märkte, die jedes Audit besteht – aus einem Unternehmen im Besitz seiner Mitarbeitenden.
