Zum Hauptinhalt springen
FromNine
Menü

Entwicklung

Unternehmens­software, die Ihre eigenen Teams weiter­entwickeln können.

Wir entwickeln SaaS-Produkte, Portale für Bürgerinnen und Bürger oder für Mitarbeitende sowie zentrale Geschäftsanwendungen. Sie sind barrierefrei, von Haus aus sicher und bleiben auch lange nach dem Start in der Hand Ihrer eigenen Teams wartbar.

Für Softwarehäuser, Finanzdienstleister und öffentliche Stellen in Luxemburg, deren Nutzer in mehreren Sprachen und Ländern zu Hause sind.

Projekt anfragenModernisierung ansehen
Unternehmens­software & SaaS: die BausteineDas Bild zeigt vier gestaffelte Ebenen. Ganz oben die barrierefreie Oberfläche für die Nutzer, darunter die Fachmodule, in denen die Regeln stecken, dann die Plattformdienste für Mandanten und Identitäten, zuunterst die abgesicherte Pipeline, über die jede Version ausgeliefert wird.01Barrierefreie Oberflächen02Fachmodule und Regeln03Mandanten, Identität, Daten04Abgesicherte Auslieferung
  1. 01Domain-driven Design für regelintensive Arbeit wie die Bearbeitung von Dossiers
  2. 02Barrierefreiheit nach EN 301 549 und WCAG 2.2 AA ab dem ersten Entwurf
  3. 03Dokumentation und Entscheidungsprotokolle, die Ihre Teams übernehmen können

01 Probleme

Was wir vor einem Neubau hören

  1. 01

    Jede Änderung dauert ein Quartal

    Die Anwendung läuft, aber an den Kern traut sich niemand heran. Kleine Änderungen brauchen große Regressionstests und ein eigenes Release-Fenster.

  2. 02

    Das Portal lässt seine Nutzer im Stich

    Mit Screenreader, auf dem Smartphone oder in der zweiten Sprache seiner Nutzer funktioniert es nicht. Die Beschwerden kommen, bevor die Barrierefreiheitsprüfung überhaupt stattfindet.

  3. 03

    Die Änderung für einen Kunden legt den nächsten lahm

    Das SaaS-Produkt ist durch Anpassungen pro Kunde gewachsen. Jetzt ist jedes Release eine Verhandlung, und einige Mandanten hängen auf alten Versionen fest.

  4. 04

    Das Wissen ist mit dem Lieferanten gegangen

    Warum etwas so gebaut wurde, steht nirgends. Die ursprünglichen Entwickler sind längst in anderen Projekten, und außer dem Quellcode gibt es keine Unterlagen.

  5. 05

    Kunden und Aufsicht stellen Sicherheitsfragen

    Ein Kunde aus Deutschland oder eine Ausschreibung in Luxemburg fragt nach Stückliste (SBOM), Schwachstellenprozess und Belegen zum Cyber Resilience Act, und im Haus hat das niemand zur Hand.

02 Leistungsumfang

