Уявіть, що ви вирішили врятувати старий, зношений корабель, замінивши його двигуни на найсучасніші. Але замість того, щоб “полетіти у світле майбутнє”, він починає тонути ще швидше. Це історія про те, як Clean Architecture може стати і рятівним кругом, і каменем на шиї проєкту. У першій частині — хроніки болю: спроба впровадити архітектурну красу у хаос легасі коду, де навіть успіхи здавались випадковістю та чому "Ми просто робимо Clean Architecture" не завжди працює. У другій — історія “тріумфу”: коли зріла команда і правильний підхід перетворили Clean Architecture на фундамент масштабованої, гнучкої та живої системи. Дві історії з реальної практики, що показують, чому той самий підхід може як провалити, так і врятувати проєкт.

Запуск Diia AI всупереч усім труднощам Що потрібно, щоб створити розмовного AI-асистента для мільйонів громадян? Подорож зі створення Diia.AI, національного цифрового асистента України, почалася з простого й багатообіцяючого Proof of Concept. Але перехід від контрольної демо-версії до живої, продуктивної системи, що працює з чутливими даними та реальними державними сервісами, виявився шляхом, сповненим несподіваних викликів. Ця доповідь — чесний, закулісний погляд на нашу архітектурну еволюцію. Ми заглибимося у реальні виклики, з якими зіткнулися: від боротьби з непередбачуваними "галюцинаціями" LLM та інтеграції зі складними державними реєстрами, до проєктування системи для національного рівня безпеки й масштабування під екстремальним тиском. Це не історія бездоганного успіху; це історія вирішених проблем — від абсурдно простих до монументально складних. Приєднуйтесь, щоб дізнатися практичні уроки, яких немає в підручниках. Ми розповімо, як проєктували систему з урахуванням стійкості, застосовуючи RAG-підхід для боротьби з дезінформацією, впроваджували надійні Guardrails для забезпечення безпеки та будували масштабовану, відмовостійку екосистему. Ця сесія буде корисною для архітекторів, розробників і продуктових лідерів, які хочуть зрозуміти справжні «шрами від битв» та важко здобуті інсайти, що приходять із запуском масштабної AI-платформи всупереч усім труднощам.

Ми хотіли зробити сервіс швидким для користувачів у будь-якій точці світу. Edge Computing виглядало як ідеальне рішення. На практиці ж ми отримали і зменшення latency, і цілу купу несподіваних проблем. У цій доповіді я розповім: - як ми проектували edge-архітектуру для глобальних користувачів; - edge-провайдери та інфраструктура: що обрали і чому; - які оптимізації справді дали відчутний результат; - архітектурні компроміси, що вплинули на дизайн системи; - де edge перетворився на “edge-case” і змусив шукати нестандартні обхідні рішення; - наші факапи, та best practices;

Як проєктувати архітектуру для продукту, який уже має успішний прод, але всередині нього хочеться запускати стартапи? Як не завалити стабільну систему, зберегти довіру користувачів, і водночас дати бізнесу простір для експериментів? - Болючі кейси "важких фіч", що не прижились - Як перетворили бажання бізнесу "більше й швидше" на архітектуру - Успішний кейс швидких фіч: Таємні бокси в Expirenza - Проблеми після успіху "тимчасової" фічі - Зміна майндсету команди розробки

Зараз дуже багате різноманіття інструментів для документування архітектури програмного забезпечення. При цьому з часом виникає питання, а чи є інструмент, який дозволяє не тільки зображувати архітектурні блоки як взаємопов'язані сервіси чи компоненти, а й включати комплексну інформацію про бізнес-прцеси, інформаційні системи та ІТ-інфраструктуру в єдиному вигляді? Таким інстурментом є Archimate. ArchiMate — мовa моделювання для опису, візуалізації й аналізу корпоративної архітектури, що разом з TOGAF стає потужним інструментом в руках архітектора. Під час доповіді розповім на прикладах про мову моделювання Archimate, покажу які є можливості в Archi для прискорення документування та аналізу архітектури, розповім як ми в використовуємо можливості мови моделювання у нас в компанії.

Протягом багатьох років наша платформа для корпоративних клієнтів працювала на великому, надійному моноліті. Але з часом технічний борг, повільні релізи та залежності між модулями почали гальмувати розвиток. Настав час для переосмислення. Це історія еволюції для 150 тис. клієнтів: від паралельної роботи моноліту та мікросервісів — до Domain-Driven Development із понад 20 платформеними та продуктовими командами, від JSP до мікрофронтендів і дизайн-системи, від IBM до Open Source. Ключові інсайти: Чому стабільного моноліту вже недостатньо для сучасного банкінгу Як переходити без шкоди бізнесу і клієнтам Паралельна робота моноліту та мікросервісів — практичні уроки Domain-Driven Development у масштабі 20+ команд (платформені та продуктові) Мікрофронтенди та дизайн-система для швидших релізів Коли Open Source — правильний вибір, а коли варто купити

Доповідь присвячена архітектурному підходу для контролю якості AI-рішень, де замість традиційних методів тестування використовується інший AI в ролі «судді». На прикладі реального кейсу AI Calories Tracker, який щодня розпізнає 5000+ зображень страв, ми покажемо, як нестандартний підхід до контролю якості дозволяє ефективно керувати ризиками і підвищувати довіру до штучного інтелекту.

Уявіть, що одного дня вашій команді передають систему, яку 4 роки створювали шість різних команд, просто щоб перевірити гіпотези. Ніякої документації, просто гігантська монорепа і Jenkins для деплою. Саме в таких умовах ми вирішили зробити повну інвентаризацію — і почали з Architecture as Code. У цьому виступі я розповім, як ми системно підійшли до опису архітектури: від побудови C4-діаграм до створення Service Documentation, ERD та Sequence Diagram-ів. Ви дізнаєтесь, як ми на практиці відновили розуміння системи, впровадили архітектурну прозорість, а також які інструменти (PlantUML, Mermaid) та підходи спрацювали найкраще. Це не лише про діаграми — це про виживання в хаосі, командну синхронізацію та архітектурну еволюцію через прозорість.

Як правильно спланувати глобальні зміни у компанії з понад 25 тис. клієнтів. Чому комунікація між технічними командами та бізнесом є ключем до успіху. SRE, RnD, Архітектура як драйвери трансформації. Роль ФінОпс у сталому розвитку. Реальні кейси, помилки та висновки.