К итогам прошлого года: многопользовательский редактор простых архитектурных эскизов, который я еще не успел опробовать в качестве инструментов на дистанционным обучении ИТ-архитектуре https://blog.excalidraw.com/rethinking-virtual-whiteboard/

Плюс появившаяся в конце декабря библиотечка для архитекторов https://libraries.excalidraw.com/

https://kroki.io с версии 4.0 поддерживает Excalidraw. Я писал обзор этой утилитки. Кому интересно, пост на моем сайте https://www.golodiuk.com/news/it-architecture-diagrams-from-text/

Сегодня немного про стратегию. Стандарт O-AA™ возвращает нас к понимаю стратегии, сформулированному Портером.

Michael Porter recommends distinguishing operational effectiveness from strategy. Strategy is about developing sustainable differentiation based upon strategic positioning.

“Strategic positioning means performing different activities from rivals' or performing similar activities in different ways.” — Porter 1996
https://pubs.opengroup.org/architecture/o-aa-standard/#strategy

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

Проблема в том, что организации формулируют свои стратегии прямо противоположным образом – методом copy-paste из разных авторитетных источников и стратегий своих конкурентов. Поэтому, определение дифференциаторов часто выпадает на долю корпоративных архитекторов

Всё более вероятным мне представляется развитие событий, при котором нотации моделирования будут вытеснены палитрами элементов архитектурного представления (view) и отношений между ними. Это уже сейчас происходит у облачных провайдеров, выпускающих наборы иконок и руководства по архитектурным диаграммам (см., например, https://cloud.google.com/icons). Их легко расширять, адаптировать под конкретные задачи, версионировать и т.д. Если в подобных наборах чего и не хватает, так это наличия у каждой иконки гиперссылки, на страницу с описанием визуализируемого понятия

Сложнее ситуация с описанием отношений. Вообще говоря, N-арные отношения описываются фреймами, а визуализируются в виде canvas (вот здесь http://masterfacilitator.com/canvas-collection/ полсотни примеров). Но пока они слишком громоздкие, а потому никто не рискует включать несколько фреймов в одну диаграмму. Но рано или поздно это произойдет

Поделюсь кратким обзором https://t.me/theworldisnoteasy/1208 вот этой статьи https://medium.com/@EthanZ/beyond-facebook-logic-help-us-map-alternative-social-media-889b874b7aee про альтернативны современным социальным сетям

The Open Group опубликовал new Snapshot IT4IT Reference Architecture, Version 3.0: Managing Digital Excerpt opengroup.org/library/s210

Вот здесь https://www.infoq.com/news/2021/01/elastic-aws-open-source/ продолжение истории о том, как Elastic изменил тип лицензии для Elasticsearch, а AWS решил форкнуть этот легендарный опенсорс

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

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

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

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