Was wir liefern

  1. 01 Entwicklung von SaaS-Produkten

    Produkte, die viele Kunden aus einer Codebasis bedienen: das passende Mandantenmodell, Konfiguration statt Sonderanpassung und Releases, die bei jedem Mandanten ankommen.

    Was wir tun

    • Wahl des Mandantenmodells: gemeinsam, gebündelt oder je Mandant isoliert
    • Strategie für Konfiguration und Feature Flags
    • Anbindung von Nutzungsmessung und Abrechnung
    • Release-Züge mit Ausrollen je Mandant

    Was Sie erhalten

    • Konzept für Mandantenfähigkeit und Isolation
    • Konfigurationsmodell mit Leitplanken
    • Release-Prozess mit Rücknahme je Mandant

  2. 02 Fachliches Design für komplexe Regeln

    Domain-driven Design dort, wo die Regeln das Produkt sind: Bearbeitung von Dossiers, Anspruchsprüfung, Berechnungen mit vielen rechtlichen Vorgaben. Zwischen modularem Monolithen und Microservices wählen wir bewusst und beginnen meist mit dem Monolithen.

    Was wir tun

    • Event Storming mit den Fachleuten
    • Bounded Contexts und Modulgrenzen
    • Regeln explizit und testbar machen
    • Architekturentscheidungen für die großen Weichenstellungen festhalten

    Was Sie erhalten

    • Fachmodell und Context Map
    • Modulare Codebasis mit durchgesetzten Grenzen
    • Ausführbare Spezifikationen für zentrale Regeln

  3. 03 Portale für Bürger und Mitarbeitende

    Oberflächen auf Basis eines Designsystems, von Anfang an barrierefrei und ab dem ersten Release mehrsprachig. In Luxemburg heißt das zum Beispiel Französisch, Deutsch und Englisch nebeneinander; maßgeblich sind die Sprachen, die Ihre Nutzer tatsächlich verwenden.

    Was wir tun

    • Designsystem mit barrierefreien Komponenten
    • Texte in verständlicher Sprache
    • Tests mit assistiven Technologien und echten Nutzern
    • Übersetzungsablauf für jede Sprache

    Was Sie erhalten

    • Portal auf einem wiederverwendbaren Designsystem
    • Bericht zur Konformität der Barrierefreiheit
    • Ablauf für Inhalte und Übersetzungen

  4. 04 Qualitäts­sicherung und sichere Entwicklung

    Automatisierte Tests dort, wo sie am meisten bringen, Vertragstests an den Schnittstellen zwischen Diensten, Lastprüfungen vor dem Go-live und ein abgesicherter Entwicklungsablauf, der sich auf OWASP ASVS, SBOMs und Kontrollen der Software-Lieferkette stützt.

    Was wir tun

    • Teststrategie und Automatisierung
    • Vertrags- und Performancetests
    • Bedrohungsmodellierung und Prüfung nach ASVS
    • Erzeugung von SBOMs und Regeln für Abhängigkeiten

    Was Sie erhalten

    • Automatisierte Testsuiten in der Pipeline
    • Bericht zur Sicherheitsprüfung
    • Prozess für Schwachstellen, vorbereitet auf den Cyber Resilience Act

  5. 05 Schrittweise Modernisierung

    Ein Altsystem wird Funktion für Funktion hinter einer Routing-Fassade abgelöst, während der Betrieb weiterläuft. Mehr dazu unter Modernisierung von Altsystemen.

    Was wir tun

    • Funktionslandkarte der bestehenden Anwendung
    • Routing nach dem Strangler-Fig-Muster und Kapselung über APIs
    • Datenmigration mit Abgleichsberichten
    • Parallelbetrieb für kritische Berechnungen

    Was Sie erhalten

    • Modernisierungsfolge mit fachlichen Meilensteinen
    • Fassade und neue Module im Produktivbetrieb
    • Abgeglichene Daten bei jeder Umstellung

  6. 06 Wartbarkeit und Übergabe

    Software, die Ihren Teams gehört: lesbarer Code, festgehaltene Entscheidungen, Betriebshandbücher und ein Übergabeplan, der zu Beginn vereinbart wird und nicht am Ende auffällt.

    Was wir tun

    • Pair Programming mit Ihren Entwicklerinnen und Entwicklern während des Baus
    • Architekturentscheidungen direkt beim Code abgelegt
    • Betriebshandbücher und Leitfäden für die Bereitschaft
    • Meilensteine für den Wissenstransfer

    Was Sie erhalten

    • Übergabeplan mit Abnahmekriterien
    • Dokumentation in Ihren Repositories
    • Geschultes internes Team

03 Architektur

Eine Referenz­architektur zur Veranschaulichung

Löst eine neue Geschäftsanwendung eine ältere ab, landen wir oft bei diesem Aufbau: vorne eine barrierefreie Oberfläche, dahinter eine Fassade, die pro Funktion entscheidet, ob das Alt- oder das Neusystem antwortet, dann eine API-Schicht mit festen Verträgen und im Kern Module, die nach fachlichen Zuständigkeiten geschnitten sind.

Mandantenfähigkeit und Einstellungen liegen in eigenen Plattformdiensten statt in Abfragen, die sich durch den ganzen Code ziehen. Bei jedem Build laufen automatisch Tests und Sicherheitsprüfungen, und am Ende steht eine aktuelle SBOM.

Schichten in der Zeichnung

