Архитектура ИТ-решений
13K subscribers
270 photos
27 files
1.07K links
Разговоры об архитектуре корпоративных информационных систем (архитектура предприятия, архитектура ИТ-решений, микросервисы).

Этот канал не продается, а я не сдаю квартиры/машины/яхты. Будьте, пожалуйста, осторожны!
Download Telegram
Короткая заметка о том, что с заинтересованными лицами ситуация чуть сложнее, чем кажется на первый взгляд: Слоёный пирог стейкхолдеров
Фаулер завершил обновление в своей bliki заметки Continuous Integration(оригинальная версия появилась в сентябре 2000, обновилась в 2006, а о переработке статьи было объявлено в октябре прошлого года). И хотя все уже давно и хорошо понимают о чем идет речь, в этом большом тексте можно найти интересные моменты.

Но я хочу обратить внимание на то, как устроены «пошаговые» картинки (см. скрин выше, но оригинал в тексте). Мы на днях спорили в чатике о том, нужна ли архитектурным диаграммам анимация. В виде переливающихся линий – может и нет, а вот такое пошаговое развитие сюжета, на мой взгляд, более чем уместно
Любителям традиционной архитектуры предприятия, но в формате на одной странице: TOGAF ADM - фазы и документы (из предыдущих версий)

Взял здесь: Architecture Frameworks: TOGAF, ArchiMate, Zachman & DoDAF (Там есть еще ряд интересных вещей)
Что почитать в выходные

Недавно в чате про архитектуру в очередной раз случилось обсуждение систем, а чуть раньше, в начале января, у Грэма Беррисфорда появилась пара новых больших текстов про сходства и различия в понимании систем в архитектуре предприятия, кибернетике и системной динамике.

Лучше начинать читать отсюда On human knowledge В конце текста больше дюжины ссылок на другие его тексты вокруг систем.

Можно начать и с этого текста How EA departs from cybernetics, но будет сложнее. В любом случае, читать Грэма проще, чем разгребать первоисточники (Хотя на некоторые из них ссылки есть прямо в тексте)
В нашем чате Работа для ИТ-архитекторов новое обсуждение ролей и зон ответственности: архитекторы, тимлиды, техлиды и пр. Кто нужен, кто не нужен, зачем, когда, где… - прям матрица Захмана. Кстати, именно классификации типов ролей в индустрии, на мой взгляд, и не хватает. Разного рода SFIA они плоские, если так можно сказать. В них нет принципиальных различий между разными ролями.

На мой взгляд, полезней была бы многомерная модель. В ней по одной оси откладывается тип организации. Например: enterprise, outsourcing, product-based company. И в одних из них архитекторов много и разных, а в других практически нет. Ну или энтерпрайзов совсем нет, а системный архитектор - один на продукт или на технологию, как это было принято в системных интеграторах.

Другое измерение – унифицированность видов деятельности и навыков. Это можно отобразить в виде концентрических окружностей. В центре более стандартизированные роли: dev-ops-qa. Потом круг с тимлидами и аналитиками. Потом роли, которые перечни своих работ и задействованных ресурсов формируют самостоятельно и в каждой работе заново (помните в TOGAF ADM этапы B-D начинаются с выбора эталонных моделей, точек зрения и инструментов. Более общий термин для подобных вещей job crafting – подстраивание, подгонка работы под себя. Скоро об этом собираюсь рассказать поподробнее. А заодно и про модели мотивации-выгорания, JD-R и пр.). В общем, в этом измерении нужно что-то похоже на tech radar

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

В четверг Уэйд Уолдрон в своем видео на канале Confluent напомнил нам про Transactional Outbox Pattern. А следом Дерек Комартин вспомнил про свой прошлогодний ролик Alternative to the Outbox Pattern в сообщении Listen to yourself pattern: Is it an alternative to the Outbox Pattern?

Как спокойно было в нулевые, в мире монолитных приложений и транзакций, реализованных внутри СУБД. Хороших всем выходных!
Чем-то меня зацепил этот автореферат книжки Software Architecture and Decision-Making Может кто-то уже успел полистать и готов поделиться рекомендацией читать – не_читать?
Архитектура ИТ-решений
Излагая архитектуру решения мне не всегда просто:
Результаты опроса о том, что не всегда просто сделать при изложении архитектуры решения:
- Объяснять сложные вещи
- Уложиться в отведенное время
- Запоминать новые идеи
- Сдержать волнение
Однажды автор C4 model Саймон Браун подготовил A software architecture diagram review checklist.

Мне нравится С4 модель, вернувшая чересчур абстрактные подходы UML в домен информационных технологий. Мне нравятся чек-листы – простой способ направить ту или иную деятельность в нужное русло и проверить степень готовности результата этой деятельности. Но я думаю, что существует некоторая опасность, заключающая в формальном отношении к чек-листам. Это обстоятельство может все испортить.

Возьмем, например, пункт: «каждая диаграмма должна иметь заголовок» - кто бы с этим спорил. Большинство архитектурных диаграмм имеет заголовок. Значительная часть заголовков выглядит примерно так: «С4 Container Diagram». Ценность такого заголовка колеблется в районе нуля, плюс-минус. Место на диаграмме и внимание при её разборе занимает, а пользы не приносит. В кратком анонсе Браун пишет, что заголовок диаграммы должен описывать её тип и границы и в качестве примера приводит "System Context diagram for My Software System". Думаю, это не вполне подходит.

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

