Еще про технологический радар. Вот прям с самого начала: Applying product management to internal platforms  https://www.thoughtworks.com/radar/techniques/applying-product-management-to-internal-platforms Мне кажется эту идею уже несколько лет назад обсудили и... перевели в раздел магии. Есть несколько обзоров в интернет. Один из неплохих вот этот: https://www.thoughtworks.com/radar/techniques/applying-product-management-to-internal-platforms Впрочем, достаточно будет и этого твитта:
To be a Customer you have to:
a) have a Choice
b) Exchange something of value.
https://twitter.com/joshuajames/status/891432826817478657

Так зачем она в радаре v.22 от 2020г.?

PS: Тема нужная. Но до попадания в категорию ADOPT её еще трясти и трясти. Может что полезное и обнаружится

Демистификация ИТ-архитектуры
Говорят, что хороший проектный менеджер – это эксперт по управлению дефицитами. Не хватает людей в проекте, менеджер привлекает в команду новых людей. Не хватает денег – находит бюджет. Не укладывается проект в сроки, менеджер сужает рамки проекта. Заказчик начал выказывать неуверенность в результате, менеджер обнаруживает и митигирует риски, ну и т.д.

В этой логике ИТ-архитектор эксперт по управлению парадоксами. Стоит кому-либо усомниться в разрабатываемом решении, тут же зовут архитектора приводить частную точку зрения к единому видению. Возникли среди заинтересованных лиц взаимоисключающие суждения – снова зовут архитектора, чтоб он такие суждения развел по представлениям(views), объяснил людям, что и парадокса то никакого нет, просто смотрят они на проблему каждый со своей точки зрения.

В общем, роль важная, как ни крути. Не эксперт по дефицитам, конечно, но персонаж тоже полезный…

Закрыл опрос. Большое спасибо за участие! Ожидаемые для меня ответы о том, что избежать рисования картинок ИТ-архитектору практически нереально (37%),  картинку проще нарисовать (30%) и про то, что архитектура это модель, а не картинка (18%), а вот неожиданные:

- эскизы на белой доске (2%) – думал будет существенно больше

- мне это нравится (21%) – думал будет меньше. Этот вариант ответа заставляет задуматься, а правы ли авторы утверждений, что свидетельством большого ума является способность выразить мысль в формате русскоязычной прозы. Без картинок. «Визуальное мышление» (в кавычках) вещь оказывается полезная. Не то мышление, о котором пишут в популярных книжках. Я бы даже назвал его топологическое или чанковое, т.е. позволяющее структурировать наборы объектов в некоторый типовые рисунки, созвездия если угодно

Получил огромное удовольствие от проведения курса «Мастерская проектирования ИТ-решений» в онлайн. Не думал, что энергия и заинтересованность слушателей передается через zoom. Оказывается, что передается. Спасибо большое всем, кто к нам присоединился.

Но по ходу курса я сформулировал для себя одно важное понимание. Довольно часто наши уважаемые работодатели готовы оплачивать обучение только при условии, что: прослушаешь курс, вернешься, обязательно расскажешь его внутри компании…

А вот это сделать обычно не так уж и просто. Разумеется, по завершении курса мы предоставляем все материалы. Но этого абсолютно недостаточно. Нужен еще и опыт, и некоторые знания и ряд полезных лайфхаков. А вот курса на тему: Как провести внутреннее ИТ-обучение в нашем арсенале пока нет.  Может сделаем как-нибудь, но пока хочу ограничиться хотя бы вебинаром на эту тему.
Как думаете, нужен такой?

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

Возьмем, например, что-нибудь попроще, тот же Scrum Guide. Там русским по белому написано, что базируется он на эмпирической теории управления процессами, т.е. знания приходят не из TOGAF ADM или научно-популярных статей по архитектуре, а из опыта.  Придумали или вычитал где-нибудь архитектор идею серебряной пули – проверь!

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

В свое время пропустил перевод https://habr.com/ru/post/441538/ вот этого замечательного текста https://panoply.io/data-warehouse-guide/data-warehouse-architecture-traditional-vs-cloud/
Билл Инмон против Ральфа Кимбалла  (Естественно, я за второго, а вы?) "Звездочка" или "Снежинка, ETL vs. ELT, облачное хранилище от Amazon и BigQuery от Google. ... что там ещё?

Впрочем и этих vs. вполне хватит :-)

