Сталкивались ли вы при автоматизации/цифровизации бизнес-процессов с
1. проблемами использования списков требований, как основного инструмента анализа и проектирования?
2. невозможностью проверки чужих ТЗ на оптимальность принятых решений?
3. Знаете ли вы методику решения этих проблем?
Если ответы Да-Да-Нет, то welcome.
В этот четверг вечером расскажу про методику анализа и проектирования, рассматриваемую как процесс конструкции, трансформации, детализации и пополнения моделей систем разных системных уровней и аспектов.
Доклад с WAW вырос до серии выступлений, это первая серия.
https://sistemnyy-podkhod.timepad.ru/event/3336143/

22 мая (вт) в 19:00 (мск) Виктор Рудь проведёт вебинар на тему «Инструмент моделирования архитектуры предприятия СиММА»

Перед российскими предприятиями стоит задача импортозамещения таких инструментов, как Sparx, Aris, PowerDesigner, Archi. СиММА позволяет сделать такое замещение. В том числе это первое российское ПО, которое поддерживает нотацию Archimate, C4, UML и позволяет конструировать любые другие нотации, или смешивать нотации в произвольном порядке.

■ План вебинара
1. Мета-моделирование в СиММА
2. Моделирование в СиММА
3. Диаграммирование в СиММА
4. Варианты/примеры применения

■ Кому будет полезен вебинар?
— Корпоративным архитекторам
— Бизнес-аналитикам
— Системным аналитикам
— Всем, кому интересны инструменты моделирования и ведения корпоративных репозиториев

■ Ведущий вебинара — Виктор Рудь, Эксперт в области корпоративной архитектуры с 10-летним опытом работы для предприятий федерального масштаба, Автор курсов по архитектуре предприятия и языку Архимейт, в том числе для академии CORS, Владелец первого российского ПО класса Enterprise Architect — СиММА.

👥 У всех слушателей будет возможность задать вопросы в режиме реального времени

Всех, кто не хочет пропустить ни одного анонса наших вебинаров, приглашаем в нашу группу @se_webinars, где мы по топикам публикуем новости, полезные материалы, записи и слайды презентаций вебинаров.

Регистрация обязательна
❗️Если у вас не открывается страница регистрации в браузере Telegram, перейдите в любой другой браузер — это должно решить проблему.

#вебинар@systems_education

Call for papers на ArchDays, ждем ваших заявок на выступления, подавать тут: http://archdays.ru

Давайте поделимся друг с другом :) Где вы ищите информацию по архитектуре, что читаете повседневно, на какие мероприятия ходите, какие сайты или каналы мониторите и/или читаете? Конечно, все про архитектуру. По аритектуре контента не так много, думаю такой обмен источниками будет полезен всем.

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

Формальные методы хороши чем?
- у них есть структура, они при таких же вводных могут дать примерно такой же результат
- за счет повторяемости структуры их можно оценивать, улучшать, развивать
- они снижают уровень субъективизма, политики
- они повышают надежность системы, так как снижают зависимость от конкретных субъектов

Но за это проходится платить… это некоторый уровень бюрократии, некоторое замедление (особенно потому что, что раньше можно было прийти и сказать - «я сказал вот это делать», а теперь какой-то формализованный процесс) и очевидная избыточность, но направленная на повышение надежности.

И самое главное, - несмотря на повышение качества по всем фронтам от использования формальных методов, чаще всего необходимо, чтобы было достаточно число вовлеченных участников, не один единственный архитектор. В идеале так, чтобы на необходимый формализм уходило не более 25%, а лучше 10% времени. У одного архитектора исполнение формальных процедур может занимать до 90% времени, оставшиеся 10% - это когда он ночью решил заняться проектированием :)

Я это к чему, - например, решили формализовать процесс принятия решений, или управления ожиданиями стейкхолдером или еще что, - сначала стоит оценить степень готовности, распределить роли и ответственности, в целом оценить степень влияния на процессы и планируемый уровень эффективности, потому как очень легко под флагом благих намерений лишить архитектурную (да и любую другую функцию) возможности исполнять основную деятельность, даже не заметив этого.

Вариантов, что делать, на самом деле много, от найма, до автоматизации и делегирования, но об этом в другой раз.

Весь мир хайпует на AI и я очень хотел, чтобы на ArchDays появились выступления о практических применениях AI/LLM в архитектурной функции или хотя бы в каких-то других аспектах SDLC. И знаете с чем столкнулся?

Где-то внутри компаний уже год идут исследования, где-то несколько месяцев, по-разному, но рассказать пока никому и нечего, а я узнавал у не малого числа знакомых из разных компаний. Но, - нет, не образовалось пока подтвержденных, готовых к использованию, надежных примеров, ну кроме каких-то совсем базовых «допиши за меня код» и то… в промышленной разработке, где этот код нужно понимать и развивать - так себе.

И вот решил написать сюда, на широкую публику, - есть у кого-нибудь успешные кейсы, в первую очередь в архитектуре, во вторую - на любой практике SDLC, которые можно было бы оформить в метод или практику или паттерн?

Напишите в комментариях, или в личку, может быть подойдет и будет интересно для ArchDays.

