Přejít na hlavní obsah
FromNine
Nabídka

Vývoj

Podnikový software, který vaše týmy dokážou dál měnit.

Vyvíjíme SaaS produkty, portály pro občany a zaměstnance a klíčové podnikové aplikace, které jsou přístupné, ve výchozím stavu bezpečné a které vaše vlastní týmy udrží i dlouho po spuštění.

Pro softwarové firmy, výrobce a veřejné instituce v Česku, jejichž uživatelé pracují v různých jazycích a podle různých pravidel.

Domluvit konzultaciModernizace systémů
Podnikový software a SaaS: vrstvy schopnostíČtyři vrstvy nad sebou. Shora dolů: přístupné rozhraní, se kterým lidé pracují, doménové moduly s pravidly, platformní služby pro tenanty a identitu a pod tím bezpečná pipeline pro dodávky.01Přístupná rozhraní02Doménové moduly a pravidla03Tenanti, identita, data04Bezpečná pipeline dodávek
  1. 01Doménově řízený návrh pro agendy plné pravidel, například vyřizování žádostí
  2. 02Přístupnost podle EN 301 549 a WCAG 2.2 AA od prvního návrhu
  3. 03Dokumentace a záznamy rozhodnutí, které vaše týmy převezmou

01 Problémy

Co slyšíme před přestavbou

  1. 01

    Každá změna trvá čtvrt roku

    Aplikace funguje, ale do jádra si nikdo netroufne sáhnout. Malé změny vyžadují rozsáhlé regresní testy a okno pro vydání.

  2. 02

    Portál selhává u lidí, kterým má sloužit

    Nefunguje se čtečkou obrazovky, v angličtině pro cizince ani na telefonu. Stížnosti přijdou dřív než audit přístupnosti.

  3. 03

    Změna pro jednoho zákazníka rozbije jiného

    SaaS produkt rostl úpravami pro jednotlivé klienty. Každé vydání je teď vyjednávání a někteří tenanti uvízli na starých verzích.

  4. 04

    Znalosti odešly s dodavatelem

    Rozhodnutí se nikdy nezapisovala. Tým, který systém postavil, je pryč a jedinou dokumentací je kód.

  5. 05

    Bezpečnostní otázky přicházejí od zákazníků i regulátorů

    Zákazníci se v rámci bezpečnosti dodavatelského řetězce ptají na SBOM, proces řešení zranitelností a podklady pro akt o kybernetické odolnosti. Nikdo je nemá připravené.

02 Co dodáváme