Да, еще вот! Если вы не знаете кто такой Кимбалл, то почитайте Манифест многомерного моделирования https://www.kimballgroup.com/1997/08/a-dimensional-modeling-manifesto/ Надолго отбивает охоту [выключить мозг] сесть и изложить предметную область в виде ER-модели на пару десятков сущностей

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

В общем, грустная книжка о тщетности усилий по эволюционному преобразованию плохого в хорошее

Чего слушателю вебинаров не хватало для полного счастья? Правильно, чтоб YouTube вынес отметки времени из описания видео непосредственно в картинку. Так вот - это случилось!

Я не поленился, взял свой старый вебинар и набросал тайм-кодов на первые полчаса. Думаю, стало  лучше, наслаждайтесь: https://youtu.be/18D3uoUlOEw

Карьерные траектории ИТ-архитектора.
Я не собирался становиться архитектором. Даже не задумывался об этом. Мне нравилось заниматься разработкой и намного меньше управлением. Много лет я просто участвовал в тех или иных проектах. При этом, как я это сейчас понимаю, в этих проектах следовало бы заниматься архитектурой. Но тогда, почему-то, такая мысль просто не приходила в голову. И хотя своего рода сигналов: давай же, бери на себя архитектуру - было достаточно, я успешно их игнорировал. Закончилось все тем, что один топ-менеджер буквально прижал меня к стенке словами:
- у меня есть разработчики, у меня есть менеджеры, ты в какой-либо из этих ролей мне совершенно не нужен; так что давай, соглашайся на архитектора
Вот так и пришлось стать ИТ-архитектором. Поначалу, конечно, давил синдром самозванца. Но продолжалось это недолго.

К чему я всё это. Да вот, думаю, сколько вокруг потенциальных архитекторов таковыми себя не воспринимают. И ведь может выйти так, что никогда ими не станут..., а ведь могли бы

Надо бы это с HR-ами перетереть

Поделюсь ссылкой для тех, кто любит визионерские рассуждения и неочевидные идеи из серии "на подумать". Доклад не особо про DevOps, но мне очень даже зашел. Потому как много в нем оригинальных интервенций https://youtu.be/iz-X41p_BN4

Кстати, надо бы уточнить: а закон Мура, действительно уже не работает или это просто реклама EDGE Computing была

Судя по откликам в группе этого канала, мне не следовало соглашаться на работу ИТ-архитектором так быстро. Может лучше было начать с архитектурных ка-та (список от Нила Форда здесь: http://nealford.com/katas/ и я уже писал про них в этом канале https://t.me/it_arch/253) лет пять упражнения поделать, экзамен по TOGAF-у сдать и только потом...

... но каты: http://nealford.com/katas/random.html всегда можно поделать если что :-)

Cайт Real ITSM устроил обсуждение: https://realitsm.ru/2020/05/yavlyaetsya-li-it-arxitektura-chastyu-cmdb/ которое, впрочем, быстро заглохло.

Я всегда был приверженцем точки зрения, что архитектурный репозиторий AR, словно data integration tool, должен использовать все источники данных CMDB, оргструктуру, продуктовый каталог,... есть перечень бизнес-процессов - тоже тащите. Но может кому-то будет интересно пообсуждать и вопрос ИТ-архитектура и CMDB - что внутри чего, а что, соответственно, снаружи

Менеджеры продуктов думают, что они занимаются продуктами, но, на самом деле, уже давно занимаются сервисами. Просто менеджеры тоже так думают, но любая деятельность у них превращается в проект. Разработчики ненавидят проекты и потому делают продукты и сваливают их в IT operations от которых заказчик ждут не продуктов, а сервисов. Они это знают, но часто не могут внятно объяснить. Редкое исключение нашел в блоге Axelos Products, Services, and Service Relationships https://www.axelos.com/news/blogs/april-2019/itil-4-connecting-the-key-concepts-blog-part-1

Похоже, что эта новость обвалила сайт rkn

⚡️⚡️⚡️Конец "блокировки" Телеграма. Все танцуют

По согласованию с Генеральной прокуратурой РФ Роскомнадзор снимает требования по ограничению доступа к мессенджеру Телеграмм.

https://rkn.gov.ru/news/rsoc/news73050.htm

В чате "Архитектура ИТ-решений" обсуждаем темы для следующих zoom-ов
1 - https://t.me/itarchitect/65475
2 - https://t.me/itarchitect/65476