10 Best Software Engineering Books of All Time:
https://www.mostrecommendedbooks.com/lists/best-software-engineering-books?id=2

The Scrum Guide Expansion Pack
Updated: June 11, 2025
Authors: Jeff Sutherland, John Coleman, Ralph Jocham
https://scrumexpansion.org/scrum-guide-expansion-pack/

Честная статья про жизнь архитектора по мотивам выступления на archdays

https://scrumtrek.ru/blog/technical-excellence/15789/arhitektor-ozhidaniya-i-realnost/

Во время аудита арх. функции у заказчика родилась фраза:
«Производительность должна быть высокой» — это не требование, это – молитва
:)

13 июля (вс) в 18:00 мск проведём вебинар на тему «CAP-теорема в реальном мире на примере баз данных и реальных систем»

Разберем эволюцию баз данных и пару примеров на основе задач из System Design Interview с применением этих знаний. Вебинар будет продолжением доклада Андрея на System Design, спикер дополнит большим количеством примеров на основе задач из интервью.

▫️План вебинара:
1. Эволюция баз данных
2. Как индустрия отвечала на проблему масштабирования?
3. CAP-теорема и PACELC
4. Что такое распределенные транзакции и Distributed SQL?
5. Разберем разные компромиссы на примере разных настроек ScyllaDB, а затем рассмотрим их на примере двух типичных задач с технических собеседований

▫️Кому будет полезен вебинар:
Разработчикам, техлидам, тимлидам, аналитикам и менеджерам разработки, которым интересно лучше разбираться в распределенных системах и понимать компромиссы, которые нужно делать при проектировании.

▫️Ведущий вебинара — Андрей Манаков
— Работает инженером-программистом около 13 лет
— Имеет опыт в различных областях, включая разработку для десктопа, мобильных устройств и веба
— В последние 10 лет основная сфера интересов — распределённые системы
— В настоящее время занимается разработкой инфраструктуры для машинного обучения в Sharechat
— В свободное время пишет посты о распределённых системах и базах данных в своем блоге

👥 У всех слушателей будет возможность задать вопросы в режиме реального времени

Регистрация обязательна

Прекрасная история :)

Плять, 4 часа вся система была в дауне.

Какой-то клиент через апишку наобновлял данных... оно триггернуло тяжелые вебхуки. Прям мегабайты джейсона.

Раббит кластер начал задыхаться. Система обнаружила что кьюшки заполняются, и триггернула scale up.

Все нахер заскейлилось и открыло овердохуа коннекшенов к раббиту.

Раббит перестал принимать новые коннекшены и вообще отказался даже UI показывать.

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

Монолит ушел в себя, а так как 80% сервисов зависят от монолита хотя бы от одного еедпоинта, все каскадно начало падать по таймаутам.

4 часа танцев с бубном, поддержкой, енфорсинга scale down, увеличения кластера...

Ожили... первый раз такое. Было и миллион месседжей в памяти переживали. А тут на 600к умер. Размер месседжа решает 🥲

Я сейчас активно применяю AI в PDLC, так как канал архитектурный, поделюсь наблюдениями в части архитектуры на основе проектов с клиентами.

1. Мусор на входе - мусор на выходе. AI анализирует данные и здесь очень большая проблема. Сейчас же только ленивый не идет в AI и с чем сталкивается сразу на входе? Либо данных нет, либо они в ужасном состоянии, либо они с огромными пробелами, разбросаны, в итоге мы получаем фрагментированный и непригодный контекст. Если раньше можно было отложить на второй план управление тех долгом, не уделять должного внимания документации, то теперь, если вы хотите получить преимущество от использования AI, придется эти долги отдавать, иначе он выдает какую-то глупость. А отдать этого долг AI никак не помогает, у него просто нет входной иформации. И вот мы начинаем проводить event storming, архитектурые воркшопы, архитектурную базу знаний (структуру документации), чтобы ее можно было начать использовать с AI и только после этого (не совсем только) получить значительный эффект.
2. Для архитектуры очень важен бизнес-контекст, а он обычно тоже слабо описан. Структурированное описание бизнес-требований, с метриками и бизнес-архитектурой тоже становятся достаточно важными. Еще очень важным становится качественный discovery-цикл. AI может прекрасно обрабатывать со всех сторон результаты интервью клиентов, но если интервью проведено плохо – ничего не поможет, поэтому навык проведения интервью (а тут уже AI особо не поможет) тоже достаточно важен. Опрос AI в некоторой роли тоже не сильно помогает, потому что у каждой компании свой контекст, который публично не транслируется за пределы компании того, с кем проводите интервью.
3. Все-таки AI в ближайшее время на заменит архитектора, политику никто не отменял. Он даст гипотезы, подсказки, кучу материалов, но окончательное решение, валидация и ответственность будет все равно за архитектором, поэтому развитие архитектурных скилов критически важно (да, и навык критисеского мышления становится еще более важным, потому что AI порой выдает очень уверенно и обоснованно чепуху). Сильного архитектора, если у него в материалах порядок и у бизнеса в материалах порядок AI действительно очень сильно усиливает, проверено.

