Системный сдвиг

Вчера на вебинаре показывал промежуточные версии карты технологий интеграций, и внезапно одна из версий, которую я забраковал, вызвала интерес. Так что опубликую её тоже. Здесь не так явно видна связь элементов друг с другом, только по расположению, зато видны направления дальнейшего возможного развития: — от ETL идём в хранилища данных и BI — от gRPC через HTTP/2 можно проложить путь к рассмотрению низкоуровневых протоколов (нужно ли аналитикам знать, чем друг от друга отличаются HTTP /1.0, /1.1, /2 и /3 ?) — от транзакционной целостности можно дойти до паттерна Saga и микросервисов, а оттуда уже к рассмотрению архитектуры распределенных систем — а от OpenAPI и смежных нотаций дальше идём к вопросам управления API У карты четыре "центра кристаллизации" — всё те же стили из книги "Паттерны интеграций корпоративных приложений": обмен файлами, общая БД, удаленный вызов и обмен сообщениями. Вокруг группируются связанные технологии. А ещё эта карта похожа на карту местности в какой-то стратегической игре — закрепились в одной части, построили укрепления, пошли разведывать новые области :) Надо будет туман по краям дорисовать, для антуражности. Я показал эту версию ограниченному кругу, её очень ругали — мол, непонятная. Но на вебинаре она людям понравилась. Так что опубликую её тоже, а вы напишите в комментах — какую версию вы считаете более понятной и полезной.

К сегодняшнему вебинару поискал разные классификации интеграций. По статьям в интернете. И знаете что? Китайская классификация животных из рассказа Борхеса просто отдыхает. Вот смотрите. Итак, интеграции бывают: - горизонтальные - вертикальные - гибридные - точечные - в форме звезды - через шину ESB - оркеструющие процессы - событийно-ориентированные - REST - SOAP - GraphQL - интеграции платформ - интеграции данных - интеграции приложений - интеграции бизнес-процессов - облачные - через брокер - ориентированные на сообщения - через API - MQTT - gRPC - интеграции легаси-систем - через передачу файлов - в форме обмена электронными документами - высоконагруженные - вебхуки Так и хочется дописать "бесчисленные", "бегающие как сумасшедшие" и "похожие издали на мух". Вообще вопрос классификаций сложный, и мало кто умеет их нормально составлять (и мало где в природе они в чистом виде присутствуют - в биологии, например, насколько я понимаю, с классификацией есть сложности). А одна из лучших книг про классификации - "Морфология волшебной сказки" Проппа. Это вообще отличная книга по системному анализу (ну, с поправкой, что это всё же 1928 год!). В волшебной сказке Пропп выделяет следующие элементы и аспекты: - функции - действующие лица - распределение функций по действующим лицам - атрибуты действующих лиц (речь идёт в основном об объектах и их свойствах) - ходы (применение функций) и их сочетания (последовательность и наложение ходов, отвлечения и возвраты) Видите что-то знакомое? Натуральный системный анализ! 😂 Ну а с классификациями интеграций попробуем разобраться сегодня на вебинаре.

Карта паттернов и технологий интеграции в этот четверг, 20 февраля в 18 вечера мск приглашаем вас на вебинар, посвящённый Карте паттернов и технологий интеграций — уникальному инструменту от Юрия Куприянова, который поможет разобраться в сложном мире интеграционных технологий. На вебинаре мы подробно разберём, как устроена карта, как её применять на практике и как она может помочь в обучении, выборе технологий и решении бизнес-задач. План вебинара: Как появилась идея карты Этапы создания карты Как устроена карта Как применять карту на практике Развитие карты Ответы на вопросы Кому будет полезен вебинар: — Системным аналитикам и архитекторам, которые хотят лучше разобраться в интеграционных технологиях. — Разработчикам, которые сталкиваются с выбором инструментов и протоколов для интеграции. — Руководителям продуктов, Тимлидам, которым важно понимать, какие технологии использовать для решения бизнес-задач. — Студентам и начинающим специалистам, которые хотят систематизировать свои знания в области интеграций. Регистрация NB: Следите за анонсами вебинаров и обсуждайте их с коллегами в группе @SE_Webinars #вебинары#интеграция

