Должен признаться, что в молодости я являлся яростным борцом с документацией. Сейчас таких уже давно не встретишь. Если кто-то с чем-то и борется, то с отсутствием документации. Но мне всегда казалось, что пусть лучше не будет никакой документации, чем несколько сотен страниц плохо структурированного текста с аляповатыми картинками и фрагментами копипасты из других документов. Структурированное описание всегда можно вытащить в набор вики-страниц. Осмысленную информацию представить в виде таблиц и внятных диаграмм. А плохой документации пусть лучше вообще не будет. Пусть вместо неё будет маленький FAQ или How-To. В те времена разработчики инструментов рисования диаграмм еще взяли манеру генерить документы по схеме. Из одной хорошей или плохой картинки получалось страниц пять текста. И пока весь его не прочтешь, сложно понять умное там что-то было в основе или не очень.

Я и мои малочисленные единомышленники проиграли! Отрасль непрерывно производит гигабайты документации, потому что так положено. Эта документация отвратительная (потому, что всё равно никто не будет читать). А редкие исключения из этого правила заслуживают отдельного внимания и искреннего одобрения

Через полчаса начнется вебинар Карта ИТ-ландшафта По этой же ссылке появится запись, но чуть позже

Что-то у меня с таймпедом сегодня сложилось не так. Прямая ссылка, которая была во вчерашнем письме: https://youtu.be/IgOApUwgCKU А что это за новая фича с письмом за час до начала и неработающей ссылкой я обязательно разберусь

Пока Grady Booch в очередной раз троллит архитекторов в своём твиттере https://twitter.com/Grady_Booch/status/1422631999244804104 я задумываюсь о переносе всех презентаций в Google Slides по вполне прагматичной причине - возможность расположить на одном экране окно показа слайдов и окно режима докладчика

В водопадной модели разработки ПО был набор последовательных этапов работ на каждом из которых человек с определенной ролью выполнял присущие этой роли действия. Аналитик собирал требования, архитектор проектировал, разработчик писал код, тестировщик проверял как он работает, а сисадмин устанавливал решения в боевую среду. Agile объединил последовательные работы в единый спринт и постарался уничтожить роли. Но разнообразие видов деятельности сохранилось. Нам по-прежнему нужно отвечать на вопросы: что должна делать система из каких элементов она состоит, как организованы данные и т.д. И разные вопросы предусматривают разные точки зрения (viewpoints), каждая из которых представляет собственный набор понятий и отношений между ними. David C. Hay, обсуждая матрицу Захмана в книжке Requirements Analysis: From Business Views to Architecture замечает, что неправильным будет считать строки этой матрицы этапами работ. Они представляют разные точки зрения (впрочем, и столбцы тоже). И это никуда не исчезло с появлением agile и devops. Мы видим систему по-разному, обсуждая те или иные вопросы

Кстати, версия матрицы от David C. Hay мне видится более практичной

Забыл поделиться ссылкой на упомянутую книжку Дэвида Хэя https://flylib.com/books/en/1.172.1/ В своё время я вряд ли разобрался бы с ERP системами без другой его книжки Data Model Patterns

Не подумайте, что это продолжение разговора про Карту ИТ-ландшафта. Просто полезно Open Source Alternatives https://www.btw.so/open-source-alternatives

Сегодняшнее (и предшествующее ему) затяжное обсуждение в нашем чатике https://tttttt.me/itarchitect широкого спектра тем, в частности темы архитектура как код, напомнило мне, что с определениями в ИТ-архитектуре как-то всё не очень… Их не то, чтоб нет, скорее, наоборот, слишком много. Вот, например, замечательная метафора про дым и зеркала отсюда http://bredemeyer.com/ArchitectingProcess/VisualizingDesign.htm перефразирует архитектуру как намерение и архитектуру как отражение. И пока мы не договоримся, о чем именно в данный момент ведем речь об AS IS или о TO BE, то обсуждает это как код или не как код – несколько преждевременно. С другой стороны, когда все четко, понятно и однозначно воспринимается, то как-то и обсуждать нечего. Так что, ИТ-архитектура - это, действительно: Smoke and Mirrors

Программная статья Marco Palladino(Kong) https://thenewstack.io/zerolb-a-new-decentralized-pattern-for-load-balancing/ Возможно, немного запоздавшая, после книжек Ибрама Билджина и Брендана Бёрнса, но всё равно не лишняя

Развернул я IBM IT Architect Assistant Community Edition исключительно чтоб побаловаться, кнопки понажимать. Честно говоря, уже давно не видел такого страшненького UI. Прям боязно артефакты и диаграммы добавлять. Но, надеюсь, что рушиться оно особо не будет и я успеют за пару дней слайдкаст записать.

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

Записал короткий скринкаст https://youtu.be/sQLj8h5eAR8

Архитектурные комиксы.
Очередная дискуссия в группе о том, должен ли архитектор писать код заставила меня задуматься над вопросом: в чем же таком существенное отличие архитектурных моделей от исходников. Наверное, очевидный ответ в том, что исходники исполняются. Даже не важно где, в вычислительном устройстве или голове разработчика.

Но существуют ли диаграммы, которые потенциально можно было бы исполнить? Вряд ли. Может быть только statechart, ну в какой-то мере sequence. Но не предназначены они для этого. Как, например, поведут себя несколько потоков на этих картинках? С другой стороны, в учебниках информатики для детского сада были[наверное] вполне себя внятные истории про переменные, указатели, стеки и очереди (см. картинку выше и, кстати, по ней одним предложением можно пояснить чем брокеры потоков сообщений aka kafka отличаются от очередей)

Может мы не те картинки рисуем, как думаете?

Если вы смотрели раннюю версию, то думаю, что есть смысл вернуться по ссылке и перечитать https://martinfowler.com/articles/patterns-legacy-displacement/ Текст стабилизировался, обзавелся картинками, а на InfoQ появился короткий обзор https://www.infoq.com/news/2021/08/legacy-displacement/ для тех, кому не хочется читать много

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

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

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

Поделюсь приглашением на бесплатный митап:
26 августа в 18:00 компания IT_One вместе с JUG Ru Group проведет бесплатный онлайн митап по Big Data и Java.

На «IT_One Meet Up: Java and Big Data» эксперты будут говорить о технологиях, инструментах, методах и многом другом, чем живут дата-специалисты. Участие бесплатное, нужно только зарегистрироваться.

Друзья! Пережидая очередную волну спама, я временно отвязал группу обсуждения этого канала от самого канала. Безусловно, вы можете продолжать добавлять в неё свои комментарии, равно как и в нашу большую группу Архитектура ИТ-решений И не забывайте про группу Работа для ИТ-архитекторов, радующую нас вакансиями как смешными, так и не очень

Популярные спикеры [слеш авторы] скоро вытеснят собой штамм компьютерных журналистов. Пока некоторые продолжают наслаждаться летними отпусками Gregor Hohpe слазил в машинное отделение интеграции приложений и вернулся к нам со своим рассказом https://architectelevator.com/architecture/engine-room/
Впрочем, сама история вряд поведает что-то новое. Но вот её концовка:

So, to me the question isn’t so much whether architects write a lot of code. It’s more important whether they have been to the engine room recently and frequently enough to understand the available solution options and trade-offs, and a few of the dark corners

непременно оживит горячо любимый всеми флейм

📅 30 августа (понедельник) 19:00 MSK
Продолжим объединяться в неформальные онлайн-группы Архитекторов Решений. Ссылка на zoom: [ удалена ]