Zum Hauptinhalt springen
FromNine
Menü

Engineering

Unternehmens­software, an der Ihr eigenes Team weiterbauen kann.

SaaS-Produkte, Portale für Bürgerinnen, Bürger und Bedienstete sowie zentrale Fachanwendungen: Wir bauen sie barrierefrei, mit sicheren Voreinstellungen und so, dass Ihre Leute sie lange nach dem Start selbst weiterentwickeln.

Für Softwarehäuser und öffentliche Stellen in Österreich, deren Nutzerinnen und Nutzer in mehreren Ländern, Sprachen und Rechtsordnungen zu Hause sind.

Erstgespräch anfragenAltsysteme ablösen
Unternehmenssoftware & SaaS: der AufbauVier Schichten übereinander. Zuoberst die barrierefreie Oberfläche, mit der Menschen arbeiten, darunter die Fachmodule mit den Regeln, dann die Plattformdienste für Mandanten und Identität und als Fundament die abgesicherte Auslieferungs-Pipeline.01Barrierefreie Oberflächen02Fachmodule und Regeln03Mandanten, Identität, Daten04Sichere Auslieferung
  1. 01Domain-driven Design für regelintensive Arbeit wie die Bearbeitung von Akten und Ansuchen
  2. 02Von der ersten Skizze an barrierefrei gemäß EN 301 549 und WCAG 2.2 AA
  3. 03Dokumentation und Entscheidungsprotokolle, die Ihr Team übernehmen kann

01 Probleme

Was wir vor einer Neuentwicklung zu hören bekommen

  1. 01

    Jede Änderung dauert ein Quartal

    Die Anwendung tut ihren Dienst, nur den Kern rührt keiner mehr an. Selbst Kleinigkeiten verlangen aufwendige Regressionstests und warten auf das nächste Release-Fenster.

  2. 02

    Das Portal lässt seine Nutzerinnen und Nutzer im Stich

    Mit Screenreader geht nichts, eine zweite Sprache fehlt, am Handy ist es kaum bedienbar. Die Beschwerden treffen früher ein als der Prüfbericht zur Barrierefreiheit.

  3. 03

    Was ein Kunde bekommt, legt den nächsten lahm

    Das SaaS-Produkt ist über Sonderanpassungen je Kunde gewachsen. Heute wird jedes Release verhandelt, und manche Mandanten hängen auf alten Ständen fest.

  4. 04

    Das Wissen ist mit dem Dienstleister gegangen

    Begründungen für Entscheidungen hat nie jemand aufgeschrieben. Das ursprüngliche Team ist weitergezogen, und außer dem Code gibt es keine Dokumentation.

  5. 05

    Kundschaft und Behörden stellen Sicherheits­fragen

    Der Einkauf will eine SBOM, einen Prozess für Schwachstellen und Nachweise zum Cyber Resilience Act sehen. Vorbereitet ist nichts davon.

02 Leistungs­umfang

Was wir liefern

  1. 01 Entwicklung von SaaS-Produkten

    Eine Codebasis, viele Kunden: Wir wählen das passende Mandantenmodell, setzen auf Konfiguration statt Sonderanpassung und sorgen dafür, dass jedes Release bei allen Mandanten ankommt.

    Was wir tun

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

    Was Sie erhalten

    • Konzept für Mandantentrennung und Isolation
    • Konfigurationsmodell mit Leitplanken
    • Release-Prozess mit Rückfallmöglichkeit je Mandant

  2. 02 Fachlicher Entwurf für komplexe Regeln

    Wo die Regeln das eigentliche Produkt sind, etwa bei Aktenbearbeitung, Anspruchsprüfung oder vorschriftenlastigen Berechnungen, arbeiten wir mit Domain-driven Design. Zwischen modularem Monolithen und Microservices entscheiden wir bewusst und beginnen meistens mit dem Monolithen.

    Was wir tun

    • Event Storming mit den Fachleuten
    • Bounded Contexts und Modulgrenzen
    • Regeln, die ausdrücklich formuliert und testbar sind
    • Architekturentscheidungen für die großen Weichenstellungen schriftlich festgehalten

    Was Sie erhalten

    • Domänenmodell und Kontextlandkarte
    • Modulare Codebasis mit erzwungenen Grenzen
    • Ausführbare Spezifikationen für die zentralen Regeln

  3. 03 Portale für Bürger­service und Belegschaft

    Oberflächen auf Basis eines Designsystems, von Haus aus barrierefrei und ab dem ersten Release mehrsprachig. Für österreichische Portale heißt das in der Regel Deutsch als Basis, die Anmeldung mit ID Austria, wo Bürgerinnen und Bürger oder Unternehmen sich ausweisen müssen, und die weiteren Sprachen, die Ihre Nutzerinnen und Nutzer tatsächlich brauchen.

    Was wir tun

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

    Was Sie erhalten

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

  4. 04 Qualitäts­sicherung und sichere Entwicklung

    Testautomatisierung auf den richtigen Ebenen, Vertragstests zwischen Diensten, Lasttests vor dem Start und ein sicherer Entwicklungsprozess, der auf OWASP ASVS, SBOMs und Kontrollen der Lieferkette aufsetzt.

    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 über die Sicherheitsprüfung
    • Prozess für Schwachstellen, vorbereitet auf den Cyber Resilience Act

  5. 05 Schrittweise Modernisierung

    Eine Altanwendung wird hinter einer Routing-Fassade Funktion um Funktion ersetzt, und das Geschäft läuft dabei weiter. Mehr dazu unter Altsysteme ablösen.

    Was wir tun

    • Landkarte der Funktionen der bestehenden Anwendung
    • Strangler-Fig-Routing und Kapselung über APIs
    • Datenmigration mit Abgleichsberichten
    • Parallelbetrieb für kritische Berechnungen

    Was Sie erhalten

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

  6. 06 Wartbarkeit und Übergabe

    Software, die Ihrem Team gehört: lesbarer Code, festgehaltene Entscheidungen, Runbooks und ein Übergabeplan, den wir zu Beginn vereinbaren, statt ihn am Ende zu improvisieren.

    Was wir tun

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

    Was Sie erhalten

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

