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

С наступившим Новым годом! Всем профессиональных успехов и развития в новом году! Ну а я буду стараться докидывать вам авторского видения нашей отрасли, её задач и проблем, а также интересных материалов. Вот, например, руководства по стилю REST API. Как мы все знаем, REST -- это просто набор архитектурных принципов, но, когда доходит дело проектирования конкретных API, возникает множество мелких вопросов. Иногда совсем мелких: какой регистр использовать для названий полей в json? А в названиях эндпоинтов? А имена ресурсов писать во множественном числе или в единственном? Такие вопросы хорошо бы закрепить на уровне всей компании, чтобы не думать каждый раз заново. Образцы таких гайдлайнов, как ни странно, можно найти у правительств разных стран. Они есть у Австралии, Новой Зеландии, Канады, Великобритании, у США конечно. Но мне больше всего нравится бельгийский гайдлайн: https://www.belgif.be/specification/rest/api-guide . Он и устроен наиболее логично, и как-то по-человечески, что ли. И при этом учитывает разнообразные аспекты, о которых и вправду стоит подумать. В частности, в нём есть: 👉🏻 формат для URI эндпоинтов: рекомендуется lowerCamelCase, без расширений файлов; 👉🏻 три типа ресурсов: документ, коллекция и контроллер. Документ — единичная сущность, с которой можно делать CRUD, у неё есть id, URI и поля; Коллекция — набор однотипных сущностей, с которыми можно делать только GET и POST, и в редких случаях DELETE - если мы хотим удалить все элементы сразу; документы обычно лежат в коллекциях, и могут содержать подчиненные коллекции: /{имя коллекции}/{id документа}/{имя подчиненной коллекции}/{id подчиненного документа}. Ну а контроллер — это подчиненный ресурс документа, представляющий бизнес-операцию, не укладывающуюся в CRUD (примеры: POST /accounts/123/withdraw, GET /convertMoney?from=EUR&amount=45&to=USD). При этом для долгих операций рекомендуется создавать ресурс типа документ, и уметь возвращать промежуточный статус операции (превращая её, таким образом, в асинхронную). 👉🏻 спецификация дополнительных операций: для документов — ?select={(поле,(поле,поле))}, чтобы выбирать только указанные поля — убираем overfetching; для коллекций — сортировка: ?sort={поля для сортировки} , пагинация: ?page, ?next, ?prev, ?pageSize= , полнотекстовый поиск: ?q={поисковый запрос}, фильтрация: ?{поле}={значение}. 👉🏻 механизм для встраивания ресурсов (возможности GraphQL в REST!): ?embed={название связанной сущности, которую мы хотим встроить в ответ}, убираем underfetching. 👉🏻 требования к идентификаторам документов: рекомендуется текст, URI или UUID, а вообще там множество нюансов: идентификатор должен хорошо запоминаться, легко вводиться, легко проверяться, распечатываться, подсказывать природу объекта (по структуре идентификатора), предупреждать коллизии, не содержать чувствительной информации, не быть легким для подбора (если идентификаторы выдаются последовательно - легко угадать предыдущие и последующие, и даже вычислить, например, количество сущностей), использоваться в разных системах, быть расширяемым, вставляться в URL, логичным образом сортироваться... То есть вообще непонятно, бывают ли идентификаторы, удовлетворяющие всем требованиям! 👉🏻 рекомендации по использованию кодов ошибок; 👉🏻 соглашение об использовании значений null в json (решение: не должны использоваться, чтобы не создавать неоднозначности; если значение null, то оно не передаётся. При этом [] — это не null!) 👉🏻 кэширование (по времени и по содержимому, управление через параметры заголовка: 👉🏻 эволюция и версионирование API (обсуждаются совместимые и несовместимые изменения) 👉🏻 интернационализация (фильтрация языка через ?lang={код языка}) 👉🏻 отслеживание (Trace-Id в заголовках) 👉🏻 статус API (ресурс health) В общем, рекомендую и для справки и тренировки насмотренности — всё-таки, тут зафиксировано решение многих вопросов, с которыми авторы сталкивались в реальной жизни, и для использования в качестве шаблона, если у себя в компании соберетесь вводить единые гайдлайны.

