Запущу еще один круг рассуждений на тему: платформа - ограничения или возможности. Возможности хороши тем, что предлагают нам альтернативные варианты развития событий. Мы пользуемся возможностью или игнорируем её. Предпочитаем одну возможность другой или какой-то третьей. Т.е. находимся в ситуацию, которую Gregor Hohpe сравнил здесь с продажей опционов. Но предпочтя некоторый вариант другим, мы утрачиваем возможность выбора. В этот момент возможность перестает существовать. Это хорошо для менеджера, задача которого устранять неопределенность, но плохо для архитектора. Ограничение же наоборот, сохраняет возможность последующего выбора.

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

Коллеги, как и обещал, анонс вебина по доменно-ориентированному подходу к интеграции:
https://sysanschool.timepad.ru/event/1714986/

Буду рад обратной связи!

Напоминаю, мы с Максимом Смирновым договорились устроить "баттл" по интеграции на конференции ArchDays

Выкладываю слайды вчерашнего вебинара про Платформу цифровых сервисов и вторую обещанную ссылку, которой не поделился в ходе вебинара. Речь шла о [мета-]процессах (или функциях или операциях), названия четкого нет, но идея в двух словах следующая.

В ООП у нас есть наследование и полиморфизм. Для двух объектов, несколько различающихся структурой и/или поведением, мы можем описать два разных класса, имеющих общего предка. При моделировании бизнес-процессов чего-то подобного нет. Когда нам нужно расширить функциональность, мы меняем описание процесса (в крайнем случае вызываемого подпроцесса, но концепции «интерфейс-реализация» там тоже нет). В общем, бизнес-процессы архитектурить не очень удобно. Максимум что можно сделать – форкнуть процесс, но почему-то процессники и этого не делают.

В какой-то степени эту тему затронул Ивар Якобсон в Use-Case 2.0 <- вот обещанная ссылка

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

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

Четкое определение ландшафтной карты появилось в языке описания архитектуры предприятия Archimate и просуществовало в тексте стандарта до версии 2.0 включительно. В те славные времена стандарт включал в себя 18 viewpoints, одним из которых и был Landscape Map Viewpoint. Каждая такая точка зрения формально описывалась в табличке и помечалась на шестиугольнике (см. картинку в следующей заметке).
Из более поздних версий стандарта описание этого и многих других точек зрения исчезло, но сохранилось в дополнительных материалах. См., например, ArchiSurance Case Study А если копнуть глубже, когда Archimate еще не принадлежал The Open Group, то можно найти и более интересные вещи, как например в работе Landscape Maps for Enterprise Architectures приводятся рассуждения об использовании этого подхода для визуализации произвольных ассоциаций между элементами двух множеств, задаваемых элементами еще одного множества. Впрочем, иногда карту приложений используют и как простую кластерную диаграмму или диаграмму взаимодействий. Я планирую на вебинаре успеть привести пять вариантов использования ландшафтной карты

Исходное позиционирование карты ИТ-ландшафта из Archimate 2.0

Нагло отрекламирую свой канал, но не просто так)
В посте ниже можнопосмотреть Landscape Map реальной компании)

Публикую так как:
- это абсолютно настоящая обезличенная Landscape Map
- компании уже не существует
- ее помогал мне делать Максим
- с помощью нее мы сделали проект по объединению трех компаний на одну

Внутри поста ссылка на Visio
https://tttttt.me/it_ace/270

Большой текст (на самом деле, кластер из нескольких текстов) о разрыве цикла модернизации унаследованных систем появляется на сайте у Мартина нашего Фаулера https://martinfowler.com/articles/patterns-legacy-displacement/

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

Должен признаться, что в молодости я являлся яростным борцом с документацией. Сейчас таких уже давно не встретишь. Если кто-то с чем-то и борется, то с отсутствием документации. Но мне всегда казалось, что пусть лучше не будет никакой документации, чем несколько сотен страниц плохо структурированного текста с аляповатыми картинками и фрагментами копипасты из других документов. Структурированное описание всегда можно вытащить в набор вики-страниц. Осмысленную информацию представить в виде таблиц и внятных диаграмм. А плохой документации пусть лучше вообще не будет. Пусть вместо неё будет маленький 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. Прям боязно артефакты и диаграммы добавлять. Но, надеюсь, что рушиться оно особо не будет и я успеют за пару дней слайдкаст записать.

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