03 Architektur

Eine Referenz­architektur zum Veranschaulichen

So sieht eine Fachanwendung häufig aus, die eine ältere ablöst: vorne eine barrierefreie Oberfläche, dahinter eine Routing-Fassade, die jede Funktion entweder zum alten oder zum neuen System schickt, eine API-Schicht mit klaren Verträgen und ein modularer Kern, der nach der Fachdomäne gegliedert ist.

Mandantenfähigkeit und Konfiguration sind eigene Plattformdienste und keine Bedingungen, die quer durch den Code verstreut sind. In jedem Build laufen Tests und Sicherheitsprüfungen, und jeder Build liefert eine SBOM.

Schichten in der Zeichnung

Menschen
Bürgerinnen und Bürger, Kundschaft und Mitarbeitende, auf jedem Gerät und mit assistiven Technologien.
Modernisierung
Routing-Fassade, bestehende Anwendung und Datenmigration mit Abgleich.
Plattform
API-Schicht, Identität, modularer Kern, Mandanten und Konfiguration, operative Daten.
Sichere Auslieferung
Jeder Build mit Vertrags- und Lasttests, ASVS-Prüfung und SBOM.
Beispiel zur Veranschaulichung

  1. Menschen

    • Bevölkerung, Kundschaft, Belegschaft
    • Barrierefreie Oberfläche

  2. Schrittweise Modernisierung

    • Routing-Fassade
    • Bestehende Anwendung
    • Migration mit Abgleich

  3. Plattform

    • API-Schicht und Verträge
    • Identität und Rollen
    • Modularer Kern: Eingang, Akten, 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 System eines Kunden.

Diagramm als Text lesen

Vom Menschen führt der Hauptweg zur barrierefreien Oberfläche, weiter über Routing-Fassade und API-Schicht bis zum modularen Kern, der in Bounded Contexts gegliedert ist.

Einen Teil der Funktionen reicht die Fassade vorerst an die Altanwendung weiter, die nach und nach außer Betrieb geht. Ihre Daten gelangen per Migration samt Abgleich in die operativen Speicher.

Die Identitätsverwaltung bedient die API-Schicht. Unter dem Kern liegen Dienste für Mandanten und Konfiguration. Ein Band für sichere Auslieferung ganz unten umfasst Vertragstests, Lasttests, Sicherheitsprüfungen und SBOMs.

04 Überlegungen und Grenzen

