Вернемся к 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), я понимаю не очень
Анонсированные в вчерашнем чате "9 принцев Амбера" от Евгения Чикунова
Архитектура ИТ-решений
Какой вы архитектор?
Текущие результаты опроса (1318 голосов) за вычетом варианта Посмотреть результат:
52% - Solution
24% - Enterprise
22% - System
16% - Application
8% - Infrastructure
52% - Solution
24% - Enterprise
22% - System
16% - Application
8% - Infrastructure
Почему-то я пропустил этот опрос O'Reilly Microservices Adoption in 2020 (Everyone’s talking about microservices. Who’s actually doing it?). Может раньше он не был в открытом доступе, не знаю.
Конечно, отчет не очень свежий(начало 2020), но довольно интересный. С попытками обнаружить и прокомментировать корреляции между ответами на разные вопросы. Т.е. с тем, что отличает подготовленные исследования от традиционных тупых опросников. В общем, всё как мы любим
Конечно, отчет не очень свежий(начало 2020), но довольно интересный. С попытками обнаружить и прокомментировать корреляции между ответами на разные вопросы. Т.е. с тем, что отличает подготовленные исследования от традиционных тупых опросников. В общем, всё как мы любим
📆 20 июня 19:00 MSK Архитектор ИТ-решений. Несколько полезных приемов - бесплатный вебинар с обсуждением навыков архитекторов решений (Solution Architect)
Зарегистрироваться на вебинар, задать вопросы, поделиться собственным опытом можно по ссылке: https://mxsmirnov.timepad.ru/event/2071039/
Присоединяйтесь!
Зарегистрироваться на вебинар, задать вопросы, поделиться собственным опытом можно по ссылке: https://mxsmirnov.timepad.ru/event/2071039/
Присоединяйтесь!
Архитектура ИТ-решений
Слайды Саймона Брауна с GOTO Copenhagen 2021 https://static.architectis.je/gotocph2021-diagrams-as-code-2.pdf (аж целых 97 штук) из которых я с удовольствием позаимствую выражение notation independent (см. слайд 17: "The C4 model is notation independent").…
А запись выступления Саймона Брауна Diagrams as Code 2.0 на GOTO Copenhagen 2021 выложили только позавчера. Интересующимся: https://youtu.be/Za1-v4Zkq5E
YouTube
Diagrams as Code 2.0 • Simon Brown • GOTO 2021
This presentation was recorded at GOTO Copenhagen 2021. #GOTOcon #GOTOcph
http://gotocph.com
Simon Brown - Author of "Software Architecture for Developers" & Creator of the C4 Software @simonbrown4821
ABSTRACT
Diagrams as code is becoming a popular way…
http://gotocph.com
Simon Brown - Author of "Software Architecture for Developers" & Creator of the C4 Software @simonbrown4821
ABSTRACT
Diagrams as code is becoming a popular way…