Вопрос к тем, кто использует ADR и считает полезным. Как вы решаете проблему, описанную @mxsmirnov здесь: https://www.youtube.com/live/9vtf33NIJrE?feature=share&t=40m30s на 40:30?

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

#SoftwareArchitecture

Коллеги, спасибо всем за активное и качественное обсуждение в чате канала. В результате этой дискуссии у меня сформировалось понимание: https://www.tgoop.com/emacsway_chat/5759

Возвращаясь к вопросу, который озвучил @mxsmirnov . Полный контекст вопроса https://www.youtube.com/live/9vtf33NIJrE?feature=share&t=38m20s начинается с 38:20.

Максим обращает внимание на то, что архитектурное решение - это ассоциация в архитектурной модели, причем n-арная.

Иными словами, ассоциации находятся не между ADR, а внутри ADR между мотивационными элементами (требованиями, ограничениями, целями, драйверами, стейкхолдерами и т.д.).

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

Хороший пример приводит Игорь Беспальчук: "Пилоту нужно уворачиваться от зениток, а бомбардиру нужно чтобы вели ровно, чтобы лучше прицелиться. Конфликт неизбежен и успех в поиске баланса."

Другой пример - добавили mtls - повысили безопасность, но ухудшили performance.

Какая причина появления ADR? Как писал сам Michael Nygard https://www.cognitect.com/blog/2011/11/15/documenting-architecture-decisions , он пытался найти баланс между тяжеловесностью традиционной архитектурной документации и её полным отсутствием в условиях Agile.

О чем это говорит? Почему в Agile требования выражаются чаще всего посредством PBI (Story)? Почему не делают спецификаций и трассировок? Потому что трассировки нужны для предвидения (prediction) последствий решения, в то время как Agile основан на итеративной модели, где основной способ обработки неопределенности осуществляется опытным путем (adaptation). Long read по теме:

- https://dckms.github.io/system-architecture/emacsway/it/sdlc/models/agile/agile.html

- https://dckms.github.io/system-architecture/emacsway/it/sdlc/uncertainty-management/balancing-prediction-adaptation.html

Иными словами, Agile был ориентирован на проекты, где создание артефактов для заблаговременного (prediction) разрешения неопределенности путем логического вывода себя не оправдывает экономически, ибо дешевле, как говорится, проверить "методом тыка" (adaptation).

Отсюда вывод - если сам способ выражения требований в Agile (PBI) не обеспечивает трассировки (связи между PBI являются зависимостями, а не трассировками), то и в ADR она и подавно не нужна.

Если мы посмотрим на дату статьи Michael Nygard, то увидим 2011 год. О чем это говорит? Это говорит о том, что в это время на рынке происходит рост сложности и размера среднего проекта. Именно по этой же причине на рынке возникает запрос и на микросервисы, и на гибридные SDLC-модели разработки (цель которых сводилась к снижению доли Adaptation в пользу Prediction). Dean Leffingwell в 2011 выпустил книгу Agile Software Requirements и первый релиз SAFe.

Примерно через пару лет Brandolini изобретает Event Storming, потому, что:

💬 "...iterative development [на тот момент стал - прим. мое] is expensive. It is the best approach for developing software in very complex, and lean-demanding domains. However, the initial starting point matters, a lot. A big refactoring will cost a lot more than iterative fine tuning (think splitting a database, vs renaming a variable). So I'll do everything possible to start iterating from the most reasonable starting point."
—"Introducing EventStorming: An act of Deliberate Collective Learning" by Alberto Brandolini

💬 "Upfront is a terrible word in the agile jargon. It recalls memories the old times analysis phase in the worst corporate waterfall. Given this infamous legacy, the word has been banned from agile environments like blasphemy. But unfortunately ...there's always something upfront. Even the worst developer thinks before typing the firs line of code."
—"Introducing EventStorming: An act of Deliberate Collective Learning" by Alberto Brandolini

Еще через пару лет выходит статья "Insights from 15 Years of ATAM Data: Towards Agile Architecture". ATAM в Agile!!!

Появляется MiniQAW.

Таким образом, был конкретный рыночный запрос на рост доли Prediction в обработке неопределенности в силу роста размера среднего проекта на рынке, который Michael Nygard пытался решить путем введения компромиссной формы документирования, о чем он сам же и говорит.

Продолжение следует...

