Marlin: как мы создавали архитектурный репозиторий
Цель
Поделиться опытом и обсудить с экспертами процесс разработки и внедрения собственного архитектурного репозитория и внедрения RPA.
Описание секции
Специалисты блока ИТ Страхового Дома ВСК расскажут про уникальные ИТ-разработки и продукты. Иван Маслов — об опыте использования RPA, и о том, как упростить работу с legacy системами. А Степан Дудник — про корпоративную систему архитектурного репозитория, которая может сэкономить сотни часов менеджерам проектов и команде разработчиков.
Для кого
1
Разработчики
2
Аналитики
3
Тимлиды
4
Руководители проектов
5
Студенты
6
ИТ-директора
Спикеры
Александр Саханский
Руководитель регионального IT-центра
Страховой Дом ВСК, г. Томск
«IT в страховании, RPA как основа IT-автоматизации»
Иван Маслов
Руководитель направления перспективных технологий
Страховой Дом ВСК, г. Санкт-Петербург
«IT в страховании, RPA как основа IT-автоматизации»
Степан Дудник
Руководитель центра развития платформенных решений ВСК
Страховой Дом ВСК, г. Москва
«Технологическая платформа Марлин»
Купить билет на Город IT
8 сентября мы собираемся на Воркшопе который ориентирован в первую очередь на тимлидов и желающих ими стать (так же воркшоп подойдет руководителям направлений, менеджерам проектов и продуктов и всем, кто работает с людьми). Покупая билет на воркшоп, БОНУСОМ вы получаете доступ к всем секциям Город IT Pro.
Покупая билет на секции, вы получаете право принять участие во всех секциях Город IT Pro (9 и 10 сентября), в билет не входит посещение Воркшопа. На секции мы приглашаем всех, кто интересуется IT выступлениями спикеров и мощнейшим нетворкингом.
Автор резонансных статей на Habr и VC. Иван наглядно продемонстрировал огромный разрыв между IT и бизнес-сообществом. Иван работает в Страховом Доме ВСК на должности руководителя направления RPA. Является основателем первой в мире open source платформы роботизации RPA для бизнеса, которая полностью заменяет функциональность TOP-4 RPA решений.
RPA как основа IT-автоматизации
Тезисы:
-Сервисы, монолит, микросервисы - что дальше? -RPA как основа IT-архитектуры. Технология, которая не зависит от трендов. -Парадокс: в целевой ИТ архитектуре не должно быть технологии RPA. Но фактически потребность в этой технологии становится всё больше и больше!
Дудник Степан Викторович (Страховой Дом ВСК)
Project&Product Management Опыт в ИТ и страховании - с 2006 года Участвовал в развитии различных проектов в крупных страховых компаниях. Имеет практический опыт в управлении проектами с бюджетом до 1,5 млрд рублей Имеет практический опыт в формировании ИТ-команд с 0, выстраивании процессов работы команд
Технологическая платформа Марлин
Тезисы:
- Производственный поток ценности - можно ли сделать прозрачно и оптимально? - Переход от монолита к микросервисам - можно ли сделать удобно и эффективно в "кровавом энтерпрайзе"? - Задача с звездочкой - эффективный архитектурный репозиторий для всех, включая информационную безопасность которым просто пользоваться
Денис Юрьев(Skyeng)
Ваша компания сделала успешный продукт в своей нише. Круто, но пора двигаться дальше. Часто бизнес решает масштабироваться для большего охвата клиента с похожим решением, но «с перламутровыми пуговицами». Компания нанимает новую команду. Команда клонирует имеющийся код, слушает советы старичков, начинает отрезать лишнее и докручивать нужное, и... через полгода у компании уже два совершенно разных проекта, независимо от того, насколько одинаковы были решаемые задачи. Сложность поддержки тоже выросла.
У меня такое пару раз было и с тех пор хотелось сделать это всё иначе. Поэтому когда в Skyeng решили запускать новые предметы после успеха нашей с командой платформы, предложил: «А давайте мы своими силами». Поддержка новых репозиториев казалась неинтересным, а с учетом планов на десяток потенциальных проектов — самоубийственным решением. Поэтому мы пошли новой дорогой.
Предстояло найти компромисс между удобством поддержки нескольких проектов минимальными силами и требованием беспроблемно вносить новый функционал. Возможность запуска новых продуктов в течение считанных часов получилась сама собой.
В докладе поделюсь историей в деталях, как мы спланировали архитектуру, как пошли не по принятым в компании практикам, на какие «грабли» Symfony наткнулись в процессе — и почему оно у нас вообще получилось.
Денис Юрьев(Skyeng)
Ваша компания сделала успешный продукт в своей нише. Круто, но пора двигаться дальше. Часто бизнес решает масштабироваться для большего охвата клиента с похожим решением, но «с перламутровыми пуговицами». Компания нанимает новую команду. Команда клонирует имеющийся код, слушает советы старичков, начинает отрезать лишнее и докручивать нужное, и... через полгода у компании уже два совершенно разных проекта, независимо от того, насколько одинаковы были решаемые задачи. Сложность поддержки тоже выросла.
У меня такое пару раз было и с тех пор хотелось сделать это всё иначе. Поэтому когда в Skyeng решили запускать новые предметы после успеха нашей с командой платформы, предложил: «А давайте мы своими силами». Поддержка новых репозиториев казалась неинтересным, а с учетом планов на десяток потенциальных проектов — самоубийственным решением. Поэтому мы пошли новой дорогой.
Предстояло найти компромисс между удобством поддержки нескольких проектов минимальными силами и требованием беспроблемно вносить новый функционал. Возможность запуска новых продуктов в течение считанных часов получилась сама собой.
В докладе поделюсь историей в деталях, как мы спланировали архитектуру, как пошли не по принятым в компании практикам, на какие «грабли» Symfony наткнулись в процессе — и почему оно у нас вообще получилось.
Денис Юрьев(Skyeng)
Ваша компания сделала успешный продукт в своей нише. Круто, но пора двигаться дальше. Часто бизнес решает масштабироваться для большего охвата клиента с похожим решением, но «с перламутровыми пуговицами». Компания нанимает новую команду. Команда клонирует имеющийся код, слушает советы старичков, начинает отрезать лишнее и докручивать нужное, и... через полгода у компании уже два совершенно разных проекта, независимо от того, насколько одинаковы были решаемые задачи. Сложность поддержки тоже выросла.
У меня такое пару раз было и с тех пор хотелось сделать это всё иначе. Поэтому когда в Skyeng решили запускать новые предметы после успеха нашей с командой платформы, предложил: «А давайте мы своими силами». Поддержка новых репозиториев казалась неинтересным, а с учетом планов на десяток потенциальных проектов — самоубийственным решением. Поэтому мы пошли новой дорогой.
Предстояло найти компромисс между удобством поддержки нескольких проектов минимальными силами и требованием беспроблемно вносить новый функционал. Возможность запуска новых продуктов в течение считанных часов получилась сама собой.
В докладе поделюсь историей в деталях, как мы спланировали архитектуру, как пошли не по принятым в компании практикам, на какие «грабли» Symfony наткнулись в процессе — и почему оно у нас вообще получилось.