Продолжение мысли, высказанной ранее https://news.1rj.ru/str/sysarchthoughts/21.
Сложные методы работы (типа DDD), нацеленные на предотвращение сложных проблем в возможном будущем, почти неизбежно будут внедряться с большим трудом. Почему так?
Во-первых, сложные проблемы возникают в командах с высокой квалификацией, потому что без неё до сложных проблем не добраться, завязнут в простых.
Во-вторых, людей с высокой квалификацией объективно сильно меньше, чем со средней или невысокой. Ну, это банальная статистика.
Следствие - для подавляющего большинства проблемы, на решение которых нацелены подобные методы - это просто слова, абстракция. Они этих проблем не видели и не могут оценить их значимость или сложность. А вот сложности, которые привносит метод, они не гипотетические, а вполне ощутимые.

👉Т.е. почти всегда проблемы (непонятные) и польза (гипотетическая) будут (возможно) потом, а сложности от использования/внедрения метода возникают сразу и они не гипотетические.

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

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

Что с этим делать, честно говоря не знаю. 🤔
Будете смеяться, но пока единственный подход к борьбе со скептицизмом внедрения подобных сложных практик, который у меня реально работал - это довод, что делать "вот так", как минимум, существенно интереснее, чем по-старинке.
Т.е. внедряем Just for fun, и пользуемся с удовольствием 😃

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

Тут есть очень тонкий момент ... с одной стороны DDD как раз говорит о том, что нужно разделять модели по контекстам, с другой стороны - на ранних этапах это сильный оверинжиниринг.
Мне видится, что истина - где-то посередине. Т.е. не стоит стремится на старте сразу сделать "полную и правильную" карту контекстов, это все равно невозможно - придут новые вводные и карту придется перестраивать, и чем больше наработали по этой карте, тем больше придется переписывать.
С другой стороны, совсем без карты нельзя, поэтому в каждый момент времени должна быть актуальная гипотеза о будущей целевой карте контекстов (та, в которую мы верим и которую подкручиваем по мере появления новых вводных), и одновременно упрощенная карта текущего состояния, в которой может быть какие-то контексты объединены, какие-то отсутствуют, но у нас есть четкое понимание как, в какой ситуации и какие изменения модели будут предприняты, чтобы прийти к целевой карте.
Это означает, что мы, действительно, можем начать с простого монолита, например, с общей модели заказа, но эта модель развивается не стихийно, а мы как бы закладываем ростки будущего разделения в архитектуру, в принципы построения системы, и разваливаем контексты и модели на части, как только возникает такая необходимость.
с одной стороны, такой подход позволяет избежать лишних усложнений на старте, а с другой, его реализация требует еще более высокой квалификации, опыта и "насмотренности", чтобы контролировать архитектурные принципы еще до того, как они нашли фактическое воплощение в реальном выделении модулей, интерфейсов и сервисов.
Грубо говоря, писать простой код оказывается еще сложнее, чем писать сложный :)

Что такое настоящий бизнес-анализ, как я это вижу

Опишу линейно, хотя там есть несколько циклов:
1. Взять первичный запрос, сформулировать в виде проблемы, также если у инициатора есть видение решения, тоже сформулировать
2. Определить, о каком участке бизнеса идёт речь, построив модель контекста
3. Построить онтологию и модель деятельности на этом участке
4. Выявить организационные роли в окружении участка бизнеса и их интересы, оценки текущей реализации интересов
5. Построить проблемное месиво и структурировать его через причинно-следственные связи (дерево текущей реальности), найти корневые причины, экономически измерить ущерб, наносимый последствиями
6. Построить дерево будущей реальности, выйдя на целевые эффекты
7. Сформулировать ограничения на решение
8. Из интересов оргролей сформулировать требования к решению
9. Разработать несколько вариантов решений, для каждого оценить стоимость и риски
10. Обосновать выбор конкретного решения
11. Принять участие в заказе, реализации и приёмке решения
12. Оценить эффект от решения, соотнести его с плановым

