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

Кстати, еще одна ссылка к вебинару - обзор истории ADR от Olaf Zimmermann (ZIO) https://ozimmer.ch/practices/2020/04/27/ArchitectureDecisionMaking.html

Разрешите представить Виктора Хоменко (@viktorkho), Билайн в Казахстане, Алматы, который теперь вместе со мной будет администратором наших групп по ИТ-архитектуре

Оригинальное описание Леонардом Ричардсоном его модели зрелости RESTful API объясняется вот здесь: https://www.crummy.com/writing/speaking/2008-QCon/act3.html Возможно, кому-то этих слайдов и текста будет достаточно. Идея просто отличная.

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

Richardson Maturity Model

Обнаружил, что в январе 2022 The Open Group выпустило руководство о том, как делать микросервисы по TOGAF ADM. https://publications.opengroup.org/togaf-library/g21i Вот прям по тупо по процессу, со всеми фазами: бизнес-архитектура, архитектура данных и т.д. На 50 страниц руководство.

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

В далеком 1987-м Джон Захман предложил любую модель системы причислять к одному из трех фундаментальных типов: описание данных, описание функций или описание физической структуры системы.

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

Спасибо за большое количество отзывов на такую маленькую заметку. Было бы ошибкой с моей стороны попробовать ответить на все комментарии сразу, т.к. они очень разные. Постараюсь сделать это постепенно. Начну, пожалуй, со сложности https://xn--r1a.website/c/1304614627/18955

Во-первых, поделюсь ссылкой на перевод старого, но всё еще актуального текста Ефима Натиса Покорение сложности ИТ Удивительно, но ссылки на этот легендарный текст в этом канале до сих пор не было.
Во-вторых, уже от себя замечу, что разные виды сложности можно и нужно различать. Есть сложность реальная, проистекающая из большой вариативности объектов, отношений и вариантов развития событий. Есть сложность невынужденная, связанная с выбором не самого подходящего варианта реализации. А еще бывает сложность мифологическая. Примером такой сложности является популярная в своё время история о том, что интеграция точка-точка проигрывает интеграции через серверную шину. Вообще, любые комбинаторные предположения должны нас насторожить. В реальности интегрировать все системы со всеми никто и не собирался. Это просто не требуется. Сейчас похожий сюжет используют в страшилках про сложность взаимодействия между микросервисами в топологии каждый с каждым. Зачем бы это понадобилось сказать сложно, но выглядит вполне пугающе

И еще одно замечание. В упомянутой статье https://www.osp.ru/os/2005/07-08/185761 Натис вводит следующее определение

Сложность (IT Complexity) — это мера нашей неспособности понимать, использовать, «ремонтировать» и наращивать свою ИТ-среду. Любое решение, помогающее воспринимать, диагностировать и обслуживать эту среду как единое целое, упрощает ее. А любые факторы, препятствующие этому, ее усложняют

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

Нашел у себя в ссылках запись вебинара "Архитектура предприятия: Что происходит?" https://youtu.be/YIgNkop6xvY , на котором Святослав Котусев рассказывает историю дисциплины EA (на русском)

аудиодорожка из этого видео https://xn--r1a.website/c/1304614627/18995

А тем временем, я продолжаю проводить обучение по ИТ-архитектуре. Ближайший курс Микросервисная архитектура начнется 11 апреля

Появившаяся в прошлом году серия руководств Patterns of Legacy Displacement продолжает расширяться. Новая статья Transitional Architecture появилась как раз вовремя. Я готовлю небольшое выступление на тему Модернизация унаследованных приложений, а тут позавчера выходит такое подспорье про перехватчики событий и прочие связанные вещи

Помните, в начале нулевых появилось множество гибких методологий разработки: XP Кента Бека, семейство Crystal Коберна, ICONIX и т.д. А потом они все отошли на второй план и на какое-то время остался один SCRUM, т.е. подход, который в наименьшей степени можно назвать методологией разработки. Скорее, это мета-методология. Она не отвечает на вопрос Что делать? давая вместо этого ответ на вопрос Как? (см. Scrum guide). По сути, рекомендация звучит так: изобретите свой собственный процесс. Но этот ваш процесс должен быть эмпирическим, прозрачным, адаптируемым и т.д. Т.е. задан только самый общий минимум техник и инструментов.

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

... Но вопросы что делать, как вырабатывать и принимать решения, остались. На них никто не ответил! ИТ-архитектура как-то пытается заполнить этот разрыв. Поэтому и шаблоны архитектурных решений ADR содержат наборы альтернатив и описание мотиваций выбора, как это принято у solution architects, и DDD так востребован и истории про топологии команд из той же серии…

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

