Гошечка отмечает сегодня своё первое 10-летие https://blog.golang.org/10years

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

Нужна картинка!

(насколько большее число людей восприняло бы этот текст, будь он нарисован)

... проблема усугубляется тем, что отработанные техники проектирования заменяются выхолощенными типа "методиками". Найдите, например, в domain storytelling стикер с надписью aggregate. Но жизнерадостные спикеры рассказывают, что придумана эта штука именно для предметно-ориентированного проектирования aka DDD. Возможно, это изменится. Выросла же вслед за техникой customer journey map и потребность в service blueprint

(не ругайтесь, если кому покажется, что опять много новых слов и нет картинок)

Рейтинг инструментов для обучения 2019 https://www.toptools4learning.com/

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

Что делать с legacy системами

Продолжение: https://medium.com/@alexanderpolomodov/%D0%B2%D0%BF%D0%B5%D1%87%D0%B0%D1%82%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F-%D0%BE%D1%82-software-architecture-conference-2019-%D0%B2-%D0%B1%D0%B5%D1%80%D0%BB%D0%B8%D0%BD%D0%B5-part-ii-78425bba82d3

Только ленивый не похвалил очередную версию 3.1 нотации моделирования архитектуры предприятия Archimate за появление в ней потоков создания ценности, а я поругаю, но сначала краткое отступление. В позднем СССР было такое явление как педагоги-новаторы. В частности, Виктор Федорович Шаталов придумал метод опорных конспектов, по сути – хорошо проработанных шпаргалок, в котором выбору для понятий адекватных визуализации отводилось важное место.
В Archimate с пиктограммами всегда было не важно :( Возможно стрелочка и шеврон ассоциируются у кого-то с бизнес-процессом и бизнес-функцией, но у большинства людей они ассоциируются примерно с чем угодно. Но теперь, барабанная дробь, в стандарте появляется value stream. И какой же пиктограммой он отображается, как вы думаете?

Эта замечательная линейка была создана для рисования flowchart diagram. Представьте какого размера будет аналог для создания диаграмм в нотации Archimate 3.1 Поймите меня правильно. Мне нравится Archimate. Но ходить по встречам с таким огромным трафаретом не очень удобно

И снова про Archimate (не отпускает :). На этот раз цифра 3 - это количество измерений. Нас приглашают проникнуть внутрь трехмерной модели, выполненной в этой нотации: https://smarchy.com/blog/f/a-virtual-trip-inside-an-archimate-model

Спорим, что вы не знали о существовании такой спецификации? https://www.asyncapi.io/

В этом году у меня несколько раз просили порекомендовать архитектора экосистемы. Кто это такой? Какими компетенциями обладает архитектор экосистемы? Пока The Open Group безмолвствует на эту тему, появляются разные попытки создать, ну, например The Business Ecosystem Architecture Modeling (TEAM) framework. https://www.thevalueengineers.nl/what-is-your-ecosystem-the-ecosystem-architecture-modeling-framework/ По архитектурной традиции в фреймворке много букв "С": Company, Customers, Competitors, Complementors...

Интервью Gene Kim о книжке "Проект Единорог" (не путать с Фениксом). После The DevOps Handbook (2016) и Accelerate (2018) очередная вымышленная история, в которой рецензенты дружно узнают свои проекты. Буду ждать перевода https://www.infoq.com/articles/unicorn-project/

Какая прелестная новость пришла вчера про ГосОблако
(Государственная единая облачная платформа,
ГЕОП) Правительство назначило двух единственных исполнителей "Ростелеком" и НИИ "Восход" (не спрашивайте меня, как такое бывает) http://www.tadviser.ru/index.php/%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D1%8F:%D0%93%D0%BE%D1%81%D0%BE%D0%B1%D0%BB%D0%B0%D0%BA%D0%BE_%D0%93%D0%BE%D1%81%D1%83%D0%B4%D0%B0%D1%80%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D0%B0%D1%8F_%D0%B5%D0%B4%D0%B8%D0%BD%D0%B0%D1%8F_%D0%BE%D0%B1%D0%BB%D0%B0%D1%87%D0%BD%D0%B0%D1%8F_%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D0%B0_(%D0%93%D0%95%D0%9E%D0%9F) В принципе, это всё что следует знать про ГосОблако хотя ниже и написано многабукв

Прикольный титл у презентации: Камо грядеши (Куда ты идешь), Enterprise Architecture Management?

Предсказываю паттерны корпоративной интеграции. Недорого! Гарантированный результат!

O'Reilly купил https://www.katacoda.com/ Демо, которые я использовал в курсе Микросервисная архитектура, https://itexpert.ru/msa/ остаются в открытом доступе (пока?). Что будет с новыми интерактивными обучающими сценариями не очень понятно. Подробности здесь: https://www.oreilly.com/online-learning/interactive-learning.html

Познавательно о governance https://twitter.com/DPBoK_TM/status/1197215095069331459

При всём огромном уважении к Мэтту Стайну (автору знаменитой книжки "Migrating to Cloud-Native Application Architectures" и других отличных текстов) его перечисление стратегий декомпозиции мне представляется неполным https://builttoadapt.io/whats-your-decomposition-strategy-e19b8e72ac8f Впрочем, вопрос затронут мега-важный. Наверное, самый важный для архитектора ИТ-решений

Сейчас будет очередная серия заметок в формате «много слов об одном и том же». На этот раз о том, почему техника Domain Storytelling (далее DS) сорвав низко висящее яблоко, не съела его, а всего лишь понадкусывала.

Вообще, проводить анализ-дизайн в виде веселых групповых сессий с рисованием каракуль и развешиванием стикеров хорошо и правильно. Неправильно выходить с таких сессий без внятного результата. В DS совершенно справедливо полагается, что создать хорошую модель предметной области в DDD-подходе невозможно без обсуждения поведения. Именно это помогает нам определить агрегаты, репозитории, быть может даже ограниченные контексты. В общем, те сущности, которыми мы оперируем в domain driven design. Проблема DS в том, что всех этих агрегатов, объектов-значений и пр. в нём нет. Персоны есть, документы есть, даже e-mail и смартфоны есть, а вот агрегатов нет. Зачем же мы тогда проводим такие сессии? #карта_предметной_области

Изначально в DDD было принято рисовать концептуальные карты (concept map). Это отличный метод, у которого есть всего лишь два недостатка. Первый заключается в том, что нарисовать при помощи концептуальной карты можно примерно всё. Т.е. метод настолько универсален, что мало отличается от набросков на салфетке и поэтому и методом то может называться с большой натяжкой. Проблема номер два: концептуальная карта – это граф. Рисовать его более-менее просто, а вот читать нет. Нету в нем сжатия информации и потому эффекта мгновенного понимания ожидать от такой картинки не следует. Ну и вспоминая основную находку Domain Storytelling – совмещение описания структуры и описания поведения, мы вынуждены признать, что в концептуальных картах DDD этого тоже нет. В общем, максимум для чего они годятся – выделять границы контекстов
#карта_предметной_области