Всех с наступающим Новым годом! Счастья в новом году, профессиональных успехов и мирного неба! 🔥🎄🥂

Персональный подарочек под ёлочку! 🎄 Теперь я ещё и "соавтор книги" 🤵‍♂ На самом деле, рад иметь общий труд вместе с людьми, которых считаю своими учителями — в университете и в профессии. Всех с наступающим! 🎄

Продолжают публиковать записи моих выступлений. В основном про ChatGPT, много про него говорил в этом году. Вот это — с Инфостарта, точнее с их спин-оффа "Анализ & управление в ИТ-проектах". Видео: https://www.youtube.com/watch?v=qG0Hx3LeMlc В виде текста: https://infostart.ru/pm/2004555/ Новости, конечно, в этой области устаревают стремительно. Всё уже поменялось с весны — теперь есть GPT4-turbo, в которой: 📆 данные о мире актуальны на апрель 2023, 📝окно контекста может быть до 128Кб (это прямо много!) 💻есть возможность получить ответ, структурированный в виде json 🤖есть возможность воспроизводить строго одинаковый ответ для идентичных запросов ⚒есть возможность вызывать кастомные функции (запросы к внешним API, БД) и формировать ответ на основе их результата 🖼на вход можно подать изображение, и задать по нему вопросы (уже писал об этом тут на примере документирования интерфейсов, но так же можно и схемы в виде картинок разбирать -- например, попросить описание процесса и инструкции для участников по его модели-картинке). Я уже не говорю о прогрессе альтернативных моделей, за ними пока просто не успеваю следить. Пишите, если знаете ещё хорошие новости.

Про Винcтона Ройса, Agile и разработку программного обеспечения. На заре индустрии разработки программного обеспечения был хороший доклад Винстона Ройса (Winston Royce 1970) про то, как БЫСТРЕЕ выводить программный продукт в эксплуатацию. Так, как основная проблема отрасли это... ОШИБКИ! Ключевая мысль доклада: Пиши БОЛЬШЕ документов, чтобы БЫСТРЕЕ выводить программный продукт в эксплуатацию. И тут стоит понимать, что в 1970 году, время от Идеи до осязаемого Результата - минимум 1 неделя, просто потому что технологии такие. И тут на курсе (который сейчас провожу), при разборе применения Теории Ограничений коллеги заметили что, на самом деле Ройс решал проблему ЗАЩИТЫ ОГРАНИЧЕНИЯ! То есть: Пиши много документов для того, чтобы..... ЗАЩИТИТЬ ОГРАНИЧЕНИЕ! Где Ограничение - машинное время ЭВМ. Другими словами, это шаг "три" из пяти фокусирующих шагов ТОС. Отсюда вывод: Если у вас разработчики - это Ограничение, то им нужны Аналитики и Архитекторы, как "цех заготовки". Чтобы разработчики делали то, что нужно сделать и не делали то, что не нужно делать. И была "полная комплектация" перед началом работы по задаче. #ответы_на_вопросы#TOC

А вот ещё интересный взгляд на роль аналитика (и архитектора) с точки зрения Теории ограничений (TOC) Голдратта. Если у вас разработка является ограничением, логично перед ней ставить звено предобработки, чтобы на вход подавать не сырье, а заготовку. (Помним, что Голдратт в основном анализировал материальные производства). Как вам кажется, похоже это на работу аналитика? Не постановка задачи, а предобработка, подготовка материала для работы, создание заготовок. Если с этой точки зрения посмотреть на процесс, можно уточнить у разработки — что именно им полезно в качестве заготовки, а что не нужно (заготовка не должна быть излишне тщательной).

СМИ и блогеры тиражируют исследование Head Hunter'а — хотя первоисточник не находится почему-то — по профессиям специалистов с самой большой средней зарплатой. И там на первом месте Devops (214 тыс.) , на втором — дата саентисты (202), а вот на третьем — системные аналитики (150). С чем всех коллег и поздравляю! Понятно, что это средние зарплаты по стране, и за неимением первоисточника трудно сказать — какой там разброс и кто утянул на дно разработчиков, и куда вообще подевались архитекторы, которым раньше меньше 240 не предлагали. Но в целом вы теперь знаете, на что в среднем ориентироваться.

