Вебинар для ИТ-директоров и руководителей разработки
Агенты разработки позволяют сотрудникам за пределами ИТ создавать работающие приложения для реальных бизнес-процессов. Но проверять их архитектуру, безопасность и сопровождаемость, встраивать в корпоративный контур и отвечать за инциденты по-прежнему предстоит ИТ. Разберем, как сохранить полезную инициативу и превратить прототип, созданный с помощью ИИ, в систему, которую инженерная команда может принять на сопровождение.
Бизнес уже пишет приложения сам. Что делать ИТ?
25 ноября, 16:00 по МСК
Прототип уже работает. Проблема только начинается.
Начальник охраны показывает форму заказа автомобильного пропуска, согласование, статусы и экран сотрудника КПП. «Мы уже проверили. Давайте поставим на сервер и запустим». Задача реальная, владелец процесса компетентен, результат можно показать руководству. Но приложение затрагивает персональные данные, права доступа, интеграции, аудит и физическую безопасность.
Кто проверит код? Кто определит архитектуру? Кто будет отвечать за изменения и инциденты через год?
Вариант
Что видит ИТ-директор
Запретить
ИТ снова тормозит полезную инициативу
Принять как есть
Неизвестные риски и стоимость сопровождения
Переписать
Потеря обещанной скорости ИИ-разработки и возврат в очередь задач
Оставить бизнесу
Новый слой бизнес-критичных теневых ИТ-решений
Код стал дешевле.
Способность проверять его — нет.
Способность проверять его — нет.
Агенты разработки увеличивают скорость появления изменений. Пропускная способность архитекторов, ИБ, проверки кода, тестирования и эксплуатации не растет с той же скоростью. Работающих прототипов становится больше, но путь до промышленной эксплуатации не сокращается автоматически.
Рост скорости генерации
Увеличение разрыва между генерацией и проверкой
Накопление когнитивного долга
Размывание ответственности
*Пропускная способность проверки
Способность организации проверить требования, архитектуру, безопасность, данные, интеграции и эксплуатационную готовность изменений.
*Когнитивный долг
Разрыв между объемом созданного кода и способностью команды понимать систему, уверенно изменять ее и отвечать за результат.
Способность организации проверить требования, архитектуру, безопасность, данные, интеграции и эксплуатационную готовность изменений.
*Когнитивный долг
Разрыв между объемом созданного кода и способностью команды понимать систему, уверенно изменять ее и отвечать за результат.
Разработка с помощью ИИ уже вышла за границы ИТ-команды
бизнес приносит работающие прототипы вместо заявок в очередь разработки;
после демо проект выглядит готовым, но ИБ и архитектура еще не подключались;
ведущие инженеры не успевают проверять растущий объем изменений;
ответственность за сопровождение в итоге все равно оказывается у ИТ;
нужны правила, которые сохраняют скорость, а не запрещают инициативу.
Вопрос уже не в том, умеет ли ИИ писать код. Вопрос — какую часть этого кода организация способна проверить, понять и принять на сопровождение.
Сквозным примером станет система автомобильных пропусков,
созданная с помощью Qwen на Джеймикс
созданная с помощью Qwen на Джеймикс
Не запрещать инициативу. Не проверять каждый фундамент с нуля.
На вебинаре участники разберут, как направить ИИ-разработку в стандартизированный технологический контур: сохранить скорость создания приложений, сосредоточить проверку на специфической бизнес-логике и передать результат профессиональной Java-команде.
Что вы заберете после вебинара
Критерии готовности к промышленной эксплуатации
как отличить демонстрационный прототип от системы, которую ИТ может принять на сопровождение.
Тест инженерной ответственности
способ проверить, сможет ли команда объяснить, изменить и сопровождать приложение.
Маршрут принятия прототипа
какие подтверждения нужны, прежде чем ИТ сможет взять систему на сопровождение.
Критерии технологического фундамента
какие части архитектуры не следует изобретать заново в каждом проекте.
План первого шага
что сделать с уже существующими прототипами после вебинара.
Программа вебинара
Приложение теперь может создать почти любой
Новое узкое место — пропускная способность проверки
Когнитивный долг и потеря ответственности
При каких условиях ИТ может принять прототип на сопровождение
Как технологический фундамент сокращает область неизвестного
Система пропусков на Джеймикс: от исходного запроса до развития
Вопросы и ответы
Где здесь Джеймикс — и где его нет
Этот вебинар не предлагает разрабатывать на Джеймикс любую систему вместо покупки готового продукта. Джеймикс рассматривается как технологический фундамент для профессиональных
Java-команд в тех случаях, когда организация решила самостоятельно создавать и развивать транзакционное корпоративное приложение с интенсивной работой с данными.
Java-команд в тех случаях, когда организация решила самостоятельно создавать и развивать транзакционное корпоративное приложение с интенсивной работой с данными.
Джеймикс помогает
задать стандартную архитектуру приложения
использовать знакомые технологии Java и Spring
не создавать заново типовые механизмы данных, безопасности и пользовательского интерфейса
сохранить исходный код и стандартный инженерный процесс
сделать структуру приложения понятнее для другой Java-команды
Джеймикс не заменяет
требования и продуктовую ответственность
проверку кода, тестирование и ИБ
интеграционную архитектуру всей компании
BI, MLOps, ECM, шину интеграции и другие специализированные классы систем
Джеймикс не отвечает за результат вместо команды.
Он делает систему достаточно стандартной и понятной, чтобы команда могла принять за нее ответственность.
Кому будет полезно
- ИТ-директорам, определяющим правила разработки с помощью ИИ
- Руководителям разработки с растущим потоком изменений, созданных с помощью ИИ
- Корпоративным архитекторам и архитекторам решений, отвечающим за стандарты и интеграции
- Руководителям цифровой трансформации, которым нужно переводить пилоты в измеримый результат
- Руководителям ИБ и эксплуатации, участвующим в принятии систем в промышленную эксплуатацию
- Особенно полезно компаниям, где уже появился хотя бы один убедительный прототип, созданный с помощью ИИ, но еще нет стандартного маршрута его оценки и принятия в промышленную эксплуатацию.
Спикер
- Виктор ФадеевРуководитель продукта ДжеймиксОтвечает за развитие продуктов платформенной разработки Джеймикс и OpenBPM в компании Haulmont. Занимается продуктовой стратегией инструментов для создания корпоративных информационных систем, автоматизации бизнес-процессов и агентной разработки. Выступает и модерирует конференции по корпоративной автоматизации,
open-source инструментам, платформам данных и BI.
Формат
60 минут
основная часть
+ 20 минут вопросы
Онлайн на платформе МТС Линк
Ссылка после регистрации
Бесплатно
Ваш следующий прототип, созданный с помощью ИИ, может прийти не из ИТ. Подготовьте маршрут до промышленной эксплуатации заранее.
Зарегистрируйтесь, чтобы получить способ оценки прототипов и понять, как сохранить новую скорость разработки без потери инженерной ответственности.