Всех с наступившими праздниками! 🎄Позитивных сдвигов в новом году!
В качестве небольшого новогоднего подарка коллеги из школы Systems.Education подготовили подборку ссылок на материалы по интеграциям информационных систем, curated content :) Ссылок много, получилась целая wiki. Enjoy! 🎅

Мы с коллегами-добровольцами подготовили для вас
Базу ссылок на полезные материалы по системной интеграции
для аналитиков и проектировщиков.

В базе собраны ссылки на русскоязычные и англоязычные статьи, видео, книги, сервисы и курсы.

Что в неё сейчас вошло:

Основы интеграции информационных систем
- Постановка задачи и общий обзор
- Способы классификации интеграций

Форматы представления данных
- Форматы JSON и YAML
- Форматы XML и XSD

Сетевые протоколы и транспорт
- Протоколы HTTP, HTTPS
- Протокол WebSocket

Сценарии взаимодействия, Sequence, Plant UML

Web Serviсes / RPC
- Проектирование API
- REST-like сервисы. Стиль REST
- Протокол SOAP и форматы XML, XSD, WSDL
- Технология GraphQL
- Технология gRPC

Обмен сообщениями
- Паттерны обмена сообщениями
- Apache Kafka
- Брокер Rabbit MQ

Файловый обмен

Интеграция через общую БД

Архитектурные паттерны интеграции систем
- Интеграционные шины, Enterprise Service Bus (ESB)
- API Gateway, Backend For Frontend
- Оркестрация и хореография
- Circuit breaker

Дальше готовим другие подборки по темам:

- Базы данных и анализ данных
- Бизнес-анализ и моделирование
- Архитектура программного обеспечения и Systems Design

На курсе по микросервисной архитектуре встретил чеканную формулировку: микросервисная архитектура нужна для снижения lead time в крупных системах. Lead time — время прохождения через цепочку производства отдельной новой функции. Можно сказать, снижение Time-to-market отдельной фичи. И если после перехода на микросервисы — а на микросервисы почему-то всегда переходят, никто не начинает с микросервисов :)) — эта метрика должна упасть. Если растет, в не падает — значит, вы делаете что-то не так. Это очень простое объяснение, ценное для бизнеса.

Agile, кстати, обещает то же самое. Джефф Сазерленд вообще так и назвал свою книгу: как делать вдвое больше работы за половину времени. То есть, пообещал ускорение аж в 4 раза. Это название даже на русский испугались перевести. И всё, у всех теперь SCRUM :) Ну ещё бы, кто же не захочет ускорить работу программистов в 4 раза.

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

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

‍26 января в 18:00 пройдет бесплатный открытый вебинар, который развеет мифы о ГОСТ 34 и поможет взглянуть на него по-новому. Спикер — Василий Баракин, применяет ГОСТ 34 более 15 лет и в роли архитектора ПО участвовал в проектах Enterprise уровня.

Этот вебинар для вас, если вы:
• аналитик
• руководитель проекта
• технический писатель
• ведущий разработчик
• представитель заказчика
• сотрудник ИТ-компании, работающей с госзаказчиками

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

Наш гость:

— Развеет заблуждения о ГОСТ 34 и поможет взглянуть на ГОСТ по-новому
— Покажет ТЗ во взаимосвязи с документами других стадий создания АС
— Раскроет важность пунктов ТЗ, которые либо упускают, либо копируют из Интернета

О спикере:

Василий Баракин:

• Архитектор проектов по информационной безопасности
• Опыт применения ГОСТ серии 34 более 15 лет
• Участвовал в создании автоматизированных систем федерального уровня

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

Регистрируйтесь по ссылке, участие бесплатное!

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

Риски же тут огромны: Chaos Report дает оценку около 17-20% вероятности полного провала проекта, и 40-50% вероятности значимого выхода проекта за границы сроков или бюджета. Конечно, любому менеджеру хочется снизить такие огромные вероятности. Что интересно, эти вероятности практически не зависят от квалификации команды (если только вы не набрали совсем неподходящих людей — тогда вероятность примерно на 10% выше. Что интересно — связь с высокой квалификацией менеджмента вообще отрицательная — менеджеры с высокой квалификацией с большей вероятностью ведут проект к провалу).

Так вот практики agile или микросервисов подходят к этой задаче с другой стороны — они снижают ущерб. Работа короткими итерациями с частыми поставками (а значит — с частым получением обратной связи) разделяет большую систему на маленькие инкременты, потеря или переделка каждого из которых не несет большого ущерба. Даже если вероятность накосячить очень высока. Кроме того, в процессе этого путешествия команда постепенно узнает предметную область и задачу всё лучше и лучше, а значит — может предложить лучшее решение (см. Paul Ralph, Is Requirements Engineering Inherently Counterproductive?), то есть и вероятность тоже со временем снижается.

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

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

А вы знали, что, если попросить ChatGPT вывести результаты в таблицу, эту таблицу потом можно скопировать и вставить в Miro как отдельные карточки? И потом уже на доске располагать их, как угодно? Например, так можно вытаскивать на доску User Story, идеи для мозговых штурмов, события для Event Storming (шучу, их должны предметные эксперты генерировать) или, например, модули и их API. #chatGPT