В крупных организациях, опять же, по моему опыту (он достаточно обширный) системный аналитик занимается тремя основными вещами: 1. Проводит сбор требований со стейкхолдеров 2. Пытается определить в каких ИС и какие изменения необходимо реализовать (это следствие бесконечно огромных протечек моделей предметных областей друг в друга, высокой привнесенной сложности) 3. Фиксирует требования и какие ИС затрагиваются в документах

Интересная мысль про необходимость роли системного аналитика из-за протечек абстракций (а точнее — ещё и из-за слабой изоляции контекстов). То есть, у нас обычно системы так реализованы, что у них контексты сильно пересекаются — от этого сразу не ясно, в какой системе делать изменения. Нет чёткого понимания, за что каждая система отвечает, а за что нет. Одновременно в системах ещё и слои абстракций дырявые: представление данных для пользователя не отделено от способов хранения данных, а логика вообще размазана по всем слоям. Тут-то конечно, для каждого изменения нужно разобраться — что где лежит, что где отображается и что где проверяется и преобразуется. И куда новые функции воткнуть, чтобы ничего не сломать. Продолжая тему игр — это Дженга наоборот получается: как напихать в систему ещё функций, пока она не совсем не развалится. Причем в N-мерном пространстве. Собственно, задачи по интеграции почти все такие — понять, в какой из N систем должна быть новая функция, найти K систем, из которых нужно данные взять и в которые отправить, и решить — кто именно будет брать, что брать, куда отправлять, кто за всем этим будет следить + всё это ещё и во времени. Ergo, если мы имеем чистую архитектуру, low coupling high cohesion, да ещё и единый язык бизнеса и разработки, то системные аналитики становятся ненужными. Хм, кажется, я только что сформулировал основные принципы DDD. Аналитики! Сопротивляйтесь внедрению в своих компаниях DDD! Запутывайте архитектуру! Ломайте станки! Храните документацию в Ворде!

Практически на каждом Летнем аналитическом фестивале умудрённые опытом аналитики жаловалась, что для них мало докладов, а всё в основном для начинающих и миддлов. И вот, наконец, организаторы решили сделать отдельное событие для опытных системных аналитиков! Причём зимой. Меня пригласили в качестве председателя программного комитета, что очень лестно. Я ещё помню, как 10 лет назад выступал на ЛАФ, и это было чуть ли не первое выступление моё на отраслевой конференции вообще. Но для опытных в системном анализе людей мы не хотим делать просто конференцию, "чтобы послушать" — мы хотим вместе поговорить про саму нашу отрасль, и выпустить в итоге некоторый манифест или совместное видение того, где мы находимся и куда движемся. 🎙 Итак, идея Зимних аналитических выходных 2024 — настоящее и будущее индустрии системного анализа. Кроме традиционных докладов и мастер-классов мы запланировали сессии совместного выявления основных трендов и требований к самим задачам системного анализа, к людям, которые работают в этой сфере, и к подразделениям, выполняющим эту роль в компании. В течение 2 дней на площадках мероприятия пройдет более 20 докладов, мастер-классов, круглых столов и деловых игр от топовых экспертов, основателей сообществ аналитиков, авторов профессиональных стандартов и карт компетенций, руководителей направлений СА. 📆 Даты: 17-18 февраля 2024 года. 🏨 По традиции ЛАФ, это загородный отель, проживание по системе "все включено", зимние развлечения, бассейн, скалодром и всё такое. И afterparty с музыкой и общением 🎉. Мы уже собрали звездный пул спикеров, но программа ещё будет пополняться. Регистрация уже открыта: участвуйте в самом ярком аналитическом событии зимы!🚀❄️