#бизнес_анализ

Забавный плагин к VSCode для визуализации json
https://marketplace.visualstudio.com/items?itemName=AykutSarac.jsoncrack-vscode
https://jsoncrack.com/
До XMLSpy ему, конечно, как до луны, но выглядит симпатично, когда нужно осознать структуру JSON-документа может быть полезно
#инструменты #json #vscode

На днях обнаружил, что неправильно трактовал понятие Application Interface в нотации Archimate. Я как-то по инерции (и пиктограмма это поддерживала) думал, что это примерно то же самое, что и Interface в UML или SysML. Однако внимательное изучение определения показало, что это понятие ближе к понятию Port из UML или SysML.

Archimate: An application interface represents a point of access where application services are made available to a user, another application component, or a node.

Сходство с портом подчеркивается отношением composition, которое принято использовать, чтобы показать, что интерфейс (точка контакта) - это часть приложения.

SysML: Ports are points at which external entities can connect to and interact with a block in different or more limited ways than
connecting directly to the block itself.

UML: port is a structural feature of a classifier and specifies a kind of gate that represents an opening between the environment in which the classifier is embedded and the interior of the classifier.

Т.е. в SysML/UML точка контакта приложения/класса/блока с внешним миром обозначается портом, а интерфейс описывает протокол взаимодействия с этой точкой (точнее даже, между двумя точками/портами - на одной указываем, что интерфейс provided, а на другой, что он required).
Но вот в Archimate есть элемент Interface, который точка контакта, причем, судя по Cookbook, он обозначает только тот порт, который Provide какой-то интерфейс/сервис, но вот элемента, обозначающего программный интерфейс в смысле "контракт, протокол, правила взаимодействия", похоже, что нет☹️
Т.е. я не понимаю как корректно выразить утверждение, что два сервиса реализуют один и тот же интерфейс в смысле "контракт", а другой сервис этот контракт потребляет. Ведь интерфейсы в смысле "точки контакта" у них объективно разные. Может показаться, что Application Service - хороший кандидат на такую роль. Но мне кажется, это более абстрактная сущность. Сервис может быть, например, управление информацией о заказах, к нему может прилагаться несколько интерфейсов - REST, асинхронные команды через кафку и GRPC. И в каждом интерфейсе будет своя спецификация.
🤔 Коллеги, что думаете?

#archimate

Запоздалая картинка для иллюстрации