🥁InfoQ продолжает традицию вставлять слово микросервисы во все свои публикации. В этот раз абсолютно не к месту.

В общем-то, вполне неплохая заметка о Technology Capability Plan (TCP) https://www.infoq.com/articles/managing-technical-debt-microservices/ естественно, не имеет к микросервисам никакого отношения.

На ArchDays’19 я рассказывал, что специфика работы с техдолгом в современных распределенных системах состоит в том, что вы можете выбросить отдельный микросервис вместе с накопленным в нем техдолгом. Если угодно, списать технический долг. И вы не можете этого сделать в больших сильносвязанных системах. Но можете перехватить команду или запрос и передать его/её обработку в отдельный сервис

Pace layered подход, сформулированный когда-то в Gartner (см., например https://mxsmirnov.com/pace-layer/), это не только о том, когда надо, а когда не надо собирать требования, например

Предлагаю посмотреть на эту классификацию как на набор из трех фундаментальных ценностей, которые ИТ может принести:
1. Дать вам чужую технологию и операционную модель (system of records)
2. Поддержать ваши уникальные операции (system of differentiation)
3. Выявить потребность (system of innovation) Именно третья ценность является наиболее актуальной. Её мало кто понимает. Другие (инженерные) технологии так не умеют. Для них важно заранее знать что именно мы хотим сделать (вариант 2). А вот ИТ умеет работать в ситуации, когда владелец ресурсов совершенно не представляет чего хотеть, как с пользой задействовать доставшийся ему ресурс

Вот эта картинка (Hanschke, Strategic IT Management...) иллюстрирует основной вызов, стоящий сейчас перед бизнес-архитектором. Заключается он в необходимости разработки метамодели деятельности организации. Две идеи с картинки:

1. В информационной архитектуре не существует никаких уровней или доменов. (Бизнес-объект расположен между прикладным уровнем и уровнем бизнеса). Система информационных понятий едина (по вертикали). Одни и те же концепции пронизывают все слои: прикладной, бизнесовый, технологический (помните ubiquitous language).

2. В разных бизнес-доменах при организации деятельности используются разные концепции. У кого-то это продукты, у кого-то бизнес-процессы, а у третьих что-то совсем иное. Нет никакой единой модели деятельности организации, основанной, например, на бизнес-процессах. В каких-то функциональных областях процессы заходят, а в других – нет. Предметную область для каждого бизнес юнита надо проектировать и это снова про Domain Driven Design

Недели три я перечитываю снова и снова Why Software Is Eating the World 2011 года и другие рассуждения на эту тему от Marc Andreessen.

Читаю и никак не могу уловить тот тайный ингредиент, делающий software столь востребованным и уникальным продуктом. Таким, что нужен все большему и большему количеству заказчиков и во всё больших и больших объемах. Рассуждения о том, что процессора стали слишком производительными и чересчур дешевыми выглядят неубедительно. История про мобильные приложения если и была актуальна, то во времена написания статьи, т.е. десяток лет назад, а софт и его разработчики нужны всем не меньше прежнего. Почему?

Раздел Techniques 26-го технологического радара (29 марта 2022) оказался интересней, чем того можно было бы ожидать. Обычно, я сначала смотрю на новые или поменявшие своё место темы (кстати, на картинке такие обведены полным кругом или же его четвертинкой). В области Trail таких немало, я бы отметил:

- Documentation quadrants Очень полезно ознакомиться вот здесь
- Rethinking remote standups Все и так уже сделали
- Server-driven UI Речь про мобильные приложения. Если кто успел так сделать и больше не нуждается в публикации каждой версии в магазине приложений, то он молодец
- Tactical forking Тоже полезно почитать здесь
- Transitional architecture Обсуждали выше, в связи с Patterns of Legacy Displacement

В общем, только definition of production readiness (DPR) как-то мне не откликнулся. Может я просто недостаточно погружен в Google SRE

Вчерашнее обсуждение распределенной, а теперь и опенсорсной, YDB в нашей группе несколько схлынуло. Смотреть надо, но думаю там будет все более-менее нормально. Однако, вопрос: а не потеряют ли актуальность все эти CQRS-ы и Event Sourcing-и? - после таких новостей остается

И просматривая ссылки на эту тему я совершенно случайно обнаружил книжку Gregory Young Versioning in an Event Sourced System (практически дописанную, в 90% готовности) Книжку можно купить, а можно воспользоваться кнопкой "Free To Read Online". Я прям зачитался

Поделюсь слайдом из одной недавней презентации на давно уже обозначенную тему