Przejdź do treści głównej
FromNine
Menu

Inżynieria

Oprogramowanie, które Państwa zespoły mogą dalej rozwijać.

Tworzymy produkty SaaS, portale dla obywateli i pracowników oraz kluczowe aplikacje biznesowe, które są dostępne, domyślnie bezpieczne i które Państwa zespoły mogą utrzymywać długo po uruchomieniu.

Dla firm produktowych i instytucji publicznych, które obsługują użytkowników w Polsce i w innych krajach, w wielu językach i przy różnych przepisach.

Oprogramowanie biznesowe i SaaS: warstwy kompetencjiCztery warstwy ułożone jedna za drugą. Od góry do dołu: dostępny interfejs, z którego korzystają ludzie, moduły domenowe z regułami, usługi platformy dla wielodostępności i tożsamości oraz bezpieczny potok wdrożeniowy pod spodem.01Dostępne interfejsy02Moduły domenowe i reguły03Wielodostępność, tożsamość, dane04Bezpieczny potok wdrożeniowy
  1. 01Projektowanie domenowe (DDD) dla pracy opartej na wielu regułach, takiej jak obsługa spraw
  2. 02Dostępność zgodna z EN 301 549 i WCAG 2.2 AA od pierwszego projektu
  3. 03Dokumentacja i zapisy decyzji, które zespoły organizacji mogą przejąć

01 Problemy

Co słyszymy przed przebudową

  1. 01

    Każda zmiana trwa kwartał

    Aplikacja działa, ale nikt nie odważy się ruszyć jej rdzenia. Drobne zmiany wymagają dużych testów regresji i okna wydania.

  2. 02

    Portal zawodzi ludzi, którym ma służyć

    Nie działa z czytnikiem ekranu, na telefonie ani w języku, którym posługuje się część użytkowników. Skargi przychodzą wcześniej niż audyt dostępności.

  3. 03

    Zmiana dla jednego klienta psuje system innemu

    Produkt SaaS rósł przez dostosowania dla poszczególnych klientów. Teraz każde wydanie to negocjacje, a część klientów utknęła na starych wersjach.

  4. 04

    Wiedza odeszła razem z dostawcą

    Decyzji nigdy nie zapisano. Zespół, który zbudował system, pracuje już gdzie indziej, a kod jest jedyną dokumentacją.

  5. 05

    Pytania o bezpieczeństwo zadają klienci i regulatorzy

    Dział zakupów prosi o SBOM, proces obsługi podatności i dowody na potrzeby aktu o cyberodporności. Nikt nie ma ich pod ręką.

02 Co dostarczamy