Один из важнейших принципов, который позволяет снизить темпы нарастания сложности, это принцип неразрастания кодовой базы без необходимости, который еще принято формулировать как YAGNI («You aren't gonna need it»).

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

Если же код пишется "на будущее", без четкого понимания зачем это делается, кто и как будет его использовать в обозримом будущем, то польза от него умозрительная, а вред самый настоящий. Я стараюсь такой код не писать сам и всячески препятствую его появлению в кодовой базе.

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

Что же делать? Общего решения, как всегда нет, но есть несколько стратегий, которые позволяют хоть как-то двигаться, а не сидеть и ждать.
- Демонстрационная реализация. Совершенно не обязательно делать потенциальный функционал в production ready качестве, чтобы только его продемонстрировать и продать. Такая демонстрационная реализация имеет единственную цель - показать наличие функционала и найти потенциальных покупателей. После продажи его все равно придется переделывать, так давайте хотя бы не будем на него тратить сильно много времени и сил, не так жалко будет выкинуть. Так мы сильно улучшаем отношение польза/вред, но надо понимать, что в этом подходе мы разрабатываем не функционал продукта, а инструмент продаж, и требования (НФТ) к такого рода реализации будут другими.
- Развитие продукта вслед за продажами/проектами. Делать функционал не сразу, а по мере появления клиентов, которые будут им пользоваться, набивать шишки и развивать. Так мы при разработке приносим не только вред, но и пользу.

❗️P.S. Не надо думать, что "демонстрационная" реализация чем-то хуже чем "настоящая". Это не менее важная часть процесса разработки продукта, просто это немного другой продукт и у него другие пользователи.

Коллеги, 20-21 апреля, в выходные дни, планирую выступить на онлайн-конференции «Systems Design» по проектированию ИТ-систем с докладом «Роль аналитика в создании информационных систем».

🔺Какой формат конференции?
В первый день Вас будут ждать 3 секции докладов:
— Enterprise Solution Architecture & Design
— Software Architecture & Design
— Data Engineering

Сейчас уже собрано 13 докладов от ведущих экспертов в разработке, проектировании, анализе и архитектуре.

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

🔺Кому конференция будет особенно полезна?
— Разработчикам
— Архитекторам
— Системным аналитикам
— ИТ-специалистам, которые интересуются вопросами проектирования

Более подробно про конференцию, воркшопы и доклады Вы можете узнать в отдельном TG-канале и на сайте.

Присоединяйтесь, чтобы не пропускать важную информацию!

В прошедшую субботу выступил на конференции «Systems Design»
📎презентация во вложении

Большое спасибо организаторам за приглашение и возможность выступить.
Попытался краешком зацепить кусочек большого айсберга про моделирование и декомпозицию окружающей действительности. В докладе практически ничего не было про архитектуру, скорее про подготовительные мероприятия. Архитектура - это способ решения некоторой задачи, и часто вижу, что у многих есть склонность приступать к решению задачи без формулировки исходных условий. Это как если бы в школьной задаче по физике мы услышали несколько слов и чисел и, не вникая в то, откуда они взялись, как связаны с реальностью, кинулись бы подставлять их в формулы и получать какие-то ответы. Поведение школьника "Разделили какие-то метры на какие-то секунды и получили какую-то скорость" превратилось в "Услышали какие-то слова, сделали какие-то микросервисы и формочки с этими словами, получили какую-то программную систему".
Зато быстро, технично и с применением всех правильных технологий.
А это точно то, что надо было сделать?
https://www.youtube.com/watch?v=XaKtt3eIkkg&t=3s

О, как это ехидно и точно...

—
Офлайн-встреча об AI для предпринимателей: https://news.1rj.ru/str/aioftheday/1331

Многие рисуют диаграммы в Draw.io и радуются. А я что-то чем дальше, тем реже пользуюсь этим инструментом.
Попытался сформулировать почему.

🔸 Что такое архитектурная диаграмма? Это модель, представление, форма описания какого-то аспекта будущего или существующего решения.
Диаграммы мы обычно рисуем в какой-то нотации, которая задает язык, понятия и смыслы, с помощью которых мы формируем модель.
С помощью выразительных средств выбранной нотации мы формулируем набор утверждений, например:
- Наша система состоит из 5 сервисов, которые называются вот так
- Нашей системе для работы необходима Kafka, которая обеспечивает функционирование топиков, через которые наши сервисы обмениваются данными
- Сервис "А" взаимодействует с сервисом "Б" по интерфейсу "И"
- Сервис "С" использует СУБД "У"
ну и так далее.

Да, нарисовать такую схемку в Draw.io легко и просто почти в любой нотации. А дальше начинаются многочисленные "НО".

🔹 Во-первых, Draw.io - это просто рисовалка квадратиков и стрелочек. Она не контролирует корректность утверждений с точки зрения выбранного языка. Запросто можно нарисовать, что интерфейс "И" реализует Сервис "Б", и ничего за это не будет. Отсюда два возможных последствия - либо архитектор сам строго и внимательно следит за корректностью диаграммы с точки зрения нотации, либо строгость и точность диаграмм будет "плавать", и как следствие, будет снижаться точность принятых решений, ведь неточности и расплывчатости каждый "читатель" будет трактовать по-своему. И что-то мне подсказывает, что второй кейс будет встречаться существенно чаще.

🔹 Во-вторых, такие модели просто невозможно поддерживать в сколько-нибудь сложных проектах. Ну вот, нарисовали мы такую диаграммку, обсудили с коллегами и решили, что нужно сделать разбиение чуть-чуть иначе, функции сервисов чуть-чуть по другому разложить. Теперь нужно это решение отразить в модели. Хорошо, когда у нас одна, ну две диаграммы. А если их десятки, а то и сотни, причем один и тот же элемент системы в разных видах представлен на разных диаграммах? Конечно, можно на это забить, и поменять только ту пару диаграмм, которые обсуждали, но дальше это приводит к тому, что накапливается большое число диаграмм непонятного статуса: невозможно понять, отражают они реальность или нет?

По итогу, я для себя выбрал два подхода к моделям, и ни для одного из них Draw.io не подошел:
- Нестрогие диаграммы, картинки, схемки и прочие наброски, которые делаются "в моменте", для текущих обсуждений и не поддерживаются в дальнейшем.
Тут нужен инструментарий максимально простой, легковесный, доступный. Чаще всего я использую легковесные рисовалки типа Excalidraw или yEd. Попытки использовать в этом качестве Draw.io не увенчались успехом, чтобы сделать даже простенький набросок нужно очень много всего нажимать и корректировать.

- Строгое моделирование для документирования решений и отслеживания изменений. Делается в специализированных моделерах, которые контролируют нотацию, отслеживают представления, в которых используются элементы модели.
Вносить изменения в модель может быть трудоемко, поэтому все изменения вносятся после того, как ключевые моменты уже обсуждены и приняты на уровне набросков. В качестве моделера Draw.io использовать не получается, каждая диаграмма - сама по себе. Тут я использую что-то вроде Archi, Visual Paradigm, Sparx EA, для таких инструментов диаграмма - это лишь интерфейс для работы с моделью.
#инструменты

Всем привет!

Я сейчас повторяю одно исследование про диаграммы (в частности, UML), и прошу вас принять в нем участие. Что именно я воспроизвожу: в 2014 году исследователи из Трирского университета проводили опрос про использование диаграмм, эскизов и набросков при разработке и проектировании ПО в Германии и США. Я взял их опросник и перевел на русский: https://forms.gle/zU7PncWsWc9u3cXZ6

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

В анкете есть несколько вопросов именно про UML — возможно, для архитекторов это не так актуально, но заодно мы как раз и это узнаем). Если вы создаёте диаграммы в другой нотации — напишите в последнем ответе, там в свободной форме можно дописать комментарии.