Technische Überlegungen und Grenzen

  • Zuerst der modulare Monolith

    Wie wir damit umgehen

    Wir beginnen mit sauber getrennten Modulen in einer einzigen auslieferbaren Einheit. Eigene Services lösen wir nur heraus, wo Skalierung, Release-Takt oder Teamzuständigkeit es verlangen.

    Grenzen und Abhängigkeiten

    Microservices lösen organisatorische Probleme ebenso wie technische. Fehlen die Teams, die sie betreuen, bringen sie vor allem Kosten und zusätzliche Fehlerquellen.

  • Barrierefreiheit ist Ingenieursarbeit

    Wie wir damit umgehen

    Barrierefreie Komponenten, automatische Prüfungen in der Pipeline und vor jedem größeren Release manuelle Tests mit assistiven Technologien.

    Grenzen und Abhängigkeiten

    Automatische Werkzeuge erkennen nur einen Teil der Mängel. Volle Konformität verlangt manuelle Audits und im besten Fall Tests mit Menschen mit Behinderungen.

    Was die Redaktion nach dem Start an Texten und PDFs hochlädt, muss genauso zugänglich sein. Schulungen geben wir, die Veröffentlichungen selbst liegen aber außerhalb unseres Einflusses.

  • Die Daten bestimmen das Tempo

    Wie wir damit umgehen

    Die Datenmigration planen wir je Funktion, proben sie und gleichen sie ab. Jede Umstellung braucht die Freigabe der Fachseite.

    Grenzen und Abhängigkeiten

    Wie schnell es vorangeht, hängt oft an der Qualität der Altdaten. Sie zu bereinigen ist ebenso Aufgabe der Fachseite wie der Technik.

  • Regulierung für Softwareprodukte

    Wie wir damit umgehen

    Unsere Standard-Pipeline erzeugt SBOMs, verwaltet Schwachstellen und setzt sichere Voreinstellungen. Damit bereiten wir ein Produkt auf den Cyber Resilience Act vor.

    Grenzen und Abhängigkeiten

    Ob und wie die Verordnung Ihr Produkt erfasst, ist eine Rechtsfrage. Wir liefern die technischen Nachweise, die Beurteilung trifft Ihre Rechtsberatung.

05 Vorgehen

So arbeiten wir

Kurze Zyklen, frühes Feedback von echten Nutzerinnen und Nutzern und eine Übergabe, die ab der ersten Woche mitgeplant ist.

  1. 01

    Die Fachdomäne erfassen

    Event Storming mit jenen, die die Regeln im Kopf haben, dazu eine Übersicht der heute vorhandenen Funktionen.

    ErgebnisKontextlandkarte und erste Entscheidungsprotokolle

  2. 02

    Einen dünnen Schnitt liefern

    Eine Funktion vollständig umgesetzt, über die Fassade in Produktion gebracht und von echten Nutzerinnen und Nutzern verwendet.

    ErgebnisLauffähiger Schnitt im Produktivbetrieb

  3. 03

    Funktion um Funktion wachsen

    Mit jedem Release übersiedeln eine Funktion, ihre Daten und ihre Nutzerinnen und Nutzer, Abgleich und Rückfallplan stehen bereit.

    ErgebnisRelease-Plan nach Funktionen

  4. 04

    Übergeben

    Ihr Team entwickelt mit unserem gemeinsam, übernimmt die Rufbereitschaft und verantwortet die Roadmap, sobald die Übergabekriterien erfüllt sind.

    ErgebnisAbgenommene Übergabe

06 Menschliche Kontrolle

Wo Menschen die Kontrolle behalten

