И снова в нашей группе архитектурные katas. Крайне престижное 2-место и отличный пример архитектурного описания. Но, в первую очередь, хочу обратить внимание на отличную презентацию постановки задачи и предлагаемой архитектуры ИТ-решения https://youtu.be/NENcmM48n-M

Всем срочно учиться создавать слайдкасты!

Всем привет!
Вчера моя команда заняла 2е место в конкурсе O’Reilly Arch Katas.
Так получилось, что в этом раз нужно было по-сути расширить функционал системы, которую спроектировал Андрей Гордиенко и победил на одном из предыдущих мероприятий.

Вот что получилось в итоге у нас: https://github.com/vadagama/sever_crew
Если по-делу накидаете на вентилятор, буду признателен. Хорошие отзывы тоже люблю. 🙂

Лет 10 назад я увлекался штукой, которая называется adaptive case management (в других источниках слово adaptive заменялось на dynamic или даже advanced). Этот термин обозначал особый вид бизнес-процессов, для которых не всегда можно указать правильную последовательность шагов, ведущую к цели, да и не так уж она важна по сравнению со спецификой данного конкретного случая. Здесь есть некоторая игра слов, даже смыслов. Слово кейс, с одной стороны, обозначает портфель или папку с бумагами (материалы дела, история болезни и т.п.), а с другой - некоторый уникальный прецедент, требующий своего подхода или решения (кейс, при обсуждении успешных примеров в бизнес-школе). Обычно с кейсом работает специально назначаемый на него человек – case worker (лечащий врач, адвокат, в общем knowledge worker), который и решает, что, когда и зачем следует делать в сложившейся ситуации.

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

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

Хорошей вам пятницы, друзья!

Мэтт МакЛарти представил большой текст про Data Mesh https://blogs.mulesoft.com/api-integration/api-management-and-data-mesh/ Возможно, после первых абзацев вы решите что читать его вряд ли следует, но не спешите. Автор вовсе не собирается безоговорочно поддерживать новую модную концепцию блистательной Жамак Дехгани. И потому дальше по тексту он выскажется о том, чем data mesh не является, а так же поделится своими мыслями и сомнениями. Почему-то, такое теперь редкость

Наконец расставил тайм-коды https://youtu.be/kN7XNp9Feio

Не только O'Reilly проводят архитектурные ката https://youtu.be/6MDKKuqn07A

В чем реальная причина отказа от проектирования решений? Почему команды не описывают архитектуру? Есть разные варианты ответа на этот вопрос: потому, что ленятся; из-за того, что не видят конкретной пользы; просто некому этим заниматься (и некогда)… На мой взгляд, все эти причины несколько поверхностны. Т.е. они имеют место быть, но под ними часто скрывается причина более весомая. Часто это озвучивается в доверительном разговоре как:
- Мы попробовали, но у нас как-то не пошло!

И вот здесь уже есть, о чем поговорить. А кто именно пробовал: разработчик, аналитик, devops-инженер? И что именно пошло не так. Всё ведь просто (на первый взгляд). Нарисовать контейнерную диаграмму из C4 может даже школьник. Ну вот, кто-то, допустим аналитик, нарисовал. У него все получилось. Разработчики кивнули, сказали: да, похоже на правду. И в следующий раз все ОК. Автор окрылен, испытывает легкую эйфорию и уже считает себя немного архитектором! Но потом наступает облом. Жесткая посадка! Диаграммы не рисуются, с решениями все спорят, вылезает масса технических деталей, на которые следует обратить внимание. А еще ограничения, мешающиеся сделать правильно. В общем, пригрезившиеся ожидания стремительного роста компетенций вас, как архитектора, серьезно расходятся с реальным положением дел. Вообще, это называется кривая Бандуры! (см. рис. в следующем сообщении. Про Альберта Бандуру надо отдельного поговорить. Его кривая встречается часто, но теория социального научения глубже и интересней кривой). Архитекторами становятся те, кто преодолевает барьеры. Но часто этого не случается.
Архитектуру не делают по банальной причине: потому, что не умеют! В это сложно поверить тем, кто регулярно создает архитектуры: – Чего там уметь? Проектируешь варианты, потом сравниваешь! Или тем, кто сам не делал, а только читал об этом: - в книжке же все понятно! Но в большинстве случаев уклонение от проектирования - простое желание не заниматься незнакомой работой.

