Программа Практики Архитектуры Предприятия

Есть у меня задумка превратить учебный курс https://itexpert.ru/eap-online/ в программу из нескольких модулей. Напомню, что в сентябре прошлого года The Open Group выпустила новый архитектурный стандарт Open Agile Architecture™ (O-AA), расширив тем самым практики и задачи архитектора предприятия.

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

Как-то много вокруг поднялось разговоров о двадцатилетии agile-манифеста, появившегося 11-13 февраля 2001 года. Ну, помните: Люди и взаимодействие важнее процессов и инструментов…

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

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

Так что корпоративная культура не только съедает на завтрак стратегию, что подмечено было еще Питером Друкером, но и закусывает информационными технологиями. Что уж тут праздновать?

А вот к ИТ-архитекторам это относится в минимальной степени. Эти парни хорошо устроились, буквально растворяясь в своей работе и не чувствуя ни малейшего дискомфорта. Типичные агенты постмодерна: система одна, а представлений (views) у неё несколько; вместо наилучшего решения - анализ компромиссов. А эволюционная архитектура - это вообще шедевр псевдологики.

Следите за руками:
"Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change." -- Grady Booch
Но потом Кент Бек предлагает нам обратимость для обуздания сложности https://www.facebook.com/notes/kent-beck/taming-complexity-with-reversibility/1000330413333156/
А Фаулер говорит: a good architect reduces architecture
https://twitter.com/martinfowler/status/1285581525380202496
В общем в идеальной архитектуре вообще нет каких-либо significant decisions. А значит и самой её тоже нет

Похоже, что разговоры про культуру заходят у нас не очень. Потому сегодня вернемся к технологиям. Поделюсь ссылкой на рассуждения архитектора из MuleSoft Антонио Гарроте, об описании асинхронных взаимодействий https://engineering.salesforce.com/asyncapi-and-openapi-an-api-modeling-approach-db9873695910

Для REST есть спецификация Open API. А для обмена сообщениями AsyncAPI как-бы есть, но мало кто ей пользуется.

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

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

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