Если у вас есть возможность — отправьте опросник своим коллегам и знакомым, в том числе программистам; так мы обеспечим представительство большего числа профессий в ИТ. У меня уже есть ответы системных и бизнес-аналитиков, теперь собираю архитекторов и программистов.

Итоговые результаты опубликую у себя в канале и здесь тоже обязательно продублирую.

Пост согласован с @mxsmirnov

Промежуточные итоги по опросу:

164 ответа (надеюсь, наберем ещё)
47% — системные аналитики, 24.4% — архитекторы, 16.5% — бизнес- или фуллстеки.
Почти все из средних (37,2%) или крупных (48,8) компаний, почти все из России.
По отраслям: 38,4% — финтех(!), 11,6% — ритейл, 11% — госпроекты, 9,1% — автоматизация производства.
Проекты в основном крупные: от 11 человек и выше (суммарно 58,5%), и 33,5% — от 4 до 10 человек.

Теперь самое интересное:
🔹 67,1% составляли диаграммы буквально на днях или в этом месяце, 10,4% — прямо в течение дня, когда проходили опрос.
🔹 88,4% вносили несколько изменений в диаграмму после создания(!)
🔹 Суммарно потраченное время на диаграмму: несколько часов (43,3%) или даже дней! (11,6%). За час уложились 34,8%.
🔹 При этом в основном над диаграммой работает 1-3 человека (51,2% работают в одиночку).
🔹 Срок жизни диаграммы в основном около года (34,8%) или больше (25,6%), и здесь впервые значимая величина ответов "не знаю" (10,4%)

