Evolutionary Architecture - аn architecture that supports guided, incremental change across multiple dimensions – не самое понятно определение, сформулированное Нилом Фордом. Intentional Architecture – еще один новый термин из Open Agile Architecture™ и так далее и тому подобное

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

Кто-то уже шагнул в такое пакетное изменение, но для многих компаний главными словами остаются проекты и системы. Что делает в этом случае? Нужно ли здесь изменение архитектурных подходов и возможно ли оно. Думаю, что да. Но выглядит всё непросто. Уж точно надо все такие вещи чётко предварительно проговаривать

В разговорах о том, что роль ИТ-архитектора всё больше смещается в область внутреннего консультанта по технологиям (и не только по технологиям) мы часто упускаем один момент

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

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

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

Какой шаблон описания микросервисов выбрать?

Несмотря на то, что microservice canvas придумано уже не мало, все они похожи довольно похожи. По крайнем мере, в каждом шаблоне взаимодействие сервиса с внешним миром описывается по схеме Queries-Commands-Events. Так какой выбрать?

Наиболее простой вариант взять готовый файл у LaunchAny В принципе, он повторяет шаблон Matt McLarty просто переставив ячейки. Если взаимодействий у сервиса чуть больше, то лучше переключиться на шаблон от Криса Ричардсона в нем строчки вставлять удобней. Ну или задуматься об инструментальной поддержке, как в этой штуке MDC Editor, визуализирующей описание сервиса на лету

Поделюсь этим большим и несколько занудным октябрьским отчетом a16z специально для любителей эталонных архитектур. Может кому пригодится: https://a16z.com/2020/10/15/the-emerging-architectures-for-modern-data-infrastructure/

Микросервисы. Обратный билет

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

В первой заметке мы поговорим о том, из-за чего нас постигла эта микросервисная напасть и возможно ли было, хотя бы теоретически, другое развитие событий. В чем оно состоит, где находится развилка и до какого момента времени можно свернуть в указанном направлении. И начнем мы даже не с микросервисов, а с распределенных систем – приложений, данные и код которых, не вмещались по тем или иным причинам на одном сервере. Пока приложения развертывались на одном сервере всё было неплохо. Ну, может про один я не прав. Один для базы данных, еще один для сервера приложений, плюс еще парочка для резервирования, да и всё. Даже не вдаваясь в детали реализации я замечу, что данные на экземплярах БД были одинаковыми, как и приложения на серверах бизнес-логики.

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

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

Ну, давайте. Логику опять перепишем. Вернем её с java на PL/SQL и засунем в СУБД. Ну и сервисы, конечно, соберем, так сказать, на единой платформе и запустим в одном процессе. Или нет? Не будем спешить и в следующее заметке поговорим о том, а с чего это приложения в какой-то момент вдруг стали рассыпаться на сервисы

В среду, 24 февраля в 19:00 MSK
проведу небольшой стрим на эту тему. Ссылка трансляции на YouTube: https://youtu.be/S8JMVXAfFOM Вопросы можно задавать в комментариях к этому сообщению или в анонсе на FB: https://www.facebook.com/events/3781729695241571

Если вы не любите задавать вопросы, но готовы поделиться своим мнением, то тоже не стесняйтесь. Жду всех в среду вечером, присоединяйтесь!

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

А скоро уже трансляция: https://youtu.be/S8JMVXAfFOM

В одной из компаний, в которой я когда-то работал, ИТ-архитекторы делились на два вида: системные и бессистемные.

Системными называли тех, кто отвечал за развитие какой-то конкретной информационной системы, а бессистемными – архитекторов, проектировавших решения и интеграционные взаимодействия. Я еще шутил, что им просто своей системы не досталось. Возможно, термин этот был немного обиден, но мне он нравился. Да и архитекторов этих вскоре стали называть solution architect.

А вспомнил я о том, прочитав свежую реплику Анатолия Левенчука, которой хочу поделиться с вами https://ailev.livejournal.com/1557247.html Сразу скажу, что мне порой доводилось встречать еще одно, третье понимание системного мышления, не совпадающее с рассмотренными в этом тексте. Но обобщение, которое я для себя принял исходя из этого и подобных рассуждений в том, что при встрече с термином системный, или производными от него, лучше проявить некоторую настороженность

Сейчас просто предложение договориться о терминах для людей, хоть чуть-чуть знакомых с тем же DDD, выглядит несколько стрёмно. Оно может рассматриваться как приглашение в чужой ограниченный контекст или же попытка нарушить границу вашего (Пришли тут инженеры учить айтишников программы писать)

Да никогда мы, в полной мере, не договоримся о терминах! Мы можем договориться о следовании к общей цели и это позволит нам временно закрыть глаза на несоответствия в терминах и смыслах соратника. Чтоб действовать не разобщенно, а согласовано. Временно войти в некоторую игру, принять её правила, оставаясь частично вне игры. Соблюдать эти правила мы будет ровно до момента достижения цели и ни секундой дольше

Так стоит ли договариваться о терминах? Давайте отдадим предпочтение пониманию

Я давно слежу за выступлениями Жамак Дегани, но не знал что есть переводы её текстов на русский https://habr.com/ru/post/495670/

Поделюсь приглашением из чата

Приглашаем 16 марта в 18:00 на митап по архитектуре продуктов — поговорим о микросервисной архитектуре и использовании git submodules.

В программе выступления спикеров от Банка «Санкт-Петербург» и Lipt-Soft, интерактив и подарки за классные вопросы спикерам.

На игру мы приглашаем специалистов уровня миддл и выше. Участие бесплатное, но нужно зарегистрироваться. Мы пришлем вам приглашение после модерации: https://bit.ly/3c1VCvu

В чате это сообщение может потеряться, поэтому поделюсь здесь

Добрый день!

На днях структурировал и описал подход по выделению функциональности из монолита в отдельный сервис системным аналитиком.

Кому будет интересно, можете посмотреть по ссылке:

https://youtu.be/dUeFaucs-pw

Я, как это всегда и бывает, пропустил самое интересное. На этот раз речь о серии из шести прошлогодних заметок, которые Gregor Hohpe озаглавил Thinking Like An Architect. Мне на глаза попалась только пятая Architects Zoom In and Out, See Different Things в которой он пошагово улучшает ;) картинку из книжки Марка Ричардса и Нила Форда The Fundamentals of Software Architecture.

Естественно, я посмотрел и остальные. Серия начинается здесь: https://architectelevator.com/architecture/famous-architects-sketch/ А посетовать я хочу на то, что мне более чем симпатичны идеи автора, но, почему-то, совершенно не нравятся его тексты. Может у кого-то сходные ощущения?

А теперь время согласиться и одновременно поспорить с уважаемым Грегором Хоупом. В первой статье цикла Мыслить как архитектор он замечает, что архитекторы (не айтишные, проектирующие дома), создающие эскизы зданий, иногда в виде скетчей на салфетке, зарабатывают много больше инженеров, разрабатывающих чертежи поэтажных планов и схем электропроводки. Но автор никак не может ухватить слово, описывающее их деятельность: abstraction не abstraction, illusion, gestalt… Хотя, на мой взгляд, здесь вполне подошло бы слово ideation, т.е. концептуализация – формирование понятий или представлений. И все дальнейшие разговоры об «устранении шума» в эскизах, выделении главного и пр., встречающееся и в первой, и в пятой заметке цикла, выражаются этим словом.

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

Подборка информационных рассылок по архитектуре ПО от Екатерины Новосельцевой https://dzone.com/articles/15-software-architecture-newsletters-that-are-wort

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