А вы читали "Алмазный век, или Букварь для благородных девиц" Нила Стивенсона? Это такая фантастика, одним из центральных элементов в сюжете которой служит "Алмазный букварь" — такой интерактивный, или даже иммерсивный учебник, подстраивающийся под ученика. В принципе, с #chatGPT мы уже очень близки к этому. Вот, например, сказочка про системного аналитика (упоминание Алмазного букваря явно сбило с толку ИИ, потому что в книге Букварь был для маленькой девочки, поэтому и сказка):

"Давным-давно, в мире, где технологии правили всем, жил-был молодой человек по имени Макс, который мечтал стать системным аналитиком. Макс был очарован тем, как работают технологии, и хотел стать частью команды, благодаря которой все это произошло.

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

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

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

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

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

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

Конец.

Упражнения и проекты для учащихся:

1. Создайте систему для управления ассортиментом небольшого магазина
2. Спроектировать сетевую архитектуру для школы
3. Создать программу для автоматизации системы выставления оценок ученикам.
4. Напишите отчет о преимуществах и недостатках облачных вычислений для бизнеса.
5. Создайте систему управления базой данных для местной библиотеки."

Довольно часто в запросах и обсуждениях всплывает тема ТРИЗ в системном анализе. Кто-то помнит ещё! Действительно, эта технология мышления — одна из признанных в мире чисто российских/советских разработок. И польза в ней, определенно, есть. Хотя некоторые концепции выглядят просто как здравый смысл :) Впрочем, это не мешает проектировщикам систем сплошь и рядом это здравый смысл не использовать.

Вот, например, техника "9 экранов". Очень мощная, если вдуматься. Обычно же как — аналитик фокусируется на центральном экране — система как есть. (В Systems.Education учат этому на курсе Разработка требований. Это для начала. Хороший аналитик смотрит на надсистему (окружение, использующую систему) и на внутреннюю архитектуру. Появляются интеграции, и это большая тема. Про это тоже есть целый курс. Иногда кто-то задумывается о развитии продукта. Вот тут мы про это рассуждаем — что делать сначала, а что потом. Иногда — про внедрение: например, перенос данных из замещаемых систем. Извините, курса на эту тему пока нет.
А вот удержать полную картину очень сложно: целых 9 точек зрения! И это, вообще, считайте, ТРИЗ ещё не начался — только самая первая техника.

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

А значит — данные должны быть подготовлены и загружены в системы (а может, у нас несколько шагов внедрения — например, с параллельной эксплуатацией и постепенным замещением), справочники сконвертированы, смежные системы подключены, пользователи обучены, технические средства выделены и настроены, мониторинг, бэкапы и балансировщики подключены. Всё очень сложно? Так это именно та сложность, о которой писал Фредерик Брукс в "Мифическом человеко-месяце": переход от простой программы к программному продукту или программному комплексу стоит x3, а от программы к системному программному продукту (комплекс+продукт) — x9.

А всего-то чек-лист из 9 экранов #ТРИЗ :)

"9 экранов" ТРИЗ

Я продолжаю исследовать возможности #chatGPT с разных сторон. Вот попросил его накидать основных концепций и технологий в какой-нибудь области. Специально выбрал такую, в которой я поверхностно разбираюсь. Дорогие читатели, а кто-нибудь из вас понимает в блокчейне? Эта диаграмма похожа на правду, хотя бы отдаленно? Или совсем пургу ИИ гонит? Не забыл ли он чего-то важного, не написал ли лишнего? Что бы ещё стоило добавить на диаграмму для понимания этой предметной области? (Тут он, кроме самих концепций, пишет, чем в этой области можно заняться. Например, research и education. Ну и, если что, на каждую связь у него есть объяснение — почему эти концепции связаны. Просто эти объяснения на диаграмму не влезли)

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

UPD: Мне тут говорят, что это он сразу рисует, как на самом деле процесс будет работать после внедрения :D

Интересную тут практику я обнаружил на рынке: разработка классических требований по agile-процессу(!). То есть, люди говорят про scrum, работу итерациями и всякое такое, но при этом выясняется, что они либо "по скраму" разрабатывают большое ТЗ на систему (спринтами-итерациями, ага. То есть, такой очень растянутый нулевой спринт, который сам разбит на спринты, и на выходе у которого большой документ), либо у них "опережающие" аналитические спринты: то есть, команда аналитиков идёт на 1-2 спринта впереди разработки, прорабатывая тему и формулируя "ЧТЗ на спринт" для них. В более-менее классическом виде, не какой-нибудь там бэклог из User story или JTBD.

Иногда это не "аналитический" спринт, а опережающий "UX" или "дизайн"-спринт, если аналитиков не, но есть UX-проектировщики (это больше в продуктах или сайтах).

Удивительное дело. Чего только люди не придумают. С другой стороны, работает — не трогай! :)

В продолжение предыдущего поста, заметка-наблюдение: все говорят про Continuous Integration / Continuous Delivery, встречается также термин Continuous Testing. Но я ни разу не слышал про Continuous Analysis... 🤷‍♂️ Только про Analysis Paralysis.

Доброе утро! 😉