Пришли дети, увидели открытый draw.io, ой, а что это за стикмены? Слово за слово, нарисовали диаграмму.

Вопросы:
— содержит ли эта диаграмма элементы UML?
— это структурная или поведенческая диаграмма? (или диаграмма взаимодействия?)
— какой процесс тут, собственно, изображен?

В этом году я пошел учиться — прямо по-настоящему, на 2.5 года, в магистратуру. Вот такой неожиданный поворот, хотя, как я вижу по окружению, пошли учиться многие. Коллективное помешательство — видимо, солнечная активность вызывает тягу к новым знаниям.

И вот что интересно: все  практики и подходы, о которых мы говорили в 2010-2012 годах, которые развивали и проектировали — и тогда это был какой-то невероятный полуподпольный эксперимент — все вот они, в обычном вузовском образовании! Ну ладно, не совсем в обычном, из верхнего перцентиля, но — тут.

Например, два года назад я учился в РАНХиГС, и там мы строили CJM. А нынешнее обучение началось с трехдневной "деловой игры", которая на практике оказалось форсайтом (и именно rapid foresight, про который я несколько раз рассказывал в ИТ-сообществе, и который сейчас активно продолжает продвигать Дима Безуглый — собственно, я его с методикой и познакомил).

Методику воспроизводят неточно, где-то утерян дух, где-то — смысл, но, тем не менее, это она. Нужно отдать должное авторам — теперь, кажется, форсайты стали общим местом и стандартом для стратегических сессий (кстати, обращайтесь, если что, я их тоже провожу 🖐). А дальше обещают lego serious play и всё такое прочее.

Согласитесь, это вам не традиционные лекции и семинары! (Хотя они предусмотрены тоже, но, кажется, их не более трети от всех учебных активностей)

И это правильно — учиться нужно через деятельность, и только делая что-то своими руками/головой.

Управленцам — анализировать и оценивать ситуации, разрабатывать стратегии и планы по их реализации, программистам — проектировать и писать программы, архитекторам — обеспечивать развитие больших систем, аналитикам — выяснять детали и обозначать пространство возможных решений.

И если вместо того, чтобы что-то сделать, вам предлагают послушать, как что-то сделать — это не обучение, а ознакомление с материалом.

С другой стороны, без ознакомления тоже не обойтись. Можно сразу выдать задание, ничего особо не объясняя, а потом демонстративно сажать людей в лужу, отмечая недостатки результата. Некоторым ведущим это очень нравится, они называют такое действо "проблематизацией", или "приземлением", или даже "сбиванием короны" — то есть, демонстрацией человеку, что его предыдущие знания и навыки ни на что не годятся.

Подразумевается, что человек немедленно всё осознает, и дальше со всей внимательностью будет изучать то, что ему дальше расскажут и покажут.

На практике же получается совсем другое: люди начинают защищать свой результат, потому что никому не нравится выглядеть дураком (об этом был прекрасный рассказ на Fail Night на последнем Flow — без записи, естественно).

Часто говорят, что не хватило времени или не было чётко поставлено задание. В большинстве случаев это так и есть, и любимая фраза ведущих: "у вас никогда не будет хватать времени и вы никогда не получите точного задания". Это тоже отчасти правда, но уж очень напоминает газлайтинг.
Собственно, в этот момент вся ситуация становится токсичной — в большей или меньшей степени, планово или неосознанно, но токсичной. То есть, это манипуляция.

В ситуации манипуляции человек тоже учится, но часто чему-то не тому (помните — "выученная беспомощность"? Вот, выучился!)

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

Другой вариант — такие манипуляции — часть культуры той среды, в которой обучающимся придётся потом работать, поэтому нужно научиться их распознавать и обрабатывать в безопасной ситуации. По моим наблюдениям, именно такая культурная среда у нас в госпроектах, и тут, наверное, такая подготовка оправдана.

Хотя, на мой взгляд, лучше бы образованию заняться изменением этой культуры, а не её трансляцией.

Я лично глубоко убежден, что обучение должно и может происходить в экологичной среде и без всяких манипуляций.

А с мотивацией можно работать отдельно, если это требуется.

К сожалению, эта часть технологий пока не дошла до учреждений высшего образования. Про экологичное и уважительное общение там ещё мало кто слышал — наоборот, хвалятся, чей профессор больше жестит, хамит и троллит.