Co dostarczamy

  1. 01 Inżynieria produktów SaaS

    Produkty projektowane tak, aby obsługiwały wielu klientów z jednej bazy kodu: właściwy model wielodostępności, konfiguracja zamiast dostosowań i wydania, które trafiają do każdego klienta.

    Co robimy

    • Wybór modelu wielodostępności: współdzielony, pulowany lub izolowany dla każdego klienta
    • Strategia konfiguracji i flag funkcji
    • Integracja pomiaru użycia i rozliczeń
    • Cykle wydań z wdrażaniem uwzględniającym poszczególnych klientów

    Co Państwo otrzymują

    • Projekt wielodostępności i izolacji
    • Model konfiguracji z regułami ochronnymi
    • Proces wydań z wycofaniem zmian dla każdego klienta
  2. 02 Projekt domenowy dla złożonych reguł

    Projektowanie domenowe tam, gdzie produktem są reguły: obsługa spraw, ocena uprawnień do świadczeń, obliczenia wynikające z przepisów. Świadomie wybieramy między modularnym monolitem a mikrousługami i najczęściej zaczynamy od monolitu.

    Co robimy

    • Event storming z ekspertami dziedzinowymi
    • Konteksty ograniczone i granice modułów
    • Reguły zapisane jawnie i testowalnie
    • Zapisy decyzji architektonicznych dla dużych wyborów

    Co Państwo otrzymują

    • Model domeny i mapa kontekstów
    • Modularna baza kodu z egzekwowanymi granicami
    • Wykonywalne specyfikacje kluczowych reguł
  3. 03 Portale dla obywateli i pracowników

    Interfejsy zbudowane na systemie projektowym, domyślnie dostępne i od pierwszego wydania gotowe na wiele języków: polski dla usług w Polsce oraz te języki, którymi rzeczywiście posługują się użytkownicy.

    Co robimy

    • System projektowy z dostępnymi komponentami
    • Treści pisane prostym językiem
    • Testy z technologiami wspomagającymi z udziałem użytkowników
    • Proces lokalizacji dla każdego języka

    Co Państwo otrzymują

    • Portal na systemie projektowym wielokrotnego użytku
    • Raport zgodności z wymaganiami dostępności
    • Proces tworzenia treści i tłumaczeń
  4. 04 Inżynieria jakości i bezpieczne wytwarzanie

    Automatyzacja testów na właściwych poziomach, testy kontraktowe między usługami, testy wydajności przed uruchomieniem oraz bezpieczny cykl wytwarzania oparty na OWASP ASVS, SBOM i kontroli łańcucha dostaw.

    Co robimy

    • Strategia i automatyzacja testów
    • Testy kontraktowe i wydajnościowe
    • Modelowanie zagrożeń i weryfikacja ASVS
    • Generowanie SBOM i polityka zależności

    Co Państwo otrzymują

    • Zautomatyzowane zestawy testów w potoku
    • Raport z weryfikacji bezpieczeństwa
    • Proces obsługi podatności gotowy na akt o cyberodporności
  5. 05 Stopniowa modernizacja

    Zastępowanie starszej aplikacji funkcja po funkcji, za fasadą routującą, przy działającym biznesie. Więcej w opisie rozwiązania Modernizacja systemów.

    Co robimy

    • Mapa funkcji istniejącej aplikacji
    • Routing według wzorca strangler fig i opakowanie w API
    • Migracja danych z raportami uzgodnień
    • Równoległe przebiegi dla krytycznych obliczeń

    Co Państwo otrzymują

    • Kolejność modernizacji z kamieniami milowymi biznesu
    • Fasada i nowe moduły w produkcji
    • Uzgodnione dane przy każdym przełączeniu
  6. 06 Łatwość utrzymania i przekazanie

    Oprogramowanie, które zespoły organizacji mogą przejąć: czytelny kod, zapisy decyzji, instrukcje operacyjne i plan przekazania uzgodniony na początku, a nie odkrywany na końcu.

    Co robimy

    • Praca w parach z programistami organizacji w trakcie budowy
    • Zapisy decyzji architektonicznych przechowywane razem z kodem
    • Instrukcje operacyjne i przewodniki dyżurowe
    • Kamienie milowe transferu wiedzy

    Co Państwo otrzymują

    • Plan przekazania z kryteriami akceptacji
    • Komplet dokumentacji w repozytoriach organizacji
    • Przeszkolony zespół wewnętrzny

03 Architektura

Poglądowa architektura referencyjna

Typowy kształt aplikacji biznesowej, która zastępuje starszą: dostępny interfejs, fasada routująca, która kieruje każdą funkcję do starego lub nowego systemu, warstwa API z jasnymi kontraktami i modularny rdzeń zorganizowany wokół domeny.

Wielodostępność i konfiguracja to jawne usługi platformy, a nie warunki rozproszone po kodzie. Pod spodem każda kompilacja uruchamia testy i kontrole bezpieczeństwa oraz tworzy SBOM.

Warstwy na rysunku