Диаграммы в основном скорее формальные, но не идеально формальные.
Чисто UML-ных диаграмм около трети, с некоторыми элементами — больше половины. Совсем без UML — 18,4%

Для чего рисуют (только ответы >50%):
➡️ Зафиксировать требование
➡️ Презентовать решение
➡️ Объяснить задачу
➡️ Спроектировать архитектуру
➡️ Проанализировать требования

Что чаще всего описывает диаграмма:
➡️ Архитектуру
➡️ API / интеграцию

Понятно, что с большим отрывом лидирует Sequence Diagram: более 70% ответов, следующие за ней — Use Case (45,7%) и State Machine (43,9%). Совсем не используют UML 6,7%.


Средний возраст респондентов — 35 лет, средний стаж — 5 (правда, есть выбросы на 20, 25 и 30 — видимо, на таких сроках уже пятилетками считают, детали смазываются 😂).

Корреляции показателей пока не считал, там должно быть интересно.

Ещё очень интересные комментарии — спасибо огромное всем, кто развернуто написал!


В общем, что хочу сказать — пока каких-то крупных инсайтов нет, но что бы я выделил:

⭐️ Большинство аналитиков рисуют диаграммы, но многие не для того, чтобы разобраться или что-то спроектировать, а потому, что в документации есть такой раздел. Некоторые даже не знают, куда эта документация дальше пойдет. Такие дела.

⭐️ UML жив, тут даже сомнений нет. Но жив он частично. И используется совсем не так, как был придуман. От всего UML осталась диаграмма последовательности (и она ого-го как используется!), диаграмма вариантов использования (вот это меня удивило, думал, её мало кто использует) и диаграмма состояний. При этом сиквенс в основном фиксирует уже спроектированное решение — тут, конечно, нужен корреляционный анализ, но пока кажется это так.

⭐️ С другой стороны, почти 20% живут без всякого UML, и им норм.

⭐️ Лично меня удивила популярность диаграммы юскейсов — правда так много людей её используют? А зачем?

В чём результаты опроса сошлись с экспертами индустрии:
Sequence diagrams, the only good thing UML brought to software development. Это статья от создателя mermaid.js. Там и про смерть UML с разных позиций, и про пользу сиквенсов, и про то, как их использовать. С цитатами типа "The reward of the clarity of sequence diagrams is worth the pain and boredom of learning all the others at university" и "Sequence diagrams are the only type of diagrams I use anymore."

Статья классная, попробую перевести её, как будет время.

А итоговый вывод: UML — как латынь для некоторых наук. Мёртв-не мёртв, а лучше знать хотя бы основы и понимать, как его правильно применять сейчас. Lingua Franca для разработки.

Красивое пошаговое визуальное объяснение как работает алгоритм Raft для достижения согласованного состояния распределенных систем.
https://thesecretlivesofdata.com/raft/
#distributed #raft

Не удержался, вступил в холивар про хореографию и орекстрацию https://news.1rj.ru/str/c/1120099288/159035

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

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

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

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

ArchDays

1 ноября пройдет конференция ArchDays. Мы продолжаем отбор выступлений.

Темы выступлений:
- Процессы проектирования
- Практики проектирования
- Инструменты проектирования
- Обучение архитектуре
- Собственная разработка

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

Подавайте темы для выступлений, приглашайте выступить знакомых.

Ссылка: https://archdays.ru

Если кого-то хотите увидеть на конференции, пишите в тред, отправлю персональное приглашение.

Увидимся на ArchDays!

Репост приветствуется :)