Интересно здесь сравнить реакцию студентов в зависимости от возраста и области деятельности — я когда-то преподавал в департаменте медиа ВШЭ, куда обычно идут сразу после бакалавриата — то есть, молодые, просвещенные и эмансипированные люди, и вот там профессорам приходилось тяжело — с их пафосом, снобизмом и сексистскими шуточками старого образца.

Не знаю, как с этим обстоит сейчас дело в технических и итшных вузах, да и в компаниях, но, кажется, в нормальной компании и общение должно быть нормальным, а иначе бы все из них сбежали — при таком-то рынке кандидата!

Тут мне скажут, что давно я в крупных компаниях не работал, и компанию с нормальной культурой общения ещё поискать нужно. Напишите — как у вас, насколько экологичная атмосфера в этом плане?

Ну а для тех, кто организует, выбирает или проектирует обучение, повторю ещё раз:

1⃣ Освоение навыков происходит только в практической деятельности, соответствующей навыку (прохождение тестов учит проходить тесты, ну ещё способствует запоминанию, если вам это требуется).

2⃣ Манипуляции результатами через нарушения в организации деятельности (чрезмерное сокращение времени на задание, нечеткие инструкции или требования к результату, намеренный или случайный пропуск шагов при работе по методике) приводят не к обучению, а к отторжению (и иногда — к сплочению группы против ведущих, тоже результат).

3⃣ Уважительное общение и поддержка желательного поведения даёт при обучении гораздо больший эффект, чем выискивание и подчеркивание ошибок.

4⃣ Без лекционной части не обойтись, но старайтесь доносить одну сильную мысль за один смысловой блок — объем внимания человека ограничен.

5⃣ В практических заданиях сталкивайте человека со средой, фактами и логическими промахами, а не с мнением ведущего (особенно если это мнение выглядит как "к чему бы тут докопаться").


Так что спасибо этому обучению, я лучше стал понимать свои ценности и методы в обучении — на контрасте.

Опять дискуссии в разных группах подкидывают темы для постов. Вот, например, конференции. Многие пишут, что не видят смысла, что дорого, и при этом особо ничего нового, и ничему не научишься за эти деньги.

Мне кажется (как члену ПК нескольких конференций и много выступавшему чуваку), что конференции нужны для того, чтобы понять "где мы сейчас" и "что нового и актуального появилось". Это не совсем про учебу -- за один доклад ничему не научишься, а мастер-классы на конференциях ограничены по времени и их обычно не очень много.

А вот именно понять, чем индустрия дышит, что обсуждет, что нового появилось -- вот для этого. Можно читать форумы и статьи, но тут есть некоторое сведенная воедино силами программного комитета картина, курированный контент. То есть, не выдумки отдельных авторов, а репортажи о реальных делах.

Что с этим дальше делать -- конечно же, принимать решения. Моими первыми конференциями были, кажется, IT-people и RuCamp. Это был просто другой мир, после затхлых банков (это было время, когда итшников в банках ещё считали центром расходов и неизбежными дармоедами, и относились соответственно) и примерно таких же вузов. Во многом эти события определили мою дальнейшую траекторию. И я очень жалею, что не попал в те тусовки, в которые в итоге попал благодаря этим конференциям, ещё раньше (например, прозевал расцвет рунета).

Сейчас, конечно, таких мощных событий не очень много -- информации полно, удивить людей сложно. Но, повторюсь, в идеале -- конференция должна быть срезом, демонстрировать state-of-the-art индустрии и давать взглянуть в будущее.

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

У аналитиков, наверное, новое не так часто возникает, поэтому и кажется, что всё одно и то же. Ну, это тоже некоторый ответ -- раз всё одно и то же, значит что, индустрия стагнирует и не развивается? Все книжки друг другу кидают, так они ещё из прошлого века. Вигерс 2013, но это переиздание, первая версия написана в 1999. Купер и "Психбольница в руках пациентов" -- 1998. Что нового появилось? Какие новые технологии, какие вызовы?

Если они есть -- решением по выходе с конференции должно быть "о! вот как у них! вот о чем они думают и как работают! Надо у нас тоже такое внедрить, пойду читать подробнее". Или "о, блин, вот как можно-то! а у нас какая-то фигня происходит, пойду в нормальную компанию работать". То есть, какой-то инсайт, озарение. Ещё на конференции ходят, когда в компании нет профессионального сообщества -- убедиться, что ты такой в мире не один, и есть много людей, которые сталкиваются с похожими проблемами и которых волнует то же, что и тебя. Но это не настолько ценно обычно, чтобы свои деньги платить, это входит в мотивационный пакет компании.

