Архитектура ИТ-решений

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

Но оказывается, у arc42 есть такая штука, как Architecture Communication Canvas (ACC). Не вдаваясь сейчас в обсуждение содержания этого шаблона, должен признать, что он задает некоторую планку по оформлению, да и описанию таких шаблонов.

Все их шаблоны можно посмотреть здесь, ну а мне свой придется чуть-чуть дооформить :)

🔴 Повелители цифр: какие перспективы у IT-архитекторов в Москве?

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

🔴 Как правило, IT-архитекторы вырастают из разработчиков. Это профессионалы, имеющие за плечами от пяти лет работы в IT-индустрии. В каких сферах они нужнее всего и на какую зарплату могут рассчитывать? Об этом нам рассказывает представитель IT-рекрутинговой компании «ГИКСОРС» Кира Морева. Смотрим ролик!

Поделюсь видео Киры Моревой - руководителя группы консультантов GeekSource, с комментарием о зарплатах enterprise и solution архитекторов

📃 BABOK Guide уже много лет не обновлялся. Зато на днях появилась вторая версия The Business Analysis Standard. Скачать стандарт можно по ссылке выше ☝️, при желании, предварительно зарегистрировавшись здесь

🔖 Что поменялось (сжатый анонс от авторов):
- Оптимизирован язык для более легкого понимания и навигации
- Области знаний реорганизованы в соответствии с BABOK Guide. Согласована терминология стандарта и руководства
- Стили документа приведены в соответствие со стандартами ISO
- Для быстро ознакомления со стандартом добавлен общий обзор
- Новые и расширенные разделы: ценность и результаты (outcomes and value), организационные соображения, улучшения и проработка идей

🖇 Как всё это связано с архитектурой решений. В какой-то момент IIBA стал максимально широко трактовать бизнес-анализ, захватив заметный кусок solution architectгure. Вряд ли это правильно, но зато, пока у солюшенов нет своего стандарта, в какой-то мере, можно воспользоваться стандартом аналитиков (а не только стандартами архитекторов предприятия)

Иногда InfoQ размещает более-менее содержательные тексты. Вчера это был Adam Bellemare из Confluent с лонгридом The End of the Bronze Age: Rethinking the Medallion Architecture

Вообще говоря, вопрос о том, как совместить операционные и аналитические данные (и соответствующие процессы и потоки их сбора и обработки) совсем не новая. Здравый смысл призывает относится к таким идеям с настороженностью. Но Адам достаточно аккуратен и убедителен. И тему Shift Left (сдвига вверх по течению) рассказывал всю прошлую осень в блоге Confluent.
Конечно, можно посчитать это простым PR-ом Kafka, но в ледниковый период сокращений и оптимизаций я бы, как минимум, думал бы в этом направлении

🏛 The Open Group непрерывно ведет полезную, но невидимую деятельность по переупорядочиванию своих информационных ресурсов.

➡️ Вот еще один такой типичный ресурс Case Studies Collection - подборка учебных кейсов с нашими любимыми компаниями ArchiSurance и ArchiMetal и другими историями в формате pocket guide

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

🔽 Сформулировал пять характеристик такого примера. Возможно, кто-то меня дополнит или с чем-то не согласится

📑 Архитектура решений. Сложные компромиссы

Архитектура и agile часто противопоставляются. Потому многие архитекторы либо полностью дистанцируются от обсуждения этой темы, либо безоговорочно поддерживают любые вещи, промаркированные словом «agile». Если оставить в стороне стандарт Open Agile Architecture, включающий очень разные идеи, то я бы обратил ваше внимание на небольшую статью What is agile enterprise architecture? Svyatoslav Kotusev – перечень из шести направлений в которых архитектору предприятия следует найти (а возможно и формально зафиксировать) компромисс между предварительным планированием и гибкостью

На мой взгляд, это практически готовые к использованию рекомендации

Я тут сделал перевод к видео, пока готовил лекции для студентов.
Короткий ролик про Agile. Очень талантливо снято
Субтитры вшиты в видео. Могу отдать отдельно видео и исходник субтитров

Продолжаю делиться чужими переводами. Сегодня от Mikhail Zaborov

Мартин Фаулер, международный эксперт по программной инженерии, начал свою публичную просветительскую деятельность с книги Analysis Patterns 1997-го года.

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

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

Андрей Гордиенков решил исправить это досадное обстоятельство и подготовил собственную версию перевода.