В четверг расскажу, как появилась идея карты технологий интеграции, как шёл процесс её создания, какие сложности и что ещё нужно знать в области интеграций, но в карту не вошло. Приходите, готовьте свои вопросы!

Когда появились первые таблицы? Мы, как аналитики, сталкиваемся с таблицами в двух случаях: — когда залезаем в базу данных или в выгрузку из неё, и пытаемся что-то понять из этих данных; — когда пытаемся структурировать какую-то информацию для требований. На всех тренингах и в личных консультациях я рано или поздно советую преобразовать информацию в таблицу. Скорее рано, это частая ошибка — не использовать таблицы. Типичный вопрос, с которым ко мне приходят — как сделать документы лучше. Ну вот вроде бы пишу требования и постановки, но что-то не то. Что можно улучшить? Один из советов — используйте таблицы! Неопытные аналитики начинают с текста. Получается длинный и не всегда хорошо структурированный текст. Текстом вообще мыслить сложно, и структурировать сплошной текст сложно. Лучше поменять форму: — список всегда лучше, чем сплошной текст (в технических текстах); — таблица ещё лучше. Чтобы построить таблицу, вам нужно задать её структуру. А для этого её нужно продумать. И таблица даёт преимущество, которое не даёт текст и список — показывает пропущенные места. Таблица Менделеева хороша не тем, что выстроила элементы в каком-то порядке, а тем, что предсказала несколько неоткрытых! Когда появились первые таблицы? Вот на картинке таблица из окрестностей Вавилона, 1900-1600 г. до н.э. Клинопись по глине. Скорее всего, это список выплат за какие-то работы. Тут уже есть столбцы с названиями, строки, в одном из столбцов — сумма двух других, в другом столбцы перемножены, под таблицей есть итоги. Практически, глиняный Эксель! Хранится в Британском музее, https://cdli.mpiwg-berlin.mpg.de/search?layout=full&id=P368686

🎞Делимся записью карьерного диалога с Юрием Куприяновым. С Юрой порассуждали о профессии системного аналитика: ▪️зачем нужны аналитики и как объяснить их необходимость руководству, ▪️как можно в себе развить системность и абстрактное мышление, ▪️как развитие ИИ влияет на ИТ и нашу профессию, ▪️почему аналитики хотят в архитекторы, ▪️в какие стороны можно еще посмотреть. Очень хочется продолжить в формате дискуссии, а не интервью, т.к.вопросов осталось еще на пару-тройку встреч. На встрече не спросили, но в чате Юра написал о 3-х книгах, которые на него повлияли: ✅Мифический человеко-месяц Брукса ✅Руководство по UI дизайну для программистов Спольски ✅Современные методы описания функциональных требований к системам Коберна про юзкейсы. Перевод названия неудачный, на самом деле она называется Writing Effective Use Cases

Коллеги выложили запись интервью. На самом деле, мы потом ещё полчаса сидели не под запись. Нужно уже к форматам Дудя переходить: есть о чем поговорить на 3-4 часа 😂

А вот это крутой ИИ-сервис! Пожалуй, он действительно может ускорить создание презентаций в разы. Вот эти картинки про принципы REST я нагенерил минут за 10, причём вместе с текстом. Что приятно — после генерации все картинки можно редактировать вручную, исправляя мелкие ошибки — это быстрее, чем "переубедить" модель. Пожалуй, возьму себе в копилку инструментов. Сервис — https://www.napkin.ai/ Пока сервис в бете — всё доступно бесплатно, пользуемся!