Если всего этого с участниками не происходит -- значит, ПК плохо сделали свою работу, ну или в индустрии правда всё тухло. Или вы переросли эту конференцию, и вам на ней нужно выступать :)

Это, кстати, проблема -- опытных товарищей уже сложно чем-то удивить, они всегда ноют, что для них всё скучно и всё уже было. Эту задачу пока никто не решил (я не видел). Ну вот мы делали WAW в прошлом году, там все общались и это было очень ценно, но можно ли это повторить -- не знаю, будем пробовать. Задача сложная.

Напишите -- а вы зачем ходите на конференции, или почему не ходите, если не?

Ещё немного инсайтов про конференции. Вот про нетворкинг спикеров — это правда. Я в свое время с очень крутыми людьми познакомился и пообщался именно в спикерской или в ПК.

Тут дело в том, что у вас есть общее занятие, а за этим занятием и общение идёт легче и знакомство. А вот у тебя в докладе то-то и то-то, а меня был вот такой опыт — и понеслось. Можно, конечно, и просто так спикера поймать — кстати, не бойтесь это делать, спикеры — такие же люди, и скорее всего будут открыты к разговору не только сразу после докладов, но и в другое время.

Но при подготовке доклада приходится общаться с другими — и крутыми! — людьми, к которым потом можно придти и со своим вопросом или идеей. А ещё на некоторых конференциях для спикеров устраивают отдельный нетворкинг, что тоже очень круто. (А где делают несколько конференций — ещё и нетворкинг для членов ПК). В этом смысле был очень хорош ЛАФ, который и начинался как посиделки за шашлыком, и сейчас продолжает эту традицию, но почему-то не все доходят — видимо, не знают главной фишки :)

В общем, запишу и для себя, и для всех, кто организует конференции — хотите эффективного нетворкинга — придумывайте деятельность, объединяющую людей, в рамках которой люди будут знакомиться, общаться и перемешиваться. На докладах нетворкинг не происходит.

Продолжая тему конференций — не кажется ли вам, что популярность тем хардов и софтов на конференциях меняется циклично?

В какой-то момент, ещё лет 5 назад, чуть ли не половина докладов была про софты: как продуктивно работать, как проводить совещания, как не выгореть, как избегать конфликтов или наоборот манипулировать. Про разные там модели личности были популярны доклады, про балансы работы и жизни. Я на ЛАФе в 2022 году даже слышал доклад про то, как устроить себе саббатикал — то есть, уйти в долгий отпуск. В докладе было про 5 месяцев, но вообще саббатикал может быть и на год; в университетах его дают профессорам каждые 7 лет (или даже 5), Дональд Кнут написал TeX как раз во время такого отпуска.

В общем, разговоров про людей и про жизнь было много. Потом маятник качнулся назад — всем захотелось хардов, технологий интеграции, архитектуры и всякого такого. Некоторые конференции даже принципиально не брали доклады на темы софт-скиллов и управления людьми — только хардкор!

И, кажется, у аудитории опять назрела потребность поговорить не про интеграции и не про ИИ, а про себя — про людей, то есть. Чтобы и про выгорание — которое никуда не делось, и про развитие — и собственное, и своих сотрудников, если вы лид/начальник подразделения. И про поиск, и про адаптацию, и про управление, и про взаимодействие со стейкхолдерами, и про противодействие манипуляциям.

Я вижу это по запросам на менторинг/консультации (а на Flow, например, была такая активность — "спроси эксперта", вот я был тем экспертом, и угадайте — про что был вопрос? Точно не про интеграции :))

Ещё примерно те же темы поднимались в опросе, который я когда-то проводил — и проблемы тоже совсем не с технологиями связаны и не с техниками анализа, а в основном с людьми.

Как вам кажется — актуальные темы про людей в системном анализе? Что бы вы хотели услышать и обсудить про всё, что не харды?

Давайте продолжим эту практику — спросите меня о чем-нибудь, что относится к людям? Как быть с собой и как быть с другими. Постараюсь вам ответить, насколько смогу. Ну и других опытных коллег призываю отвечать, по возможности.

