Към основното съдържание
FromNine
Меню

Разработка

Корпоративен софтуер, който собствените Ви екипи могат да развиват.

Разработваме SaaS продукти, портали за граждани и служители и основни бизнес приложения, които са достъпни, сигурни по подразбиране и поддържани от Вашите екипи дълго след пускането.

За софтуерни компании и публични институции, които обслужват потребители в няколко държави, на няколко езика и при различни правни режими.

Обсъдете проекта сиМодернизация на системи
Корпоративен софтуер и SaaS: слоеве на услугатаЧетири слоя, наредени един зад друг. Отгоре надолу: достъпният интерфейс, който хората използват, модулите на предметната област, които съдържат правилата, платформените услуги за наематели и идентичност и отдолу сигурният конвейер за доставка.01Достъпни интерфейси02Модули и бизнес правила03Наематели, идентичност, данни04Сигурен конвейер за доставка
  1. 01Проектиране по предметната област за работа с много правила, като обработката на преписки
  2. 02Достъпност по EN 301 549 и WCAG 2.2 AA още от първия дизайн
  3. 03Документация и записани решения, които екипите Ви могат да поемат

01 Проблеми

Какво чуваме преди нова разработка

  1. 01

    Всяка промяна отнема тримесечие

    Приложението работи, но никой не смее да пипне ядрото. Малките промени изискват големи регресионни тестове и прозорец за нова версия.

  2. 02

    Порталът не служи на хората, за които е създаден

    Не работи с екранен четец, на телефон или на втори език за чуждестранните потребители. Оплакванията пристигат преди одита за достъпност.

  3. 03

    Промяна за един клиент чупи системата на друг

    SaaS продуктът е растял чрез настройки по поръчка за всеки клиент. Сега всяка нова версия е повод за преговори, а някои клиенти са заседнали на стари версии.

  4. 04

    Знанието си тръгна с доставчика

    Решенията никога не са записвани. Екипът, който е изградил системата, вече е другаде, а кодът е единствената документация.

  5. 05

    Клиенти и регулатори задават въпроси за сигурността

    Възложителите искат SBOM, процес за уязвимости и доказателства по Акта за киберустойчивост. Никой не ги има готови.

02 Какво доставяме

Какво доставяме

  1. 01 Разработка на SaaS продукти

    Продукти, проектирани да обслужват много клиенти с една кодова база: правилният модел за наематели, конфигурация вместо разработка по поръчка и нови версии, които стигат до всеки клиент.

    Какво правим

    • Избор на модел за наематели: общ, групиран или изолиран за всеки клиент
    • Стратегия за конфигурация и превключватели на функции
    • Интеграция на отчитането на използването и фактурирането
    • Редовни нови версии с поетапно разгръщане по клиенти

    Какво получавате

    • Проект за наемателите и изолацията
    • Модел на конфигурацията с предпазни правила
    • Процес за нови версии с връщане назад за всеки клиент

  2. 02 Проектиране на предметната област при сложни правила

    Проектиране по предметната област (domain-driven design), когато правилата са самият продукт: обработка на преписки, проверка на правото на помощи и услуги, изчисления с много регулаторни правила. Съзнателно избираме между модулен монолит и микроуслуги и най-често започваме с първото.

    Какво правим

    • Event storming с експерти от областта
    • Ограничени контексти и граници на модулите
    • Правила, направени явни и проверими
    • Записи на архитектурните решения за големите избори

    Какво получавате

    • Модел на областта и карта на контекстите
    • Модулна кодова база с наложени граници
    • Изпълними спецификации за ключовите правила

  3. 03 Портали за граждани и служители

    Интерфейси, изградени върху дизайн система, достъпни по подразбиране и многоезични от първата версия. За български портал за електронни административни услуги това означава ясен български език и достъпност по Закона за електронното управление; за международен продукт означава езиците, на които потребителите Ви наистина говорят.

    Какво правим

    • Дизайн система с достъпни компоненти
    • Съдържание на ясен и разбираем език
    • Тестове с помощни технологии и реални потребители
    • Процес за локализация за всеки език

    Какво получавате

    • Портал върху дизайн система за многократна употреба
    • Доклад за съответствието с изискванията за достъпност
    • Процес за съдържание и преводи

  4. 04 Инженеринг на качеството и сигурна разработка

    Автоматизирани тестове на правилните нива, договорни тестове между услугите, тестове за производителност преди пускането и жизнен цикъл на сигурна разработка, изграден върху OWASP ASVS, SBOM и контроли на веригата за доставки на софтуер.

    Какво правим

    • Стратегия за тестване и автоматизация
    • Договорни тестове и тестове за производителност
    • Моделиране на заплахите и проверка по ASVS
    • Генериране на SBOM и правила за зависимостите

    Какво получавате

    • Автоматизирани тестове в конвейера
    • Доклад от проверката на сигурността
    • Процес за уязвимости, подготвен за Акта за киберустойчивост

  5. 05 Постепенна модернизация

    Заменяме старо приложение функция по функция, зад маршрутизираща фасада, докато работата продължава. Вижте също Модернизация на стари системи.

    Какво правим

    • Карта на функциите на съществуващото приложение
    • Постепенна замяна чрез маршрутизиране и обвиване с API
    • Миграция на данни с доклади за съгласуване
    • Паралелна работа при критичните изчисления

    Какво получавате

    • Последователност на модернизацията с бизнес етапи
    • Фасада и нови модули в експлоатация
    • Съгласувани данни при всяко превключване

  6. 06 Поддържаемост и предаване

    Софтуер, който екипите Ви могат да поемат: четим код, записани решения, оперативни ръководства и план за предаване, уговорен в началото, а не открит в края.

    Какво правим

    • Работа по двойки с Вашите разработчици по време на изграждането
    • Записи на архитектурните решения, съхранявани заедно с кода
    • Оперативни ръководства и указания за дежурства
    • Етапи за предаване на знанията

    Какво получавате

    • План за предаване с критерии за приемане
    • Документация във Вашите хранилища
    • Обучен вътрешен екип