В предыдущем посте мы установили, почему ADR не содержит трассировок - за ненадобностью в своем историческом контексте ввиду того, что они создавались для такой SDLC-модели, в которой преобладает эмпирический способ обработки неопределенности (adaptation), в то время как трассировка больше нужна для заблаговременного способа обработки неопределённости путем логического вывода (prediction).

Исторический контекст появления ADR сопровождался ростом размера среднего проекта на рынке, численностью команды (и команд) его разработки, ростом доли scaled agile и гибридных SDLC-моделей, появлением новых практик заблаговременного разрешения неопределенности. Выделим важное - маятник Prediction/Adaptation двигался в сторону Prediction. Очень хорошо этот момент отражается в Open Agile Standard:

💬 "When combining intentional and emergent architecture, decisions that come from intentional architecture may change. New ones are added and past decisions can be reversed. Therefore, it is important to document the motivations behind past decisions. An Architecture Decision Record (ADR) provides an Agile and lightweight way of doing this."
-- "Open Agile Architecture™ :: 5.2. Architecturally Significant Decisions"

Обратите внимание на фразу "intentional [Prediction] architecture may change [Adaptation]". Эта фраза хорошо выражает причины появления ADR.

На рынке сложилась ситуация, когда на среднем рыночном проекте без архитектурной документации уже нельзя, а с полновесной архитектурной документацией еще нельзя. Эта ситуация привела к появлению ADR, Event Storming, C4 Model и других легковесных практик intentional architecture.

По правде говоря, существуют инструменты, способные создавать связи между ADR, например, https://github.com/npryce/adr-tools

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

Из всех архитектурных артефактов я чаще всего на практике применяю мотивационную диаграмму и Event Storming в терминах C.1.10. Business Process Cooperation Viewpoint.

Вообще говоря, предпочитаемые мною методы документирования архитектуры описаны в
https://publications.opengroup.org/g20e

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

И вот теперь я позволю себе переформулировать вопрос, поставленный Максимом Смирновым. Agile за это время изменился. Если раньше преобладали single-team модели, то сегодня - scaled agile. Стремительно увеличилась доля гибридных SDLC-моделей разработки на рынке, в коллективах разработки появились выделенные роли аналитиков и архитекторов, работа с требованиями обрела полноценный характер, стали популярны системы управления требованиями. Сохранил ли при этом формат ADR, предложенный Michael Nygard, свою актуальность? Не пора ли добавить ему полноценную поддержку ассоциаций?

Если мы посмотрим на шаблоны ADR, то мы увидим следующее (продолжение следует):

Если мы посмотрим на шаблоны ADR, то мы увидим следующее:

💬 "Related requirements: Decisions should be business driven. To show accountability, explicitly map your decisions to the objectives or requirements. You can enumerate these related requirements here, but we’ve found it more convenient to reference a traceability matrix. You can assess each architecture decision’s contribution to meeting each requirement, and then assess how well the requirement is met across all decisions. If a decision doesn’t contribute to meeting a requirement, don’t make that decision."
-- https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/templates/decision-record-template-by-jeff-tyree-and-art-akerman/index.md

💬 Requirement: The text that details the requirement itself
...
Priority: A statement of priority and claim on resources
Stakeholders: Parties materially affected by the requirement"
-- https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/templates/decision-record-template-using-planguage/index.md

💬 "List all relevant use case / requirements documents."
-- https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/templates/decision-record-template-by-edgex/index.md

💬 "An ADR should log the resolution of at least one architecturally significant requirement"
💬 "trace the decision back to requirements"
-- https://ozimmer.ch/practices/2023/04/03/ADRCreation.html

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

Присмотрел для себя два инструмента:
- https://github.com/melexis/sphinx-traceability-extension
- https://sphinx-needs.readthedocs.io/en/latest/

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

В статистике репостов обнаружил неплохой канал https://www.tgoop.com/nikitapinchuk

Коллеги, хочу дать рекомендацию первоклассному архитектору, которого знаю лично с 2010 года: @alexey_prokopchuk

Он впервые на российском рынке, и поддержка не помешала бы.

Ручаюсь за него, как за себя самого.

Где-то мы обсуждали причины появления Golang, и там среди прочих причин звучало появление впервые в истории огромного парка железа, низкий к-т которого выливался в немалые деньги. Тут есть немного цифр по этому поводу:
"Using Go allowed MercadoLibre to cut the number of servers they use for this service to one-eighth the original number (from 32 servers down to four), plus each server can operate with less power (originally four CPU cores, now down to two CPU cores). With Go, the company obviated 88 percent of their servers and cut CPU on the remaining ones in half—producing a tremendous cost-savings."
- https://go.dev/solutions/mercadolibre