В общем, очень похоже на микросервисы. Микросервисы - это архитектурный стиль, один из многих. Чтобы спроектировать хорошее микросервисное решение, нужно хорошо понимать фундамент архитектуры, проектирования распределенных систем и DevOps и микросервисы тогда становятся всего лишь одним из стилей в арсеналей архитектора. С AI выглядит точно так же. Так что потребность в базе никуда не делась, а, видимо, стала даже более важной, иначе мы рискуем получить тысячи нерабочих решений и экспоненциальный рост техдолга.

Книга "Cloud Native Data Security with OAuth: A Scalable Zero Trust Architecture"

Совсем недавно, вот буквально в марте, вышла новая книга на тему Identity & Access Management. Я уже писал, что интересных книг про IAM знаю совсем немного, поэтому, конечно, обрадовался такому событию.

Книга аффилирована с компанией Curity, ее авторы как раз там и работают. Поскольку ранее я уже отмечал свое положительное впечатление о качестве публикуемых компанией материалов, к книге изначально тоже подходил с определенными надеждами =)
Также у Gary Archer, одного из авторов, очень достойные ответы на Stack Overflow, не раз их встречал.

В посте традиционно для книги указал ссылку на Амазон, однако сразу хочу сказать, что в электронном виде книгу авторы сами раздают бесплатно (подсказка: данные в форме можно указать любые).

В книге четыре принципиальных части:
📚 Part I. Introducing Cloud Native OAuth
📚 Part II. Securing APIs with Tokens
📚Part III. Operating Cloud Native OAuth
📚Part IV. Securing API Clients

Собственно, их и намереваюсь рассмотреть, начав с первой.

#book #iam_general #oauth

[1/2] Вторая часть обзора книги “Cloud Native Data Security with OAuth”

Продолжаю писать про данную книгу. Также напомню, что ее можно получить бесплатно.

Вторую часть книги авторы посвящают использованию токенов для обеспечения безопасности API и начинают с главы 5 - «Secure API Development».

Авторам нравится идея, когда конечные сервисы работают только с self-contained, JWT токеном доступа (мне такая идея тоже нравится, кстати), а сами clients могут использовать другие, различные временные учетные данные.

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

Авторы отделяют проверку JWT от самой проверки авторизации, и далее как раз пишут и про нее. Например, упоминают о возможности использования scopes для «грубой» (coarse) проверки авторизации. При этом пишут, что scopes могут помочь задать некоторые «границы» применения токена, но не предоставляют, естественно, сами по себе полного решения задач проверки авторизации.

В контексте обработки истечения времени жизни токенов говорят про «короткое» время жизни токенов доступа, отмечая, что такие токены живут меньше, чем «users’ sessions». Это любопытно, потому что я как раз таким же образом выводил определение короткого времени жизни в докладе “Refresh token в веб-приложениях: быть или не быть?” (надеюсь, скоро доберусь опубликовать материал в виде статьи).

Переходят к вопросам тестирования. Предлагают подход разделения самого JWT и уже того, что называют «claims principal object» - как модельку уже. Из этого исходит идея, что можно тогда покрывать логику проверки авторизации юнит-тестами, используя в качестве фикстуры различные вариации этого «claims principal object».
Также рассказывают, как можно имитировать OAuth-обвязку для тестирования работы конечного сервиса: создать свою ключевую пару, замокать JWKS URI и настроить сервис на работу с ним. Тогда с приватным ключом из ключевой пары можно наподписывать себе любых токенов, что как раз удобно для различных тестов. Ну и с таким подходом, соответственно, поощряют разработчиков к более частому и легкому запуску тестов изолированно, локально – без необходимости поднимать какие-то еще сервисы для обвязки.

Дальше авторы переходят к вопросам проектирования и использования самих access tokens. Предлагают рассматривать access token как контракт, причем даже если он является непрозрачным (opaque), потому что, например, увеличив длину токена, можно тоже поломать чью-нибудь работу.

Пишут, что scopes не являются полным решением для [проверки] авторизации, однако они как раз формируют область действия для токена (я бы сюда еще добавил и audiences). Соответственно авторы тоже говорят о том, что используя скоупы client может получить access token для конкретных целей, ну и что их всегда стоит ограничивать.

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

Упоминая claims, напоминают, что помещая их в токен, authorization server как бы “ручается” за их содержимое, и конечные сервисы будут им доверять. Поэтому важно не помещать непроверенную информацию в содержимое клˈеймов.
Говорят про различные источники данных для клеймов, отмечают и факт, что часто меняющиеся значения не являются хорошими кандидатами на помещение в claims, потому что могут быстро стать неактуальными.

Также в этой главе авторы приводят определенный подход к дизайну scopes и claims, в том числе с учетом дальнейшей эксплуатации и масштабирования.

Затрагивают такую тему, как передача, распространение токенов (token sharing). Кратко разбирают такие подходы, как token exchange и embedding tokens in tokens. Упоминают и про использование токенов доступа при асинхронных операциях: что делать, когда проверка токена может произойти значительно позже отправки сообщения с ним.

(продолжение см. ниже)

#book #iam_general #oauth.