03 Архитектура

Примерна референтна архитектура

Типична форма за бизнес приложение, което заменя по-старо: достъпен интерфейс, маршрутизираща фасада, която насочва всяка функция към старата или новата система, API слой с ясни договори и модулно ядро, организирано около предметната област.

Наемателите и конфигурацията са изрични платформени услуги, а не условия, разпръснати из кода. Отдолу всяко изграждане изпълнява тестове и проверки за сигурност и създава SBOM.

Слоеве в диаграмата

Хора
Граждани, клиенти и служители, на всяко устройство и с помощни технологии.
Модернизация
Маршрутизиращата фасада, съществуващото приложение и миграцията на данни със съгласуване.
Платформа
API слой, идентичност, модулното ядро, наематели и конфигурация, оперативни данни.
Сигурна доставка
Договорни тестове и тестове за производителност, проверки по ASVS и SBOM при всяко изграждане.
Илюстративен пример

  1. Хора

    • Граждани, клиенти, служители
    • Достъпен интерфейс

  2. Постепенна модернизация

    • Маршрути­зираща фасада
    • Съществуващо приложение
    • Миграция със съгласуване

  3. Платформа

    • API слой и договори
    • Идентичност и роли
    • Модулно ядро: заявления, преписки, фактуриране
    • Наематели, конфигурация, превключ­ватели
    • Оперативни хранилища за данни

  4. Сигурна доставка

    • Договорни тестове и тестове за производи­телност, проверки по ASVS, SBOM при всяко изграждане
Модулно ядро зад маршрути­зираща фасада

Примерна архитектура, а не система на клиент.

Прочетете диаграмата като текст

Основният маршрут води от хората към достъпен интерфейс, през маршрутизираща фасада и API слой, до модулно ядро, организирано в ограничени контексти.

Фасадата насочва някои функции и към съществуващото приложение, което се извежда от употреба стъпка по стъпка. Неговите данни преминават през миграция със съгласуване към оперативните хранилища за данни.

Управлението на идентичността обслужва API слоя. Услугите за наематели и конфигурация са под ядрото. Лента за сигурна доставка отдолу обхваща договорните тестове, тестовете за производителност, проверката на сигурността и SBOM.

04 Съображения и ограничения