Нашел эту цитату в статье, которая сравнивает Golang и Rust:
- https://thenewstack.io/rust-vs-go-why-theyre-better-together/

Этот фактор объясняет, почему Golang стал популярным на рынке РФ, сформированном под влиянием крупных компаний-гигантов, которых вопрос эффективности утилизации железа действительно интересует.

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

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

Другая выгода - решения на Golang никогда не испытывали проблем с сертификацией во ФСТЭК/ФСБ, что немаловажно в условиях динамически меняющегося законодательства в сфере ИБ.

Вдруг, кто не знал, - возрождение https://zlibrary-asia.se/

[UPDATE]: Тут еще одной превосходной ссылочкой поделились: http://libgen.is

[UPDATE-2]: И еще одной: https://annas-archive.org

[UPDATE-3]: И еще одной: https://www.letmeread.net/

#Literature

Бомбовый инструмент управления проектами на простых текстовых файлах. Попробовал - остался в восторге. И уже начал использовать его.
- https://github.com/taskjuggler/TaskJuggler

Не хватает только работы со среднеквадратичным отклонением оценки (но этим вообще мало какой инструмент может похвастаться). Если допилить, то будет вообще песня.

Позволяет организовать собственную структуру файлов проекта для упрощения навигации.

Импортер из Jira:
- https://github.com/melexis/jira-juggler

Импортер из Redmine:
- https://github.com/chris2fr/redmine_taskjuggler

OpenProject integration:
- https://www.project-open.com/en/integration-taskjuggler

Импортер из Trac:
- https://trac-hacks.org/browser/taskjugglerplugin?rev=16580

Импортер из org-mode:
- https://orgmode.org/worg/org-tutorials/org-taskjuggler.html

Дока:
- https://taskjuggler.org/download/TaskJuggler-Workshop.pdf
- https://taskjuggler.org/tj3/manual/index.html

Примеры:
- https://github.com/taskjuggler/TaskJuggler/tree/master/examples

Просто запускаете: $ tj3 examples/Scrum/scrum.tjp и открываете сгенерированную html-у.

Web-based UI:
https://www.project-open.com/en/integration-taskjuggler

#Management

Великолепный сборник материалов по оцениванию/планированию/прогнозированию от Troy Magennis:
- https://github.com/FocusedObjective/FocusedObjective.Resources
- https://www.focusedobjective.com/

Статейка в довесок "Monte Carlo Forecasting in Software Delivery":
- https://medium.com/expedia-group-tech/monte-carlo-forecasting-in-software-delivery-474bb49cb3f9

[UPDATE]: "Towards Risk-aware Scheduling of Enterprise Architecture Roadmaps" (Redmine integration of the risk-aware scheduling) https://www.researchgate.net/figure/Redmine-integration-of-the-risk-aware-scheduling_fig8_333435127

[UPDATE-2]: Тут советуют походить по его сайту через web.archive.

[UPDATE-3]: И ещё по его medium: https://medium.com/@troy.magennis

Довольно интересная статья "Open Source and Proprietary Project Management Tools for SMEs", из которой я узнал про LibrePlan - Open Source project management tool, поддерживающий Monte Carlo из коробки:
- https://www.libreplan.dev/
- https://github.com/LibrePlan/libreplan

Демо:
- https://demo.libreplan.dev/

Не призываю, но на безрыбье... Django + Transactional Outbox: https://medium.com/@antunesleo/ensuring-data-consistency-in-microservices-using-django-jaiminho-and-transaction-outbox-to-avoid-e9fbc21e2dcc

Исходный код: https://github.com/loadsmart/django-jaiminho

Параллельно подвернулась неплохая статейка "Event Sourcing vs. Change Data Capture" by Eric Murphy:
- https://debezium.io/blog/2020/02/10/event-sourcing-vs-cdc/

See also: https://github.com/juntossomosmais/django-outbox-pattern

#DistributedSystems

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

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

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

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

Как говорил Gregor Hohpe:
"There's a definite Dunning-Kruger effect for authors.
The people who hold a ton of knowledge hesitate because they find their insights "obvious" or "nothing special".
Then you have people who write a lot but do little real work that they could base their writing on..."

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

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

