Запись https://youtu.be/SWzyDGG52mQ

Дорогие друзья!

Наступает Новый, 2023-й год! По традиции, мы связываем с новогодним праздником свои самые лучшие, самые светлые мечты и надежды. Разрешите и мне пожелать вам позитивных изменений, открытия новых горизонтов и проявления обнадеживающих перспектив! Здоровья и благополучия вам, вашим друзьям и близким!

С Новым годом! 🍾🎄🎉

Новый год начинается с вечнозеленой темы https://www.workingsoftware.dev/software-architecture-documentation-the-ultimate-guide/, которую Patrick Roos предложил осмысливать при помощи шаблона #arc42 и #с4model

Продолжение ответов на вопросы: https://youtu.be/yIv6rGa2Pck

Насколько применимы идеи DDD в архитектуре предприятия? Готовы ли enterprise architects к серьезному восприятию концепций ubiquitous language, bounded context, которые возможно потребуют отказа от идеи единой метамодели? Имеет смысл хотя бы это обсуждать или подходы корпоративной архитектуры и предметно-ориентированного проектирования настолько разные, что и мешать их не стоит

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

PS: Ссылка на группу https://tttttt.me/+RjhmcXf0go0zMjli

Мне показалась такая метафора достаточно красивой, пусть и немного многословной. https://betterprogramming.pub/is-your-microservices-architecture-more-pinball-or-mcdonalds-9d2a79224da7

... но всё равно короче, чем объяснить что такое CQRS тому, кто еще не в курсе

Cranking out lines of code isn’t the most value-add activity for architects. But understanding system structures and hidden dependencies is, and debugging is all about that

Gregor Hohpe начинает 2023 год с разговора на нашу любимую тему: "Должен ли архитектор писать код" и приходит к неожиданному выводу о большей пользе для архитектора от участия в отладке: https://architectelevator.com/transformation/debugging-architect/

Наконец у Alan McSweeney появилась новая, вот такая картинка, описывающая типы входящих в архитектуру решения элементов

2023 - новый год платформ? Поделюсь ссылкой на сообщение в канале Express 42. Просто потому, что я тоже обратил внимание на PlatformCon 2022 и не столько из-за выступления G.Hohpe, а скорее вот из-за этого незатейливого рассказа с прекрасным названием Building disruptive platform while rewriting legacy applications. Думаю, в ближайшее время мы снова будем много говорить о платформах. И не важно, есть у вас унаследованное приложение из которого вы сделаете платформу или же вам потребуется луч маяка. Вера в волшебную платформу проявляется там, где перестают срабатывать другие механизмы управления сложностью
#platformengineering

Platform Engineering как новый тренд в IT

Всего за какие-то пару лет платформенная инженерия перешла из разряда «шумихи» в современный IT-тренд. Многие компании, инженеры и просто идейные вдохновители смогли на практике изучить все ценности концепции.

Совсем недавно многие даже не слышали о такой области как Platform Engineering. На сегодняшний день, существуют десятки международных сообществ с тысячами последователей концепции платформенной инженерии. А первая в мире конференция PlatformCon собрала под одной крышей более 6 000 участников даже несмотря на ограничения в связи с пандемией.
При этом было бы неправильно говорить, что платформенная инженерия – совершенно новое явление. Одно из первых упоминаний появилось в 2017 году в Thoughtworks Tech Radar. Далее концепцию более подробно осветили Мануэль Паис и Мэтью Скелтон в своей книге «Топологии команд», выпущенной в 2019 году.

Сегодня все больше ведущих специалистов в компаниях из разных сфер ставят платформенную инженерию в качестве основного приоритета для развития бизнеса. В рамках исследований, специалисты разбили компании по секторам, указав процент специалистов внутри этих компаний, проголосовавших «за» внедрение концепции Platfrom Engineering⬇️

Кстати, уже в наступившем году McSweeney опубликовал огромную, как всегда, презентацию об архитектуре данных для архитекторов решений: https://www.researchgate.net/publication/366964200_Data_Architecture_For_Solutions

Отличная задумка - показать читателю разработку High Level Design от начала и до конца сделана в тексте Solution Architecture 101 : For Budding Architects Но, к сожалению, автор остановился в самом начале, на уровне предварительного наброска.

Подумываю о том, чтоб как-нибудь завершить в рамках одного из своих курсов

Я не знаю в каких еще инструментах рисования архитектурных картинок реализованы потоки (flow, анимация последовательности взаимодействий, в общем, см. картинку здесь: https://twitter.com/ice_panel/status/1615014031018053634),

Но вот в IcePanel они выглядят очень даже неплохо. Почитать подробнее можно во вчерашней заметке https://blog.icepanel.io/2023/01/16/reducing-diagram-maintenance-with-icepanel-overlays/

Обещал найти ссылку о применимости шаблона описания архитектурных решений ADR для более широкого класса решений.
Делюсь: ADR = Any Decision Record? Architecture, Design and Beyond

Вот прям сейчас, на наших глазах, в твиттере Саймон Браун рассказывает Крису Ричардсону что такое c4model https://twitter.com/crichardson/status/1615385523438092298

Похоже, что предыдущие 10 лет эти люди провели на разных планетах. Книжки, наверное, писали. Времени заглянуть в интернет не было

Краткое графическое введение в c4model от IcePanel

https://blog.icepanel.io/2022/10/03/c4-model-for-system-architecture-design/

Возможно, что в каких-то областях деятельности метамодель Nikola Schou окажется полезной, но мне она не понравилась. Зато мне понравился сам текст, в котором он её описывает A new software architecture metamodel inspired by C4, Agile and TOGAF

Статья того же автора https://nikolaschou.medium.com/let-us-revise-the-c4-model-for-software-architecture-diagrams-e2ae0d3de41c из которой следует, что он просто не понимает что такое контейнер в с4model. Обычно после этого говорят политкорректную фразу о том, что если вы используете UML и видите в этом пользу, то можете продолжать это делать, для остальных же ...

В прошлом году обновился ISO/IEC/IEEE 42010 – основной, а долгое время и единственный ИСО-шный стандарт по архитектуре. Теперь он называется Software, systems and enterprise — Architecture description вместо Systems and software engineering — Architecture description – названия 2011 года.

Внесены некоторые изменения и в содержание стандарта. В частности, основные определения синхронизированы со стандартами 2019 года. Так основное определение теперь звучит так:

3.2 architecture - fundamental concepts or properties of an entity in its environment and governing principles for the realization and evolution of this entity and its related life cycle processes

Т.е вместо архитектуры системы мы теперь рассматриваем архитектуру an entity, в качестве которого может выступать:
enterprise, organization, solution, system (including software systems), subsystem, business, data, application, information technology, mission, product, service, software item, hardware item, etc.

Архитектуру чего именно рассматривают 42-ые стандарты лучше почитать в ISO/IEC/IEEE 42020:

Архитектура можно рассматривать в широком смысле или же она может относится к какому-либо объекту (enterprise, solution, system… ), а может и к subject of interest (security architecture, functional architecture, physical architecture), ну и иногда перед словом архитектура может стоять purpose of the architecture, например: integration architecture. (см. раздел 0.2 стандарта, он открыт по приведенной выше ссылке)