Co dodáváme

  1. 01 Vývoj SaaS produktů

    Produkty navržené tak, aby z jednoho kódu obsloužily mnoho zákazníků: správný model tenantů, konfigurace místo úprav na míru a vydání, která se dostanou ke každému tenantovi.

    Co děláme

    • Volba modelu tenantů: sdílený, seskupený, nebo izolovaný pro každého tenanta
    • Strategie konfigurace a přepínačů funkcí
    • Napojení měření spotřeby a fakturace
    • Pravidelný rytmus vydání (release train) s postupným zaváděním podle tenantů

    Co dostanete

    • Návrh tenantů a jejich izolace
    • Konfigurační model s mantinely
    • Proces vydání s možností návratu pro každého tenanta

  2. 02 Doménový návrh pro složitá pravidla

    Doménově řízený návrh tam, kde jsou pravidla samotným produktem: vyřizování žádostí, nárokovost, výpočty svázané s předpisy. Mezi modulárním monolitem a mikroslužbami volíme vědomě a nejčastěji začínáme monolitem.

    Co děláme

    • Event storming s doménovými odborníky
    • Ohraničené kontexty a hranice modulů
    • Pravidla zapsaná výslovně a testovatelně
    • Záznamy architektonických rozhodnutí pro velké volby

    Co dostanete

    • Doménový model a mapa kontextů
    • Modulární kód s vynucenými hranicemi
    • Spustitelné specifikace klíčových pravidel

  3. 03 Portály pro občany a zaměstnance

    Rozhraní postavená na design systému, ve výchozím stavu přístupná a vícejazyčná od prvního vydání. V Česku to znamená češtinu a obvykle i angličtinu, u exportních firem často němčinu, a přihlášení přes Identitu občana tam, kde portál slouží občanům.

    Co děláme

    • Design systém s přístupnými komponentami
    • Obsah psaný srozumitelným jazykem
    • Testování s asistivními technologiemi a skutečnými uživateli
    • Postup lokalizace pro každý jazyk

    Co dostanete

    • Portál na znovupoužitelném design systému
    • Zpráva o shodě s požadavky na přístupnost
    • Postup tvorby obsahu a překladů

  4. 04 Kvalita a bezpečný vývoj

    Automatizované testy na správných úrovních, kontraktové testy mezi službami, výkonnostní testy před spuštěním a bezpečný životní cyklus vývoje postavený na OWASP ASVS, SBOM a kontrolách dodavatelského řetězce.

    Co děláme

    • Strategie testování a automatizace
    • Kontraktové a výkonnostní testy
    • Modelování hrozeb a ověření podle ASVS
    • Generování SBOM a pravidla pro závislosti

    Co dostanete

    • Automatizované testovací sady v pipeline
    • Zpráva o ověření bezpečnosti
    • Proces řešení zranitelností připravený na akt o kybernetické odolnosti

  5. 05 Postupná modernizace

    Nahrazujeme starší aplikaci schopnost po schopnosti za směrovací fasádou, zatímco provoz pokračuje. Viz také modernizace starších systémů.

    Co děláme

    • Mapa schopností stávající aplikace
    • Směrování podle vzoru strangler fig a obalení přes API
    • Migrace dat se zprávami o odsouhlasení
    • Souběžný provoz u kritických výpočtů

    Co dostanete

    • Pořadí modernizace s obchodními milníky
    • Fasáda a nové moduly v provozu
    • Odsouhlasená data při každém přepnutí

  6. 06 Udržovatelnost a předání

    Software, který vaše týmy dokážou vlastnit: čitelný kód, záznamy rozhodnutí, provozní příručky a plán předání dohodnutý na začátku, ne objevený na konci.

    Co děláme

    • Párová práce s vašimi vývojáři během vývoje
    • Záznamy architektonických rozhodnutí uložené u kódu
    • Provozní příručky a návody pro pohotovost
    • Milníky předávání znalostí

    Co dostanete

    • Plán předání s akceptačními kritérii
    • Dokumentace ve vašich repozitářích
    • Vyškolený interní tým

03 Architektura

Ilustrativní referenční architektura

Typický tvar podnikové aplikace, která nahrazuje starší systém: přístupný front-end, směrovací fasáda, která posílá každou schopnost do starého, nebo nového systému, vrstva API s jasnými kontrakty a modulární jádro uspořádané podle domény.

Tenanti a konfigurace jsou výslovné platformní služby, ne podmínky roztroušené po kódu. Pod tím každé sestavení spouští testy a bezpečnostní kontroly a vytváří SBOM.

Vrstvy v diagramu

Lidé
Občané, zákazníci a zaměstnanci, na jakémkoli zařízení a s asistivními technologiemi.
Modernizace
Směrovací fasáda, stávající aplikace a migrace dat s odsouhlasením.
Platforma
Vrstva API, identita, modulární jádro, tenanti a konfigurace, provozní data.
Bezpečné dodávky
Kontraktové a výkonnostní testy, kontroly ASVS a SBOM v každém sestavení.
Ilustrativní příklad

  1. Lidé

    • Občané, zákazníci, zaměstnanci
    • Přístupný front-end

  2. Postupná modernizace

    • Směrovací fasáda
    • Stávající aplikace
    • Migrace s odsouhlasením

  3. Platforma

    • Vrstva API a kontrakty
    • Identita a role
    • Modulární jádro: příjem, případy, fakturace
    • Tenanti, konfigurace, přepínače funkcí
    • Provozní datová úložiště

  4. Bezpečné dodávky

    • Kontraktové a výkonnostní testy, kontroly ASVS, SBOM v každém sestavení
Modulární jádro za směrovací fasádou

Ilustrativní architektura, nikoli systém klienta.

Zobrazit diagram jako text

Hlavní trasa vede od lidí k přístupnému front-endu, přes směrovací fasádu a vrstvu API k modulárnímu jádru uspořádanému do ohraničených kontextů.

Fasáda směruje některé schopnosti také do stávající aplikace, která se postupně vyřazuje. Její data se přes migraci s odsouhlasením přesouvají do provozních datových úložišť.

Vrstvu API obsluhuje identita. Pod jádrem jsou služby pro tenanty a konfiguraci. Pás bezpečných dodávek vespod zahrnuje kontraktové testy, výkonnostní testy, ověření bezpečnosti a SBOM.

