Вчерашнее обсуждение распределенной, а теперь и опенсорсной, YDB в нашей группе несколько схлынуло. Смотреть надо, но думаю там будет все более-менее нормально. Однако, вопрос: а не потеряют ли актуальность все эти CQRS-ы и Event Sourcing-и? - после таких новостей остается
Telegram
Alexander "SonnySlave" Zaitsev in ИТ-архитектура во всех её проявлениях
Кому интересно - Яндекс свой YDB опенсорснул: https://ydb.tech/
Архитектура ИТ-решений
Вчерашнее обсуждение распределенной, а теперь и опенсорсной, YDB в нашей группе несколько схлынуло. Смотреть надо, но думаю там будет все более-менее нормально. Однако, вопрос: а не потеряют ли актуальность все эти CQRS-ы и Event Sourcing-и? - после таких…
И просматривая ссылки на эту тему я совершенно случайно обнаружил книжку Gregory Young Versioning in an Event Sourced System (практически дописанную, в 90% готовности) Книжку можно купить, а можно воспользоваться кнопкой "Free To Read Online". Я прям зачитался
Leanpub
Versioning in an Event Sourced System
Архитектура ИТ-решений
В момент выхода версии 9.2 TOGAF развивающая его The Open Group анонсировал свое намерение превратить TOGAF в открытую расширяемую библиотеку. В 10-ой версии это практически реализовалось. PDF-ы скачать можно, но их довольно много и работать с ними не очень…
Собственно, короткая заметка о выходе TOGAF10 у меня в блоге https://mxsmirnov.com/2022/04/28/togaf-10/
Архитектура ИТ-решений
Собственно, короткая заметка о выходе 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 и пр.
- Потребуется ли миграция архитектурных репозиториев на новую версию 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 и пр.
pubs.opengroup.org
An Introduction to the TOGAF® Standard, 10th Edition
The Open Group
Поступают первые обзоры 10-ой версии TOGAF. Хочу обратить ваше внимание на заметку What Makes TOGAF 10 a Valuable Contribution, которую написал Markus Freimuth Согласен с его идеями о назревшей необходимости актуализировать ADM. Этого пока не случилось, но в TOGAF Series Guides появились руководства, предлагающие альтернативу традиционному тяжеловесному процессу
The Digital Blog and Podcast - Architecture, Technology, and Digital Transformation
What Makes TOGAF 10 a Valuable Contribution
TOGAF 10 was recently released. Major changes to the old version include a restructuring of the content to allow for easier understanding, fewer inconsistencies
Многие знакомые мне ИТ-архитекторы стараются дистанцироваться от темы low-code/no-code. Попыток серьезно об этом поговорить немного, да и они заглушаются хором отраслевых консультантов и поставщиков loconoco решений. Именно поэтому стоит обратить внимание на январскую заметку The Quest for Low-Code: 9 paths, some of which actually work от Gregor Hohpe. В ней есть над чем поразмышлять и даже о чем поспорить
The Architect Elevator
The Quest for Low-Code: 9 paths, some of which actually work
No-code, low-code has become a popular quest. Architects are called in to separate fact from fiction. No French were harmed.
ГОСТы возвращаются. В начале 2019-го, приказом 216 Росстандарт отменил так называемые руководящие документы РД-50, задававшие требования к содержанию документов по автоматизированным системам.
С конца апреля 2022-го они снова действуют. Теперь под новым названием ГОСТ Р 59795-2021 Возможно, детальное сравнение и выявит ряд отличий, но заниматься подобной ерундой я не стану. Всегда считал, что ИТ-архитекторам, вынужденных работать с ГОСТами, лучше держаться за свой ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011 и дистанцироваться от требований 19-ых и 34-х ГОСТов, чтоб не утонуть в бессмысленности современной частной или государственной бюрократии
С конца апреля 2022-го они снова действуют. Теперь под новым названием ГОСТ Р 59795-2021 Возможно, детальное сравнение и выявит ряд отличий, но заниматься подобной ерундой я не стану. Всегда считал, что ИТ-архитекторам, вынужденных работать с ГОСТами, лучше держаться за свой ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011 и дистанцироваться от требований 19-ых и 34-х ГОСТов, чтоб не утонуть в бессмысленности современной частной или государственной бюрократии
docs.cntd.ru
О признании недействующими на территории Российской Федерации актов, изданных государственными органами, правопреемником которых…
О признании недействующими на территории Российской Федерации актов, изданных государственными органами, правопреемником которых является Федеральное агентство по техническому регулированию и метрологии / Приказ Росстандарта от 12 февраля 2019 г. № 216
Архитектура ИТ-решений
ГОСТы возвращаются. В начале 2019-го, приказом 216 Росстандарт отменил так называемые руководящие документы РД-50, задававшие требования к содержанию документов по автоматизированным системам. С конца апреля 2022-го они снова действуют. Теперь под новым…
Давайте я слегка обострю. Документирование, т.е. представление фактов, знаний, договоренностей в виде набора отдельных текстов (возможно, включающих картинки и таблички) – привычный, но довольно архаичный способ организации информации. С конца XIX века предпринимаются попытки существенно его поулучшать. Сначала речь шла о строгих формализмах (Наверное, здесь было бы уместно порассуждать об «Исчисление понятий» Готтлоба Фреге, 1879 г. или предложенных Пирсом кванторах, но воздержусь).
С появлением компьютеров получили распространения альтернативы текстам, используемые как для описания действий в виде программ, так и для сбора и обработки данных. Не последнее место в этой истории занимают ИТ-архитекторы, полагающие что модели существующих или только создаваемых ИТ систем описывают их существенно лучше текстов. А есть еще архитекторы предприятия, предлагающие использовать модели для описания структуры и деятельности компании в целом, а не только для ИТ-систем, используемых в этих компаниях.
Но тут возвращаются из прошлого любители текстов и текстов по написанию этих текстов. Как будто не было предыдущих 50 лет, когда отрасль придумала формальные и не очень формальные подходы к моделированию, научилась декомпозировать документы на отдельные статьи, адресуемые посредством URI, маркировать их метками и собирать в категории. Более структурированные вещи описывать в формальных подходах от BNF до Open API Spec, менее формальные другими способами.
Всего этого как бы не было. Хорошо хоть рамки на страницах псевдографикой от нас рисовать не требуют
С появлением компьютеров получили распространения альтернативы текстам, используемые как для описания действий в виде программ, так и для сбора и обработки данных. Не последнее место в этой истории занимают ИТ-архитекторы, полагающие что модели существующих или только создаваемых ИТ систем описывают их существенно лучше текстов. А есть еще архитекторы предприятия, предлагающие использовать модели для описания структуры и деятельности компании в целом, а не только для ИТ-систем, используемых в этих компаниях.
Но тут возвращаются из прошлого любители текстов и текстов по написанию этих текстов. Как будто не было предыдущих 50 лет, когда отрасль придумала формальные и не очень формальные подходы к моделированию, научилась декомпозировать документы на отдельные статьи, адресуемые посредством URI, маркировать их метками и собирать в категории. Более структурированные вещи описывать в формальных подходах от BNF до Open API Spec, менее формальные другими способами.
Всего этого как бы не было. Хорошо хоть рамки на страницах псевдографикой от нас рисовать не требуют
Опубликовали записи с конференции BeeTech Conf 2.0. Мой короткий рассказ: https://youtu.be/_4lXdAILYY0
YouTube
Максим Смирнов, «Модернизация унаследованных приложений», BeeTech Conf 2.0
Максим Смирнов, автор telegram-канала «Архитектура IT-решений»
BeeTech Conf 2.0, 23 апреля, 2022
Описание доклада:
Несмотря на повсеместное внимание к инновациям, значительную часть бизнес-транзакций компании обрабатывают с использованием информационных…
BeeTech Conf 2.0, 23 апреля, 2022
Описание доклада:
Несмотря на повсеместное внимание к инновациям, значительную часть бизнес-транзакций компании обрабатывают с использованием информационных…
Вернемся к TOGAF10. Интересный вопрос вызван разбиением TOGAF Fundamental на шесть отдельных частей. Будут ли эти части релизиться независимо друг от друга?
Где-то я встретил такое мнение: Обычный человек может делить что-либо на части по множеству различных причин. Но когда архитектор разбивает нечто на части, то резонно предположить, что последующие изменения он планирует проводить независимо, внутри отдельных частей. Т.е. сегодня, например, обновляем раздел стандарта про метод разработки архитектуры ADM, завтра часть с техниками, а послезавтра - Architecture Content.
Честно говоря, я не думаю, что дальнейшее развитие TOGAF Fundamental будет происходить таким способом. А вот отдельные независимые стандарты в рамках TOGAF Series Guides появляться станут. Да и существующие руководства будут обновляться независимо друг от друга
Где-то я встретил такое мнение: Обычный человек может делить что-либо на части по множеству различных причин. Но когда архитектор разбивает нечто на части, то резонно предположить, что последующие изменения он планирует проводить независимо, внутри отдельных частей. Т.е. сегодня, например, обновляем раздел стандарта про метод разработки архитектуры ADM, завтра часть с техниками, а послезавтра - Architecture Content.
Честно говоря, я не думаю, что дальнейшее развитие TOGAF Fundamental будет происходить таким способом. А вот отдельные независимые стандарты в рамках TOGAF Series Guides появляться станут. Да и существующие руководства будут обновляться независимо друг от друга
Dean Leffingwell писал о воронке инициатив еще в книжке 2011 года «Agile Software Requirements...» (а другие авторы рассказывают эту же историю с еще более ранних времен). Рекомендации по выстраиванию процесса установки приоритетов и выбора идей, которые следуют реализовать, были прописаны в SAFe несколько лет назад (см. https://www.scaledagileframework.com/portfolio-kanban/). И тем не менее я регулярно сталкиваюсь с тем, что для кого-то эта идея является совсем новой. Потому делюсь здесь ссылкой на соответствующую страничку в SAFe
Пожалуй, это самая важная картинка в недописанной книжке Брандолини Introducing EventStorming Правда, она скорее объясняет, что такое CQRS, а не рассказывает про Event Storming или Domain Driven Design. Тем не менее, идея инициируемой командой пользователя петли событий, возвращающейся к нему же или порождающую новую команду – это базовый сценарий взаимодействия пользователя с сервисом. Всё крутится вокруг этого…
Архитектура ИТ-решений
Пожалуй, это самая важная картинка в недописанной книжке Брандолини Introducing EventStorming Правда, она скорее объясняет, что такое CQRS, а не рассказывает про Event Storming или Domain Driven Design. Тем не менее, идея инициируемой командой пользователя…
… даже процесс DDD или предметно-ориентированного проектирования. Сравните картинку из реплики выше c рассказом Брандолини о The Whirlpool Model https://blog.avanscoperta.it/2020/08/03/which-process-for-domain-driven-design/ Эрика Эванса
Архитектура ИТ-решений
Пожалуй, это самая важная картинка в недописанной книжке Брандолини Introducing EventStorming Правда, она скорее объясняет, что такое CQRS, а не рассказывает про Event Storming или Domain Driven Design. Тем не менее, идея инициируемой командой пользователя…
Простое пошаговое описание Event Storming с сайта про архитектуру от IBM https://www.ibm.com/cloud/architecture/architecture/practices/event-storming-methodology-architecture/ Ничего лишнего.
Ibm
IBM Garage
Accelerate digital transformation with the end-to-end model from IBM. Generate innovative ideas get the technology and expertise to make them real.
Автор С4model Саймон Браун не только написал «Missing Chapter» в книжку Роберта Мартина «Чистая архитектура». Здесь The delivery mechanism is an annoying detail и здесь Clean Architecture вы можете почитать дискуссию этих уважаемых экспертов случившуюся еще в 2011.
Но я бы развернул это обсуждение в противоположную сторону. Меня тоже всегда интересовал вопрос почему дядюшка Боб 1) решил, что бизнес-сущности и сценарии (entities, use cases) меняются наиболее редко и потому нуждаются в избавлении от зависимостей в первую очередь 2) кто расскажет об этом бизнес/системным аналитикам, которые обычно и отвечают за выделение в предметной области сущностей и юзкейсов. Если мы в это верим, то влияние аналитиков на дизайн ИТ-решения становится колоссальным. (Но вряд ли они об этом даже подозревают).
Но я бы развернул это обсуждение в противоположную сторону. Меня тоже всегда интересовал вопрос почему дядюшка Боб 1) решил, что бизнес-сущности и сценарии (entities, use cases) меняются наиболее редко и потому нуждаются в избавлении от зависимостей в первую очередь 2) кто расскажет об этом бизнес/системным аналитикам, которые обычно и отвечают за выделение в предметной области сущностей и юзкейсов. Если мы в это верим, то влияние аналитиков на дизайн ИТ-решения становится колоссальным. (Но вряд ли они об этом даже подозревают).
Codingthearchitecture
The delivery mechanism is an annoying detail - Coding the Architecture
Не понимаю я современного работодателя! На hh в московском регионе 16(!) архитектурных вакансий включают слово Zachman (и еще 4 – Захман). Зачем это современному корпоративному архитектору? Я в своих курсах рассказываю про матрицу Захмана, но не как о рабочем инструменте, а скорее в формате некоторой ретроспективы развития EA. Но работодателю то это зачем? Я понимаю, когда требуют TOGAF (75 вакансий) или Archimate (78). Но зачем требовать подходы, сформулированные Джоном Захманом еще в 1987(и скорректированные в 1992), я понимаю не очень