Валидация в системном анализе. Аналитик — сложная профессия, которая находится на пересечении многих умений. Нужно и про требования понимать, и про бизнес, и про архитектуру, и про технические вопросы, и про людей. С таким разбросом тем нужно обязательно смотреть в смежные области, для которых этот объект является основным. Например, психология. Мы обшаемся с людьми, и нам хорошо бы знать, как люди устроены. А часто бывает, что мы общаемся с людьми, испытывающими какие-то проблемы (обычно — рабочие, но бывает по-разному). И вот в психологии есть понятие валидации. У нас оно тоже есть, это проверка соответствия системы (решает ли система изначальную проблему, приносит ли система ту ценность, для которой создавалась). В психологии валидация — это про другое. Это про признание опыта другого человека как валидного, имеющего право на существование. К сожалению, в процессе интервью и обсуждений я очень часто вижу, как одни люди отрицают опыт и ощущения других людей. Вы не можете так себя чувствовать, это с вами что-то не так! [а не с нашими процессами или системами] Вы не можете так оценивать свой опыт или иметь такие суждения, потому что вы ошибаетесь! [потому что я считаю по-другому]. Обратите внимание — речь не про обсуждение ошибки, а про запрет думать то, что ты думаешь и чувствовать то, что чувствуешь. Не надо так. У человека есть повод думать и чувствовать. Сначала дайте ему это чувствовать, провалидируйте, разрешите ему так думать и так считать. Признайте, что это нормально. Ошибки будете потом исправлять. У психологов есть инструкции с несколькими шагами валидации, они могут быть полезны при интервью с заказчиками и пользователями: 1. Присутствие. Будьте здесь на 100%. Не в телефоне, не в блокноте с записями, не за экраном. 2. Отражение. Я могу понять и не осуждаю. 3. Догадка. Мне не все равно, я пытаюсь понять, что происходит. 4. Контекст. Я признаю, что действительно есть повод так думать или так действовать. 5. Нормализация. Это нормально (хотя я, возможно, не согласен, но не отрицаю, что такая позиция в принципе может быть). 6. Уважение. Я не смотрю сверху-вниз и помогаю, а не пинаю и критикую. С этой базы уже можно начинать спокойное обсуждение правильности или ошибочности взглядов и формировать общую позицию / принимать решение, если требуется. Кажется, если бы мы все старались следовать этим принципам — общение было бы гораздо более экологичным и безопасным.

Отличная картинка в начале рабочей недели — как архитектура выглядит на самом деле, и как в неё реально вмещается бизнес-логика. Автор явно хорошо знает предмет и проблематику: — от безопасности сразу отрезали треть — потому что с ней никакая бизнес-логика нормально не работает; — зато на место безопасности приехали данные, и теперь они размазаны по системе; — туда же въехал кусок UX, а весь UX повернули набок (чтобы не сказать "повертели"); — ну и API треснуло и готово развалиться, и стык с бизнес-логикой не очень-то гладкий (то же можно сказать и про стык данных и UX, там вообще рваное взаимодействие). Ну и всё это не помогает, конечно же.

Про 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 новых клиентов", они обычно не сбываются; страшнее слова "мы хотим распространить этот сервис" — на всех клиентов, на все регионы, на другие операции и т.п., то есть туда, где эти пользователи или эти операции в таком объеме уже сейчас есть. Вот это можно включить в требования, чтобы архитекторы смогли заложить в архитектуру.

Планы на февраль и март. На повестке — два (или даже три) мощных мероприятия: Во-первых, в этом году мы уже во второй раз проводим WAW — Winter Analytical Weekend (и я там опять председатель программного комитета). Темы конференции этого года — искусственный интеллект (и его практическое применение в системном и бизнес-анализе), люди — потому что не ИИ единым, всё-таки, пока мы работаем людьми и с людьми, и практики системного анализа — а как, собственно, работать лучше. Мы хотим сделать это событие не просто конференцией, а скорее серией мастер-классов (хотя доклады тоже будут), а главное, как и в прошлом году — самой ламповой тусовкой для всех системных и бизнес-аналитиков, как это было на первых ЛАФ-ах. В общем, если у вас есть время 22-23 февраля и вы можете приехать в Подмосковье — буду рад вас всех видеть! Ну и приходите в личку за промокодом (10%). Во-вторых, 27 стартует первый в этом году очный тренинг по интеграции систем — "Интеграция систем. Разработка требований и основы проектирования". Если вы хотите за три дня интенсивно погрузиться в тему интеграций (и разобрать всё, что нарисовано на этом плакате и ещё примерно столько же) — приходите, будет круто и практично. Ну а потом уже в марте (20-22) будет курс про разработку требований, там прокапываем основы, самую суть системного анализа. Такие планы.