К сегодняшнему вебинару поискал разные классификации интеграций. По статьям в интернете. И знаете что? Китайская классификация животных из рассказа Борхеса просто отдыхает.
Вот смотрите. Итак, интеграции бывают:
- горизонтальные
- вертикальные
- гибридные
- точечные
- в форме звезды
- через шину ESB
- оркеструющие процессы
- событийно-ориентированные
- REST
- SOAP
- GraphQL
- интеграции платформ
- интеграции данных
- интеграции приложений
- интеграции бизнес-процессов
- облачные
- через брокер
- ориентированные на сообщения
- через API
- MQTT
- gRPC
- интеграции легаси-систем
- через передачу файлов
- в форме обмена электронными документами
- высоконагруженные
- вебхуки
Так и хочется дописать "бесчисленные", "бегающие как сумасшедшие" и "похожие издали на мух".
Вообще вопрос классификаций сложный, и мало кто умеет их нормально составлять (и мало где в природе они в чистом виде присутствуют - в биологии, например, насколько я понимаю, с классификацией есть сложности). А одна из лучших книг про классификации - "Морфология волшебной сказки" Проппа.
Это вообще отличная книга по системному анализу (ну, с поправкой, что это всё же 1928 год!). В волшебной сказке Пропп выделяет следующие элементы и аспекты:
- функции
- действующие лица
- распределение функций по действующим лицам
- атрибуты действующих лиц (речь идёт в основном об объектах и их свойствах)
- ходы (применение функций) и их сочетания (последовательность и наложение ходов, отвлечения и возвраты)
Видите что-то знакомое? Натуральный системный анализ! 😂
Ну а с классификациями интеграций попробуем разобраться сегодня на вебинаре.
Вот смотрите. Итак, интеграции бывают:
- горизонтальные
- вертикальные
- гибридные
- точечные
- в форме звезды
- через шину ESB
- оркеструющие процессы
- событийно-ориентированные
- REST
- SOAP
- GraphQL
- интеграции платформ
- интеграции данных
- интеграции приложений
- интеграции бизнес-процессов
- облачные
- через брокер
- ориентированные на сообщения
- через API
- MQTT
- gRPC
- интеграции легаси-систем
- через передачу файлов
- в форме обмена электронными документами
- высоконагруженные
- вебхуки
Так и хочется дописать "бесчисленные", "бегающие как сумасшедшие" и "похожие издали на мух".
Вообще вопрос классификаций сложный, и мало кто умеет их нормально составлять (и мало где в природе они в чистом виде присутствуют - в биологии, например, насколько я понимаю, с классификацией есть сложности). А одна из лучших книг про классификации - "Морфология волшебной сказки" Проппа.
Это вообще отличная книга по системному анализу (ну, с поправкой, что это всё же 1928 год!). В волшебной сказке Пропп выделяет следующие элементы и аспекты:
- функции
- действующие лица
- распределение функций по действующим лицам
- атрибуты действующих лиц (речь идёт в основном об объектах и их свойствах)
- ходы (применение функций) и их сочетания (последовательность и наложение ходов, отвлечения и возвраты)
Видите что-то знакомое? Натуральный системный анализ! 😂
Ну а с классификациями интеграций попробуем разобраться сегодня на вебинаре.
👍25😁12👏4👎2🤔1
Вчера на вебинаре показывал промежуточные версии карты технологий интеграций, и внезапно одна из версий, которую я забраковал, вызвала интерес. Так что опубликую её тоже.
Здесь не так явно видна связь элементов друг с другом, только по расположению, зато видны направления дальнейшего возможного развития:
— от ETL идём в хранилища данных и BI
— от gRPC через HTTP/2 можно проложить путь к рассмотрению низкоуровневых протоколов (нужно ли аналитикам знать, чем друг от друга отличаются HTTP /1.0, /1.1, /2 и /3 ?)
— от транзакционной целостности можно дойти до паттерна Saga и микросервисов, а оттуда уже к рассмотрению архитектуры распределенных систем
— а от OpenAPI и смежных нотаций дальше идём к вопросам управления API
У карты четыре "центра кристаллизации" — всё те же стили из книги "Паттерны интеграций корпоративных приложений": обмен файлами, общая БД, удаленный вызов и обмен сообщениями. Вокруг группируются связанные технологии.
А ещё эта карта похожа на карту местности в какой-то стратегической игре — закрепились в одной части, построили укрепления, пошли разведывать новые области :) Надо будет туман по краям дорисовать, для антуражности.
Я показал эту версию ограниченному кругу, её очень ругали — мол, непонятная. Но на вебинаре она людям понравилась. Так что опубликую её тоже, а вы напишите в комментах — какую версию вы считаете более понятной и полезной.
Здесь не так явно видна связь элементов друг с другом, только по расположению, зато видны направления дальнейшего возможного развития:
— от ETL идём в хранилища данных и BI
— от gRPC через HTTP/2 можно проложить путь к рассмотрению низкоуровневых протоколов (нужно ли аналитикам знать, чем друг от друга отличаются HTTP /1.0, /1.1, /2 и /3 ?)
— от транзакционной целостности можно дойти до паттерна Saga и микросервисов, а оттуда уже к рассмотрению архитектуры распределенных систем
— а от OpenAPI и смежных нотаций дальше идём к вопросам управления API
У карты четыре "центра кристаллизации" — всё те же стили из книги "Паттерны интеграций корпоративных приложений": обмен файлами, общая БД, удаленный вызов и обмен сообщениями. Вокруг группируются связанные технологии.
А ещё эта карта похожа на карту местности в какой-то стратегической игре — закрепились в одной части, построили укрепления, пошли разведывать новые области :) Надо будет туман по краям дорисовать, для антуражности.
Я показал эту версию ограниченному кругу, её очень ругали — мол, непонятная. Но на вебинаре она людям понравилась. Так что опубликую её тоже, а вы напишите в комментах — какую версию вы считаете более понятной и полезной.
👍29🔥9❤5👎1👌1
А вот уже и запись вебинара по карте интеграций готова: https://youtu.be/27KmDUMkV6A
Смотрим, ставим лайки, задаем вопросы!
Upd.: Альтернатива на VK: https://m.vk.com/video-211773358_456239310
Смотрим, ставим лайки, задаем вопросы!
Upd.: Альтернатива на VK: https://m.vk.com/video-211773358_456239310
YouTube
Карта паттернов и технологий интеграции • Юрий Куприянов
Юрий Куприянов, эксперт школы Systems.Education, провёл вебинар, посвящённый Карте паттернов и технологий интеграций — уникальному инструменту ведущего, который поможет разобраться в сложном мире интеграционных технологий.
На вебинаре мы подробно разобрали…
На вебинаре мы подробно разобрали…
🔥34👍4
На канале Solvery поделился небольшой инструкцией по написанию документов требований с помощью ИИ.
В двух словах: не стоит ждать, что ИИ напишет сходу всё ТЗ или PRD. То есть, он конечно напишет, но результат может быть не совсем целостным. Поэтому нужно, во-первых, действовать последовательно — идти от верхнеуровнего описания или модели к деталям. Я начинаю с выявления ролей пользователей, основных юскейсов и контекстной диаграммы. Потом прошу выявить объекты и составить модель данных. А потом уже можно требования и интерфейсы описывать (всё — отдельными запросами).
Во-вторых, нужно проверить полноту документа через связи. Мы описываем одну систему с разных точек зрения, так ничего не должно "провисать" -- все части описания со всеми связаны. Это тоже может проверить ИИ.
В общем, смотрите карточки!
У ребят из Solvery на канале вообще интересный формат — многие эксперты делятся своим опытом. В основном про поиск работы и вход в ИТ — в разные профессии, не только в СА. Но есть и посты конкретно про аналитиков:
👉 прохождение собеса на аналитика в Т-банк
👉 подкаст про то, как джунам выжить на перегретом рынке IT
👉 и как упаковать профессиональный опыт, чтобы стартовать в системном анализе
В двух словах: не стоит ждать, что ИИ напишет сходу всё ТЗ или PRD. То есть, он конечно напишет, но результат может быть не совсем целостным. Поэтому нужно, во-первых, действовать последовательно — идти от верхнеуровнего описания или модели к деталям. Я начинаю с выявления ролей пользователей, основных юскейсов и контекстной диаграммы. Потом прошу выявить объекты и составить модель данных. А потом уже можно требования и интерфейсы описывать (всё — отдельными запросами).
Во-вторых, нужно проверить полноту документа через связи. Мы описываем одну систему с разных точек зрения, так ничего не должно "провисать" -- все части описания со всеми связаны. Это тоже может проверить ИИ.
В общем, смотрите карточки!
У ребят из Solvery на канале вообще интересный формат — многие эксперты делятся своим опытом. В основном про поиск работы и вход в ИТ — в разные профессии, не только в СА. Но есть и посты конкретно про аналитиков:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12🔥2❤1
Forwarded from Solvery | Айтишники о карьере, росте и провалах
Как джуну в системном анализе использовать ИИ и не спалиться? 🔵
Поделился Юрий Куприянов - независимый эксперт и консультант в области системного анализа и архитектуры, ведущий тренер школы Systems.Education, автор канала "Системный сдвиг", программный директор конференции Winter Analytical Weekend.
⏩ Он также первым в России использовал ИИ для работы системных аналитиков и рассказал об этом на Хабре :)
▶️ Продолжает развивать эту тему в своем канале, где публикует также полезные материалы для аналитиков по проектированию интеграций и разработке требований.
Подписывайтесь, если хотите узнавать больше
Поделился Юрий Куприянов - независимый эксперт и консультант в области системного анализа и архитектуры, ведущий тренер школы Systems.Education, автор канала "Системный сдвиг", программный директор конференции Winter Analytical Weekend.
Юрий больше 25 лет проектирует и создает программные системы в разных ролях — разработчика, аналитика, архитектора и продакта. Создавал системы для крупнейших банков и в области образования (EdTech).
Постоянный докладчик на конференциях по системному анализу, автор лучших докладов на Analyst Days, ЛАФ и Flow.
Подписывайтесь, если хотите узнавать больше
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16👍7❤2👎2
Второй по счету WAW — Зимний аналитический уикенд — прошел. Я, честно говоря, очень переживал — такую высокую планку с точки зрения атмосферы и нетворкинга задал первый WAW. Когда в любое время проходишь по лобби отеля, и видишь, что везде тут и там сидят группками люди и общаются — это кайф! 💖 То есть, в основном же все на докладах и мастер-классах, но всегда кто-то активно тусит в кулуарах — огонь! 🔥 Кажется, это то, чего хотят все организаторы всех конференций.
Опытные люди говорили мне после первого WAW — ну, это эффект новой конференции, первый раз обычно всегда хорошо проходит, а вы попробуйте повторить. Поэтому в этом году я особенно волновался — удастся ли нам повторить успех прошлого года? В первую очередь — сохранить эту атмосферу и вайб? Ну и набрать доклады с мастер-классами — достаточно глубокие, чтобы было интересно, и достаточно практические, чтобы можно было брать и делать? При том, что конференций по системному анализу становится всё больше, а вот спикеров сильно больше не становится.
И, знаете что? Кажется, всё получилось!😻 Так же до ночи сидели люди, что-то обсуждая, так же исписали весь флипчарт, установленный в фойе, так же тусили между и параллельно с докладами, перемешивались за обедом, танцевали на афтепати.
Ну и отзывы. Отзывы всегда приятно читать — значит, все нервы и споры в ПК, все горящие дедлайны и общение со спикерами (не всегда простое) — всё было не зря!
Теперь нужно в третий раз затащить, и это будет уже точно не случайность, а закономерность!
Опытные люди говорили мне после первого WAW — ну, это эффект новой конференции, первый раз обычно всегда хорошо проходит, а вы попробуйте повторить. Поэтому в этом году я особенно волновался — удастся ли нам повторить успех прошлого года? В первую очередь — сохранить эту атмосферу и вайб? Ну и набрать доклады с мастер-классами — достаточно глубокие, чтобы было интересно, и достаточно практические, чтобы можно было брать и делать? При том, что конференций по системному анализу становится всё больше, а вот спикеров сильно больше не становится.
И, знаете что? Кажется, всё получилось!
Ну и отзывы. Отзывы всегда приятно читать — значит, все нервы и споры в ПК, все горящие дедлайны и общение со спикерами (не всегда простое) — всё было не зря!
Теперь нужно в третий раз затащить, и это будет уже точно не случайность, а закономерность!
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤18🔥13👍2👏1
На WAW был очень жаркий круглый стол, "Стандарты в процессах разработки в эпоху ИИ".
Спорили прямо сильно. А я вспомнил старое эссе Джоела Спольски "5 миров". Он говорит, что в программировании есть 5 миров:
- продукты (он пишет shrinkwrap, "упакованные" — то есть, коробка с диском; это 2002 год, облачных сервисов ещё не было)
- внутренняя разработка
- встроенное ПО
- игры
- одноразовое ПО (скрипты и т.п.)
Статья, конечно, устарела, и сейчас у нас очень редко продаются продукты "в пленке", зато есть очень много онлайн-продуктов, которые не нужно устанавливать. Внутреннюю разработку можно разделить на заказную и разработку своими силами. Встроенное ПО получило возможность частых обновлений. Некоторые игры тоже стали выпускать в состоянии глубокой альфы, и это норм. "Одноразовые" скрипты стали частью пайплайнов DevSecOps, и не очень-то одноразовыми.
Джоел обращает внимание, что почти вся литература по организации разработки и системному анализу написана людьми из внутренней разработки — потому что только в этой области компании могут привлекать консультантов и экспертов, которые в основном и пишут книги.
Это же проявилось и у нас на круглом столе: кому-то важна стандартизация процессов, имея в виду предсказуемость оценок и сроков завершения проектов — это явно люди из заказной разработки, для них сроки===деньги в самом прямом смысле. Для внутренней разработки своими силами сроки, по моему опыту, не так уже важны. Только в редких случаях, когда это нужно к какому-то событию, но тогда и угадывать их команде не надо.
Я с такими проектами много работал: изменение нормативки, запуск новой внешней системы, софт для поддержки какого-то события. Для банка вариант не запустить интеграцию с новой платежной системой ЦБ в срок просто не рассматривается, даже не ставится этот вопрос.
С другой стороны, какие-то внутренние вещи для удобства вообще не имеют большого значения. Автоматизируем мы какой-то процесс в этом месяце или в следующем — в принципе, большой разницы нет. Даже год не всегда важен. Именно отсюда все данные про проекты с превышением сроков и бюджета, как будто это что-то плохое. И умные книги — как за долю времени на анализ улучшить прогноз времени на выполнение.
А вот в продуктах — за что топили другие участники дискуссии, и я в том числе — важно число экспериментов и, соответственно, TTM — время до предъявления фичи рынку. И вот тут аналитики вообще не нужны — нужна хорошо построенная архитектура и инфраструктура, которая позволяет быстро делать фичи без глубокой проработки, выкатывать на часть аудитории и смотреть на реакцию. Потом быстро обратно откатывать, если не пошло, ну или развивать дальше, если угадали. Всё, что замедляет релиз — убирать из процесса. Аналитиков в первую очередь. По последним веяниям тут даже продакт-оунеры лишние — в больших продуктовых компаниях команды без них работают.
И это нас приводит к тому, как мы смотрим на людей и каких людей набираем. На этот счет есть ещё из 60-х годов два разных подхода: Теория X и Теория Y — про то, кто такие люди вообще. Теория X говорит, что люди ленивы, не амбициозны, не любят свою работу, избегают ответственности и низкомотивированы. Соответственно, им нужны стандарты, регламенты, KPI, ручное управление и микроменеджмент. С точки зрения менеджера, таких людей лучше всего заменить ИИ.
Теория Y видит в людях высокомотивированных, креативных, инициативных, отвечающих за результат своей работы (taking ownership). С этой точки зрения их нужно усилить ИИ и максимально избавлять от рутинной бездумной деятельности.
Общий вывод: следите, про какой мир вы говорите — примеры про управление атомными реакторами и кардиостимуляторами относятся к встроенному ПО, а цели людей из заказной разработки и продуктовой (и даже внутренней) прямо противоположны. И какая у вас основная теория в отношении людей — X или Y?
Спорили прямо сильно. А я вспомнил старое эссе Джоела Спольски "5 миров". Он говорит, что в программировании есть 5 миров:
- продукты (он пишет shrinkwrap, "упакованные" — то есть, коробка с диском; это 2002 год, облачных сервисов ещё не было)
- внутренняя разработка
- встроенное ПО
- игры
- одноразовое ПО (скрипты и т.п.)
Статья, конечно, устарела, и сейчас у нас очень редко продаются продукты "в пленке", зато есть очень много онлайн-продуктов, которые не нужно устанавливать. Внутреннюю разработку можно разделить на заказную и разработку своими силами. Встроенное ПО получило возможность частых обновлений. Некоторые игры тоже стали выпускать в состоянии глубокой альфы, и это норм. "Одноразовые" скрипты стали частью пайплайнов DevSecOps, и не очень-то одноразовыми.
Джоел обращает внимание, что почти вся литература по организации разработки и системному анализу написана людьми из внутренней разработки — потому что только в этой области компании могут привлекать консультантов и экспертов, которые в основном и пишут книги.
Это же проявилось и у нас на круглом столе: кому-то важна стандартизация процессов, имея в виду предсказуемость оценок и сроков завершения проектов — это явно люди из заказной разработки, для них сроки===деньги в самом прямом смысле. Для внутренней разработки своими силами сроки, по моему опыту, не так уже важны. Только в редких случаях, когда это нужно к какому-то событию, но тогда и угадывать их команде не надо.
Я с такими проектами много работал: изменение нормативки, запуск новой внешней системы, софт для поддержки какого-то события. Для банка вариант не запустить интеграцию с новой платежной системой ЦБ в срок просто не рассматривается, даже не ставится этот вопрос.
С другой стороны, какие-то внутренние вещи для удобства вообще не имеют большого значения. Автоматизируем мы какой-то процесс в этом месяце или в следующем — в принципе, большой разницы нет. Даже год не всегда важен. Именно отсюда все данные про проекты с превышением сроков и бюджета, как будто это что-то плохое. И умные книги — как за долю времени на анализ улучшить прогноз времени на выполнение.
А вот в продуктах — за что топили другие участники дискуссии, и я в том числе — важно число экспериментов и, соответственно, TTM — время до предъявления фичи рынку. И вот тут аналитики вообще не нужны — нужна хорошо построенная архитектура и инфраструктура, которая позволяет быстро делать фичи без глубокой проработки, выкатывать на часть аудитории и смотреть на реакцию. Потом быстро обратно откатывать, если не пошло, ну или развивать дальше, если угадали. Всё, что замедляет релиз — убирать из процесса. Аналитиков в первую очередь. По последним веяниям тут даже продакт-оунеры лишние — в больших продуктовых компаниях команды без них работают.
И это нас приводит к тому, как мы смотрим на людей и каких людей набираем. На этот счет есть ещё из 60-х годов два разных подхода: Теория X и Теория Y — про то, кто такие люди вообще. Теория X говорит, что люди ленивы, не амбициозны, не любят свою работу, избегают ответственности и низкомотивированы. Соответственно, им нужны стандарты, регламенты, KPI, ручное управление и микроменеджмент. С точки зрения менеджера, таких людей лучше всего заменить ИИ.
Теория Y видит в людях высокомотивированных, креативных, инициативных, отвечающих за результат своей работы (taking ownership). С этой точки зрения их нужно усилить ИИ и максимально избавлять от рутинной бездумной деятельности.
Общий вывод: следите, про какой мир вы говорите — примеры про управление атомными реакторами и кардиостимуляторами относятся к встроенному ПО, а цели людей из заказной разработки и продуктовой (и даже внутренней) прямо противоположны. И какая у вас основная теория в отношении людей — X или Y?
🔥15❤9👍8🤔3🤯1