Придумал игру "Снежинки среди нас": новогодняя ИТ-мафия. Позволяет и развлечься, и прокачать софт-скиллы, и украсить офис к Новому году. Правила как в Мафии, только роли такие: — Скрам-мастер — ведущий. В игре не участвует, но следит за ритуалами. — Заказчики. Их несколько, никто не знает, кто они, но каждую ночь они просыпаются и подбрасывают в бэклог новые таски, и могут, на выбор — либо забраковать произвольное число готовых задач ("не прошли приемку"), или потребовать снять кого-нибудь с проекта. Таски выбираются из отдельной колоды с идеями по украшению офиса: вырезать снежинку, раскрасить гномика, сделать гирлянду и т.п. За одну ночь можно подкинуть в бэклог столько тасок, сколько осталось игроков. В начале игры бэклог наполняется тасками по числу игроков x2. — Команда. Ночью спят, днём выполняют таски из бэклога. Заодно обсуждают, как вообще успеть сделать всё, что навалили, и кого можно выгнать, чтобы уже перестали наваливать. Тот, кого выгоняют, вскрывает свою карту и дальше участвует только как наблюдатель. Во время спринта ("днем") Заказчики работают, как члены команды. — Продакт-оунер. Просыпается раньше всех, может либо проверить кого-то — не является ли тот Заказчиком, либо выкинуть из бэклога несколько задач, которые ещё не взяли в работу (до половины от числа оставшихся игроков). — Ресурсный менеджер. Может спасти от снятия с проекта одного из членов Команды, но не дважды подряд. Себя может спасти только один раз за игру. — Человек-снежинка. Не является Заказчиком, но выигрывает, когда выигрывают они. Никакими специальными умениями не обладает, ночью не просыпается, но старается незаметно парализовать работу команды. Игра заканчивается победой Команды, если всех Заказчиков выкинули (объявлен фича-фриз и можно спокойно доделать все задачи в работе). Заказчики (и Снежинки) побеждают, когда Команда полностью разобрана (результат работы им достаётся бесплатно + неустойка). Пока на практике играть не пробовал, но должно быть весело!

К вопросу про развитие "после senior": обнаружилась забавная история — некоторые работодатели, когда хотят написать "опытный аналитик", пишут "Бизнес-архитектор"; особенно такое название любят интеграторы. Список обязанностей достаточно типовой для аналитика: — выявлять требования заказчика совместно с командой аналитиков; — проектировать и описывать сквозные бизнес-процессы; — формулировать архитектурное видение и требования к продуктам, входящим в единое проектное решение: — искать способы использования готового функционала в продуктах для решения потребности заказчика; — валидировать технологические решения; — совместно с владельцами продукта находить возможности реализации требуемой функциональности; — участвовать в переговорах с заказчиком и отстаивать архитектурное решение перед ним; — проводить демонстрации для заказчика: обсуждать реализованные пользовательские сценарии, требования к бизнес-процессам; — разрабатывать в паре с техническим писателем техническую документацию, описывающую целевую модель разрабатываемого решения по согласованным бизнес-требованиям; — участвовать в подготовке и проведении приемо-сдаточных испытаний; — организовывать обучение пользователей заказчика; — быть единой точкой экспертизы по проектному решению для заказчика и участников команды. Или вот: — Анализ общего перечня функциональных требований. Определение расхождений с базовым функционалом системы и противоречий с существующей архитектурой системы. — Взаимодействие с заказчиком на уровне согласования общей архитектуры системы в контексте бизнес-процессов, управление конфигурацией и составом решения. — Непрерывный мониторинг в части изменения требований и соответствия поставляемого продукта данным требованиям. — Формирование консолидированной оценки по объему работ в рамках запросов на разработку и конфигурацию системы. — Управление сквозными кросс-модульными клиентскими путями и пользовательским опытом. — Принятие решений о подходе к реализации функциональных требований в рамках стандарта и запросов на разработку. — Непрерывное взаимодействие с менеджерами продуктов и системными аналитиками в рамках проработки решений. — Участие в разрешении сложных вопросов по реализации требований совместно с техническим архитектором и руководителями направлений, поиск обходных путей. — Согласование и экспертиза проектной документации Иногда, конечно, под этим названием попадаются и настоящие бизнес-архитекторы, основная задача которых, по-честному: "Развивать возможности бизнеса, идентифицировать и реагировать на изменения рынка и окружающей среды" и "Исследовать и описывать бизнес-архитектуру компании на языке потоков ценностей и business-capabilities, бизнес-функций, бизнес-сервисов, бизнес-возможностей и бизнес-процессов" — но это буквально только в одной вакансии. В общем, хотите стать архитектором — просто назовите себя архитектором! Делов-то.