Аналитика микросервисов. Практический опыт аналитика в enterprise

PosgreSQL

Методологии и процессы разработки ПО; Сроки и приоритеты
Большие проекты/команды
Управление / другое
Управление изменениями, управление требованиями
Проектирование информационных систем
Проектные артефакты, инструментарий
Аналитика / другое
Enterprise-системы

Доклад отклонён

Целевая аудитория

Для кого я решил написать? Данная статья, написана для моих коллег аналитиков или для тех, кто желал бы им стать. Если вы теперь захотели стать аналитиком, то подумайте хорошенько. Микросервисы. С хайпом вокруг них, лучше быть разработчиком, архитектором, тестировщиком, проджект-менеджером, дизайнером. Хорошо быть кем угодно в микросервсиах, но только не аналитиком. Аналитик ведь всегда во всем виноват. Ни разу не слышал, чтобы в “факапе” и срыве сроков обвинили архитектора, ну или там разработку. Нет, господа, вина всегда лежала и будет лежать на плохой документации и нечетко поставленных задачах. Вот вся команда собралась и тычет в тебя пальцами. Дескать, это все он! Опытный архитектор спроектировал, хороший разработчик сделал, внимательный тестировщик протестировал, мотивированный проджект-менеджер обеспечил… а невнимательный аналитик все завалил. А меж тем, материалов по аналитике и как её вести на русском языке очень мало. И как “анализировать” эти самые микросервисы не совсем понятно. Более того, никто вам не скажет, чем “системный аналитик” теперь отличается от “солюшн архитектора”. Вот во всем этом я и захотел разобраться и поделиться. Поэтому, если вы не аналитик - не читайте. Вам не будет интересно. Ведь, нет в вас экзистенциального кризиса и вопросов “Кто я? и зачем я им нужен на проекте”.

Тезисы

В докладе будет рассказано о практическом опыте работы аналитика на проектах российских банков уровня ТОП-5. В условиях Agile сопровождать "монолит" стало проблематично и в последнее время все чаще крупные банки (как в прочем и многие крупные компании) переходят к микросервисному архитектурному стилю. В связи с этим к аналитикам начали предъявляться новые требования. Аналитик больше не "технический писатель", занимающийся документацией и подготовкой маппингов для адаптеров.Теперь он больше "солюшн архитектор" и центральная фигура в команде, отвечающая как за выбор решения, так и за постановку задач разработке. В докладе будут рассмотрены следующие темы: Что же такого в микросервисах с методологической точки зрения и какие артефакты требуют внимания при анализе. Микросервисы - всегда хорошо и есть ли кейсы, когда все же лучше оставить монолит? DDD, онтология как лучшие практики. Как выбрать и описать решение, чтобы оно не стало препятствием для последующих доработок и интеграции.

Видео