Архитектура ИС. Страница 14
4563
@it_arch
Разговоры об архитектуре корпоративных информационных систем (архитектура предприятия, архитектура ИТ-решений, микросервисы).
-
Архитектура ИС
-
Архитектура ИС
Наконец расставил тайм-коды https://youtu.be/kN7XNp9Feio -
Архитектура ИС
Мэтт МакЛарти представил большой текст про Data Mesh blogs.mulesoft.com/api-int…ata-mesh Возможно, после первых абзацев вы решите что читать его вряд ли следует, но не спешите. Автор вовсе не собирается безоговорочно поддерживать новую модную концепцию блистательной Жамак Дехгани. И потому дальше по тексту он выскажется о том, чем data mesh не является, а так же поделится своими мыслями и сомнениями. Почему-то, такое теперь редкость -
Реклама
-
Архитектура ИС
📆 21 декабря 10:30 MSK Решил заранее проанонсировать очередной бесплатный вебинар https://mxsmirnov.timepad.ru/event/1868368/ В этом году мы часто обсуждали архитектурное описание, разбирали каты O'Reilly, смотрели различные подходы, обсуждали старые и новые инструменты. Под конец года хочу посмотреть на архитектурное описание несколько с другой точки зрения. Поговорить о совместной работе, частично структурированных данных и когнитивной нагрузке. Регистрация по ссылке. Трейлер уже на YouTube-канале 
-
Архитектура ИС
Лет 10 назад я увлекался штукой, которая называется adaptive case management (в других источниках слово adaptive заменялось на dynamic или даже advanced). Этот термин обозначал особый вид бизнес-процессов, для которых не всегда можно указать правильную последовательность шагов, ведущую к цели, да и не так уж она важна по сравнению со спецификой данного конкретного случая. Здесь есть некоторая игра слов, даже смыслов. Слово кейс, с одной стороны, обозначает портфель или папку с бумагами (материалы дела, история болезни и т.п.), а с другой - некоторый уникальный прецедент, требующий своего подхода или решения (кейс, при обсуждении успешных примеров в бизнес-школе). Обычно с кейсом работает специально назначаемый на него человек – case worker (лечащий врач, адвокат, в общем knowledge worker), который и решает, что, когда и зачем следует делать в сложившейся ситуации. Ну так вот, ИТ-архитектура – это типичный процесс вот этого самого адаптивного кейс-менеджмента. Когда с одной стороны нам необходимо довольно тщательно фиксировать некоторые факты: текущее положение дел с имеющимися процессами, приложениями и данными, требования, достигнутые договоренности и пр. А, с другой стороны, постоянно выстраивать и перестраивать набор следующих действий (у юристов в таких случаях говорят: в связи с вновь открывшимися обстоятельствами дела). Какую диаграмму нам следует теперь нарисовать, какого типа архитектурные решения проработать и т.д. А написал я все эти слова по мотивам обсуждения – можно ли сэкономить на ИТ-архитекторе, взяв специалиста попроще и вооружив его правильными паттернами. Вопрос из серии: можно ли сэкономить на враче или адвокате? Конечно, можно, если ваша цель не выздороветь, а правильно и своевременно заполнить требуемую минздравом документацию. Хорошей вам пятницы, друзья! -
Архитектура ИС
Всем привет! Вчера моя команда заняла 2е место в конкурсе O’Reilly Arch Katas. Так получилось, что в этом раз нужно было по-сути расширить функционал системы, которую спроектировал Андрей Гордиенко и победил на одном из предыдущих мероприятий. Вот что получилось в итоге у нас: https://github.com/vadagama/sever_crew Если по-делу накидаете на вентилятор, буду признателен. Хорошие отзывы тоже люблю. 🙂 -
Архитектура ИС
И снова в нашей группе архитектурные katas. Крайне престижное 2-место и отличный пример архитектурного описания. Но, в первую очередь, хочу обратить внимание на отличную презентацию постановки задачи и предлагаемой архитектуры ИТ-решения https://youtu.be/NENcmM48n-M Всем срочно учиться создавать слайдкасты! -
Архитектура ИС
Управленческий паралич. До пятницы еще далеко, но банальностей в ленте новостей уже хватает. Внесу и я свой скромный вклад в этот набирающий силу поток. Я уже не раз вспоминал метафору Грегори Хоупа, сравнивающую архитектурное решение с финансовым опционом - возможностью, но не обязательством купить или продать в будущем некоторую бумагу по заранее зафиксированной цене architectelevator.com/archite…-options Кажется, что отправляя в будущее такие развилки архитектура препятствует своевременному принятию каких-либо решений. В частности, решений управленческих. Но посмотрите на это с другой стороны. Корпорации скованны повальным нежеланием принятия каких-либо решений. Вопросы не двигаются с мертвой точки месяцами. Все как будто договорились исключить из делового лексикона слова "да" и "нет". Хоть как-то изменить ситуацию могут гарантии возможности отказа от ранее принятого решения, возврата в текущее состояния. Те самые архитектурные "опционы". Они как тормоза, помогающие гоночному болиду ехать быстрее. Единственное, что архитектору предприятия неустанно надо об этом рассказывать -
Архитектура ИС
Спасибо всем за поступившие комментарии! Жду продолжения, но выскажусь немного про Low-Code: Просто идея. Может это и бред, но... В общем, сначала были венчурные инвесторы и был SaaS. Первые давали деньги вторым, а те передавали их AWS. Все хорошо работало! Потом SaaS стало много, впрочем, как и венчурных инвесторов и их денег. И еще AWS стало много, а вот пользователей, готовых платить за SaaS - не очень много. Подписку на доски купили, рисовалки купили, что еще юзеру надо? К несчастью в некоторый момент все научились деньги считать(end2end аналитика, юнит-экономика - все дела). В общем, нельзя стало делать SaaS без платящих пользователей. И тут разработчики SaaS задумались: чем бы еще юзверей развлечь? Покопались в архивах истории. Нашли! Тот самый low-code из начала этого затянувшегося сообщения. Как говорится, чем бы дитя ни тешилось, лишь бы платную подписку продлевало! -
Архитектура ИС
Поделитесь своим мнением о моём сентябрьском тексте https://mxsmirnov.com/uml-schrodinger/ Я постарался вытащить несколько альтернативных суждений о том, что же с нами случилось четверть века назад от таких известных людей как Эрик Эванс или Алистер Коберн. Может надо было голосом этот текст записать? В общем, делитесь, и не только лайками, но и критическими замечаниями или вопросами. Спасибо! -
Архитектура ИС
В целом, скептически отношусь к айтишным подкастам, но этот выпуск Читаем вместе https://t.me/readingtogetherdev/37 хорошо зашел. Спасибо! (... и это не реклама ;-) 
-
Архитектура ИС
The Process Automation Map Любителям бизнес-процессов: большой текст про разные типы процессов (и подходы к их автоматизации) от Bernd Rücker (Camunda) blog.bernd-ruecker.com/explori…a181a747 и его более короткая версия techspective.net/2021/11…tion-map -
Архитектура ИС
Два года назад написал у себя в блоге заметку Развилки архитектурных решений с предостережениями для других. Сейчас пригодилось в качестве предостережения для самого себя, что подтвердило два банальных тезиса: 1) блог полезно писать; 2) еще более полезно его потом самому и читать -
Архитектура ИС
Тоже поделюсь сегодняшним текстом с хабра про интервью аналитика https://habr.com/ru/post/591057/ С одной стороны хорошо, что аналитики наконец выучили слова идемпотентный или безопасный. С другой стороны, экономить на архитекторах всё равно себе дороже будет -
Архитектура ИС
Какой шаблон описания микросервисов выбрать?
Несмотря на то, что microservice canvas придумано уже не мало, все они похожи довольно похожи. По крайнем мере, в каждом шаблоне взаимодействие сервиса с внешним миром описывается по схеме Queries-Commands-Events. Так какой выбрать?
Наиболее простой вариант взять готовый файл у LaunchAny В принципе, он повторяет шаблон Matt McLarty просто переставив ячейки. Если взаимодействий у сервиса чуть больше, то лучше переключиться на шаблон от Криса Ричардсона в нем строчки вставлять удобней. Ну или задуматься об инструментальной поддержке, как в этой штуке MDC Editor, визуализирующей описание сервиса на лету -
Реклама
-
Архитектура ИС
В разговорах о том, что роль ИТ-архитектора всё больше смещается в область внутреннего консультанта по технологиям (и не только по технологиям) мы часто упускаем один момент
Поделюсь ссылкой на сообщение в канале ИТ-АС (ИТ-Архитектура, ИТ-Стратегия, ИТ-менеджмент в корпорациях), архитектура, стратегия, менеджмент (это не реклама :) и вставлю в рекомендацию как разговаривать с ночальнегами свои пять копеек
Мы все ищем универсальные рецепты для разных людей и ситуаций. Но лучше, что можно сделать - подходить к каждому человеку индивидуально. Выстроить у себя в голове, пусть поначалу не очень правильную гипотезу о том, какой он. Как этому конкретному руководителю удобно обсуждать решения, вникает ли он быстро или медленно, лезет в детали или скользит по верхам, принимает решения сразу или уходит подумать. Спросить у коллег, что они знают о нашем собеседнике, какие картинки тот воспринимает, как выстраивает разговор. Узнать результаты других обсуждений. И идти разговаривать с конкретным человеком.
Я долго не мог понять, насколько люди ценят такое вот индивидуальное отношение.
С ситуациями похожая история. Их просто намного больше, чем людей. Но придать ситуации уникальность – мега-инструмент в рассмотрении архитектуры решений -
Архитектура ИС
Evolutionary Architecture - аn architecture that supports guided, incremental change across multiple dimensions – не самое понятно определение, сформулированное Нилом Фордом. Intentional Architecture – еще один новый термин из Open Agile Architecture™ и так далее и тому подобное
Что здесь обязательно учитывать. Все эти изменения в архитектуре идут общим пакетом. Причем не только с изменениями в архитектуре, но и в разработке, развертывании, в ИТ в целом. Смещение от проектов к продуктам расщепляет архитектурные решения на те, от которых мы сможем потом отказаться и на те, которые формируют продукт и являются преднамеренными (вытекают из продуктовой стратегии и архитектуры самого продукта). Но вне продуктового контекста такое разделение вряд ли осмысленно.
Кто-то уже шагнул в такое пакетное изменение, но для многих компаний главными словами остаются проекты и системы. Что делает в этом случае? Нужно ли здесь изменение архитектурных подходов и возможно ли оно. Думаю, что да. Но выглядит всё непросто. Уж точно надо все такие вещи чётко предварительно проговаривать -
Архитектура ИС
Похоже, что разговоры про культуру заходят у нас не очень. Потому сегодня вернемся к технологиям. Поделюсь ссылкой на рассуждения архитектора из MuleSoft Антонио Гарроте, об описании асинхронных взаимодействий https://engineering.salesforce.com/asyncapi-and-openapi-an-api-modeling-approach-db9873695910
Для REST есть спецификация Open API. А для обмена сообщениями AsyncAPI как-бы есть, но мало кто ей пользуется.
На самом деле, я думаю, что проблема глубже и стандартизировать надо не обмен сообщениями, а обработку потоков сообщений. Но, тем не менее