Telegram Web Link
📽 YouTube пока еще работает, но только медленно, а может уже не работает, зато быстро, а может что-то еще...

В общем, все видео и трансляции с канала Архитектура ИТ-решений я скопировал вот сюда: https://disk.yandex.ru/d/0lwmomky8wCjgw Их можно скачать оттуда в формате mp4 или посмотреть в удобном для вас качестве, не загружая на локальный компьютер
👍6340🔥13🎉3👎2
Если вы уже забыли (или не знали) о системах управления бизнес-процессами BPMS, то Bernd Ruecker - сооснователь Camunda, напоминает вам о них в своем свежем тексте Are You Done Yet? Mastering Long-Running Processes in Modern Architectures. Честно говоря, мне всегда нравился этот автор. В первую очередь, четким позиционированием и движков состояний и непосредственно камунды, как неких легковесных готовых компонент(библиотек) для построения более сложных решений. А еще умением изящно выделиться на фоне коммерческих BPMS

Правда, упомянутый выше текст смотрится немного поверхностным, а примеры надерганными и нецелостными. Тем не менее, я его рекомендую
👍142🔥2
Картинка накануне очередных летних выходных. Хорошей вам пятницы!
🔥47👍20🥱3👏21🤨1
Почему-то мне казалось, что однажды я уже делился в канале этим слайдом и ссылкой на статью: Distributed transaction patterns for microservices compared Билгина Ибряма о распределенных транзакциях (5 паттернов двойной записи... - другое название этой статьи).

Оказалось, что не делился, хотя и обещал на одном из вебинаров это сделать. Исправляюсь!
👍29🤔2
В IcePanel собрали пару ссылок на тексты из серии Modelling vs diagramming и дополнили их новыми словами и картинками. Но, на мой взгляд, не сделали главного, а именно не собрали в одну линию эскизы, модели, представления, исходники, работающее приложение, изменения. Обошли стороной вопросы когда и зачем нужны модели или диаграммы

В этом плане, даже матрица Захмана 1987 года, прокладывающая логику от набросков на салфетке до готовой системы, смотрится более целостной.

Ссылки:
[1] Comparison - C4 modelling vs diagramming
[2] Ardoq Compared to Drawing, Modeling, and Data Visualization Tools
[3] Modelling vs diagramming software architecture
7👍6🔥2
Архитектура ИТ-решений
В IcePanel собрали пару ссылок на тексты из серии Modelling vs diagramming и дополнили их новыми словами и картинками. Но, на мой взгляд, не сделали главного, а именно не собрали в одну линию эскизы, модели, представления, исходники, работающее приложение…
Я не ожидал, что предыдущая моя реплика вызовет столь живую дискуссию о различении моделей и представлений. Но может быть это важно, а у меня просто глаз замылен.

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

Собственно, этому и посвящена концепция архитектурного ландшафта, подробно описанная, например, в ADM Practitioners' Guide, см. 3.2.1 Introduction to the EA Landscape Только одна цитата:
This Guide distinguishes EA Landscape from EA, because there will not be a single description in a comprehensive EA Landscape. At any point in time, a typical Enterprise will have several architectures described. Some architectures will address very specific needs; others will be more general. Some will address detail; some will provide a big picture. Some will address the same topics in different states (current, target, and transition), or different periods of time.

Подробнее по указанной выше ссылке. Картинка, демонстрирующая неполноту описаний, взята из упомянутого документа
7👍6
Удивительным образом на сайте Martin Fowler нашел новый для себя текст от Gregor Hohpe. Почти 5 лет назад в заметке Don't get locked up into avoiding lock-in Грегор сделал исчерпывающий обзор того, что принято называть Vendor Lock-in, выделив разные степени подобных привязок (продукт, версия, архитектура, платформа и пр., вплоть до Mental Lock-in). Ну, а заодно, в очередной раз напомнил нам о назначении архитектурных моделей и пользе рассмотрения альтернативных вариантов.

В общем, от привязок нам не избавиться, но заголовок статьи обнадеживает: не замыкайтесь в себе, избегая блокировки
👍29🔥4
С 1 сентября ArchiMate Forum из Open Group собирает идеи и запросы на изменения языка. Называется это Archimate Feedback Campaign 2024

Подробности тут https://www.opengroup.org/archimate/feedback
👍11
Архитектура ИТ-решений
📌 26 июля в 11:00 состоится вебинар с результатами исследования State of DevOps Russia 2024, которое я анонсировал в апреле и инфопартнером которого является наш канал Необходима регистрация
И, наконец, полная версия Исследования состояния DevOps 2024! от команды Экспресс 42