Инженерни съображения и ограничения

  • Първо модулен монолит

    Как го решаваме

    Започваме с ясни модули в една единица за внедряване и отделяме услуги само там, където мащабът, темпото на новите версии или отговорността на екипите го изискват.

    Ограничения и зависимости

    Микроуслугите решават колкото организационни, толкова и технически проблеми. Без екипи, които да отговарят за тях, те добавят разходи и нови начини за отказ.

  • Достъпността е инженерна работа

    Как го решаваме

    Достъпни компоненти, автоматични проверки в конвейера и ръчни тестове с помощни технологии преди всяка голяма нова версия.

    Ограничения и зависимости

    Автоматичните инструменти откриват само част от проблемите. Пълното съответствие изисква ръчни одити и в идеалния случай тестове с потребители с увреждания.

    Съдържанието и документите, които редакторите добавят след пускането, трябва да отговарят на същия стандарт. Обучаваме редакторите, но не контролираме какво публикуват.

  • Модерни­зацията върви с темпото на данните

    Как го решаваме

    Миграцията на данни се планира за всяка функция, репетира се и се съгласува, с бизнес одобрение при всяко превключване.

    Ограничения и зависимости

    Качеството на старите данни често определя темпото. Почистването им е колкото техническа, толкова и бизнес задача.

  • Регулации за софтуерни продукти

    Как го решаваме

    SBOM, обработката на уязвимости и сигурните настройки по подразбиране са част от стандартния ни конвейер, който подготвя продуктите за Акта за киберустойчивост.

    Ограничения и зависимости

    Дали и как Актът се прилага за Вашия продукт е правен въпрос. Ние осигуряваме инженерните доказателства; юристите Ви правят оценката.

05 Как работим

Как работим

Кратки цикли, реални потребители от рано и предаване, планирано още от първата седмица.

  1. 01

    Очертаваме предметната област

    Event storming с хората, които познават правилата, и карта на функциите, които съществуват днес.

    РезултатКарта на контекстите и първи записани решения

  2. 02

    Пускаме тънък срез

    Една функция от край до край, през фасадата, в експлоатация с реални потребители.

    РезултатРаботещ срез в експлоатация

  3. 03

    Растем функция по функция

    Всяка нова версия премества една функция, нейните данни и потребители, като съгласуването и връщането назад са подготвени предварително.

    РезултатПлан на версиите по функции

  4. 04

    Предаваме

    Вашите разработчици работят по двойки с нашите, поемат дежурствата и отговарят за пътната карта, когато критериите за предаване са изпълнени.

    РезултатПрието предаване

06 Човешки контрол

Къде контролът остава у хората

В бизнес софтуера контролът означава да знаете кой какво е променил, кой го е одобрил и как да го върнете.

  • Продуктовите отговорници определят обхвата

    Вашият продуктов отговорник определя приоритетите и приема всяка нова част. Ние съветваме, той решава.

  • Конфигура­цията има отговорник

    Настройките на клиентите и превключвателите на функции се променят чрез процес с одитна следа, от роли, които Вие определяте.

  • Превключ­ванията се одобряват

    Всяко преминаване от старата към новата система се одобрява от бизнеса, с репетирано връщане назад.

  • Решенията се записват

    Записите на архитектурните решения показват какво е избрано, от кого и защо, така че бъдещите екипи да могат да ги преразгледат информирано.

07 Технологии

Технологии, с които работим

Сървърна част
  • Java и Kotlin
  • .NET
  • TypeScript и Node.js
  • Python
Потребителски интерфейс
  • React и Next.js
  • Angular
  • Дизайн системи с достъпни компоненти
  • Нативни и междуплатформени мобилни приложения
Данни
  • PostgreSQL
  • SQL Server и Oracle (при съществуващи системи)
  • Поточна обработка на събития
  • Търсачки
Качество и сигурност
  • Playwright и договорни тестове
  • Тестове за натоварване и производителност
  • SAST, DAST и сканиране на зависимостите
  • SBOM във формат CycloneDX или SPDX

Посочването на технология описва инженерния ни опит. То не означава партньорство с нейния производител или одобрение от него.

08 Пример

Илюстративен пример

Илюстративен пример

SaaS продукт за работни заплати на българска софтуерна компания, разширен към нови държави