https://habr.com/ru/articles/872598/

Вступление
1.1 Концептуальные модели
1.2 Мир шаблонов
1.3 Шаблоны в этой книге
1.4 Концептуальные модели и реинжиниринг бизнес-процессов
1.5 Шаблоны и фреймворки
1.6 Использование шаблонов

Часть 1. Аналитические шаблоны
2. Ответственность
3. Наблюдения и измерения
4. Наблюдения для корпоративных финансов
5. Обращение к объектам
6. Инвентаризация и учет
7. Использование моделей учета
8. Планирование
9. Торговля
10. Производные контракты
11. Торговые пакеты

Часть 2. Поддерживающие шаблоны
12. Слоёная архитектура для ИС
13. Фасады приложения
14. Подходы для моделирования типов
15. Шаблоны ассоциации
16. Послесловие

Часть 3. Приложения
А. Техники и обозначения
В. Таблица паттернов
C. Краткая справка по диаграммам

Если немного уйти от метафоричности, которую всегда так умело использует Gregor Hohpe в своих текстах, то вчерашний его текст Enterprise Architects: From Cartographers to Scouts подтверждает одну простую вещь:
архитектура предприятия все больше воплощается посредством архитектуры решений (solution architecture)

📑 Хочу поделиться с вами вот этим лонгридом What is Enterprise Architecture? Сomplete Guide (надеюсь встроенная реклама вас не смутит). Давайте расскажу почему

Я часто ссылаюсь на книжку ADM Practitioners’ Guide из TOGAF 10 в качестве примера современного взгляда на EA, отличающегося от архаики Fundamental Content, например. А текст руководства практика по архитектуре предприятия написали авторы из Conexiam.

Собственно, верхняя ссылка представляет собой выжимку основных идей руководства

Небольшой текст с итогами и планами: Навстречу 2025-му. Свершения и прогнозы

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

В хит-параде текстов прошлого года я бы, наверное, выделил Like we don’t see air, we don’t see the Digital Revolution от Gerben Wierda, автора книжки Mastering ArchiMate.

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

А еще Gerben добавляет к тексту пару постскриптумов:
1. The Fundamental Limit of ‘Being Digital’ - построенный на двоичной логике цифровой образ мира тесно связывает производительность операций с хрупкостью и инерционностью(низкой гибкостью, способность к изменениям) осуществляющих их систем. И это предопределяет ограниченность дискретно-событийных систем
2. AI are going to teach us lessons about ourselves

Давайте я еще немного прокомментирую этот опрос.
Лет 20 назад основной вопрос, который обсуждался в связи с работой был в том, как помочь людям раскрыть на работе свой потенциал. Было много вариантов ответа из которых практически ничего не сработало. Сейчас даже как-то неудобно обсуждать вопросы, типа помогает ли agile раскрыть потенциал сотрудника (или офис класса А или удаленка или печеньки с кофепоинтами, или отдел DevRel - не суть). Есть исследование State of DevOps (которое из книжки Accelerate), ищущее подобные корреляции, да пожалуй и все

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

📽 Запись предновогоднего стрима

На других ресурсах:
🔘 YouTube
🔘 VK Видео

Стартуем через 20 минут здесь https://us02web.zoom.us/j/84807018425?pwd=cbiGKZoIXuA8Iwoq3wvZN97VcksxGA.1

Пару недель назад у Ivar Jacobson появилась бумага с названием Use-Case 3.0 и даже прошел вебинар (запись можно посмотреть здесь)

Я напомню, что концепция Use-Case 2.0 была о том, как организовать итерационную инкрементальную разработку посредством разделения сложного варианта использования на ломтики (slices) (Почитать можно здесь)

Что принципиально нового принесла версии 3.0 я пока так и не разобрался. Но, несмотря на это, варианты использования à la Alistair Cockburn/Ivar Jacobson остаются полезным способом описания сложных сценариев взаимодействия между системами/сервисами и разного прочего поведения

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

📊 Оверимплоймент: что это?
По просьбе NEWHR приглашаю вас принять участие в новом исследовании

Вы сотрудник и совмещаете несколько мест работы? Или пока только задумываетесь о поиске подработки и взвешиваете «за» и «против»? А может, никогда не смотрели в эту сторону? Или вы — работодатель, который сталкивается с феноменом оверимплоймента среди своих сотрудников? А может, не сталкивались или не знаете наверняка, совмещают ли ваши сотрудники? Расскажите нам о своем опыте и/или отношении к вопросу!