Пишите в комментах вопросы, которые вас беспокоят, и на которые у вас нет ответа — будем разбираться!

Раз зашла речь про софт-скиллы, напомню ещё раз анекдотическую ситуацию с половиной статей про эти самые софт-скиллы: https://news.1rj.ru/str/systemswing/213

Помните! Если вы видите в какой-нибудь статье фразу "Ученые из Гарварда, Стэнфорда и Фонда Карнеги выяснили, что «гибкие навыки» — это 85% успеха человека в профессии, жесткие составляют только 15%." — это из книги 1918 (не опечатка!) года про обучение инженеров в США, и главный "софт-скилл" там — твердость характера!

В обсуждении софт-скиллов и хард-скиллов возник вопрос -- а какие, собственно, у аналитика хард-скиллы? Ну, кроме, цитирую, "сбора требований и базовых знаний по отрисовке диаграмм". Если речь про знание технологий, то любой программист погружен в нюансы технологии гораздо больше аналитика.

Про харды именно по анализу напишу чуть позже, а вот про знания технологий вспомнил хорошую метафору из Руководства по написанию требований INCOSE:

Представим, что на дворе 1930-е годы. На выставке инструментов для лесного хозяйства фирма Андреаса Штиля только что представила бензопилу, способную сделать революцию в отрасли. Герои нашей истории работают в небольшой компании, занимаются валкой леса. Её менеджеры только что вернулись с выставки. Просто взять и начать валить деревья с большей скоростью — это прекрасно. Но ведь нельзя просто так взять и посадить первого попавшегося представителя какой-нибудь из заинтересованных сторон за стол и попросить его написать требования для закупки бензопилы. Системное мышление заставляет задуматься: как же эта новая технология будет применяться с точки зрения бизнес-операций?

К сожалению, менеджмент также не может с пользой для дела прийти к заинтересованным сторонам, видимым с точки зрения бизнес-операций, и попросить их сформулировать потребности и требования к возможностям, открываемым новой бензопилой. Операционные менеджеры ведь управляют лесорубами, которые работают топорами. А эти серьезные мужчины вряд ли смогут рассказать, что им придется делать с новым инструментом: они никогда этого не делали, их никто не учил, не проводил инструктаж по безопасности или обслуживанию пилы. Или, что более вероятно, не захотят помогать: ведь в лучшем случае им придется переучиваться. А в худшем вообще остаться без работы.

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

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

Обслуживание топоров устоялось: торговцы не просто продают инструмент, но и отвечают за его состояние. Сломалось топорище? Просто отправляем его торговцу, он заменит. Затупилось лезвие? Снова к торговцу: он заточит. А с кем и как вести дела, если закупить бензопилы? Как поддержать снабжение? Как перевозить материалы— топливо, масла — с которыми сегодня в компании никто не работает? Как и кто эту новую способность предприятия (все эти двигатели, цепи) будет поддерживать? Как поменять структуру организации? Как внедрять эту новую способность: выдать всем операторам бензопилы сразу, командам по очереди или начать скаких-то определенных регионов? Если начать валить деревья быстрее, нужно ли будет найти дополнительный транспорт для перевозки материала? Не придется ли расширять лесопилку? В конце концов, бизнес-менеджменту придется решить, стоит ли поставлять больше продукции и наводнить ею рынок, обрушив таким образом цены.

Эта метафора показывает разницу между использованием технологии и системным анализом использования технологии. Программисты, безусловно, отлично знают все детали технологий, но задача аналитика (на мой взгляд) -- рассмотреть технологию и её влияние в комплексе и с разных сторон.

Знаете ли вы, что у ChatGPT можно попросить нарисовать вашу жизнь по мотивам вашего общения?

Промпт такой: "Based on what you know about me from our previous conversations, please draw a picture how in your opinion my life could look like“

Мне рисует вот такое 👆

Не знаю, откуда он взял всех этих Supplers Suppllelers Suppleton, но если считать, что я поддерживаю и обеспечиваю деятельность аналитиков — то даже похоже :)

Вообще, если говорить о софт-скиллах, одним из самых важных я считаю такой скилл, который не знаю, как называется, и про который почему-то редко говорят, когда говорят про софт-скиллы. Что-то вроде способности преодолевать страх наказания и смело идти навстречу неприятностям, вот так многословно.

