Интересный результат...

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

Есть две крайности.
⭐ Первая крайность - оптимистичная оценка. Такая оценка обычно не учитывает риски, выдается в предположении что ничего плохого не случится, поставщики все привезут вовремя, никто не заболеет, а данных в базе будет ровно столько, сколько кажется сейчас, и никаких новых вводных не придет.
С одной стороны, так не бывает. Вероятность вписаться в такую оценку практически равна 0, но, с другой стороны, такая оценка - это очень полезная величина. Можно с большой уверенностью сказать, что лучше точно не будет.

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

👉 Скорее всего реальные сроки, бюджеты и ресурсы окажутся где-то между оптимистичной и пессимистичной оценкой.

❓Но вот где они окажутся?

Как же повысить точность оценок? Купить колоду карт Таро!

✍️ Во-первых, я предлагаю относится к оценке не как к попытке угадать реальность, а как к психологической величине, примерно как к ставке в игре "угадай мелодию":
" - Я смогу реализовать данную фичу за 14 дней "
" - Реализовывай! "
Такой подход переводит процесс оценивания из пассивной попытки "измерения будущего" в область квантовых эффектов, когда оценивающий влияет на объект оценки. После оценки не нужно пассивно ждать, пока все случится, чтобы сравнить оценку и реальность, а наоборот, следует активно воздействовать на реальность, чтобы она не сильно расходилась с оценкой, и оценку выдавать, в том числе, исходя из своих возможностей влияния. (а также и возможных последствий "промаха" :) )
👉 Оценка - это величина, в которую вы верите, и которая не сильно пугает.
Круто, если вы можете её обосновать расчетами. Но это вторично, первично именно психологическое отношение :).

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

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

Чем больше у вас будет возможности в будущем влиять на реальность, чем более стабильно и предсказуемо окружение - тем ближе оценка к оптимистичному краю📉. И наоборот, чем меньше стабильность, чем меньше влияния - тем больше оценка смещается к пессимистичному краю 📈.

👉Итого, методика получения "точной" оценки звучит так:
двигать оценку между крайностями, стремясь удержать её в диапазоне целесообразности
и добиваясь чувства психологического комфорта 🙂

💭 Кстати...
Ваша итоговая оценка может в разы превышать порог целесообразности.
Это не криминал, а лишь повод для переговоров.

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

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

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

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

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

На практике же все совсем не так. На начальном этапе продукта/проекте еще кто-то думает про архитектуру, рисует красивые схемки, модели и прочие описания, потом по ним что-то реализуется... А дальше система сама по себе, а архитектура - сама по себе. В лучшем случае есть реестр ADR-ок, как набор событий в Event Sourcing. И если тебе надо понять, что же там в системе на самом деле - то надо либо прочитать и осмыслить весь журнал ADR-ок, либо идти реверсить код. И второй вариант кажется более практичным...

Пытаюсь выстроить работу с архитектурой, как с моделью, на практике.
Пришел к тому, что нужно развивать поддерживать следующие модели:
1. Модель текущего состояния системы. Отражает факт. Применяется для анализа возможных изменений, онбординга, источник картинок для документации по системе. Акцентируется на фактическом состоянии архитектурных элементов и их взаимосвязей.
2. Модель возможного будущего. Отражает мечты и возможные планы. Используется для для планирования будущих работ и презентаций руководству. Зыбкая, часто изменяемая. Акцентируется на крупных элементах и отношениях, без внимания к деталям.
3. Модель планируемых изменений. Отражает изменения текущего состояния в рамках постепенного движения к светлому будущему. Акцентируется на том, какие архитектурные элементы нужно добавить/изменить/удалить в рамках развития системы. Из таких моделей формируется ADR.

Осталось только придумать, как всё это реализовать на Archi.
#моделирование #archi

Продолжение. Начало - https://xn--r1a.website/sysarchthoughts/71.
Итак, рабочая гипотеза следующая.

Основной тезис - все перечисленные выше виды моделей буду вести в одном файле-модели Archi.

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

Структура моделей задаётся папками, в которые раскладываются представления.
Верхнеуровневая структура папок выглядит так:
📂 Baseline - представления, которые описывают текущее состояние системы. Внутри они сгруппированы по типам/назначению (модели данных, описания поведения, структуры, развертывания и т.п.). Представления из этой папки берутся как базовые для новых задач, требующих архитектурного изменения
📂 Cases - сгруппированные по кейсам/задачам представления планируемых изменений архитектуры. Одна папочка - одно качественное изменение, описываемое в разных аспектах. Одновременно в работе может находиться несколько кейсов, которые ведут разные архитекторы. Каждый работает с представлениями в своей папке, это позволяет избегать конфликтов слияния.
📂 Future - представления, описывающие возможные варианты будущей архитектуры.
📂 Archive - папка с представлениями, которые не находятся в активной работе, но которые жалко удалять хочется сохранить.
Это завершенные кейсы, отклоненные варианты будущего, устаревшие представления текущего состояния и т.п.

Основной рабочий цикл выглядит так:
- Пришел запрос на архитектурное изменение - создаем подпапку в Cases, дублируем в неё нужные представления из Baseline
- Моделирование по кейсу ведется с представлениями в папке кейса - вносятся изменения, обсуждаются варианты, готовятся постановки задач
- По мере завершения разработки и внесения фактических изменений в архитектуру, архитектор изменяет затронутые представления в Baseline.

Сначала я предполагал, что изменяется непосредственно представление в baseline, сейчас пришел в решению, что представление именуется в соответствии с версией/номером релиза приложения/системы, архитектуре которой оно соответствует. При выходе версии с изменениями делается копия представления, которая именуется под новую версию, в ней отражаются внесенные изменения, а старая версия идет в архив.

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

#моделирование #archi

Продолжение мысли, высказанной ранее https://xn--r1a.website/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