В отчете семь тематических секций, из которых вы узнаете об используемых в индустрии инструментах, рынке труда DevOps и изменениях ключевых целей компаний. По традиции, есть и раздел о Kubernetes и оркестраторах. Особое внимание в этом году уделено инструментальным платформам и тому, с какими сложностями связана их разработка.

Посмотреть полную версию можно 👉 по ссылке!
👍5
В конце июля The Open Group опубликовал шаблоны документов для 10-ой версии TOGAF. Загрузить можно отсюда: https://publications.opengroup.org/togaf-library/practical-application/i094

Внутри:
Preliminary Phase
TOGAF® Template - Architecture Principles.docx
TOGAF® Template - Architecture Repository.docx
TOGAF® Template - Business Principles, Goals, and Drivers.docx
TOGAF® Template - Organizational Model for Enterprise Architecture.docx
TOGAF® Template - Request for Architecture Work.docx
TOGAF® Template - Tailored Architecture Framework.docx
Phase A - Architecture Vision
TOGAF® Template - Architecture Definition.docx
TOGAF® Template - Architecture Vision.docx
TOGAF® Template - Capability Assessment.docx
TOGAF® Template - Communications Plan.docx
TOGAF® Template - Statement of Architecture Work.docx
Phase B - Business Architecture
TOGAF® Template - Architecture Requirements Specification.docx
TOGAF® Template - Architecture Roadmap.docx
Phase C - Information Systems Architecture
Architecture Deliverables Phases C and D.docx
Phase D - Technology Architecture
Architecture Deliverables Phases C and D.docx
Phase E - Opportunities and Solutions
TOGAF® Template - Implementation and Migration Plan.docx
Phase F - Migration Planning
TOGAF® Template - Architecture Building Blocks.docx
TOGAF® Template - Architecture Contract.docx
TOGAF® Template - Implementation Governance Model.docx
Phase G - Implementation Governance
TOGAF® Template - Compliance Assessment.docx
TOGAF® Template - Solution Building Blocks.docx
Phase H - Architecture Change Management
TOGAF® Template - Change Request.docx
TOGAF® Template - Requirements Impact Assessment.docx
🔥33👍142
Необходимость архитектуры (или её отсутствие) вызывает много довольно оживленных споров. Уверен, что большинство подписчиков канала находятся на понятно какой стороне этого спора. Несмотря на это, я позволю себе не совсем обычный тезис: Потребность в ИТ-архитектуре отвечает общим закономерностям возникновения и формирования потребностей. Закономерности эти такие же как для других потребностей, например, потребностей в той или иной вещи или технологии (см. выше картинку про лестницу узнавания Бена Ханта, ну или описание соответствующей маркетинговой модели в гугле).

Развитие системы может находится на этапе, когда никто и не думает про архитектуру и все хорошо. Но потом что-то становится не очень хорошо. Приходит осведомленность в том, почему это самое нехорошо имеет системный характер и просто так его не вылечишь. Начинается поиск вариантов избавления от проблемы и выбор ИТ-архитектуры в качестве основного лекарства (ну или отказ от такого выбора в пользу гомеопатии или agile). Но если предпочтение отдано архитектуре, то потом наступает непростой этап воплощения этого намерения…

В общем, все не просто! Но всегда полезно представлять на какой мы сейчас ступеньке находимся
30👍14💯5
The Solution Architect As Product Manager – новая сотня слайдов от автора учебника по архитектуре решений Alan McSweeney. Краткое резюме (см. слайд 98):
- Давно существуют и широко применяются проработанные подходы к разработке и развитию потребительских продуктов/решений/услуг (в тексте даже упомянут New Product Development (NPD) Stage Gate)
- Архитектура решений может использовать их двумя способами. Первый в том, чтоб расширить восприятие ландшафта изменения (а не ограничиваться доработкой ИТ-систем)
- Второй, для выбора действительно важных и актуальных изменений из огромного множества потенциально возможных изменений (я называю это воронкой инициатив)
- Роль архитектора решений идеально подходит для выполнения этих функций
👍60
Кстати, про архитектурные ката.
Еще один сборник ссылок описаний архитектуры решений победителей и призеров O'Reilly Software Architecture Katas можно посмотреть в ката-логе: https://github.com/TheKataLog
🔥34👍32🤩2
Представляется мне что прошли времена, когда новые метамодели, фреймворки и инструменты вызывали горячий отклик в равнодушных сердцах архитекторов предприятия.