01Ситуация
Българска софтуерна компания продава SaaS продукт за работни заплати и иска да го предложи в още три държави от ЕС. Досега всеки голям клиент е получавал собствен клон на кода, а всяка промяна в правилата се прави по няколко пъти.
02Какво бихме изградили
Една кодова база с модули за правилата на всяка държава, езиците и интеграциите в конфигурацията, обща дизайн система с достъпни компоненти и един ритъм на нови версии за всички клиенти.
03Къде решават хората
Експертите по правилата за всяка държава одобряват конфигурацията и тестовите случаи за своя пазар; продуктовият отговорник решава за общите функции.
04Какво бихме измервали
Проблеми с достъпността при всяка нова версия, време за внедряване на промяна във всички държави и дял на промените, направени веднъж вместо за всеки клиент.

09 По сектори

Във Вашия сектор

  • Публичен сектор

    Системи за преписки и портали за електронни административни услуги, които отговарят на изискванията за достъпност и за оперативна съвместимост по Закона за електронното управление.

  • Финансови услуги

    Клиентски портали и бек офис приложения със стабилна одитна следа и процеси за нови версии, които отговарят на изискванията за управление на промените.

  • Производство и индустрия

    Конфигуратори, сервизни портали и SaaS продукти за производители на оборудване, свързани с ERP и сервиза на терен.

България

Нов пазар е нова версия, а не отделен клон

Продукт, който се продава в целия ЕС, се сблъсква с Европейския акт за достъпност чрез национални закони, които се различават в подробностите, и с Акта за киберустойчивост чрез един регламент със задължения, които влизат в сила на етапи. Клиентите във всяка държава очакват и свой език, свои правила за фактуриране и свои средства за електронна идентификация.

В България Законът за изискванията за достъпност на продукти и услуги е в сила от 28 юни 2025 г.; за продуктите надзорът е при Държавната агенция за метрологичен и технически надзор (ДАМТН), а за услугите в електронната търговия при Комисията за защита на потребителите (КЗП). Законопроект, внесен в Народното събрание на 5 ноември 2026 г., предвижда структурирани електронни фактури от 1 юли 2028 г.

Държим тези разлики в конфигурацията и в ясно отделени модули, така че нов пазар да е нова версия, а не отделен клон на кода. Доказателствата за достъпност и документацията за сигурност се създават от конвейера и са готови за въпросите при обществени поръчки на всеки пазар.

Въпроси за корпоративния софтуер и SaaS

Да разработим ли софтуер по поръчка или да настроим платформа?

Настройте платформа, когато процесът Ви е близък до стандартния, и разработвайте, когато процесът Ви отличава или когато никоя платформа не отговаря на правилата Ви. Работим със Salesforce, SAP и Odoo, както и със софтуер по поръчка, затова нямаме причина да налагаме един отговор. Услугата ни Архитектура и консултиране прави този избор явен.

Можете ли да гарантирате, че порталът ни е достъпен?

Разработваме по EN 301 549 и WCAG 2.2 AA, тестваме автоматично и ръчно и предоставяме доклад за съответствието с всички известни проблеми. Не обещаваме, че няма да има проблеми; обещаваме да ги откриваме, докладваме и поправяме в рамките на нашия обхват.

Можете ли да модернизирате без миграция наведнъж?

Да, и го препоръчваме. Маршрутизиращата фасада ни позволява да преместваме по една функция, докато съществуващото приложение продължава да работи, като данните се съгласуват на всяка стъпка.

Може ли собственият ни екип да поеме софтуера?

Това е планът по подразбиране. Критериите за предаване се уговарят в началото, разработчиците Ви работят по двойки с нашите по време на изграждането, а записите на решенията и оперативните ръководства са във Вашите хранилища.

Какво означава Актът за киберустойчивост за нашия продукт?

Ако пускате на пазара на ЕС софтуер, който е продукт с цифрови елементи, Актът може да Ви наложи задължения за сигурно проектиране, обработка на уязвимости и документация. Ние изграждаме инженерните доказателства: SBOM, процес за уязвимости и сигурни настройки по подразбиране.

Кажете ни какво трябва да продължи да работи, докато се променя

Ще предложим първата функция за преместване и какво ще поеме екипът Ви в края.

Обсъдете проекта сиМодернизация на системи