Kontrolle heißt bei Unternehmenssoftware: Man weiß, wer was geändert hat, wer es genehmigt hat und wie es sich rückgängig machen lässt.

  • Der Product Owner bestimmt den Umfang

    Prioritäten setzt Ihr Product Owner, und er nimmt jedes Inkrement ab. Wir beraten, die Entscheidung liegt bei Ihnen.

  • Für Konfiguration ist jemand zuständig

    Einstellungen je Mandant und Feature Flags ändern Rollen, die Sie festlegen, und zwar über einen protokollierten Ablauf.

  • Umstellungen werden freigegeben

    Jeden Wechsel vom alten zum neuen System bestätigt die Fachseite, mit einer geprobten Rückfallmöglichkeit.

  • Entscheidungen stehen schwarz auf weiß

    Architekturentscheidungen sind dokumentiert: was gewählt wurde, von wem und warum. So können spätere Teams sie bewusst neu bewerten.

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 Mobile-Apps
Daten
  • PostgreSQL
  • SQL Server und Oracle (in bestehenden 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

Die Liste spiegelt unsere Erfahrung in der Entwicklung wider. Eine Partnerschaft mit den Herstellern oder deren Empfehlung leitet sich daraus nicht ab.

08 Beispiel

Ein Beispiel zur Veranschaulichung

Beispiel zur Veranschaulichung

Ein Händler­portal für einen Fensterhersteller mit drei Märkten

01Ausgangslage
Ein Fensterhersteller beliefert Fachhändler in Österreich, Deutschland und Italien über drei Portale, die drei verschiedene Dienstleister gebaut haben. Jedes fällt bei der Barrierefreiheitsprüfung aus anderen Gründen durch, und jede Änderung wird dreimal umgesetzt.
02Was wir bauen würden
Ein einziges Portal auf einem gemeinsamen Designsystem. Länderspezifische Inhalte, Sprachen und Anbindungen stecken in der Konfiguration, und alle Märkte bekommen ihre Releases über denselben Release-Zug.
03Wo Menschen entscheiden
Die Länderteams genehmigen Inhalte und Konfiguration für ihren Markt; über gemeinsame Funktionen entscheidet der Product Owner.
04Was wir messen würden
Barrierefreiheitsmängel je Release, Durchlaufzeit einer Änderung über alle Länder und Anteil der Änderungen, die nur noch einmal statt pro Land umgesetzt werden.

09 Branchenblick

In Ihrer Branche

  • Öffentliche Verwaltung

    Aktenverwaltung und Portale für Ansuchen, die dem Web-Zugänglichkeits-Gesetz entsprechen, die Anmeldung mit ID Austria unterstützen und an die Register und Schnittstellen der Verwaltung angebunden sind.

  • Finanz­dienst­leistungen

    Kundenportale und Backoffice-Anwendungen mit belastbaren Prüfpfaden und Release-Abläufen, die einem geregelten Change-Management standhalten.

  • Fertigung & Industrie

    Produktkonfiguratoren, Serviceportale und SaaS-Lösungen für Maschinen- und Anlagenbauer, verbunden mit ERP und Außendienst.

Österreich

Ein neuer Markt ist ein Release, keine Abspaltung

Digitale Dienste für Verbraucherinnen und Verbraucher, die der European Accessibility Act erfasst, etwa im elektronischen Geschäftsverkehr, unterliegen in Österreich seit 28. Juni 2025 dem Barrierefreiheitsgesetz (BaFG); die Marktüberwachung liegt beim Sozialministeriumservice, Kleinstunternehmen mit Dienstleistungen sind ausgenommen. Websites und Apps des Bundes folgen dem Web-Zugänglichkeits-Gesetz (WZG), dessen Einhaltung die FFG überwacht.

In Deutschland, Slowenien oder Italien gelten für dieselbe EU-Richtlinie andere nationale Gesetze, der Cyber Resilience Act dagegen ist eine einzige Verordnung mit gestaffelten Pflichten. Dazu erwarten Kundinnen und Kunden in jedem Land ihre Sprache, ihre Rechnungsformate und ihre Anmeldeverfahren, in Österreich etwa ID Austria.

Solche Unterschiede bringen wir in Konfiguration und klar umrissenen Modulen unter. Ein neuer Markt wird so zu einem Release statt zu einem eigenen Entwicklungszweig, und die Pipeline erzeugt Nachweise zu Barrierefreiheit und Sicherheit gleich mit, passend zu den Fragen in Ausschreibungen.

Fragen zu Unternehmenssoftware und SaaS

Individuell entwickeln oder eine Plattform anpassen?

Ist Ihr Prozess nahe am Standard, passt eine konfigurierte Plattform. Eigenentwicklung lohnt sich dort, wo Sie sich gerade durch den Prozess vom Mitbewerb abheben oder keine Plattform die Regeln abbildet. Da wir mit Salesforce, SAP und Odoo ebenso arbeiten wie mit eigenem Code, haben wir keinen Grund, eine bestimmte Antwort zu bevorzugen. Unser Bereich Architektur & Beratung macht diese Entscheidung nachvollziehbar.

Garantieren Sie, dass unser Portal barrierefrei ist?

Gebaut wird nach EN 301 549 und WCAG 2.2 AA, geprüft automatisch und von Hand, und am Ende erhalten Sie einen Konformitätsbericht, der bekannte Mängel offen ausweist. Fehlerfreiheit versprechen wir nicht. Wir versprechen, Mängel zu finden, zu melden und in unserem Verantwortungsbereich zu beheben.

Geht Modernisierung auch ohne Stichtagsumstellung?

Ja, und wir raten sogar dazu. Eine Routing-Fassade erlaubt es, Funktionen einzeln zu übersiedeln, die Altanwendung bleibt in Betrieb, und nach jedem Schritt werden die Daten abgeglichen.

Kann unser eigenes Team die Software übernehmen?

Davon gehen wir von vornherein aus. Die Übergabekriterien stehen zu Projektbeginn fest, Ihre Entwicklerinnen und Entwickler arbeiten während des Baus mit unseren zusammen, und Entscheidungsprotokolle sowie Runbooks liegen in Ihren Repositories.

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

Bringen Sie Software mit digitalen Elementen in der EU in Verkehr, können Pflichten zu sicherem Design, zum Umgang mit Schwachstellen und zur Dokumentation auf Sie zukommen. Wir schaffen die technischen Nachweise dafür: SBOMs, einen Schwachstellenprozess und sichere Voreinstellungen.

Was muss weiterlaufen, während es sich ändert?

Sagen Sie es uns. Wir schlagen vor, welche Funktion zuerst übersiedelt und was Ihr Team am Ende selbst verantwortet.

Erstgespräch anfragenAltsysteme ablösen