Отсутствие такого скилла иллюстрируется очень простой ситуацией: это тот чувак из фильма про зомби, который будет до последнего скрывать, что заразился, и превратится в зомби в самый неподходящий момент.

Есть отличный текст на эту тему, он прекрасен, приведу его полностью:

Чуваки! Идите навстречу неприятностям. Не бегайте и не прячьтесь от неприятных ситуаций - инициируйте их разруливание сами, будучи виновной стороной.

Ты три дня тупил, и работа не будет готова к пятнице. Скажи об этом в среду сам, а не в пятницу, когда у тебя спросят результат! Дай другим возможность передвинуть планы, поискать, как тебе помочь сделать побыстрее, предупредить клиентов и так далее! Тогда ты остаешься ответственным вменяемым человеком - ты не подвел.

Ты проболтался врагам о секретах. Ты сломал чужую вещь или общий проект. Ты ляпнул теще правду о ее прическе. Ты недооценил трудность и понял, что не выполнил обещание. Ты недооценил сроки и ваша команда не запустит проект в день, обещанный клиенту. Ты недооценил расходы и проект собирается уйти в убыток. В ту же секунду, как ты это понял - иди и скажи об этом тем, кого это касается. Тем, кому важно как можно раньше об этом узнать, чтобы начать спасательные действия, позвонить маме и задобрить ее, открыть финансовый план и поискать резервы, позвонить рекламщикам и отложить старт заранее, не попадая на штрафы, и так далее. Чем раньше они узнают - тем меньше ты их подведешь, тем больше у них шанс спасти ситуацию. Не молчи до последнего, когда спасать поздно. Да, тебя ждет неприятный разговор - но в основном он будет про конструктивное решение, а не про отрицательные эмоции. В отличие от ситуации, когда об этом твоя команда, начальник, жена или друг узнают не от тебя и слишком поздно.

Ты понял, что занят, и не хочешь выполнять обещание или заказ. Скажи об этом сразу, а не когда у тебя придут спросить результат - дай человеку время найти другого исполнителя или план Б! Ты будешь неприятным снобом - но не раздолбаем, с которым больше не станут иметь дело.

Ты занял денег или взял кредит на бизнес, и понимаешь, что твои надежды проваливаются, и в срок ты отдать не сможешь? Бегом к кредитору. Первым. Заранее, а не когда придет этот срок. Тогда ты остаешься вменяемым и ответственным заемщиком. Твой кредит реструктурируют, срок продлят, после возврата с удовольствием дадут следующий кредит: ты же не подвел, дал кредитору шанс перекрыться из других источников вовремя.

Мне это и жизнь, и бизнес, и кредитную историю спасало в невегетарианские времена, друзья. И отношения с людьми тоже. Ошибки, фейлы, факапы бывают у всех. Не их отсутствием зарабатывается репутация. 90% того, что называется "ответственный, вменяемый, надежный" описано выше.

Казалось бы, простые, очевидные вещи. Однако почему-то сплошь и рядом взрослые люди тупо боятся пройти через неприятный момент. Когда что-то идет не так - прячутся, исчезают с горизонта. Постоянно на это натыкаюсь - человек до последнего молчит, а когда приходит пора спросить (как там результат, проект, деньги, подарок дяде...) - исчезает из интернета, отключает мобильный. Словно не понимает, что отложенный момент окажется хуже в сто раз. Словно включается внезапно в нем маленький мальчик с рефлексом "разбил мамину вазу - будут ругать - надо затихариться - а дальше чем на два часа я думать не умею".

Убей в себе маленького мальчика! Не прячься от неприятного! Не дай кредиторам, партнерам, начальникам, друзьям искать тебя после того, как прошел срок - позвони им сегодня, сейчас, скажи худшее из своих прогнозов! Мир станет гораздо более удобным местом, когда все станут взрослыми в этом смысле. Идите навстречу неприятностям.

Если вам задают вопрос "Что происходит, когда вы набираете в браузере 'google.com'?", вспомните это видео: https://www.youtube.com/watch?v=atcqMWqB3hw

Осторожно, видео со звуком! В офисе используйте наушники. Ну или наоборот — зовите всех вокруг, особенно разработчиков — они наверняка порадуются. В комментариях отметился Даниэль Стенберг — собственно, создатель утилиты curl. Он такой подход одобряет! :)

По принципу Баадер-Майнхоф, вопрос "Что происходит, когда вы набираете google.com" не отпускает.

Шутки-шутками, но тут можно поговорить на серьёзную тему: про абстракции.

Ведь в этой картинке шутка в чем: никто не ожидает услышать в ответ на этот вопрос рассказ о таких глубоких уровнях реализации, как скан-коды клавиатуры (а если она USB — можно ещё и про потоки данных рассказать, стандарт USB довольно интересно устроен с точки зрения передачи данных — как маленькая сеть с иерархической топологией, и с разными режимами передачи пакетов данных). Даже в видео из предыдущего поста, на мой взгляд, чересчур подробно расписаны взаимодействия в процессе установки соединения TLS — аналитики в это обычно не погружаются.

Между тем, если абстрагироваться от устройства компьютера и ОС, а рассмотреть только сетевое соединение, остаются 7 уровней абстракции по модели OSI (никто не помнит все 7): от физического уровня — как электрончики бегают — до прикладного (собственно, протокол HTTP, например).

В модели TCP/IP уровней всего 4 (над физическим), легче запомнить: уровень передач пакетов в одной сети (link), уровень передачи между сетями (internet), уровень транспорта — как эти ваши пакеты собирать, что вам, например, важнее — надежность доставки (TCP) или своевременность (UDP), и, наконец, уровень приложений — что мы вообще передаем: файлы, гипертекст? Тут мы опять останавливаемся в лучшем случае на уровне приложений, а то и выше — SOAP и GraphQL — это надстройки на HTTP. Собственно, абстракции хороши чем — можно не думать, как они внутри устроены, а просто ими пользоваться.

Ну, до какого-то предела. Пока абстракция не начинает протекать.

В проектировании систем есть фундаментальная проблема:

Закон Дырявых Абстракций: Все нетривиальные абстракции дырявы. (All non-trivial abstractions, to some degree, are leaky)

Как бы мы не абстрагировались от всего, что ниже, мы не можем этого не учитывать. Ну, или немного можем, раз у нас есть разделение труда по уровням абстракции. Главное, четко провести границу.

Вот, например, кэширование — кто про него должен думать? Я каждый раз задаю этот вопрос на тренингах — нет, аналитики про это не думают. И нагрузку на сервера не считают. Традиционно, все нефункциональные требования не в области интересов аналитиков. Это только потом выясняется, что каждое соединение расходует на сервере память и процессор, и они, вообще говоря, могут закончиться.

А ещё бывают конкурирующие запросы — один клиент изменяет ресурс, а другие в этот момент его читают. А ещё внезапно оказывается, что запросы выполняются не мгновенно, и передача большого куска данных может идти довольно долго (а при случайном или намеренном сложном запросе может и вообще завесить ваш сервер, см. XML Bomb или Billion Laughs Attack).

Вопрос границ ответственности в данном случае очень спорный. В общем случае аналитик не может быть глубоко погружен в технические детали. Пока абстракции не начали течь, и пока своими глазами не увидишь, как два почти идентичных запроса к БД выполняются за время, отличающееся в десятки раз, потому что запрошенные данные не попали на страницу, подгруженную в кэш СУБД (какой кэш? какие страницы? почему я вообще должен об этом думать?)

Итого, ответ такой: про зоны ответственности лучше договориться заранее. Где мне остановиться и что не описывать в моем документе? Кэширование — это ещё мое, или нет? А обработка ошибок? А санитаризация ввода — об этом нужно писать?

Я знаю, во многих компаниях есть соглашение о моделировании (бизнес-процессов, архитектуры). Почему-то гораздо реже встречается соглашение о содержании требований. Где останавливается БА, что добавляет СА, а что является технологической документацией, которую пишут разработчики/архитекторы или SRE?

Заодно при составлении такого соглашения может выясниться, что у вас в команде недостает каких-то специальных компетенций (например, по тем же уязвимостям API или по оптимизации запросов к БД).

Это риски, а системный анализ — он весь про риски. Лучше их выявить и принять меры.

Ну а чтобы выявить и разобрать, что кому уходит, нужно представлять весь процесс в мельчайших деталях. И, к сожалению, на нескольких уровнях абстракции, вплоть до физического. До сих пор помню, как мы недели две искали плавающий баг — у части клиентов сервер регулярно отваливался на несколько секунд, и не принимал подключения. Вычистили пару реально странных мест в обработчиках соединений, нашли одну утечку памяти. Всё без толку. А оказалось — разъем на свитче разболтался, нужно было патчкорд поменять.