Вот смотрю я на EDGY https://enterprise.design/ пытаясь понять, что в нем не так. И не вижу каких-то серьезных проблем, но как-то совсем не цепляет
👍14💯1
🤨 InfoQ никак не может оставить в покое термин Cell-Based Architecture

В апреле они начали с него свой Software Architecture and Design Trends Report за 2024 год [2] (ссылки будут внизу), в июле выпустили eMag с набором статей [3], а вчера приступили к публикации серии Article Series: Cell-Based Architectures: How to Build Scalable and Resilient Systems [1]

Но, как это бывает практически с любым похожим термином, к его использованию возникает ряд вопрос. Из которых я выделили бы два основных: более-менее единое понимании термина и его полезность. И с тем и с другим у Cell-Based Architecture не очень все хорошо складывается.

Уже появилось множество не вполне одинаковых трактовок этого понятия. У WSO2 есть уже целая референсная архитектура [4], у ByteByteGo лаконичная картинка [5] ну и некоторый объем статей, начиная с Кристофера Сандовала [6] и продолжая теми же текстами InfoQ.

Думаю, большинство удовлетворится тем, что ячейка – это часть системы, обрабатывающая некоторое подмножество общего объема запросов и команд и способная делать это автономно, т.е. не обращаясь за границы ячейки. Подразумевается, что процессы ячейки развертываются на более-менее сосредоточенной группе серверов и взаимодействуют только между собой. Но вот цели такой архитектуры воспринимаются уже по-разному. Для кого-то это про локализацию сбоев. Другие [что странно] воспринимают это как способ обеспечения масштабирования. Третьи видят в ячейках способ сохранить данные внутри юрисдикции, ну и т.д.

Теперь про полезность. Я почему-то думаю, что десятилетия повального увлечения микросервисами немного научили отрасль построению распределенных информационных систем. И вряд ли кто собирается нынче вызывать в синхронном режиме удаленную процедуру из одного сервиса, в ходе обработки вызова от другого, который в свою очередь делает это для обработки запроса от третьего и т.д. Ну, т.е., идея переборок через которые не следует вызывать другие сервисы, банальна и очевидна. Вряд ли стоит называть это некоторым отдельным термином. В микросервисном мире предлагалось stateful взаимодействия осуществлять внутри сервера или даже pod-а. В ячеистой архитектуре потенциально ненадежные взаимодействия локализуются внутри группы серверов. Пожалуй, термин ячейка не будет лишним при развертывании в публичных облаках. Но вряд ли он станет столь же актуальным для частных облаков или собственных инфраструктур.

Но, может я чего-то в этой идее не разглядел. Посмотрим

[1] Article Series: Cell-Based Architectures: How to Build Scalable and Resilient Systems
[2] InfoQ Software Architecture and Design Trends Report - April 2024
[3] Cell-Based Architectures: How to Build Scalable and Resilient Systems
[4] Cell-Based Architecture. A Decentralized Reference Architecture for Cloud Native Applications
[5] A Crash Course on Cell-based Architecture
[6] What is Cell-Based Architecture?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍18🤔63🔥2👏1
Карту причин неудачи при модернизации унаследованных приложений нашел я в бумаге /thoughtworks Legacy modernization. A transformation opportunity

Такое впечатление, что традиционные задачи архитектуры предприятия регулярно переосмысливаются самым разными консультантами. И не то, чтоб они что-то принципиально новое предлагают. Скорее преподносят более современное звучание достаточно известных идей и подходов. Внутри снова история про business capabilities, ценностное предложение, расстановку приоритетов и управление объемом и границами изменения

Впрочем, если интересно, посмотрите эти рекомендации сами. Может вы увидите их как-то иначе
👍16🤔32
Где проходит граница изменения.pdf
3.9 MB
Отлично вчера прошел ArchDays! Огромное спасибо Сергею и всем организаторам. Выкладываю слайды своего выступления и безусловно благодарю всех тех, кто пришел его послушать

Очень раз был пообщаться со всеми, с кем успел! И непременно постараюсь сделать на днях очередной вебинар
🔥63👍20
Номер заявления на регистрацию № 4782434961
🤔13🎉13🥱9👍21
Еще один огромный SlideDoc(слайды с заметками) System Design and Software Architecture от Ruth Malan. Какие-то идеи и слайды встречались у неё раньше. Другие я увидел впервые. Анонс от автора:
Я не хотела ограничиваться тем, что архитектура программного обеспечения - это просто "части и отношения" или ADR и т.д., подробнее здесь: введение в архитектуру ПО как системный дизайн
14👍11🔥2
2025/07/09 09:32:20
Back to Top
HTML Embed Code: