Вчера заглянул на гартнеровский вебинар (слайды здесь). Удивился, что Gartner проводит вебинары на русском, да еще такие толковые. И дело даже не в том, что компонуемость (это один из трендов 2022 года) оказалась, в первую очередь, бизнес/ИТ характеристикой организации. Компонуемость эту самую оказывается можно прокачивать благодаря улучшению перечисленных в презентации практик.
Важнее, что потребность в ней возникает из-за разрушения монополии ИТ-отдела на производство ИТ-решений. Вот это вот мега-тренд! Я касался его в вебинаре Что ждет архитектора решений? В двух словах: все мы находимся в процессе замены функциональных и технологических силосов продуктовыми. Это главная история. И это главное следствие цифровой трансформации.
Ну и слайд №20 (см. рисунок) просто великолепен
Важнее, что потребность в ней возникает из-за разрушения монополии ИТ-отдела на производство ИТ-решений. Вот это вот мега-тренд! Я касался его в вебинаре Что ждет архитектора решений? В двух словах: все мы находимся в процессе замены функциональных и технологических силосов продуктовыми. Это главная история. И это главное следствие цифровой трансформации.
Ну и слайд №20 (см. рисунок) просто великолепен
👍19
Добавил много ссылок, связанных с записями архитектурных решений (architecture decision record), к видео вебинара, прошедшего в сентябре 2019 года https://youtu.be/9vtf33NIJrE
YouTube
Поток архитектурных решений
Слайды: https://speakerdeck.com/mxsmirnov/potok-arkhitiekturnykh-rieshienii
Ссылки:
Philippe Kruchten “Agility and Architecture or: What colours is your backlog?” , July7, 2011 https://pkruchten.files.wordpress.com/2012/07/kruchten-110707-what-colours-is…
Ссылки:
Philippe Kruchten “Agility and Architecture or: What colours is your backlog?” , July7, 2011 https://pkruchten.files.wordpress.com/2012/07/kruchten-110707-what-colours-is…
👍12
Я редко стал заходить на InfoQ Когда-то это был интересный ресурс, но всё рано или поздно заканчивается. Но вот сегодня я туда заглянул и тут же обнаружил вот это: https://www.infoq.com/articles/microservices-seven-fail/ Думаю, что еще лет десять одни люди будут писать разные глупости и умности, предостерегая других людей от микросервисов. Время начинать изучать это в качестве культурного феномена
InfoQ
Seven Ways to Fail at Microservices
At QCon Plus last November, I presented some of the ways microservices can go wrong. I’m a consultant for IBM, and part of my job is helping businesses get cloud-native. These problems are based on my experience – which, unfortunately, I see repeatedly in…
👍1
Архитектура ИТ-решений
Запись здесь: https://youtu.be/h-WwGQgDiBU?t=67
12 определений Cloud-Native приложений https://ozimmer.ch/index/2021/05/21/CloudNativeDefinitionAnalysis.html
Olaf Zimmermann (ZIO, socadk, MAP author): portfolio, blog
What is a Cloud-Native Application Anyway? 12 Definitions Distilled
CNA Definitions Distilled
👍1
Forwarded from Блог Сергея Баранова
Закон Конвея. Перевод статьи «How Do Committees Invent?»
Так как статья – не художественное произведение, да еще и написана в далеком 1968 году, ее перевод может (да, наверное, и должен) восприниматься как весьма косноязычный и местами непонятный, но так уж излагали мысли ученые в 68-м. Посчитал, что для научной статьи адаптивный перевод может привести к потере смыслов (хотя и понимаю, что на русском языке смысл может исказиться). Всячески рекомендую оригинал (ссылка в конце статьи), а переводом пользоваться только в том случае, если недостаточно знаний английского.
http://agilemindset.ru/закон-конвея-перевод-статьи-how-do-committees-invent/
Несколько цитат:
👉«никогда не бывает достаточно времени, чтобы сделать что-то правильно, но всегда есть достаточно времени, чтобы сделать это заново»
«Каждый раз, когда осуществляется делегирование и сужается чья-то область исследования, также сужается и класс вариантов решений по проектированию, которые могут быть эффективно реализованы.»
«Как только определены сферы деятельности, возникает проблема координации. Координация между рабочими группами, хотя и снижает продуктивность отдельных сотрудников в небольшой группе, обеспечивает единственную возможность того, что отдельные рабочие группы смогут объединить свои усилия в единую систему.»
«осознание первоначальными проектировщиками того, что система будет большой, вместе с определенным давлением в организации делает непреодолимым искушение назначить для разработки дизайна слишком много людей»
«Менеджер должен отдать в субподряд важную и сложную задачу по проектированию. Он выбирает между двумя подрядчиками: небольшой новой организацией, которая предлагает интуитивно привлекательный подход за гораздо меньшие, чем заложено в бюджете, деньги, и давно зарекомендовавшей себя, но традиционной организацией, которая требует более «реалистичную» плату. Он знает, что, если яркая молодая организация не сможет добиться достаточных результатов, его обвинят в неумелом управлении, а если потерпит неудачу проверенная организация, это будет доказательством того, что проблема действительно сложна.
В чем тут сложность? Большая ее часть относится к рассуждениям об измерении ресурсов, вытекающим из традиционной теории бухгалтерского учета. Согласно этой теории, единицей ресурса является доллар, и все ресурсы должны измеряться с использованием единиц измерения, конвертируемых в доллары. Если ресурсом является человеческий труд, единицей измерения является количество часов, отработанных каждым человеком, умноженное на его почасовую ставку, суммированные для всей рабочей силы.
Одним из заблуждений, лежащих в основе этого расчета, является свойство линейности, согласно которому два человека, работающие в течение года, или сто человек, работающие в течение недели (при одинаковых почасовых ставках на человека), являются ресурсами равной ценности. Если предположить, что два человека и сто человек не могут работать в одной и той же организационной структуре (это интуитивно очевидно и будет обсуждаться ниже), наш гомоморфизм говорит, что они не будут проектировать подобные системы; поэтому ценность их усилий может быть даже несопоставимой. По опыту мы знаем, что два человека, если они правильно подобраны и имеют нужный опыт, дадут нам лучшую систему. Предположения, которые могут быть достаточными для чистки картошки и возведения кирпичных стен, не годятся для проектирования систем.»
«Даже в умеренно небольшой организации возникает необходимость ограничить общение, чтобы люди могли выполнить какую-то «работу».»
«Необходима философия управления дизайном систем, которая не основывается на предположении, что простое добавление рабочей силы повышает производительность.» – Закон Конвея именно об этом, хоть и звучит как «организация, проектирующая систему (в принятом здесь широком смысле), производит дизайн, являющийся копией коммуникационных структур этой организации»
Так как статья – не художественное произведение, да еще и написана в далеком 1968 году, ее перевод может (да, наверное, и должен) восприниматься как весьма косноязычный и местами непонятный, но так уж излагали мысли ученые в 68-м. Посчитал, что для научной статьи адаптивный перевод может привести к потере смыслов (хотя и понимаю, что на русском языке смысл может исказиться). Всячески рекомендую оригинал (ссылка в конце статьи), а переводом пользоваться только в том случае, если недостаточно знаний английского.
http://agilemindset.ru/закон-конвея-перевод-статьи-how-do-committees-invent/
Несколько цитат:
👉«никогда не бывает достаточно времени, чтобы сделать что-то правильно, но всегда есть достаточно времени, чтобы сделать это заново»
«Каждый раз, когда осуществляется делегирование и сужается чья-то область исследования, также сужается и класс вариантов решений по проектированию, которые могут быть эффективно реализованы.»
«Как только определены сферы деятельности, возникает проблема координации. Координация между рабочими группами, хотя и снижает продуктивность отдельных сотрудников в небольшой группе, обеспечивает единственную возможность того, что отдельные рабочие группы смогут объединить свои усилия в единую систему.»
«осознание первоначальными проектировщиками того, что система будет большой, вместе с определенным давлением в организации делает непреодолимым искушение назначить для разработки дизайна слишком много людей»
«Менеджер должен отдать в субподряд важную и сложную задачу по проектированию. Он выбирает между двумя подрядчиками: небольшой новой организацией, которая предлагает интуитивно привлекательный подход за гораздо меньшие, чем заложено в бюджете, деньги, и давно зарекомендовавшей себя, но традиционной организацией, которая требует более «реалистичную» плату. Он знает, что, если яркая молодая организация не сможет добиться достаточных результатов, его обвинят в неумелом управлении, а если потерпит неудачу проверенная организация, это будет доказательством того, что проблема действительно сложна.
В чем тут сложность? Большая ее часть относится к рассуждениям об измерении ресурсов, вытекающим из традиционной теории бухгалтерского учета. Согласно этой теории, единицей ресурса является доллар, и все ресурсы должны измеряться с использованием единиц измерения, конвертируемых в доллары. Если ресурсом является человеческий труд, единицей измерения является количество часов, отработанных каждым человеком, умноженное на его почасовую ставку, суммированные для всей рабочей силы.
Одним из заблуждений, лежащих в основе этого расчета, является свойство линейности, согласно которому два человека, работающие в течение года, или сто человек, работающие в течение недели (при одинаковых почасовых ставках на человека), являются ресурсами равной ценности. Если предположить, что два человека и сто человек не могут работать в одной и той же организационной структуре (это интуитивно очевидно и будет обсуждаться ниже), наш гомоморфизм говорит, что они не будут проектировать подобные системы; поэтому ценность их усилий может быть даже несопоставимой. По опыту мы знаем, что два человека, если они правильно подобраны и имеют нужный опыт, дадут нам лучшую систему. Предположения, которые могут быть достаточными для чистки картошки и возведения кирпичных стен, не годятся для проектирования систем.»
«Даже в умеренно небольшой организации возникает необходимость ограничить общение, чтобы люди могли выполнить какую-то «работу».»
«Необходима философия управления дизайном систем, которая не основывается на предположении, что простое добавление рабочей силы повышает производительность.» – Закон Конвея именно об этом, хоть и звучит как «организация, проектирующая систему (в принятом здесь широком смысле), производит дизайн, являющийся копией коммуникационных структур этой организации»
👍80
Архитектура ИТ-решений
Добавил много ссылок, связанных с записями архитектурных решений (architecture decision record), к видео вебинара, прошедшего в сентябре 2019 года https://youtu.be/9vtf33NIJrE
Не важно, какой именно формат архитектурных решений использовать – MADR с картинки над сообщением или какой-то другой. Практически любой шаблон ADR представляет собой ещё и чек-лист для самопроверки: какую задачу мы решаем, рассмотрели ли альтернативные варианты, видим ли негативные последствия решения или зациклились только на позитивных и т.д.
Кстати, еще одна ссылка к вебинару - обзор истории ADR от Olaf Zimmermann (ZIO) https://ozimmer.ch/practices/2020/04/27/ArchitectureDecisionMaking.html
Кстати, еще одна ссылка к вебинару - обзор истории ADR от Olaf Zimmermann (ZIO) https://ozimmer.ch/practices/2020/04/27/ArchitectureDecisionMaking.html
👍29
Разрешите представить Виктора Хоменко (@viktorkho), Билайн в Казахстане, Алматы, который теперь вместе со мной будет администратором наших групп по ИТ-архитектуре
👍18👎2
Оригинальное описание Леонардом Ричардсоном его модели зрелости RESTful API объясняется вот здесь: https://www.crummy.com/writing/speaking/2008-QCon/act3.html Возможно, кому-то этих слайдов и текста будет достаточно. Идея просто отличная.
Для остальных непременно хочу пересказать эту модель заново, своими словами. И обязательно это сделаю, но не сейчас
Richardson Maturity Model
Для остальных непременно хочу пересказать эту модель заново, своими словами. И обязательно это сделаю, но не сейчас
Richardson Maturity Model
👍27
Обнаружил, что в январе 2022 The Open Group выпустило руководство о том, как делать микросервисы по TOGAF ADM. https://publications.opengroup.org/togaf-library/g21i Вот прям по тупо по процессу, со всеми фазами: бизнес-архитектура, архитектура данных и т.д. На 50 страниц руководство.
Сначала мне показалось это бредом, но потом я решил еще немного почитать и подумать. Вдруг есть в этом тот или иной смысл?
Сначала мне показалось это бредом, но потом я решил еще немного почитать и подумать. Вдруг есть в этом тот или иной смысл?
publications.opengroup.org
TOGAF® Series Guide: Microservices Architecture (MSA)
This document is part of the TOGAF Standard, 10th Edition.
This document provides guidance on how the architect can use the TOGAF® Standard to develop, manage, and govern Microservices Architecture (MSA) or any architecture where MSA is part of the scope.
This document provides guidance on how the architect can use the TOGAF® Standard to develop, manage, and govern Microservices Architecture (MSA) or any architecture where MSA is part of the scope.
👍21❤1
В далеком 1987-м Джон Захман предложил любую модель системы причислять к одному из трех фундаментальных типов: описание данных, описание функций или описание физической структуры системы.
Cловом архитектура обычно обозначают модели третьего типа. А вот решение о выделении фрагмента системы в отдельный модуль завязано на элементах моделей первых двух. Модуль включает в себя либо некоторый набор данных, либо некоторый набор функций.
Не так уж всё и сложно, правда?
Cловом архитектура обычно обозначают модели третьего типа. А вот решение о выделении фрагмента системы в отдельный модуль завязано на элементах моделей первых двух. Модуль включает в себя либо некоторый набор данных, либо некоторый набор функций.
Не так уж всё и сложно, правда?
👍30
Архитектура ИТ-решений
В далеком 1987-м Джон Захман предложил любую модель системы причислять к одному из трех фундаментальных типов: описание данных, описание функций или описание физической структуры системы. Cловом архитектура обычно обозначают модели третьего типа. А вот решение…
Спасибо за большое количество отзывов на такую маленькую заметку. Было бы ошибкой с моей стороны попробовать ответить на все комментарии сразу, т.к. они очень разные. Постараюсь сделать это постепенно. Начну, пожалуй, со сложности https://news.1rj.ru/str/c/1304614627/18955
Во-первых, поделюсь ссылкой на перевод старого, но всё еще актуального текста Ефима Натиса Покорение сложности ИТ Удивительно, но ссылки на этот легендарный текст в этом канале до сих пор не было.
Во-вторых, уже от себя замечу, что разные виды сложности можно и нужно различать. Есть сложность реальная, проистекающая из большой вариативности объектов, отношений и вариантов развития событий. Есть сложность невынужденная, связанная с выбором не самого подходящего варианта реализации. А еще бывает сложность мифологическая. Примером такой сложности является популярная в своё время история о том, что интеграция точка-точка проигрывает интеграции через серверную шину. Вообще, любые комбинаторные предположения должны нас насторожить. В реальности интегрировать все системы со всеми никто и не собирался. Это просто не требуется. Сейчас похожий сюжет используют в страшилках про сложность взаимодействия между микросервисами в топологии каждый с каждым. Зачем бы это понадобилось сказать сложно, но выглядит вполне пугающе
Во-первых, поделюсь ссылкой на перевод старого, но всё еще актуального текста Ефима Натиса Покорение сложности ИТ Удивительно, но ссылки на этот легендарный текст в этом канале до сих пор не было.
Во-вторых, уже от себя замечу, что разные виды сложности можно и нужно различать. Есть сложность реальная, проистекающая из большой вариативности объектов, отношений и вариантов развития событий. Есть сложность невынужденная, связанная с выбором не самого подходящего варианта реализации. А еще бывает сложность мифологическая. Примером такой сложности является популярная в своё время история о том, что интеграция точка-точка проигрывает интеграции через серверную шину. Вообще, любые комбинаторные предположения должны нас насторожить. В реальности интегрировать все системы со всеми никто и не собирался. Это просто не требуется. Сейчас похожий сюжет используют в страшилках про сложность взаимодействия между микросервисами в топологии каждый с каждым. Зачем бы это понадобилось сказать сложно, но выглядит вполне пугающе
👍12
Архитектура ИТ-решений
Спасибо за большое количество отзывов на такую маленькую заметку. Было бы ошибкой с моей стороны попробовать ответить на все комментарии сразу, т.к. они очень разные. Постараюсь сделать это постепенно. Начну, пожалуй, со сложности https://news.1rj.ru/str/c/1304614627/18955…
И еще одно замечание. В упомянутой статье https://www.osp.ru/os/2005/07-08/185761 Натис вводит следующее определение
Сложность (IT Complexity) — это мера нашей неспособности понимать, использовать, «ремонтировать» и наращивать свою ИТ-среду. Любое решение, помогающее воспринимать, диагностировать и обслуживать эту среду как единое целое, упрощает ее. А любые факторы, препятствующие этому, ее усложняютТ.е., по-сути такое определение делает IT complexity субъективной мерой, т.е. зависящей от того, кто именно разбирается с данной конкретной архитектурой. Субъект может знать об определенных паттернах или не знать, понимать или не понимать замысел спроектировавшего решения архитектора и это влияет на воспринимаемую сложность. В общем, как только мы вводим в нашу модель субъекта, про комбинаторную сложность можно забыть. Слишком близка стала ИТ-архитектура к гуманитарным дисциплинам, чтоб мерять её объективными мерами длин и весов
Издательство «Открытые системы»
Покорение сложности ИТ
Все возрастающее бремя сложности информационных технологий на предприятиях влечет за собой увеличение затрат и «усталость от инноваций». ИТ-отделам удается справляться со сложностью благодаря новым программным архитектурам (в том числе, SOA) и связанным с…
👍8❤1
Нашел у себя в ссылках запись вебинара "Архитектура предприятия: Что происходит?" https://youtu.be/YIgNkop6xvY , на котором Святослав Котусев рассказывает историю дисциплины EA (на русском)
YouTube
"Архитектура предприятия: Что происходит?". Запись вебинара с участием Святослава Котусева
В докладе рассматриваются исторические корни популярных методологий управления корпоративной архитектурой и связанные с ними проблемы, а также реальные практики корпоративной архитектуры, используемые в современных организациях.
#enterprisearchitecture #togaf
#enterprisearchitecture #togaf
👍28👎1
А тем временем, я продолжаю проводить обучение по ИТ-архитектуре. Ближайший курс Микросервисная архитектура начнется 11 апреля
👍14
Появившаяся в прошлом году серия руководств Patterns of Legacy Displacement продолжает расширяться. Новая статья Transitional Architecture появилась как раз вовремя. Я готовлю небольшое выступление на тему Модернизация унаследованных приложений, а тут позавчера выходит такое подспорье про перехватчики событий и прочие связанные вещи
martinfowler.com
Transitional Architecture
Software elements installed to ease the displacement of a legacy system that we intend to remove when the
displacement is complete.
displacement is complete.
👍18
Помните, в начале нулевых появилось множество гибких методологий разработки: XP Кента Бека, семейство Crystal Коберна, ICONIX и т.д. А потом они все отошли на второй план и на какое-то время остался один SCRUM, т.е. подход, который в наименьшей степени можно назвать методологией разработки. Скорее, это мета-методология. Она не отвечает на вопрос Что делать? давая вместо этого ответ на вопрос Как? (см. Scrum guide). По сути, рекомендация звучит так: изобретите свой собственный процесс. Но этот ваш процесс должен быть эмпирическим, прозрачным, адаптируемым и т.д. Т.е. задан только самый общий минимум техник и инструментов.
Думаю, что только так сформулированный подход имел шансы закрепиться. Другие просто не прижились, т.к. слишком много вопросов можно к ним сформулировать. Собственно, на текущий момент резервы развития этой темы исчерпаны. (Абстрагироваться еще на более высокий уровень невозможно. Там уже стратосфера. Потому развиваться некуда) ...
Думаю, что только так сформулированный подход имел шансы закрепиться. Другие просто не прижились, т.к. слишком много вопросов можно к ним сформулировать. Собственно, на текущий момент резервы развития этой темы исчерпаны. (Абстрагироваться еще на более высокий уровень невозможно. Там уже стратосфера. Потому развиваться некуда) ...
👍12👎2
... Но вопросы что делать, как вырабатывать и принимать решения, остались. На них никто не ответил! ИТ-архитектура как-то пытается заполнить этот разрыв. Поэтому и шаблоны архитектурных решений ADR содержат наборы альтернатив и описание мотиваций выбора, как это принято у solution architects, и DDD так востребован и истории про топологии команд из той же серии…
Но в общем и целом современный архитектурный подход не прояснен и внятно не описан. И пока кто-то не сформулирует новый подход к архитектуре(вероятно, мета-подход, как это уже случилось для процесса разработки c появлением SCRUM-а), ничего в ней не изменится
Но в общем и целом современный архитектурный подход не прояснен и внятно не описан. И пока кто-то не сформулирует новый подход к архитектуре(вероятно, мета-подход, как это уже случилось для процесса разработки c появлением SCRUM-а), ничего в ней не изменится
👍10
Архитектура ИТ-решений
Я редко стал заходить на InfoQ Когда-то это был интересный ресурс, но всё рано или поздно заканчивается. Но вот сегодня я туда заглянул и тут же обнаружил вот это: https://www.infoq.com/articles/microservices-seven-fail/ Думаю, что еще лет десять одни люди…
🥁InfoQ продолжает традицию вставлять слово микросервисы во все свои публикации. В этот раз абсолютно не к месту.
В общем-то, вполне неплохая заметка о Technology Capability Plan (TCP) https://www.infoq.com/articles/managing-technical-debt-microservices/ естественно, не имеет к микросервисам никакого отношения.
На ArchDays’19 я рассказывал, что специфика работы с техдолгом в современных распределенных системах состоит в том, что вы можете выбросить отдельный микросервис вместе с накопленным в нем техдолгом. Если угодно, списать технический долг. И вы не можете этого сделать в больших сильносвязанных системах. Но можете перехватить команду или запрос и передать его/её обработку в отдельный сервис
В общем-то, вполне неплохая заметка о Technology Capability Plan (TCP) https://www.infoq.com/articles/managing-technical-debt-microservices/ естественно, не имеет к микросервисам никакого отношения.
На ArchDays’19 я рассказывал, что специфика работы с техдолгом в современных распределенных системах состоит в том, что вы можете выбросить отдельный микросервис вместе с накопленным в нем техдолгом. Если угодно, списать технический долг. И вы не можете этого сделать в больших сильносвязанных системах. Но можете перехватить команду или запрос и передать его/её обработку в отдельный сервис
InfoQ
Managing Technical Debt in a Microservice Architecture
At QCon Plus, Glenn Engstrand described how Optum Digital engineering devised a method for reliably and predictably paying down tech debt for hundreds of microservices, forming relevant communities and identifying high-risk areas. The communities' collective…
👍2
Pace layered подход, сформулированный когда-то в Gartner (см., например https://mxsmirnov.com/pace-layer/), это не только о том, когда надо, а когда не надо собирать требования, например
Предлагаю посмотреть на эту классификацию как на набор из трех фундаментальных ценностей, которые ИТ может принести:
1. Дать вам чужую технологию и операционную модель (system of records)
2. Поддержать ваши уникальные операции (system of differentiation)
3. Выявить потребность (system of innovation) Именно третья ценность является наиболее актуальной. Её мало кто понимает. Другие (инженерные) технологии так не умеют. Для них важно заранее знать что именно мы хотим сделать (вариант 2). А вот ИТ умеет работать в ситуации, когда владелец ресурсов совершенно не представляет чего хотеть, как с пользой задействовать доставшийся ему ресурс
Предлагаю посмотреть на эту классификацию как на набор из трех фундаментальных ценностей, которые ИТ может принести:
1. Дать вам чужую технологию и операционную модель (system of records)
2. Поддержать ваши уникальные операции (system of differentiation)
3. Выявить потребность (system of innovation) Именно третья ценность является наиболее актуальной. Её мало кто понимает. Другие (инженерные) технологии так не умеют. Для них важно заранее знать что именно мы хотим сделать (вариант 2). А вот ИТ умеет работать в ситуации, когда владелец ресурсов совершенно не представляет чего хотеть, как с пользой задействовать доставшийся ему ресурс
👍17