Menschen
Bürgerinnen und Bürger, Kunden und Mitarbeitende, auf jedem Gerät und mit assistiven Technologien.
Modernisierung
Die Routing-Fassade, die bestehende Anwendung und die Datenmigration mit Abgleich.
Plattform
API-Schicht, Identität, der modulare Kern, Mandanten und Konfiguration, operative Daten.
Sichere Auslieferung
Vertrags- und Lasttests, ASVS-Prüfungen und eine SBOM in jedem Build.
Beispiel zur Veranschaulichung

  1. Menschen

    • Bürger, Kunden, Mitarbeitende
    • Barrierefreies Frontend

  2. Schrittweise Modernisierung

    • Routing-Fassade
    • Bestehende Anwendung
    • Migration mit Abgleich

  3. Plattform

    • API-Schicht und Verträge
    • Identität und Rollen
    • Modularer Kern: Eingang, Dossiers, Abrechnung
    • Mandanten, Konfiguration, Feature Flags
    • Operative Datenspeicher

  4. Sichere Auslieferung

    • Vertrags- und Lasttests, ASVS-Prüfungen, SBOM in jedem Build
Modularer Kern hinter einer Routing-Fassade

Veranschaulichende Architektur, kein Kundensystem.

Diagramm als Text lesen

Vom Nutzer aus geht es zuerst in ein barrierefreies Frontend, weiter über die Routing-Fassade und die API-Schicht in einen modularen Kern mit klar getrennten Bounded Contexts.

Ein Teil der Funktionen läuft vorerst noch über die Fassade zur Altanwendung, die nach und nach stillgelegt wird. Deren Bestände ziehen per Migration in die operativen Datenbanken um, jeweils mit Abgleich.

An der API-Schicht hängt die Identitätsverwaltung, unter dem Kern liegen die Dienste für Mandanten und Einstellungen. Ganz unten zieht sich das Band der sicheren Auslieferung entlang: Vertragstests, Lasttests, Sicherheitsprüfung und SBOM.

04 Abwägungen und Grenzen

Technische Abwägungen und Grenzen

  • Zuerst der modulare Monolith

    Unser Umgang damit

    Wir beginnen mit klar getrennten Modulen in einer auslieferbaren Einheit und lösen Dienste nur heraus, wo Skalierung, Release-Takt oder Teamzuständigkeit es verlangen.

    Grenzen und Abhängigkeiten

    Microservices sind zur Hälfte eine Antwort auf Organisationsfragen. Fehlen die Teams, die sie betreuen, bleiben vor allem höhere Kosten und mehr Stellen, an denen etwas ausfallen kann.

  • Barrierefreiheit ist Entwicklungsarbeit

    Unser Umgang damit

    Wir setzen auf zugängliche Bausteine, lassen Prüfwerkzeuge in jeder Pipeline mitlaufen und testen vor größeren Versionen zusätzlich von Hand mit Screenreader und anderen Hilfsmitteln.

    Grenzen und Abhängigkeiten

    Prüfwerkzeuge erkennen bei Weitem nicht alles. Wer Konformität belegen will, braucht manuelle Audits und am besten Rückmeldungen von Menschen mit Behinderungen.

    Inhalte und Dokumente, die Redaktionen nach dem Start hinzufügen, müssen denselben Anforderungen genügen. Wir schulen die Redaktion, haben aber keinen Einfluss darauf, was sie veröffentlicht.

  • Modernisierung dauert so lange wie die Daten

    Unser Umgang damit

    Die Datenmigration wird je Funktion geplant, geprobt und abgeglichen, und die Fachseite bestätigt jede Umstellung.

    Grenzen und Abhängigkeiten

    Oft bestimmt die Qualität der Altdaten das Tempo. Sie zu bereinigen ist ebenso Aufgabe der Fachseite wie der Technik.

  • Regulierung für Softwareprodukte

    Unser Umgang damit

    SBOMs, Umgang mit Schwachstellen und sichere Voreinstellungen gehören zu unserer Standardpipeline und bereiten Produkte auf den Cyber Resilience Act vor.

    Grenzen und Abhängigkeiten

    Ob Ihr Produkt unter die Verordnung fällt und mit welchen Pflichten, beurteilen Ihre Juristen. Von uns kommen die technischen Belege, auf die sie sich dabei stützen.

05 Arbeitsweise

Wie wir arbeiten