Когда я говорю кому-то "используй PERT", то зачастую для человека это просто пустой звук, ибо из другого источника льётся "используй story points", из третьего - "noestimate" и т.п. Разобраться в этом может помочь эмпирическая проверяемость, но только как же её может проверить человек, который ни PERT, ни noestimate готовить не умеет? Это значит, что эмпирическая проверяемость должна быть обязанностью источника знаний, а не потребителя знаний. Иными словами, рынку нужны не информационные продукты (курсы, тренинги, статьи), а комплексные решения с измеряемой обратной связью. Это и есть та проблема, на решении которой я хотел бы сосредоточиться в обозримой перспективе, наряду с другой проблемой.

#Goal

Блог автора книги "Mastering Archimate":
- https://ea.rna.nl/
Есть что почитать.

#SoftwareArchitecture

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

Мой пост (как и другой) не об этом. В истории были и дворяне, которые посвятили свою жизнь интересам бедноты. Люди, поступающие "вопреки обстоятельствам", были, есть и будут всегда.

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

В этом отношении интересна книга Jeff Sutherland "A Scrum Book: The Spirit of the Game" о том, почему вместо роли Project Manager он ввел роль Product Owner.

Jeff - довольно проницательный руководитель и хороший диалектик (возможно, неосознанный), как и Владик Хононов.

Jeff ввел роль Product Owner вовсе не потому, что не было хороших Project Managers. А потому, что наложив на Project Managers ответственность за ROI он устранил зависимость от личностного фактора, ибо у Product Owner больше не было причин действовать в ущерб долгосрочным интересам проекта, т.к. те вошли в сферу его ответственности. Правда, сам Jeff признает, что таким образом он решил одну проблему, но породил другую проблему, ибо создал мотивацию Product Owner действовать в интересах бизнеса против технических интересов, подробнее здесь (начиная со слов "Интересно, что таким образом они пытались решить другую проблему...").

Да, есть хорошие Product Owners вопреки обстоятельствам, но тем не менее, мы регулярно слышим истории о том, что из-за какого-то Product Owner растет техдолг, кодовая база загнивает, стоимость разработки взлетает, а программисты разбегаются.

Можно сказать, что виной всему конкретная личность, и даже начать перебирать личности на позиции Product Owner до тех пор, пока не повезет с личностью. И это может даже сработать. Вот только таких личностей на все должности отрасли не напасешься.

А можно переделать процессы таким образом, чтоб устранить зависимость внутреннего качества программного обеспечения от личностного фактора, и тогда не придется "угадывать" с личностными качествами Product Owner. Именно так поступил Henrik Kniberg по той же ссылке. Изменяя систему мы изменяем системные проблемы.

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

Возвращаясь к своему посту - захламленность рынка знаний растет, и у этого есть своя причина в экономической плоскости. Означает ли это то, что на рынке больше никогда не появится нового Martin Fowler, Steve McConnell, Edsger Dijkstra, Donald Knuth и т.д.? Нет, не означает. Но означает ли это то, что все участники рынка экономически заинтересованы становиться такими самоотверженными светилами? Нет, тоже не означает. Означает ли это то, что проблема захламленности рынка растет? Да, означает. А значит, по законам диалектики должно появиться решение этой проблемы. Вопрос только в том, кто и какое решение предложит. Но оно обязательно возникнет, как в свое время возникла итеративная модель разработки или Bounded Context.

#Management #Goal

Превосходное пояснение природы сопротивления коллектива изменениям, от Gregor Hohpe "Reversing the disablement cycle:
Everyone does the right thing, yet nothing much gets done. How to break self-reinforcing bad habits":
- https://architectelevator.com/transformation/reversing-disablement-cycle/

P.S.: https://dckms.github.io/system-architecture/emacsway/soft-skills/change-making.html

#Psychology #Management

💬 "Vendors also create complexity in the product strategy. If marketing hasn’t coined a new buzzword or positioned a new-and-improved solution within 6 months, the sales pipeline is at risk."
-- Gregor Hohpe
https://architectelevator.com/architecture/it-complexity/

Gregor Hohpe разделяет точку зрения Niklaus Wirt.

💬 "System Integrators...

Generally, more complexity means more work and thus more revenue. This isn’t necessarily intentional or devious - self-preservation is at the very base of Maslow’s Hierarchy of Needs.

Consultants

While the SIs are the enterprise’s helping hands, consultants are the hired brains. They solve complex problems and devise IT strategies. But they also want to remain employed, so they might solve a problem almost completely, leaving just enough for more work to be done. Self-preservation equally takes hold here. In consultant vernacular this is called scoping or expectation management."
-- Gregor Hohpe
https://architectelevator.com/architecture/it-complexity/

Gregor Hohpe о той же проблеме неоправданного переусложнения.