Вопрос: вижу во многих постах, разборах и шпаргалках для интервью по интеграциям упоминание протокола MQTT. Все с умным видом пишут: легковесный, обеспечивает небольшую нагрузку на каналы связи, может работать в условиях неустойчивой передачи, используется для IoT...

А кто-нибудь его вообще в реальной жизни на работе применял? В смысле, не только для умного дома? Расскажите?

Любопытные результаты! Половина аудитории вообще не слышала про MQTT, четверть — слышала, и только 7% (29 человек) используют в работе.

Это при том, что MQTT — один из самых ранних протоколов, реализующих паттерн "Публикация-подписка", ещё 1999 года. AMQP, на котором построен RabbitMQ и прочие брокеры с буквами MQ в названии — предложен в 2003, а Kafka вообще в 2011.

Я, собственно, спрашивал для одной тут инфографики с разными типами интеграции. Вопрос — включать ли туда MQTT, или это совсем экзотика. И, честно, говоря, пока так и не решил — вроде бы, 7% — это не так уж и мало, а знать полезно. Видимо, всё-таки нужно, для общего развития аналитиков.

Интересный набор статей про MQTT есть на сайте Kai Waehner. У него там интересные разборы архитектур систем стриминга данных, причем он часто сочетает MQTT с Kafka (MQTT выступает интерфейсом для сбора данных, а Kafka — для хранения и дистрибуции, как например здесь.

В общем, если в вашем проекте появляются такие слова, как IoT, сбор данных с датчиков, телеметрия, умный дом/умный город, роботы, цифровые двойники, автомобили/самокаты/велосипеды/дроны/самолеты, сотни тысяч и миллионы устройств, realtime processing, слабые каналы связи, mesh networks, а может быть наоборот — 5G для IoT, или, например, каппа-архитектура — то имеет смысл посмотреть в сторону MQTT.

Несмотря на свой почтенный возраст, протокол вполне себе жив — вот отчет о прошлогодней конференции (посмотрите презу в конце статьи, там много интересных архитектур).

Закончился очередной поток очного курса по проектированию интеграций, а я в очередной раз задумался про обучение взрослых. И кстати нашел тезисы по андрагогике Малколма Ноулза (Malcolm Knowles, отличная фамилия для ученого, занимающегося образованием!)

Он много занимался обучением взрослых ещё в середине XX века, и сформулировал следующие принципы:

1. Потребность в знаниях. Взрослым нужно четко понимать — зачем они учатся.

2. Опыт. Обучение взрослых должно быть основано на опыте (включая ошибки).

3. Самостоятельность (self-concept). Взрослые сами отвечают за решения в отношении обучения, в том числе в планирование и оценку качества преподавания.

4. Готовность. Взрослые более готовы изучать предметы, которые могут немедленно применять в своей работе или жизни.

5. Ориентация на проблему. Обучение взрослых должно строиться вокруг проблемы, а не вокруг контента.

6. Мотивация. Мотивация взрослых скорее внутренняя (улучшение жизни, рост уверенности, удовлетворенность работой), чем внешняя (оценки, учебные достижения).

Эти идеи совпадают с тем, как у нас в Systems.Education устроено обучение (мы пришли у этому на собственном опыте, без теории) — работа над кейсом в течение курса, никаких оценок, обучение выстроено вокруг получения реального опыта, применять можно сразу, есть возможность углубить или пропустить какую-то тему, если группе это нужно (или не нужно).

Однако многие онлайн-курсы сделаны по прямо противоположным принципам! Без объяснения, зачем вам нужно это обучение (это скорее внешний фактор, когда вас компания посылает на обучение, не объясняя, зачем). С минимальным опытом (пройдите тесты, вот и весь опыт). Без вариантов влияния на планирование, содержание и темп обучения (а тем более — без оценки качества преподавания). С кучей теории, которую непонятно, как применить. С занятиями, выстроенными вокруг контента (это вообще не обучение, это ознакомление). И с мотивацией в виде оценок и геймификации.

Есть, конечно, совсем противоположный полюс — типа "Арзамаса" и "Страдариума" — курсы явно не для применения прямо сейчас и организованные вокруг контента (хотя в Страдариуме есть курсы с практическими заданиями — например, в курсе по исторической кухне дают задание приготовить что-то по средневековым рецептам). Вот про эту сторону обучения я плохо понимаю, хотя проекты явно успешны.

Часто возникает вопрос — какой выбрать режим интеграции — синхронный или асинхронный.

Особенно если у вас в инфраструктуре есть и то, и то. То есть, вы приходите к владельцу/архитектору системы, с которой хотите интегрироваться, а он говорит: у нас и REST API есть, и к Кафке мы подключены, нам в принципе всё равно, что для тебя сделать, а тебе-то как удобнее? То есть, перекладывает выбор на аналитика. А как аналитику выбрать? Ну, провести анализ, а что анализировать-то?

Тем более, что вариантов у вас три (да ещё с подвариантами):
1. Синхронная интеграция (запрос-ответ, выполняемый немедленно)
— в пределе — постоянный двунаправленный канал (websockets)
2. Асинхронная (и запрос, и ответ асинхронные; по сути, двунаправленный паттерн "публикатор/подписчик", обычно это топик для запросов и топик для ответов)
3. Смешанная или гибридная (обычно синхронный запрос и асинхронный ответ), причем тут два варианта:
— ответ через очередь сообщений;
— ответ через прямое обращение (webhook, подписки в graphql / grpc)

Итого, на что смотрим и что анализируем:

1. Требования бизнес-процесса: нужен ли нам по сути деятельности немедленный ответ? (скорость ответа — десятки и сотни миллисекунд). То есть, онлайн-игры, чаты, совместное редактирование документов, управление видеоконференциями — это вебсокеты или что-то похожее. Онлайн-платежи, переводы, запрос баланса, аренда самоката, открытие автомобиля каршеринга, перевод, заполнение форм и вообще действия в интерфейсе — это синхронный запрос-ответ, REST API и RPC в любых видах.

2. Если время выполнения запроса может превышать секунды (граница тут тонкая, как видите) — можно думать про асинхронное взаимодействие. Нужны уточняющие вопросы:
— Нужно ли сохранять все запросы? Будем ли мы перепосылать каждый запрос, если его не смогли обработать? (насколько ценна информация и насколько быстро она меняется? Важен ли нам конкретный экземпляр запроса? Заказ в магазине, вызов такси и запрос на создание документа точно будем перепосылать. А вот запрос остатков товара, оповещение о текущем положении вызванной машины, подтверждающий код — можем и пропустить, сохранять его не нужно — ответ именно на этот запрос нам не актуален, мы другой отправим. То есть, если промежуточное хранение не нужно — выбираем синхронную связь с возможными потерями, если нужно сохранять сообщение или обеспечить точный порядок сообщений — асинхронную очередь.

— Нагрузка, которую мы обеспечим взаимодействующей системе: сможет ли её API выдержать наши запросы? Какой у системы RPS и насколько часто мы к ней собираемся обращаться? Возможно, для разгрузки системы перед ней нужно поставить очередь.

— Как долго обрабатывается наш запрос? Если смежная система будет обрабатывать секунды и минуты — это точно асинхрон или гибрид: мы можем отдать команду на старт процесса синхронно (через REST API), а получить ответ асинхронно: через webhook, если нам ответ не очень важен, или через очередь, если ответ для нас важен, или ответов может быть несколько и важна их очередность.

— Мы обращаемся к одной системе, или ко многим сразу? Например, у нас много систем, в которых учитываются разные банковские или страховые продукты для одного клиента, и мы хотим опросить все системы. Можем на своей стороне делать по запросу к каждой системе, а можем кинуть один запрос в очередь запросов, и пусть все системы оттуда его считают и отвечают в своем темпе. Если число систем неизменно, а отвечают они быстро — это API Gateway. Если системы по-разному нагружены, и число их может расти — лучше очередь.

— Может ли наш запрос выполниться в одной системе за один раз, или это транзакция, которая выполняется в нескольких системах? Скорее всего, распределенная транзакция, особенно если это хореографическая сага, потребует асинхронной интеграции.

Ну и помним, что организация очередей и брокеров не дается бесплатно, это всегда, с одной стороны, вычислительные ресурсы, а, с другой — усложнение логики работы и тестирования.

А если вы встречали хороший алгоритм для выбора режима интеграции — скиньте в комменты, всем будет полезно.