Планы на февраль и март. На повестке — два (или даже три) мощных мероприятия:
Во-первых, в этом году мы уже во второй раз проводим WAW — Winter Analytical Weekend (и я там опять председатель программного комитета). Темы конференции этого года — искусственный интеллект (и его практическое применение в системном и бизнес-анализе), люди — потому что не ИИ единым, всё-таки, пока мы работаем людьми и с людьми, и практики системного анализа — а как, собственно, работать лучше.
Мы хотим сделать это событие не просто конференцией, а скорее серией мастер-классов (хотя доклады тоже будут), а главное, как и в прошлом году — самой ламповой тусовкой для всех системных и бизнес-аналитиков, как это было на первых ЛАФ-ах.
В общем, если у вас есть время 22-23 февраля и вы можете приехать в Подмосковье — буду рад вас всех видеть! Ну и приходите в личку за промокодом (10%).
Во-вторых, 27 стартует первый в этом году очный тренинг по интеграции систем — "Интеграция систем. Разработка требований и основы проектирования". Если вы хотите за три дня интенсивно погрузиться в тему интеграций (и разобрать всё, что нарисовано на этом плакате и ещё примерно столько же) — приходите, будет круто и практично.
Ну а потом уже в марте (20-22) будет курс про разработку требований, там прокапываем основы, самую суть системного анализа.
Такие планы.
Во-первых, в этом году мы уже во второй раз проводим WAW — Winter Analytical Weekend (и я там опять председатель программного комитета). Темы конференции этого года — искусственный интеллект (и его практическое применение в системном и бизнес-анализе), люди — потому что не ИИ единым, всё-таки, пока мы работаем людьми и с людьми, и практики системного анализа — а как, собственно, работать лучше.
Мы хотим сделать это событие не просто конференцией, а скорее серией мастер-классов (хотя доклады тоже будут), а главное, как и в прошлом году — самой ламповой тусовкой для всех системных и бизнес-аналитиков, как это было на первых ЛАФ-ах.
В общем, если у вас есть время 22-23 февраля и вы можете приехать в Подмосковье — буду рад вас всех видеть! Ну и приходите в личку за промокодом (10%).
Во-вторых, 27 стартует первый в этом году очный тренинг по интеграции систем — "Интеграция систем. Разработка требований и основы проектирования". Если вы хотите за три дня интенсивно погрузиться в тему интеграций (и разобрать всё, что нарисовано на этом плакате и ещё примерно столько же) — приходите, будет круто и практично.
Ну а потом уже в марте (20-22) будет курс про разработку требований, там прокапываем основы, самую суть системного анализа.
Такие планы.
🔥12👍4❤2👎1
Про RPS и стоимость ресурсов.
В тренингах по проектированию интеграций и по составлению требований есть часть про расчет нагрузки и масштабирования. Очень часто это вызывает у участников затруднения, потому что нет наглядной картины, примера масштабов, о чём мы вообще говорим?
Я нашел у Gitlab хорошую табличку с разными вариантами нагрузки и разной стоимостью. (Gitlab — это сервер для системы управления версиями git, типа Github — но ваш персональный).
Итак, во-первых — какая нагрузка? RPS — requests per second, число запросов в секунду. У Gitlab она измерена эмпирически, на этапе требований можно предположить её из понимания частоты выполнения процессов. Минимальная конфигурация — 20 RPS, до 1000 пользователей. Считаются и автоматические вызовы, и пользовательские: 20 вызовов API/сек, 2 RPS через web, 2 git push, 2 git pull. Как можно посчитать — ну сколько программисты делают пуллов и пушей? Штук 20 макс.? Значит, 20000/8 (рабочих часов)/60 — где-то 40 в минуту получаем, с запасом, в пике (например, в конце рабочего дня, когда все побежали пушить изменения за день) — как раз можно рассчитывать на 120 в минут, или 2 RPS.
Впрочем, нас здесь интересует ограничение сверху, т.к. это минимальная конфигурация, которая может жить на одной виртуальной машине. Это, правда, довольно здоровенная машина: 8 vCPU, 16 GB memory, но всё-таки одна. То есть это — верхний предел вертикального масштабирования. Туда помещается все элементы архитектуры Gitlab — приложение на Ruby on Rails, Sidekiq — сервис для фоновых задач, Redis для кэширования, PostgreSQL, Gitaly — RPC сервис для выполнения команд git, и, собственно, локальное хранилище текстов программ.
Следующие конфигурации уже используют размещение всех компонент на отдельных машинах, этим объясняется резкий скачок стоимости. Ну и дальше наращивается просто количество единиц одинаковых компонент:
— при росте до 40RPS и 2000 пользователей — два экземпляра веб-приложения + балансировщик;
— при 60RPS и 3000 пользователях — три веб-приложения, два Sidekiq, три Redis, три Gitaly, кластер из трёх PostgreSQL. Соответственно, всё это требует обвзяки из внешних и внутренних балансировщиков, мониторинга и service discovery. На этом этапе также можно обеспечить High Availability, то есть вы можете заявлять доступность выше 99%. Можно оценить, во сколько это выражается в деньгах.
Дальнейший рост, который мы тоже иногда обсуждаем, выглядит линейным — в два раза растет нагрузка — примерно вдвое растут и расходы. на это примерно и стоит рассчитывать (кроме перехода от вертикального масштабирования к горизонтальному — там рост будет более резкий).
Поэтому, на практике, мы, как аналитики, должны сделать две вещи:
1. Выяснить — есть ли у нас потребность в горизонтальном масштабировании? Ищем пользователей больше 1000 или число запросов больше нескольких в секунду (не обязательно от пользователей, это могут быть и какие-то автоматические транзакции). Если таких чисел не видно — вам хватит одной машины.
2. Узнать — как бизнес (и система вслед за ним) собирается расти. При этом страшнее не планы бизнеса "привлечь 100500 новых клиентов", они обычно не сбываются; страшнее слова "мы хотим распространить этот сервис" — на всех клиентов, на все регионы, на другие операции и т.п., то есть туда, где эти пользователи или эти операции в таком объеме уже сейчас есть. Вот это можно включить в требования, чтобы архитекторы смогли заложить в архитектуру.
В тренингах по проектированию интеграций и по составлению требований есть часть про расчет нагрузки и масштабирования. Очень часто это вызывает у участников затруднения, потому что нет наглядной картины, примера масштабов, о чём мы вообще говорим?
Я нашел у Gitlab хорошую табличку с разными вариантами нагрузки и разной стоимостью. (Gitlab — это сервер для системы управления версиями git, типа Github — но ваш персональный).
Итак, во-первых — какая нагрузка? RPS — requests per second, число запросов в секунду. У Gitlab она измерена эмпирически, на этапе требований можно предположить её из понимания частоты выполнения процессов. Минимальная конфигурация — 20 RPS, до 1000 пользователей. Считаются и автоматические вызовы, и пользовательские: 20 вызовов API/сек, 2 RPS через web, 2 git push, 2 git pull. Как можно посчитать — ну сколько программисты делают пуллов и пушей? Штук 20 макс.? Значит, 20000/8 (рабочих часов)/60 — где-то 40 в минуту получаем, с запасом, в пике (например, в конце рабочего дня, когда все побежали пушить изменения за день) — как раз можно рассчитывать на 120 в минут, или 2 RPS.
Впрочем, нас здесь интересует ограничение сверху, т.к. это минимальная конфигурация, которая может жить на одной виртуальной машине. Это, правда, довольно здоровенная машина: 8 vCPU, 16 GB memory, но всё-таки одна. То есть это — верхний предел вертикального масштабирования. Туда помещается все элементы архитектуры Gitlab — приложение на Ruby on Rails, Sidekiq — сервис для фоновых задач, Redis для кэширования, PostgreSQL, Gitaly — RPC сервис для выполнения команд git, и, собственно, локальное хранилище текстов программ.
Следующие конфигурации уже используют размещение всех компонент на отдельных машинах, этим объясняется резкий скачок стоимости. Ну и дальше наращивается просто количество единиц одинаковых компонент:
— при росте до 40RPS и 2000 пользователей — два экземпляра веб-приложения + балансировщик;
— при 60RPS и 3000 пользователях — три веб-приложения, два Sidekiq, три Redis, три Gitaly, кластер из трёх PostgreSQL. Соответственно, всё это требует обвзяки из внешних и внутренних балансировщиков, мониторинга и service discovery. На этом этапе также можно обеспечить High Availability, то есть вы можете заявлять доступность выше 99%. Можно оценить, во сколько это выражается в деньгах.
Дальнейший рост, который мы тоже иногда обсуждаем, выглядит линейным — в два раза растет нагрузка — примерно вдвое растут и расходы. на это примерно и стоит рассчитывать (кроме перехода от вертикального масштабирования к горизонтальному — там рост будет более резкий).
Поэтому, на практике, мы, как аналитики, должны сделать две вещи:
1. Выяснить — есть ли у нас потребность в горизонтальном масштабировании? Ищем пользователей больше 1000 или число запросов больше нескольких в секунду (не обязательно от пользователей, это могут быть и какие-то автоматические транзакции). Если таких чисел не видно — вам хватит одной машины.
2. Узнать — как бизнес (и система вслед за ним) собирается расти. При этом страшнее не планы бизнеса "привлечь 100500 новых клиентов", они обычно не сбываются; страшнее слова "мы хотим распространить этот сервис" — на всех клиентов, на все регионы, на другие операции и т.п., то есть туда, где эти пользователи или эти операции в таком объеме уже сейчас есть. Вот это можно включить в требования, чтобы архитекторы смогли заложить в архитектуру.
👍21🔥3❤🔥1
Отличная картинка в начале рабочей недели — как архитектура выглядит на самом деле, и как в неё реально вмещается бизнес-логика.
Автор явно хорошо знает предмет и проблематику:
— от безопасности сразу отрезали треть — потому что с ней никакая бизнес-логика нормально не работает;
— зато на место безопасности приехали данные, и теперь они размазаны по системе;
— туда же въехал кусок UX, а весь UX повернули набок (чтобы не сказать "повертели");
— ну и API треснуло и готово развалиться, и стык с бизнес-логикой не очень-то гладкий (то же можно сказать и про стык данных и UX, там вообще рваное взаимодействие).
Ну и всё это не помогает, конечно же.
Автор явно хорошо знает предмет и проблематику:
— от безопасности сразу отрезали треть — потому что с ней никакая бизнес-логика нормально не работает;
— зато на место безопасности приехали данные, и теперь они размазаны по системе;
— туда же въехал кусок UX, а весь UX повернули набок (чтобы не сказать "повертели");
— ну и API треснуло и готово развалиться, и стык с бизнес-логикой не очень-то гладкий (то же можно сказать и про стык данных и UX, там вообще рваное взаимодействие).
Ну и всё это не помогает, конечно же.
🤣53💯14🔥10👍5❤1
Валидация в системном анализе.
Аналитик — сложная профессия, которая находится на пересечении многих умений. Нужно и про требования понимать, и про бизнес, и про архитектуру, и про технические вопросы, и про людей.
С таким разбросом тем нужно обязательно смотреть в смежные области, для которых этот объект является основным.
Например, психология. Мы обшаемся с людьми, и нам хорошо бы знать, как люди устроены. А часто бывает, что мы общаемся с людьми, испытывающими какие-то проблемы (обычно — рабочие, но бывает по-разному).
И вот в психологии есть понятие валидации. У нас оно тоже есть, это проверка соответствия системы (решает ли система изначальную проблему, приносит ли система ту ценность, для которой создавалась).
В психологии валидация — это про другое. Это про признание опыта другого человека как валидного, имеющего право на существование.
К сожалению, в процессе интервью и обсуждений я очень часто вижу, как одни люди отрицают опыт и ощущения других людей. Вы не можете так себя чувствовать, это с вами что-то не так! [а не с нашими процессами или системами]
Вы не можете так оценивать свой опыт или иметь такие суждения, потому что вы ошибаетесь! [потому что я считаю по-другому].
Обратите внимание — речь не про обсуждение ошибки, а про запрет думать то, что ты думаешь и чувствовать то, что чувствуешь.
Не надо так. У человека есть повод думать и чувствовать. Сначала дайте ему это чувствовать, провалидируйте, разрешите ему так думать и так считать. Признайте, что это нормально. Ошибки будете потом исправлять.
У психологов есть инструкции с несколькими шагами валидации, они могут быть полезны при интервью с заказчиками и пользователями:
1. Присутствие. Будьте здесь на 100%. Не в телефоне, не в блокноте с записями, не за экраном.
2. Отражение. Я могу понять и не осуждаю.
3. Догадка. Мне не все равно, я пытаюсь понять, что происходит.
4. Контекст. Я признаю, что действительно есть повод так думать или так действовать.
5. Нормализация. Это нормально (хотя я, возможно, не согласен, но не отрицаю, что такая позиция в принципе может быть).
6. Уважение. Я не смотрю сверху-вниз и помогаю, а не пинаю и критикую.
С этой базы уже можно начинать спокойное обсуждение правильности или ошибочности взглядов и формировать общую позицию / принимать решение, если требуется.
Кажется, если бы мы все старались следовать этим принципам — общение было бы гораздо более экологичным и безопасным.
Аналитик — сложная профессия, которая находится на пересечении многих умений. Нужно и про требования понимать, и про бизнес, и про архитектуру, и про технические вопросы, и про людей.
С таким разбросом тем нужно обязательно смотреть в смежные области, для которых этот объект является основным.
Например, психология. Мы обшаемся с людьми, и нам хорошо бы знать, как люди устроены. А часто бывает, что мы общаемся с людьми, испытывающими какие-то проблемы (обычно — рабочие, но бывает по-разному).
И вот в психологии есть понятие валидации. У нас оно тоже есть, это проверка соответствия системы (решает ли система изначальную проблему, приносит ли система ту ценность, для которой создавалась).
В психологии валидация — это про другое. Это про признание опыта другого человека как валидного, имеющего право на существование.
К сожалению, в процессе интервью и обсуждений я очень часто вижу, как одни люди отрицают опыт и ощущения других людей. Вы не можете так себя чувствовать, это с вами что-то не так! [а не с нашими процессами или системами]
Вы не можете так оценивать свой опыт или иметь такие суждения, потому что вы ошибаетесь! [потому что я считаю по-другому].
Обратите внимание — речь не про обсуждение ошибки, а про запрет думать то, что ты думаешь и чувствовать то, что чувствуешь.
Не надо так. У человека есть повод думать и чувствовать. Сначала дайте ему это чувствовать, провалидируйте, разрешите ему так думать и так считать. Признайте, что это нормально. Ошибки будете потом исправлять.
У психологов есть инструкции с несколькими шагами валидации, они могут быть полезны при интервью с заказчиками и пользователями:
1. Присутствие. Будьте здесь на 100%. Не в телефоне, не в блокноте с записями, не за экраном.
2. Отражение. Я могу понять и не осуждаю.
3. Догадка. Мне не все равно, я пытаюсь понять, что происходит.
4. Контекст. Я признаю, что действительно есть повод так думать или так действовать.
5. Нормализация. Это нормально (хотя я, возможно, не согласен, но не отрицаю, что такая позиция в принципе может быть).
6. Уважение. Я не смотрю сверху-вниз и помогаю, а не пинаю и критикую.
С этой базы уже можно начинать спокойное обсуждение правильности или ошибочности взглядов и формировать общую позицию / принимать решение, если требуется.
Кажется, если бы мы все старались следовать этим принципам — общение было бы гораздо более экологичным и безопасным.
❤33👍20🔥9💘3👎1
А вот это крутой ИИ-сервис! Пожалуй, он действительно может ускорить создание презентаций в разы.
Вот эти картинки про принципы REST я нагенерил минут за 10, причём вместе с текстом.
Что приятно — после генерации все картинки можно редактировать вручную, исправляя мелкие ошибки — это быстрее, чем "переубедить" модель.
Пожалуй, возьму себе в копилку инструментов. Сервис — https://www.napkin.ai/
Пока сервис в бете — всё доступно бесплатно, пользуемся!
Вот эти картинки про принципы REST я нагенерил минут за 10, причём вместе с текстом.
Что приятно — после генерации все картинки можно редактировать вручную, исправляя мелкие ошибки — это быстрее, чем "переубедить" модель.
Пожалуй, возьму себе в копилку инструментов. Сервис — https://www.napkin.ai/
Пока сервис в бете — всё доступно бесплатно, пользуемся!
👍37🔥29😎5❤2
Коллеги выложили запись интервью. На самом деле, мы потом ещё полчаса сидели не под запись. Нужно уже к форматам Дудя переходить: есть о чем поговорить на 3-4 часа 😂
Forwarded from NextWay - анализ и проектирование в IT
🎞Делимся записью карьерного диалога с Юрием Куприяновым.
С Юрой порассуждали о профессии системного аналитика:
▪️зачем нужны аналитики и как объяснить их необходимость руководству,
▪️как можно в себе развить системность и абстрактное мышление,
▪️как развитие ИИ влияет на ИТ и нашу профессию,
▪️почему аналитики хотят в архитекторы,
▪️в какие стороны можно еще посмотреть.
Очень хочется продолжить в формате дискуссии, а не интервью, т.к.вопросов осталось еще на пару-тройку встреч.
На встрече не спросили, но в чате Юра написал о 3-х книгах, которые на него повлияли:
✅Мифический человеко-месяц Брукса
✅Руководство по UI дизайну для программистов Спольски
✅Современные методы описания функциональных требований к системам Коберна про юзкейсы. Перевод названия неудачный, на самом деле она называется Writing Effective Use Cases
С Юрой порассуждали о профессии системного аналитика:
▪️зачем нужны аналитики и как объяснить их необходимость руководству,
▪️как можно в себе развить системность и абстрактное мышление,
▪️как развитие ИИ влияет на ИТ и нашу профессию,
▪️почему аналитики хотят в архитекторы,
▪️в какие стороны можно еще посмотреть.
Очень хочется продолжить в формате дискуссии, а не интервью, т.к.вопросов осталось еще на пару-тройку встреч.
На встрече не спросили, но в чате Юра написал о 3-х книгах, которые на него повлияли:
✅Мифический человеко-месяц Брукса
✅Руководство по UI дизайну для программистов Спольски
✅Современные методы описания функциональных требований к системам Коберна про юзкейсы. Перевод названия неудачный, на самом деле она называется Writing Effective Use Cases
YouTube
Кем мы станем, когда вырастем. Юрий Куприянов
С Юрой Куприяновым порассуждали о профессии системного аналитика:
▪️зачем нужны аналитики и как объяснить их необходимость руководству,
▪️как можно в себе развить системность и абстрактное мышление,
▪️как развитие ИИ влияет на ИТ и нашу профессию,
▪️почему…
▪️зачем нужны аналитики и как объяснить их необходимость руководству,
▪️как можно в себе развить системность и абстрактное мышление,
▪️как развитие ИИ влияет на ИТ и нашу профессию,
▪️почему…
❤17👍9🔥2
Когда появились первые таблицы?
Мы, как аналитики, сталкиваемся с таблицами в двух случаях:
— когда залезаем в базу данных или в выгрузку из неё, и пытаемся что-то понять из этих данных;
— когда пытаемся структурировать какую-то информацию для требований.
На всех тренингах и в личных консультациях я рано или поздно советую преобразовать информацию в таблицу. Скорее рано, это частая ошибка — не использовать таблицы.
Типичный вопрос, с которым ко мне приходят — как сделать документы лучше. Ну вот вроде бы пишу требования и постановки, но что-то не то. Что можно улучшить?
Один из советов — используйте таблицы! Неопытные аналитики начинают с текста. Получается длинный и не всегда хорошо структурированный текст. Текстом вообще мыслить сложно, и структурировать сплошной текст сложно.
Лучше поменять форму:
— список всегда лучше, чем сплошной текст (в технических текстах);
— таблица ещё лучше.
Чтобы построить таблицу, вам нужно задать её структуру. А для этого её нужно продумать.
И таблица даёт преимущество, которое не даёт текст и список — показывает пропущенные места. Таблица Менделеева хороша не тем, что выстроила элементы в каком-то порядке, а тем, что предсказала несколько неоткрытых!
Когда появились первые таблицы? Вот на картинке таблица из окрестностей Вавилона, 1900-1600 г. до н.э. Клинопись по глине.
Скорее всего, это список выплат за какие-то работы. Тут уже есть столбцы с названиями, строки, в одном из столбцов — сумма двух других, в другом столбцы перемножены, под таблицей есть итоги. Практически, глиняный Эксель!
Хранится в Британском музее, https://cdli.mpiwg-berlin.mpg.de/search?layout=full&id=P368686
Мы, как аналитики, сталкиваемся с таблицами в двух случаях:
— когда залезаем в базу данных или в выгрузку из неё, и пытаемся что-то понять из этих данных;
— когда пытаемся структурировать какую-то информацию для требований.
На всех тренингах и в личных консультациях я рано или поздно советую преобразовать информацию в таблицу. Скорее рано, это частая ошибка — не использовать таблицы.
Типичный вопрос, с которым ко мне приходят — как сделать документы лучше. Ну вот вроде бы пишу требования и постановки, но что-то не то. Что можно улучшить?
Один из советов — используйте таблицы! Неопытные аналитики начинают с текста. Получается длинный и не всегда хорошо структурированный текст. Текстом вообще мыслить сложно, и структурировать сплошной текст сложно.
Лучше поменять форму:
— список всегда лучше, чем сплошной текст (в технических текстах);
— таблица ещё лучше.
Чтобы построить таблицу, вам нужно задать её структуру. А для этого её нужно продумать.
И таблица даёт преимущество, которое не даёт текст и список — показывает пропущенные места. Таблица Менделеева хороша не тем, что выстроила элементы в каком-то порядке, а тем, что предсказала несколько неоткрытых!
Когда появились первые таблицы? Вот на картинке таблица из окрестностей Вавилона, 1900-1600 г. до н.э. Клинопись по глине.
Скорее всего, это список выплат за какие-то работы. Тут уже есть столбцы с названиями, строки, в одном из столбцов — сумма двух других, в другом столбцы перемножены, под таблицей есть итоги. Практически, глиняный Эксель!
Хранится в Британском музее, https://cdli.mpiwg-berlin.mpg.de/search?layout=full&id=P368686
🔥25👍11🤨2
В четверг расскажу, как появилась идея карты технологий интеграции, как шёл процесс её создания, какие сложности и что ещё нужно знать в области интеграций, но в карту не вошло.
Приходите, готовьте свои вопросы!
Приходите, готовьте свои вопросы!
Telegram
Системный сдвиг
В канун Нового года держите подарочек от меня: всё, что вы хотели знать про разные способы интеграций, в одной (большой) картинке.
Тут в основном только перечисления названий протоколов и технологий, но зато даёт общую картину. Это ещё круче, чем в предыдущем…
Тут в основном только перечисления названий протоколов и технологий, но зато даёт общую картину. Это ещё круче, чем в предыдущем…
10🔥15👍7
Forwarded from Systems.Education: Системный Анализ и Проектирование информационных систем: архитектура, интеграции, базы данных
systems.education
Вебинар: Карта паттернов и технологий интеграции
Подробнее →
Карта паттернов и технологий интеграции
в этот четверг, 20 февраля в 18 вечера мск приглашаем вас на вебинар, посвящённый Карте паттернов и технологий интеграций — уникальному инструменту от Юрия Куприянова, который поможет разобраться в сложном мире интеграционных технологий.
На вебинаре мы подробно разберём, как устроена карта, как её применять на практике и как она может помочь в обучении, выборе технологий и решении бизнес-задач.
План вебинара:
Как появилась идея карты
Этапы создания карты
Как устроена карта
Как применять карту на практике
Развитие карты
Ответы на вопросы
Кому будет полезен вебинар:
— Системным аналитикам и архитекторам, которые хотят лучше разобраться в интеграционных технологиях.
— Разработчикам, которые сталкиваются с выбором инструментов и протоколов для интеграции.
— Руководителям продуктов, Тимлидам, которым важно понимать, какие технологии использовать для решения бизнес-задач.
— Студентам и начинающим специалистам, которые хотят систематизировать свои знания в области интеграций.
Регистрация
NB: Следите за анонсами вебинаров и обсуждайте их с коллегами в группе @SE_Webinars
#вебинары #интеграция
в этот четверг, 20 февраля в 18 вечера мск приглашаем вас на вебинар, посвящённый Карте паттернов и технологий интеграций — уникальному инструменту от Юрия Куприянова, который поможет разобраться в сложном мире интеграционных технологий.
На вебинаре мы подробно разберём, как устроена карта, как её применять на практике и как она может помочь в обучении, выборе технологий и решении бизнес-задач.
План вебинара:
Как появилась идея карты
Этапы создания карты
Как устроена карта
Как применять карту на практике
Развитие карты
Ответы на вопросы
Кому будет полезен вебинар:
— Системным аналитикам и архитекторам, которые хотят лучше разобраться в интеграционных технологиях.
— Разработчикам, которые сталкиваются с выбором инструментов и протоколов для интеграции.
— Руководителям продуктов, Тимлидам, которым важно понимать, какие технологии использовать для решения бизнес-задач.
— Студентам и начинающим специалистам, которые хотят систематизировать свои знания в области интеграций.
Регистрация
NB: Следите за анонсами вебинаров и обсуждайте их с коллегами в группе @SE_Webinars
#вебинары #интеграция
🔥7👍2❤1
К сегодняшнему вебинару поискал разные классификации интеграций. По статьям в интернете. И знаете что? Китайская классификация животных из рассказа Борхеса просто отдыхает.
Вот смотрите. Итак, интеграции бывают:
- горизонтальные
- вертикальные
- гибридные
- точечные
- в форме звезды
- через шину 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