Предмет нового исследования — оверипмлоймент, он же совмещение нескольких работ, он же вторичная занятость, — яркий макро-тренд последних нескольких лет на рынке, распространённый не только в IT.

В рамках исследования узнаем:

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

👉🏻 Пройти опрос 👈🏻

Результаты исследования опубликуем в начале 2025 года.

🎁 Для всех, кто поучаствует в опросе:

- мы сделаем специальный расширенный материал с глубинным исследованием по вашей профессии: эти материалы получат только респонденты исследования
- предоставим возможность узнать результаты первыми
- проведем закрытый эфир с инсайтами исследования и возможностью задать любые вопросы экспертам NEWHR

📎 Для отправки результатов исследования мы попросим вас оставить электронную почту в конце. Это не обязательно, но гарантирует, что вы получите результаты первыми. Вы можете использовать любую комфортную для вас почту.

👉 Расскажите о вашем отношении к совмещению работ и/или поделитесь этим постом с теми, кому может быть интересна эта тема. Опрос займет не больше 6 минут.

📆 23 декабря в 10:30 MSK
Проведу традиционный предновогодний стрим с ответами на вопросы по
Архитектуре ИТ-решений

📽 На этот раз в zoom, но непременно с записью. Планирую уложиться в 1,5 часа

⬇️ Подробности, регистрация и форма для вопросов здесь: https://mxsmirnov.timepad.ru/event/3153091/

🧐Вон Вернон, написавший известную красную книжку про DDD Реализация методов предметно-ориентированного проектирования (а потом и зеленую книжку с подзаголовком Самое основное), пару месяцев назад запустил видеоблог под названием Design Accelerator

Недавнее видео Publishing Events From Legacy показалось мне примечательным. С технической точки зрения вы вряд ли узнаете в нем что-то новое. Но вот то, что DDD появляется в контексте модернизации унаследованных приложений, кажется мне интересным фактом. Похоже, мы возвращаем к дискуссии про Monolith First

🎙Что говорят ИТ-архитекторы

Сложно не согласиться с девятью Favorite phrases of a software architect, состоящими из:
1️⃣ It depends
2️⃣ What problem are we solving?
3️⃣ Start simple, evolve when necessary
4️⃣ Write it down
5️⃣ The simplest solution that works
6️⃣ Architecture is about trade-offs
7️⃣ Show me/Let’s find out
8️⃣ Deferring decisions is a decision
9️⃣ Which favorites did I miss?

подробней по ссылке; думаю и для архитекторов решений данный список будет актуален

Уже набралось более 800 голосов. Давайте посмотрим первые результаты:
1️⃣ Как и следовало ожидать большинство проголосовавших считают, что архитектура требует серьезного погружения. Как минимум нескольких встреч (27%), а то и десятков часов (35%)
2️⃣ Но варианты почасовой оплаты работы архитектора тоже не остались без голосов. Причем сумма распределяется более менее ровно, начиная с 12% на 3000₽, возрастая до 16% к сумме от 10 000 ₽ и снижаясь к 8% на отметке $300 в час
3️⃣ Другие варианты тоже собрали некоторое количество голосов. Т.е. не смотрятся чем-то уж совсем необычным

Привет! У нас в чате Работа для ИТ-архитекторов иногда появляются запросы на разовую консультацию. Как вы думаете, сколько должна стоить такая консультация и как долго продолжаться?

(Опрос будет в следующем сообщении. Пока я его не опубликовал можно предложить ваш вариант ответа в комментариях к этому сообщению)

Небольшой опрос (96 человек) от IcePanel State of Software Architecture Report — 2024 оказался неожиданно интересным

Update: Добавил ссылку на сообщение у них на сайте https://icepanel.io/blog/2024-11-26-State-of-software-architecture-2024 Вдруг медиум не у всех виден

С момента анонса unFIX в январе 2022 года, о котором я писал выше, появилось некоторое количество примеров использования этого нефреймворка, а еще новых текстов, картинок и реквизитов

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

Запись мне zoom сделал как-то кривовато, сумею исправить - выложу. А пока делюсь слайдами