Kurze Iterationen, echte Nutzer von Anfang an, und an die Übergabe denken wir schon in Woche eins.

  1. 01

    Die Fachlichkeit kartieren

    Im Event Storming erklären uns die Fachleute ihre Regeln; parallel erfassen wir, welche Funktionen die heutige Anwendung abdeckt.

    ErgebnisContext Map und erste Entscheidungsprotokolle

  2. 02

    Einen schmalen Schnitt ausliefern

    Eine Funktion von vorne bis hinten, durch die Fassade, im Produktivbetrieb mit echten Nutzern.

    ErgebnisFunktionierender Schnitt im Betrieb

  3. 03

    Funktion für Funktion wachsen

    Jedes Release verlagert eine Funktion samt Daten und Nutzern, mit vorbereitetem Abgleich und Rückweg.

    ErgebnisRelease-Plan nach Funktionen

  4. 04

    Übergeben

    Ihre Entwicklerinnen und Entwickler arbeiten mit unseren zusammen, übernehmen die Bereitschaft und verantworten die Roadmap, sobald die Übergabekriterien erfüllt sind.

    ErgebnisAbgenommene Übergabe

06 Menschliche Kontrolle

Wo Menschen die Kontrolle behalten

Bei Geschäftsanwendungen bedeutet Kontrolle: Jede Änderung hat einen Urheber, eine Freigabe und einen Weg zurück.

  • Der Product Owner bestimmt den Umfang

    Prioritäten und Abnahme jedes Inkrements liegen bei Ihrem Product Owner. Unser Part ist die Beratung.

  • Konfiguration hat einen Verantwortlichen

    Einstellungen je Mandant und Feature Flags werden über einen nachvollziehbaren Ablauf geändert, von Rollen, die Sie vergeben.

  • Umstellungen werden freigegeben

    Jeder Wechsel vom alten auf das neue System wird von der Fachseite bestätigt, mit einem geprobten Rückweg.

  • Entscheidungen werden festgehalten

    Architekturentscheidungen zeigen, was gewählt wurde, von wem und warum, damit spätere Teams sie bewusst überprüfen können.

07 Technologien

Technologien, mit denen wir arbeiten

Backend
  • Java und Kotlin
  • .NET
  • TypeScript und Node.js
  • Python
Frontend
  • React und Next.js
  • Angular
  • Designsysteme mit barrierefreien Komponenten
  • Native und plattformübergreifende Mobil-Apps
Daten
  • PostgreSQL
  • SQL Server und Oracle (bestehende Landschaften)
  • Event-Streaming
  • Suchmaschinen
Qualität und Sicherheit
  • Playwright und Vertragstests
  • Last- und Performancetests
  • SAST, DAST und Prüfung von Abhängigkeiten
  • SBOM in CycloneDX oder SPDX

Eine hier genannte Technologie beschreibt unsere Erfahrung in der Entwicklung. Sie bedeutet weder eine Partnerschaft mit dem Hersteller noch dessen Empfehlung.

08 Beispiel

Ein veranschaulichendes Beispiel

Beispiel zur Veranschaulichung

Ein dreisprachiges Anleger­portal für eine Fonds­administration

01Ausgangslage
Eine Fondsadministration beantwortet Anfragen von Anlegern und Initiatoren per E-Mail und PDF. Das vorhandene Portal gibt es nur auf Französisch, es besteht keine Barrierefreiheitsprüfung, und jede Änderung wird für jeden Fonds einzeln umgesetzt.
02Was wir bauen würden
Ein Portal auf einem gemeinsamen Designsystem in Französisch, Deutsch und Englisch, mit Texten, Sprachen und Anbindungen an die Fondsbuchhaltung als Konfiguration und einem einzigen Release-Zug.
03Wo Menschen entscheiden
Compliance gibt Inhalte und Konfiguration für jeden Fonds frei; über gemeinsame Funktionen entscheidet der Product Owner.
04Was wir messen würden
Barrierefreiheitsmängel pro Release, Zeit, bis eine Änderung in allen drei Sprachen live ist, und Anteil der Anfragen, die im Portal statt per E-Mail erledigt werden.

09 Branchen