Что с этим делать – на вебинаре, безусловно, поговорим https://t.me/it_arch/1224

Кривая Бандуры

We have talked about Enteprise Architects and Solution Architects but did you know there are other types of Architects too? Here is a quick summary:

Talkitecht: Talks a lot about architecture but doesn't actually do anything useful.

Markitecht: Works for a software vendor. Their architecture slides are really marketing slides.

Barkitecht: Insists loudly that you must follow their recommendations but in reality has no power or authority. Their bark is worse than their bite. Alternatively - someone who does their best work on the back of a napkin at the pub.

Narkitecht: Spends all his time annoying project teams and complaining that nobody listens to him. (more common in the UK)

Snarkitecht: Writes posts like this (с) https://www.linkedin.com/posts/gideon-slifkin-a9813_we-have-talked-about-enteprise-architects-activity-6874258514122948608-qO-o

Всё же The Open Group - волшебная организация. В случайные моменты времени, очень не часто, кто-то там внутри просыпается и в блоге появляется какой-то текст. На этой раз про микросервисы от Avolution, который пилит решение Abacus
https://blog.opengroup.org/2021/11/23/how-to-use-microservices-a-guide-for-enterprise-architects%EF%BF%BC/ И посыл текста незатейлив: нельзя просто так распилить монолит на микросервисы. Нужно принять некую крайне сомнительную метамодель, установить KPIs и купить этот странный ABACUS, чтоб рисовать правильные дашборты миграции.

Вот за это, на мой взгляд, потом и не любят корпоративных архитекторов! Хотя, может я чего-то просто не догоняю

Полезное (в большей степени для аналитиков) https://link.medium.com/H6zVMfRJ6lb

Вот эту книжку я вспоминал на сегодняшнем вебинаре https://books.google.ru/books?id=PKSnTPkp94EC

5 января 20:00 MSK
Продолжение ответов на вопросы будет здесь https://mxsmirnov.timepad.ru/event/1884406/ уже в новогодние праздники (внутри прямая ссылка на YouTube-трансляцию, а поле вопроса, кстати, на этот раз, не является обязательным)

Есть какой-то сразу опознаваемый признак коммерческого текста. Такого, например, как вот этот https://selectel.ru/blog/myths-about-kubernetes/ Вот начинаешь читать и сразу понятно, что закончится он предложением купить proprietary продукт, нестандартный сервис или еще какой-нибудь чемодан без ручки. Вот почему так пишут?

Я уже делился вот этой этой ссылкой https://blog.getambassador.io/using-api-gateways-to-facilitate-your-transition-from-monolith-to-microservices-5e630da24717 На самом деле, она не столько про API Gateway, сколько про паттерны модернизации унаследованных приложений. Почему-то, становится все актуальней и актуальней

2021/22 свершения и прогнозы. Попался я на удочку, загрузив декабрьский The InfoQ Trends Report 2021 https://www.infoq.com/minibooks/infoq-trends-report-2021/
Думал, почитаю свежие тренды наступающего года. Оказалось, что в InfoQ просто собрали в единую книжку старые публикации по Software Architecture and Design, Culture & Methods, etc., Причем вышедшие еще в первом полугодии 2021. И, похоже, что жанр рождественских гаданий на технологии следующего года, в целом, постепенно уходит в прошлое. Но некоторые динозавры всё еще остались, например, Forrester (см. https://www.forrester.com/predictions/ и чуть более сфокусировано здесь Predictions 2022: Software Development Adapts To A New Normal https://www.forrester.com/blogs/predictions-2022-software-development-adapts-to-a-new-normal/) Так что и я еще планирую под рождество прокомментировать ряд трендов. Не переключайтесь ;-)

Чуть более развернуто https://mxsmirnov.com/2021-look-back/

🎄12-ое обновление Telegram в 2021 году подоспело очень кстати https://telegram.org/blog/reactions-spoilers-translations/ru Если из-за спама мне приходится регулярно отвязывать от канала группу обсуждений, то лайки, дизлайки и прочие реакции, в какой-то мере, это компенсируют. Не лишними они будут и в наших группах https://t.me/itarchitect_jobs и https://t.me/itarchitect

С наступающим Новым годом! Самые наилучшие пожелания, оставайтесь с нами! 🍾🎄🎉

Уже послезавтра, в 20:00 MSK продолжу отвечать на вопросы об описании архитектуры ИТ-решений https://mxsmirnov.timepad.ru/event/1884406/