Ludzie
Obywatele, klienci i pracownicy, na dowolnym urządzeniu i z technologiami wspomagającymi.
Moderni­zacja
Fasada routująca, istniejąca aplikacja i migracja danych z uzgodnieniem.
Platforma
Warstwa API, tożsamość, modularny rdzeń, wielodostępność i konfiguracja, dane operacyjne.
Bezpieczne dostarczanie
Testy kontraktowe i wydajności, kontrole ASVS i SBOM w każdej kompilacji.
Przykład poglądowy
  1. Ludzie

    • Obywatele, klienci, pracownicy
    • Dostępny interfejs
  2. Stopniowa moderni­zacja

    • Fasada routująca
    • Istniejąca aplikacja
    • Migracja z uzgodnieniem
  3. Platforma

    • Warstwa API i kontrakty
    • Tożsamość i role
    • Modularny rdzeń: wnioski, sprawy, rozliczenia
    • Wielodostępność, konfiguracja, flagi funkcji
    • Operacyjne bazy danych
  4. Bezpieczne dostarczanie

    • Testy kontraktowe i wydajności, kontrole ASVS, SBOM w każdej kompilacji
Modularny rdzeń za fasadą routującą

Architektura poglądowa, nie system klienta.

Diagram w formie tekstu

Główna ścieżka prowadzi od ludzi do dostępnego interfejsu, przez fasadę routującą i warstwę API, do modularnego rdzenia podzielonego na konteksty ograniczone.

Fasada kieruje też część funkcji do istniejącej aplikacji, która jest wyłączana krok po kroku. Jej dane przechodzą przez migrację z uzgodnieniem do operacyjnych baz danych.

Tożsamość obsługuje warstwę API. Usługi wielodostępności i konfiguracji znajdują się pod rdzeniem. Pas bezpiecznego dostarczania pod spodem obejmuje testy kontraktowe, testy wydajności, weryfikację bezpieczeństwa i SBOM.

04 Uwarunkowania i ograniczenia

Uwarunkowania inżynierskie i ograniczenia

  • Najpierw modularny monolit

    Jak do tego podchodzimy

    Zaczynamy od wyraźnych modułów w jednej jednostce wdrożeniowej i wydzielamy usługi tylko tam, gdzie wymagają tego skalowanie, rytm wydań lub odpowiedzialność zespołów.

    Ograniczenia i zależności

    Mikrousługi rozwiązują problemy organizacyjne w tym samym stopniu co techniczne. Bez zespołów, które za nie odpowiadają, dokładają kosztów i nowych rodzajów awarii.

  • Dostępność to praca inżynierska

    Jak do tego podchodzimy

    Dostępne komponenty, automatyczne kontrole w potoku i ręczne testy z technologiami wspomagającymi przed każdym większym wydaniem.

    Ograniczenia i zależności

    Narzędzia automatyczne wykrywają tylko część problemów. Pełna zgodność wymaga ręcznych audytów i najlepiej testów z udziałem osób z niepełnosprawnościami.

    Treści i dokumenty dodawane przez redaktorów po uruchomieniu muszą spełniać ten sam standard. Szkolimy redaktorów, ale nie kontrolujemy tego, co publikują.

  • Modernizacja trwa tyle, ile dane

    Jak do tego podchodzimy

    Migrację danych planujemy dla każdej funkcji, przećwiczamy i uzgadniamy, a każde przełączenie zatwierdza biznes.

    Ograniczenia i zależności

    Tempo często wyznacza jakość danych w starszych systemach. Ich porządkowanie jest zadaniem biznesowym w tym samym stopniu co technicznym.

  • Przepisy dla produktów programowych

    Jak do tego podchodzimy

    SBOM, obsługa podatności i bezpieczne ustawienia domyślne są częścią naszego standardowego potoku, który przygotowuje produkty na akt o cyberodporności.

    Ograniczenia i zależności

    Czy i jak akt ma zastosowanie do danego produktu, to pytanie prawne. Dostarczamy dowody inżynierskie, a ocenę przeprowadzają Państwa doradcy prawni.