04 Úvahy a limity

Technické úvahy a limity

  • Nejdřív modulární monolit

    Jak to řešíme

    Začínáme jasnými moduly v jedné nasaditelné jednotce a samostatné služby oddělujeme jen tam, kde to vyžaduje škálování, tempo vydávání nebo vlastnictví týmů.

    Limity a závislosti

    Mikroslužby řeší organizační problémy stejně jako technické. Bez týmů, které je vlastní, přidávají náklady a nové způsoby selhání.

  • Přístupnost je inženýrská práce

    Jak to řešíme

    Přístupné komponenty, automatické kontroly v pipeline a ruční testování s asistivními technologiemi před každým větším vydáním.

    Limity a závislosti

    Automatické nástroje najdou jen část problémů. Plná shoda vyžaduje ruční audity a ideálně testování s uživateli se zdravotním postižením.

    Obsah a dokumenty, které redaktoři přidají po spuštění, musí splňovat stejný standard. Redaktory zaškolíme, ale to, co zveřejní, neovlivníme.

  • Modernizace trvá tak dlouho jako data

    Jak to řešíme

    Migraci dat plánujeme pro každou schopnost zvlášť, zkoušíme ji nanečisto a odsouhlasujeme, se schválením byznysu při každém přepnutí.

    Limity a závislosti

    Tempo často určuje kvalita starých dat. Jejich vyčištění je úkol pro byznys stejně jako pro techniku.

  • Regulace softwarových produktů

    Jak to řešíme

    SBOM, řešení zranitelností a bezpečné výchozí nastavení jsou součástí naší standardní pipeline, která produkty připravuje na akt o kybernetické odolnosti.

    Limity a závislosti

    Zda a jak se akt na váš produkt vztahuje, je právní otázka. My dodáme technické podklady; posouzení provedou vaši právníci.

05 Jak pracujeme

Jak pracujeme

Krátké cykly, skuteční uživatelé brzy a předání naplánované od prvního týdne.

  1. 01

    Zmapovat doménu

    Event storming s lidmi, kteří znají pravidla, a mapa schopností toho, co dnes existuje.

    VýstupMapa kontextů a první záznamy rozhodnutí

  2. 02

    Dodat tenký řez

    Jedna schopnost od začátku do konce, přes fasádu až do provozu se skutečnými uživateli.

    VýstupFunkční řez v provozu

  3. 03

    Růst po schopnostech

    Každé vydání přesune jednu schopnost, její data a uživatele, s připraveným odsouhlasením a návratem.

    VýstupPlán vydání podle schopností

  4. 04

    Předat

    Vaši vývojáři pracují v párech s našimi, převezmou pohotovost a po splnění kritérií předání vlastní i roadmapu.

    VýstupAkceptované předání

06 Kontrola člověkem

Kde rozhoduje člověk

V podnikovém softwaru znamená kontrola vědět, kdo co změnil, kdo to schválil a jak to vrátit.

  • O rozsahu rozhodují produktoví vlastníci

    Váš produktový vlastník určuje priority a přebírá každý přírůstek. My radíme, on rozhoduje.

  • Konfigurace má vlastníka

    Nastavení tenantů a přepínače funkcí se mění auditovaným postupem, a to rolemi, které určíte vy.

  • Přepnutí se schvalují

    Každý přechod ze starého systému na nový schvaluje byznys a návrat zpět je nacvičený.

  • Rozhodnutí jsou zapsaná

    Záznamy architektonických rozhodnutí ukazují, co se zvolilo, kdo to zvolil a proč, takže budoucí týmy se k nim mohou vědomě vrátit.

07 Technologie

Technologie, se kterými pracujeme

Back-end
  • Java a Kotlin
  • .NET
  • TypeScript a Node.js
  • Python
Front-end
  • React a Next.js
  • Angular
  • Design systémy s přístupnými komponentami
  • Nativní a multiplatformní mobilní aplikace
Data
  • PostgreSQL
  • SQL Server a Oracle (stávající prostředí)
  • Streamování událostí
  • Vyhledávací enginy
Kvalita a bezpečnost
  • Playwright a kontraktové testy
  • Zátěžové a výkonnostní testy
  • SAST, DAST a skenování závislostí
  • SBOM ve formátu CycloneDX nebo SPDX

Uvedení technologie popisuje naše inženýrské zkušenosti. Neznamená partnerství s jejím dodavatelem ani jeho doporučení.

