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

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

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

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

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

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

Вот не понимаю я, почему некоторые архитекторы предприятия недолюбливают 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-ами перетереть

Судя по откликам в группе этого канала, мне не следовало соглашаться на работу ИТ-архитектором так быстро. Может лучше было начать с архитектурных ка-та (список от Нила Форда здесь: 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

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

Всем доброго дня! По итогам встречи в zoom и докладам, заявленным в чате, сейчас будет проведено два опроса - все доклады не влезли в один. Множественный выбор доступен, отметьте все интересующие варианты - что хотите послушать, в чем хотите поучаствовать.
Приславшим короткие темы - спасибо. Темы остальных были сокращены до нужного кол-ва символов, поля с вариантами довольно маленькие.

Всем привет! Обычно я так не делаю, но для следующего вебинара, который случится в первой половине июля, хочу провести голосование по выбору темы. Какая окажется наиболее востребованной, ту и обсудим. (Уточняющие вопросы, а также рекомендации по темам приветствуются в группе этого канала)

Более половины высказались за Дилемму корпоративного ИТ-архитектора Спасибо. Так тому и быть. Ссылка на предстоящую трансляцию: https://youtu.be/XVkExnJ6lrw