05 Jak pracujemy

Jak pracujemy

Krótkie cykle, prawdziwi użytkownicy od początku i przekazanie planowane od pierwszego tygodnia.

  1. 01

    Mapa domeny

    Event storming z osobami, które znają reguły, i mapa funkcji tego, co istnieje dziś.

    RezultatMapa kontekstów i pierwsze zapisy decyzji

  2. 02

    Pierwszy wąski wycinek

    Jedna funkcja od początku do końca, przez fasadę, w produkcji z prawdziwymi użytkownikami.

    RezultatDziałający wycinek w produkcji

  3. 03

    Rozwój funkcja po funkcji

    Każde wydanie przenosi funkcję, jej dane i użytkowników, z gotowym uzgodnieniem danych i wycofaniem zmian.

    RezultatPlan wydań według funkcji

  4. 04

    Przekazanie

    Państwa programiści pracują w parach z naszymi, przejmują dyżury i mapę drogową, gdy spełnione są kryteria przekazania.

    RezultatZaakceptowane przekazanie

06 Kontrola człowieka

Gdzie kontrolę zachowuje człowiek

W oprogramowaniu biznesowym kontrola oznacza wiedzę o tym, kto co zmienił, kto to zatwierdził i jak to cofnąć.

  • Właściciel produktu decyduje o zakresie

    Właściciel produktu po stronie organizacji ustala priorytety i akceptuje każdy przyrost. My doradzamy, on decyduje.

  • Konfiguracja ma właściciela

    Ustawienia klientów i flagi funkcji zmieniają wskazane role w procesie objętym audytem.

  • Przełączenia są zatwierdzane

    Każde przejście ze starego systemu na nowy zatwierdza biznes, a wycofanie zmian jest przećwiczone.

  • Decyzje są zapisane

    Zapisy decyzji architektonicznych pokazują, co wybrano, kto wybrał i dlaczego, więc przyszłe zespoły mogą je świadomie zmienić.

07 Technologie

Technologie, z którymi pracujemy

Backend
  • Java i Kotlin
  • .NET
  • TypeScript i Node.js
  • Python
Frontend
  • React i Next.js
  • Angular
  • Systemy projektowe z dostępnymi komponentami
  • Aplikacje mobilne natywne i wieloplatformowe
Dane
  • PostgreSQL
  • SQL Server i Oracle (istniejące środowiska)
  • Strumieniowanie zdarzeń
  • Silniki wyszukiwania
Jakość i bezpieczeństwo
  • Playwright i testy kontraktowe
  • Testy obciążeniowe i wydajnościowe
  • SAST, DAST i skanowanie zależności
  • SBOM w formacie CycloneDX lub SPDX

Wymienienie technologii opisuje nasze doświadczenie inżynierskie. Nie oznacza partnerstwa z jej dostawcą ani jego rekomendacji.

08 Przykład

Przykład poglądowy

Przykład poglądowy

Wspólny portal wniosków dla związku gmin

01Sytuacja
Kilka gmin w związku międzygminnym przyjmuje te same rodzaje wniosków przez różne formularze i systemy dziedzinowe. Część formularzy nie przechodzi kontroli dostępności, a każda zmiana jest wprowadzana kilka razy.
02Co byśmy zbudowali
Jeden portal wniosków na wspólnym systemie projektowym, z logowaniem przez login.gov.pl, treściami i integracjami poszczególnych gmin zapisanymi w konfiguracji i jednym cyklem wydań.
03Gdzie decyduje człowiek
Każda gmina zatwierdza treści i konfigurację swoich usług, a właściciel produktu w związku decyduje o funkcjach wspólnych. Decyzje w sprawach wydają pracownicy gmin.
04Co byśmy mierzyli
Liczba problemów z dostępnością w każdym wydaniu, czas wprowadzenia zmiany we wszystkich gminach i odsetek zmian wprowadzanych raz zamiast osobno dla każdej gminy.