В марте этого года мы уже обсуждали направления развития распределенных архитектур и возможные альтернативы микросервисам (запись здесь: https://youtu.be/rIr6xIB_x3I). Я тогда делился сомнениями Мартина Клеппмана(автора книжки с кабанчиком) и других экспертов относительно Google Service Weaver и идеи модульного монолита

И вот тут оказывается, что с 5 декабря 2024 года активная разработка этого фреймворка останавливается. А через шесть месяцев после этого, 6 июня 2025-го репозиторий будет окончательно заморожен и заархивирован. В общем, как пишут вот здесь: we recommend that users fork the repository

Давайте я поделюсь стандартом IT4IT в ArchiMate Model Exchange File Format-е. Возможно, кто-то захочет предварительно посмотреть его, например, в Archi или другом archimate инструменте

🤔 Что общего у IT4IT и Architecture as Code?

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

⏳В октябре 2024-го обновилась эталонная архитектура управления цифровыми технологиями IT4IT. Я рассказывал о ранних версиях этого стандарта, но потом взял паузу. Пришла пора её прервать.

📆 12 ноября в 11:00 MSK присоединяйтесь ко мне на бесплатном вебинаре про IT4IT v3.0.1. На этот раз в zoom

➡️ Подробности и регистрация: https://mxsmirnov.timepad.ru/event/3106269/

А вот и обзор целой серии докладов с ArchDays от Максима Цепкова https://mtsepkov.org/ArchDays-2024
Внтури:
- Максим Цепков. Бизнес и софт как единая система: описываем архитектуру предприятия
- Максим Смирнов. Где проходит граница изменения
- Денис Свеженин, ЛЕНТА. Стратегия автоматизации или автоматизация стратегии?
- Александр Войновский, Газпром нефть. Корпоративная архитектура. Buy or Build: способы оценки архитектуры
- Филипп Дельгядо. Конфигурация и кастомизация в энтерпрайзе
- Евгения Умен из AB digital. Революционный refresh. Рефакторинг клиентского домена и долгий путь к балансу
- Павел Кан, Ensi. Поиск рабочего компромисса между стройной теорией и заковыристой реальностью: архитектурные практики в гибридных командах с продуктовым подходом

Обзор как всегда мегаподробный и очень интересный.

Podlodka Java Crew снова в деле!

Уже 18 ноября стартует неделя "Асинхронной архитектуры" для всех, кто работает с высоконагруженными системами и задачами реального времени.

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

- На круглом столе Митя Александров и Александр Нозик обсудят, что эффективнее в Java — виртуальные потоки, реактивность или корутины 💬

- В сессии Евгения Молокова обсудим, в каких случаях Kafka Streams может уступать Apache Flink и как Flink решает задачи потоковой обработки данных🚀

- Денис Винокуров и Дмитрий Разуваев объяснят, почему асинхронность Kafka не всегда соответствует ожиданиям и как это фиксировать 💻

- Сергей Петрелевич проведет воркшоп по WebFlux для асинхронных систем, где разберет реальные кейсы 🛠

Никакой теории, только конкретные подходы для использования!

Скорее забирай early-bird билеты — https://podlodka.io/javacrew.

Архитектура ИТ-решений pinned «Номер заявления на регистрацию № 4782434961»

Номер заявления на регистрацию № 4782434961

Отлично вчера прошел ArchDays! Огромное спасибо Сергею и всем организаторам. Выкладываю слайды своего выступления и безусловно благодарю всех тех, кто пришел его послушать

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

Карту причин неудачи при модернизации унаследованных приложений нашел я в бумаге /thoughtworks Legacy modernization. A transformation opportunity

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

Впрочем, если интересно, посмотрите эти рекомендации сами. Может вы увидите их как-то иначе

Как архитектурные стратегии и решения влияют на бизнес?

25 октября на Alfa Arch Meetup #1 вы узнаете это от ведущих экспертов:

- Анна Овзяк объяснит, как правильно выявлять и фиксировать требования безопасности.
- Максим Седов раскроет роль архитектурной стратегии в работе и развитии компании.
- Максим Тихонов расскажет, как строилась с нуля архитектура для проекта «Свой в Альфе».
- Борис Пишванов поделится опытом, как развивать архитекторов и архитектурные процессы.
- Михаил Салахов расскажет, что такое работа архитектора решений изнутри.

📅 Когда: 25 октября, 18:00
📍 Где: Москва, пр-т Андропова, д. 18, к. 3, и онлайн

Не упустите возможность узнать, как создавать и развивать архитектуру в реальных проектах!

Регистрация
#реклама

🤨 InfoQ никак не может оставить в покое термин Cell-Based Architecture

В апреле они начали с него свой Software Architecture and Design Trends Report за 2024 год [2] (ссылки будут внизу), в июле выпустили eMag с набором статей [3], а вчера приступили к публикации серии Article Series: Cell-Based Architectures: How to Build Scalable and Resilient Systems [1]

Но, как это бывает практически с любым похожим термином, к его использованию возникает ряд вопрос. Из которых я выделили бы два основных: более-менее единое понимании термина и его полезность. И с тем и с другим у Cell-Based Architecture не очень все хорошо складывается.

Уже появилось множество не вполне одинаковых трактовок этого понятия. У WSO2 есть уже целая референсная архитектура [4], у ByteByteGo лаконичная картинка [5] ну и некоторый объем статей, начиная с Кристофера Сандовала [6] и продолжая теми же текстами InfoQ.

Думаю, большинство удовлетворится тем, что ячейка – это часть системы, обрабатывающая некоторое подмножество общего объема запросов и команд и способная делать это автономно, т.е. не обращаясь за границы ячейки. Подразумевается, что процессы ячейки развертываются на более-менее сосредоточенной группе серверов и взаимодействуют только между собой. Но вот цели такой архитектуры воспринимаются уже по-разному. Для кого-то это про локализацию сбоев. Другие [что странно] воспринимают это как способ обеспечения масштабирования. Третьи видят в ячейках способ сохранить данные внутри юрисдикции, ну и т.д.

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

Но, может я чего-то в этой идее не разглядел. Посмотрим

[1] Article Series: Cell-Based Architectures: How to Build Scalable and Resilient Systems
[2] InfoQ Software Architecture and Design Trends Report - April 2024
[3] Cell-Based Architectures: How to Build Scalable and Resilient Systems
[4] Cell-Based Architecture. A Decentralized Reference Architecture for Cloud Native Applications
[5] A Crash Course on Cell-based Architecture
[6] What is Cell-Based Architecture?

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

Вот смотрю я на EDGY https://enterprise.design/ пытаясь понять, что в нем не так. И не вижу каких-то серьезных проблем, но как-то совсем не цепляет

Кстати, про архитектурные ката.
Еще один сборник ссылок описаний архитектуры решений победителей и призеров O'Reilly Software Architecture Katas можно посмотреть в ката-логе: https://github.com/TheKataLog

The Solution Architect As Product Manager – новая сотня слайдов от автора учебника по архитектуре решений Alan McSweeney. Краткое резюме (см. слайд 98):
- Давно существуют и широко применяются проработанные подходы к разработке и развитию потребительских продуктов/решений/услуг (в тексте даже упомянут New Product Development (NPD) Stage Gate)
- Архитектура решений может использовать их двумя способами. Первый в том, чтоб расширить восприятие ландшафта изменения (а не ограничиваться доработкой ИТ-систем)
- Второй, для выбора действительно важных и актуальных изменений из огромного множества потенциально возможных изменений (я называю это воронкой инициатив)
- Роль архитектора решений идеально подходит для выполнения этих функций

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

Развитие системы может находится на этапе, когда никто и не думает про архитектуру и все хорошо. Но потом что-то становится не очень хорошо. Приходит осведомленность в том, почему это самое нехорошо имеет системный характер и просто так его не вылечишь. Начинается поиск вариантов избавления от проблемы и выбор ИТ-архитектуры в качестве основного лекарства (ну или отказ от такого выбора в пользу гомеопатии или agile). Но если предпочтение отдано архитектуре, то потом наступает непростой этап воплощения этого намерения…

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

И, наконец, полная версия Исследования состояния DevOps 2024! от команды Экспресс 42

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

Посмотреть полную версию можно 👉 по ссылке!

С 1 сентября ArchiMate Forum из Open Group собирает идеи и запросы на изменения языка. Называется это Archimate Feedback Campaign 2024

Подробности тут https://www.opengroup.org/archimate/feedback

Удивительным образом на сайте Martin Fowler нашел новый для себя текст от Gregor Hohpe. Почти 5 лет назад в заметке Don't get locked up into avoiding lock-in Грегор сделал исчерпывающий обзор того, что принято называть Vendor Lock-in, выделив разные степени подобных привязок (продукт, версия, архитектура, платформа и пр., вплоть до Mental Lock-in). Ну, а заодно, в очередной раз напомнил нам о назначении архитектурных моделей и пользе рассмотрения альтернативных вариантов.

В общем, от привязок нам не избавиться, но заголовок статьи обнадеживает: не замыкайтесь в себе, избегая блокировки

В IcePanel собрали пару ссылок на тексты из серии Modelling vs diagramming и дополнили их новыми словами и картинками. Но, на мой взгляд, не сделали главного, а именно не собрали в одну линию эскизы, модели, представления, исходники, работающее приложение, изменения. Обошли стороной вопросы когда и зачем нужны модели или диаграммы

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

Ссылки:
[1] Comparison - C4 modelling vs diagramming
[2] Ardoq Compared to Drawing, Modeling, and Data Visualization Tools
[3] Modelling vs diagramming software architecture

В тот же каталог буду пока выкладывать видео других выступлений с YouTube. Вот, кстати, запись с прошедшего в конце июня в Санкт-Петербурге TechLeadConf и история о том, Как рассказывать архитектурные диаграммы (Ссылка на видео в канале конференции: https://youtu.be/Ba9IejlZ-ws)

Почему-то мне казалось, что однажды я уже делился в канале этим слайдом и ссылкой на статью: Distributed transaction patterns for microservices compared Билгина Ибряма о распределенных транзакциях (5 паттернов двойной записи... - другое название этой статьи).

Оказалось, что не делился, хотя и обещал на одном из вебинаров это сделать. Исправляюсь!

Картинка накануне очередных летних выходных. Хорошей вам пятницы!

Если вы уже забыли (или не знали) о системах управления бизнес-процессами BPMS, то Bernd Ruecker - сооснователь Camunda, напоминает вам о них в своем свежем тексте Are You Done Yet? Mastering Long-Running Processes in Modern Architectures. Честно говоря, мне всегда нравился этот автор. В первую очередь, четким позиционированием и движков состояний и непосредственно камунды, как неких легковесных готовых компонент(библиотек) для построения более сложных решений. А еще умением изящно выделиться на фоне коммерческих BPMS

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

📽 YouTube пока еще работает, но только медленно, а может уже не работает, зато быстро, а может что-то еще...

В общем, все видео и трансляции с канала Архитектура ИТ-решений я скопировал вот сюда: https://disk.yandex.ru/d/0lwmomky8wCjgw Их можно скачать оттуда в формате mp4 или посмотреть в удобном для вас качестве, не загружая на локальный компьютер

📌 26 июля в 11:00 состоится вебинар с результатами исследования State of DevOps Russia 2024, которое я анонсировал в апреле и инфопартнером которого является наш канал

Необходима регистрация

Можно ли сравнивать Google Cloud Architecture Framework c традиционными архитектурными фреймворками, такими как TOGAF?

Я бы не спешил отвечать отрицательно. Наблюдая уже пару лет за развитием этой истории(см. журнал изменений здесь: What’s new), можно провести некоторые параллели с эволюцией более тяжеловесных подходов, проходившей лет 15 тому назад. Да, system design это совершенно не то же самое, что описание текущей и целевой архитектур, но все же. Вот даже такие видео Introduction to the System Design Pillar of the Google Cloud Architecture Framework если и не напоминает вебинары The Open Group, то тяготеет к ним по стилистике. Дежа вю усиливается если углубиться в чтение текстов. Возможно, я субъективен

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

Оффтоп по пятницам: Честно говоря, я совершенно не помню, где, когда и зачем мне довелось программировать микрокалькулятор MK-61. Я не помню какие программы писал, хотя точно помню что писал. Но вот вдруг оказалось, что голова вполне себе отчетливо сохранила в памяти всю эту историю про стек из четырех регистров X, Y, Z, T, который можно вращать; про кнопки [В↑] и [С/П] и про то, как вводить, запускать и останавливать программу. Удивительно!

Прочитайте здесь: https://habr.com/ru/articles/505612/ может тоже что-то подобное вспомните. Развлекитесь здесь: https://mk-61.moy.su/emulator.html (там еще и на логарифмической линейке можно посчитать и арифмометр покрутить) и постарайтесь снова почувствовать ту наивную детскую радость, что непременно возникает при успешном прохождение дымового теста

Нашел для коллекции еще один кликабельный архитектурный артефакт - Enterprise Architecture Implementation Wheel