08 Příklad

Ilustrativní příklad

Ilustrativní příklad

Portál pro žádosti svazku obcí s přihlášením přes Identitu občana

01Situace
Svazek obcí přijímá žádosti občanů a firem pro své členské obce na papíře, e-mailem a přes několik formulářů od různých dodavatelů. Každý formulář jinak neprojde kontrolou přístupnosti a každou změnu je nutné udělat několikrát.
02Co bychom postavili
Jeden portál na sdíleném design systému s přihlášením přes Identitu občana, kde obsah, formuláře a napojení jednotlivých obcí jsou uložené v konfiguraci a vydávají se společně.
03Kde rozhoduje člověk
Každá obec schvaluje obsah a nastavení svých formulářů; o společných funkcích rozhoduje produktový vlastník svazku.
04Co bychom měřili
Počet nedostatků přístupnosti na vydání, doba zavedení změny ve všech obcích a podíl žádostí podaných elektronicky.

09 Podle odvětví

Ve vašem odvětví

  • Veřejná správa

    Systémy pro vyřizování žádostí a portály pro občany, které splňují zákon č. 99/2019 Sb., o přístupnosti internetových stránek a mobilních aplikací, a přihlašují přes Identitu občana.

  • Finanční služby

    Klientské portály a aplikace back-office se silnou auditní stopou a procesy vydávání, které obstojí při řízení změn.

  • Průmysl a výroba

    Konfigurátory, servisní portály a SaaS produkty pro výrobce strojů a zařízení, napojené na ERP a servis v terénu.

Česko

Nový trh je vydání, ne nová větev kódu

V Česku je od 28. června 2025 účinný zákon č. 424/2023 Sb., o požadavcích na přístupnost některých výrobků a služeb, s dozorem České obchodní inspekce; weby a aplikace veřejných institucí upravuje zákon č. 99/2019 Sb. Produkt prodávaný do dalších zemí EU narazí na jejich vlastní provedení evropského aktu o přístupnosti a na akt o kybernetické odolnosti, jehož povinnosti nastupují postupně. Zákazníci navíc čekají svůj jazyk, svá pravidla fakturace a svá schémata elektronické identity.

Tyto rozdíly držíme v konfiguraci a jasně ohraničených modulech, takže nový trh je vydání, ne nová větev kódu. Podklady o přístupnosti a bezpečnostní dokumentaci vytváří pipeline, připravené na otázky, které klade zadávací dokumentace na každém trhu.

Časté dotazy k podnikovému softwaru a SaaS

Máme vyvíjet na míru, nebo nastavit platformu?

Platformu nastavte tam, kde se váš proces blíží standardu, a vyvíjejte tam, kde vás proces odlišuje nebo kde pravidlům žádná platforma neodpovídá. Pracujeme se Salesforce, SAP a Odoo i s vlastním kódem, takže nemáme důvod tlačit jednu odpověď. Tuto volbu výslovně řeší naše služba Architektura a poradenství.

Zaručíte, že náš portál bude přístupný?

Stavíme podle EN 301 549 a WCAG 2.2 AA, testujeme automaticky i ručně a dodáváme zprávu o shodě včetně známých nedostatků. Neslibujeme nulový počet problémů; slibujeme, že je najdeme, popíšeme a opravíme to, co je v našem rozsahu.

Dokážete modernizovat bez jednorázové velké migrace?

Ano a doporučujeme to. Směrovací fasáda nám umožní přesouvat jednu schopnost po druhé, zatímco stávající aplikace dál běží a data se v každém kroku odsouhlasí.

Může software převzít náš vlastní tým?

To je výchozí plán. Kritéria předání dohodneme na začátku, vaši vývojáři pracují během vývoje v párech s našimi a záznamy rozhodnutí i provozní příručky jsou uložené ve vašich repozitářích.

Co pro náš produkt znamená akt o kybernetické odolnosti?

Pokud uvádíte na trh EU software s digitálními prvky, může vám přinést povinnosti týkající se bezpečného návrhu, řešení zranitelností a dokumentace. My připravíme technické podklady: SBOM, proces řešení zranitelností a bezpečné výchozí nastavení.

Řekněte nám, co musí běžet, zatímco se to mění

Navrhneme první schopnost, kterou přesunout, a co bude váš tým na konci vlastnit.

Domluvit konzultaciModernizace systémů