09 Perspektywa branżowa

W Państwa branży

  • Systemy obsługi spraw i portale dla mieszkańców, które spełniają wymagania dostępności cyfrowej i pozwalają zalogować się przez login.gov.pl, na przykład aplikacją mObywatel lub profilem zaufanym.

  • Portale klienta i aplikacje zaplecza z pełnym śladem audytowym i procesem wydań, który spełnia wymagania zarządzania zmianą.

  • Konfiguratory, portale serwisowe i produkty SaaS dla producentów maszyn i urządzeń, połączone z systemem ERP i serwisem terenowym.

Polska

Nowy rynek to wydanie, nie osobna wersja

Europejski akt o dostępności wdrożono w Polsce ustawą z dnia 26 kwietnia 2024 r. (Dz.U. 2024 poz. 731), zwaną Polskim Aktem o Dostępności i stosowaną od 28 czerwca 2025 r. Głównym organem nadzoru rynku jest Prezes Zarządu PFRON, a mikroprzedsiębiorcy świadczący usługi są zwolnieni z wymagań. Podmioty publiczne stosują ponadto ustawę z dnia 4 kwietnia 2019 r. o dostępności cyfrowej stron internetowych i aplikacji mobilnych podmiotów publicznych i co roku do 31 marca aktualizują deklarację dostępności.

Akt o cyberodporności to jedno rozporządzenie z obowiązkami stosowanymi etapami. Klienci oczekują też krajowych rozwiązań: w Polsce faktur w KSeF i logowania przez login.gov.pl. Te różnice trzymamy w konfiguracji i w wyraźnie wydzielonych modułach, a potok tworzy dowody dostępności i dokumentację bezpieczeństwa, gotowe na pytania zamawiających.

Pytania o oprogramowanie biznesowe i SaaS

Budować na zamówienie czy konfigurować platformę?

Platformę warto konfigurować tam, gdzie proces jest bliski standardowi, a budować tam, gdzie to proces wyróżnia organizację albo żadna platforma nie pasuje do reguł. Pracujemy z platformami Salesforce, SAP i Odoo oraz z kodem tworzonym na zamówienie, więc nie mamy powodu forsować jednej odpowiedzi. Usługa Architektura i doradztwo pozwala podjąć ten wybór świadomie.

Czy FromNine gwarantuje dostępność portalu?

Budujemy zgodnie z EN 301 549 i WCAG 2.2 AA, testujemy automatycznie i ręcznie oraz dostarczamy raport zgodności ze wszystkimi znanymi problemami. Nie obiecujemy braku problemów. Obiecujemy, że je znajdziemy, zgłosimy i naprawimy to, co należy do naszego zakresu.

Czy modernizacja jest możliwa bez jednorazowej migracji?

Tak i właśnie to zalecamy. Fasada routująca pozwala przenosić jedną funkcję naraz, podczas gdy istniejąca aplikacja dalej działa, a dane są uzgadniane na każdym etapie.

Czy nasz zespół może przejąć oprogramowanie?

To domyślny plan. Kryteria przekazania uzgadniamy na początku, Państwa programiści pracują w parach z naszymi w trakcie budowy, a zapisy decyzji i instrukcje operacyjne trafiają do Państwa repozytoriów.

Co akt o cyberodporności oznacza dla naszego produktu?

Jeśli organizacja wprowadza na rynek UE oprogramowanie lub produkty z elementami cyfrowymi, akt może nakładać obowiązki dotyczące bezpiecznego projektowania, obsługi podatności i dokumentacji. Dostarczamy dowody inżynierskie: SBOM, proces obsługi podatności i bezpieczne ustawienia domyślne.

Co musi działać, gdy system się zmienia

Zaproponujemy pierwszą funkcję do przeniesienia i wskażemy, za co zespół organizacji będzie odpowiadał na końcu.