Собственно, короткая заметка о выходе TOGAF10 у меня в блоге https://mxsmirnov.com/2022/04/28/togaf-10/

Некоторые шутники уже меня спрашивают:
- Потребуется ли миграция архитектурных репозиториев на новую версию TOGAF-10 с предыдущих версий

Шутка, безусловно, веселая, но как в любой шутке в ней есть доля чего-то большего. Во-первых, некоторые изменения и в метамодели, и в содержании стандарта в целом всё же есть. Насколько существенные - это уже другой вопрос Таблички с изменениями можно посмотреть в Appendix A An Introduction to the TOGAF® Standard, 10th Edition. Во-вторых, The Open Group, как мне представляется, действует вполне осознанно, пытаясь сохранить свои лидирующие позиции центра компетенций по архитектуре предприятия. Посмотрев какой отклик получил O-AA, а до этого и DPBOK, сейчас они возвращают наше внимание к TOGAF. И если кого-то и что-то не устраивало и не устраивает в основном стандарте, то ответы и уточнения теперь придется искать всё равно в TOGAF, но уже в TOGAF Series Guides или в TOGAF Library, куда попал, например, стандарт IT4IT и пр.

Возвращаясь к определению Bounded Context от Alberto Brandolini:

"A Bounded Context is not a purely logical (language consistency, unity of purpose) or physical (code separation, deployment unit) concept. It's an obligation to maintain integrity between those views."

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

На такую же мысль меня наводят и фразы:

"Bounded context means different models of the same thing (e.g., books, customers, etc.) and is represented by models and software that implement those models."

Иными словами, Bounded Context образует связанность между программируемой моделью и её сущностью реального мира.

Следующие две фразы трактуют термин "bounded" именно как "связанный":

"How to minimize inter-bounded context dependencies?"

"The components of complex systems are bounded sub-systems or agents that adapt or learn when they interact."

А следующая фраза говорит о том, чем именно "связаны" (т. е. скованы) команды. Кстати, слово "скованный" - один из вариантов перевода термина "bounded".

"The scope of each team was bounded by their business line and their products."

Следующие две фразы говорят о том, каким именно образом происходит "сковывание":

"Bounded contexts aligned with data source domains, such as fixed-income trading or consumer lending"

"Bounded contexts aligned with consumption domains, such as accounting or liquidity"

Эта идея немного рушится фразой:

"A bounded context is the boundary for the meaning of a model."

Но тут можно вспомнить, что термин "boundary" полисемантический, и означает также "межу" или "грань". Обратите внимание на фразу "boundary for the meaning". Не "boundary of subsystem", а "boundary for the meaning", что привязывает реализацию (solution space) к её "предметному смыслу" (meaning of a model). Т.е. главное не ограничить абы как подсистему, а привязать её к доменному толкованию. Именно это Alberto Brandolini и назвал "obligation to maintain integrity".

"bounded contexts delimit the applicability of domain models. As such, the bounded context is within the solution space."

Все цитаты из AO-S.

Что думаете? Какие мысли по этому поводу?

"Системная архитектура программно-насыщенных комплексов: за пределами нотаций, инструментов и техник" с участием @WatchTh15 https://youtu.be/2AARoFUy7vU

Чем отличается "validation" от "verification", одним предложением:

📝 "The validation process determines that the "right product is built". The verification process determines that the "product is built right".
-- "ISO/IEC/IEEE 12207:2017 Systems and software engineering — Software life cycle processes"

Чем отличаются Architecture, Design и Implementation:
- https://resources.sei.cmu.edu/asset_files/WhitePaper/2003_019_001_29559.pdf

Копия:
- https://www.researchgate.net/publication/221553844_Architecture_Design_Implementation

ГОСТы возвращаются. В начале 2019-го, приказом 216 Росстандарт отменил так называемые руководящие документы РД-50, задававшие требования к содержанию документов по автоматизированным системам.

С конца апреля 2022-го они снова действуют. Теперь под новым названием ГОСТ Р 59795-2021 Возможно, детальное сравнение и выявит ряд отличий, но заниматься подобной ерундой я не стану. Всегда считал, что ИТ-архитекторам, вынужденных работать с ГОСТами, лучше держаться за свой ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011 и дистанцироваться от требований 19-ых и 34-х ГОСТов, чтоб не утонуть в бессмысленности современной частной или государственной бюрократии

Btw, https://habr.com/ru/news/t/596715/

Наверное, самая краткая и понятная картинка по мотивационным элементам Archimate, которую я когда-либо видел: https://mellarius.ru/architecture/levels%20-%20motivation.png

#SoftwareArchitecture #ArchiMate

Часто спрашивают про альтернативы для Miro. В Archimatetool есть доска со стикерами (см. New Sketch View на стр. 110). Можно делать EventStorming обычными стикерами, а не только используя "C.1.10 Business Process Cooperation Viewpoint". При этом становятся доступны историрование, версионирование, восстановление, коллективная разработка, трассировка изменений, при этом информация не покидает периметра безопасности, on-premise, а доступ к информации задается обычной конфигурацией git-сервера.

#EventStorming #DDD #Microservices #SoftwareArchitecture #ArchiMate

Привет. Тут видео с Лампортом вышло для затравки, а потом полез в комменты (https://lobste.rs/s/slsiqa/leslie_lamport_interview_how_write) к статье и нашёл его веб страницу с видео курсами по TLA:
- https://lamport.azurewebsites.net/video/intro.html
- https://lamport.azurewebsites.net/video/videos.html

Мне тут друзья сообщили, что кто-то использует мое фото и просит у участников группы "грошей". Будьте осторожны, пожалуйста.

Про оценивание задач:

- "Practice Standard for Scheduling" 3d edition by Project Management Institute

"Practice Standard for Project Estimating" 2d edition Project Management Institute

- "Software Estimation: Demystifying the Black Art (Developer Best Practices)" by Steve McConnell (я встречал в интернете краткий конспект)

- "Agile Estimating and Planning" by Mike Cohn

Очень кратко (всего 3 страницы) о методике оценивания PERT:
- "The Clean Coder" by Robert C. Martin, "Chapter 10 Estimation :: PERT"

Статья, отвечающая на очень частый вопрос:
- "How Do Story Points Relate to Hours" by Mike Cohn

Вводное видео: YOW! 2016 Robert C. Martin - "Effective Estimation (or: How not to Lie)"

"How to Read Lead Time Distribution" by Mauvisoft Team

#Estimation

Простое пошаговое описание Event Storming с сайта про архитектуру от IBM https://www.ibm.com/cloud/architecture/architecture/practices/event-storming-methodology-architecture/ Ничего лишнего.

Пример EventStorming в предметной области логистики - доставка контейнеров.

"Container Shipment Analysis"
- https://ibm-cloud-architecture.github.io/refarch-kc/implementation/event-storming-analysis/

Исходники и демонстрационная архитектура:
refarch-kc - Implementation solution for container shipment using Event-Driven Architecture
- https://github.com/ibm-cloud-architecture/refarch-kc

#EventStorming