(Много слов получилось. В следующий раз сокращу или сделаю пост в блоге)
На сайте EventStoreDB нашел транскрипт легендарного выступления Грега Янга, случившегося 10 лет назад. В виде текста оно воспринимается немного иначе. Чем-то похоже на известный 50-страничный CQRS Documents

Знаете что меня удивляет? Несмотря на обилие инфы вокруг этой темы, в ней, почему-то, всегда остается возможность добавить еще что-то новое. В том-же блоге Event Store ряд актуальных заметок, но и не только. В общем - залезаем все глубже в кроличью нору
В материалах TheOpenGroup опубликованы не только файл с описанием и archimate-моделью учебного кейса ArchiSurance Case Study, но и сформированная при помощи Archi web-версия модели для этого кейса(правда немного кривая, как и сам Model Exchange File примера)

Начинать смотреть вот с этой вкладки: https://pubs.opengroup.org/architecture/case-study-models/archisurance-html/?view=id-45418

Не знаю, выложили недавно или же я раньше просто не обращал внимание, но непременно воспользуюсь в своем курсе про модели корпоративной архитектуры
📅 15 марта 10:30 MSK Бесплатный вебинар: Реальная альтернатива микросервисам

Монолит не альтернатива микросервисам! Будь он хоть двадцать раз модульным. Монолит всегда останется единым процессом, который не разделить по серверам... или нет?

Подробности и регистрация: https://mxsmirnov.timepad.ru/event/2803564/
У Фаулера появилось описание наверное самой востребованной техники Перехват событий в рекомендациях Patterns of Legacy Displacement

Причем рассмотрены разные случаи. Если есть такая возможность, то события извлекаются из очереди. Нет такой возможности, то перехватываем HTTP поставив reverse proxy или доработав приложение или воткнув посередине API-gateway. В крайнем случае - триггеры БД (хотя по мне, так это уже перебор, не надо так). Ну и простенький пример перехвата событий с change-data-capture процессом
На днях у /thoughtworks проскочила очередная статья про техрадар How to create your enterprise technology radar с набором не очень очевидных мыслей о том, что техрадар не только картинка для руководства, но и ещё формат обсуждения технологий в организации и даже инструмент упрощения технологического стека.
И это действительно важное преимущество радара перед аналогами.

Мне всегда хотелось использовать что-то подобное для оценки инициатив (запросов на изменения). Чтоб сразу видеть истории, которые еще пару лет назад были отправлены в Hold (где им и место если не навсегда, то надолго). Понимать что уже в Adopt, и значит у кого-то в работе, а потому теперь не требует пристального внимания. Ну и сосредоточится на распределении тем между Assess и Trial

Техрадар дает карту возможностей. Но схожий инструмент для оценки потребностей был бы не менее полезен
Читаете ли вы заметки Kai Waehner о потоковой обработке данных? Я, признаться, почитываю. И хотя они порою даже длиннее, чем волны и хайпы(те же волны, но в другой проекции) Gartner-Forrester-а, читать их как-то поинтересней. В общем, свежее гадание: The Past, Present and Future of Stream Processing. На мой взгляд, слишком облачное для наших широт. (прочие истории этого автора здесь: https://kai-waehner.medium.com/)
🏛Архитектура решения (Solution Architecture), в некотором смысле, является наиболее простой архитектурой. Простой, если её, например, сравнивать с архитектурой предприятия или системной архитектурой. При разработке архитектуры решений мы достаточно хорошо понимаем целевое состояние, в которое должны прийти. Мы примерно представляем, когда это случится, каким в этот момент времени должен быть набор функций решения, как будут выглядеть данные, какой набор технологий мы задействуем. Более того, мы неплохо понимает текущий набор технологий, приложений и данных из которого мы будем это целевое состояние создавать.

Сравним для примера этот уровень определенности с тем, с чем мы работает при разработке архитектуры системы. Пусть нам предстоит спроектировать систему, про которую мы знаем, что через пару месяцев должен полететь MVP, через полгода заказчику хочется покрыть некоторый базовый функционал, а через год от текущего момента времени выйти на окупаемость. Какую архитектуру нам рисовать? Ту, что сложится через год, полгода или в ближайшие пару месяцев? Они будут очень разные. Первая пара месяцев, быть может, предсказуема с точки зрения технологий. За этот срок вряд ли что-то изменится. Но на начальный момент времени предметная область (domain) окутаны густым туманом. Может быть что-то можно сказать про компонентный состав, т.е. мы выберем тот самый то ли стиль, то ли паттерн из книжек Форда и Ричардса. Через пару месяцев мы слегка начнем понимать домен. Через полгода может быть уже разуверимся в предсказанный заказчиком профиль нагрузки и начнем менять тот самый архитектурный стиль. К горизонту год что-то будет меняться в технологиях под нашей системой. В ходе всей истории мы регулярно будем узнавать много нового о реальных навыках команды разработчиков, а быть может и выбранном техстеке.

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