In Ihrer Branche

  • Staat & Gemeinden

    Fachsoftware und Bürgerportale für Ministerien, Verwaltungen und Gemeinden, barrierefrei nach dem Gesetz vom 28. Mai 2019, zweisprachig in Französisch und Deutsch und, wo der Prozess es vorsieht, im Zusammenspiel mit Verfahren auf MyGuichet.lu.

  • Finanzsektor

    Kundenportale und Backoffice-Anwendungen für Banken, Fondsadministrationen und Versicherer, mit belastbarem Prüfpfad und Release-Prozessen, die dem Change Management standhalten.

  • Fertigung & Industrie

    Konfiguratoren, Serviceportale und SaaS-Produkte für Hersteller von Anlagen und Geräten, angebunden an ERP und Außendienst.

Luxemburg

Ein neuer Markt ist ein Release, kein Fork

Ein Produkt, das von Luxemburg aus in die EU verkauft wird, trifft den European Accessibility Act in nationalen Fassungen. In Luxemburg ist es das geänderte Gesetz vom 8. März 2023: Seit dem 28. Juni 2025 müssen Produkte und Dienstleistungen in seinem Anwendungsbereich barrierefrei sein, mit Übergangsfrist bis zum 28. Juni 2030 für bestehende Produkte, und die Marktüberwachung liegt beim OSAPS. Der Cyber Resilience Act kommt als eine Verordnung, deren Pflichten stufenweise greifen. Dazu erwarten Kunden in jedem Land ihre Sprache, ihre Rechnungsregeln und ihre Verfahren zur Identifizierung.

Solche Unterschiede halten wir in Konfiguration und klar abgegrenzten Modulen, damit ein neuer Markt ein Release bleibt und kein Fork wird. Nachweise zur Barrierefreiheit und zur Sicherheit erzeugt die Pipeline, bereit für die Fragen, die öffentliche Auftraggeber und Einkaufsabteilungen in jedem Markt stellen.

Fragen zu Unternehmenssoftware und SaaS

Sollen wir eigene Software bauen oder eine Plattform konfigurieren?

Entspricht Ihr Ablauf weitgehend dem Branchenüblichen, ist Konfiguration meist der bessere Weg. Eigenentwicklung zahlt sich aus, wenn gerade dieser Ablauf Ihren Unterschied ausmacht oder seine Regeln in kein Standardprodukt passen. Da wir Salesforce, SAP und Odoo ebenso umsetzen wie individuelle Software, verdienen wir an keiner Antwort mehr als an der anderen. In Architektur & Beratung treffen wir diese Wahl offen und begründet.

Garantieren Sie, dass unser Portal barrierefrei ist?

Maßstab sind EN 301 549 und WCAG 2.2 AA. Wir prüfen maschinell und manuell und übergeben einen Konformitätsbericht, in dem auch offene Punkte stehen. Auf EN 301 549 beruht übrigens RAWeb, der Referenzrahmen, mit dem der Service information et presse (SIP) die Websites öffentlicher Stellen in Luxemburg überwacht. Ein Portal ganz ohne Mängel sagen wir nicht zu; zugesagt ist, dass wir Mängel aufspüren, offenlegen und innerhalb unseres Auftrags beheben.

Geht Modernisierung auch ohne Stichtagsumstellung?

Das ist sogar unser Vorschlag. Hinter einer Routing-Fassade zieht eine Funktion nach der anderen um, die Altanwendung bleibt währenddessen in Betrieb, und nach jedem Schritt gleichen wir die Daten ab.

Kann unser eigenes Team die Software übernehmen?

So ist es von Anfang an geplant. Woran die Übergabe gemessen wird, steht ab dem ersten Monat fest, Ihre Leute entwickeln im Tandem mit unseren, und Entscheidungsprotokolle wie Betriebshandbücher liegen in Ihren eigenen Repositories.

Was bedeutet der Cyber Resilience Act für unser Produkt?

Wer Software mit digitalen Elementen auf den EU-Markt bringt, kann Pflichten zu sicherem Design, Umgang mit Schwachstellen und Dokumentation haben. Das gilt für ein Luxemburger Softwarehaus genauso wie für einen Anbieter aus dem Ausland. Wir schaffen die technischen Nachweise: SBOMs, einen Prozess für Schwachstellen und sichere Voreinstellungen.

Was muss weiterlaufen, während Sie modernisieren?

Wir schlagen die erste Funktion vor, die umziehen sollte, und zeigen, was Ihr Team am Ende selbst verantwortet.

Projekt anfragenModernisierung ansehen