Принято считать, что архитектура предприятия начинается с работы Джона Захмана A framework for information system architecture, 1987. Но двумя годами позже, другой человек придумал не только подход, но и предложил инструмент такого описания.

Тим Бернес-Ли в "Information Management: A Proposal" https://www.w3.org/History/1989/proposal.html пишет: CERN – удивительная организация. В ей деятельности участвует несколько тысяч человек, многие из которых очень креативны и работают на достижение общих цели. Хотя они номинально организованы в иерархическую структуру управления, это не ограничивает способ общения между людьми и обмен информацией, оборудованием и программным обеспечением между группами. Фактически структура организации представляет собой многосвязную «сеть», которая развиваются с течением временем. В этой среде новому человеку, обычно дают несколько советов о том, с кем можно было бы поговорить. Информация о существующих возможностях публикуется в периодических информационных бюллетенях, но чаще передается в коридорах в виде сплетен. Учитывая все обстоятельства, результат является удивительно успешным, несмотря на случайные недоразумения и дублирующиеся усилия...

В чём важность этой истории. Многие организации, да и государство в целом, не первый год пытаются внедрить архитектуру предприятия as a governance. Ну, т.е. мы будем говорить вам какие технологии правильные, как структурировать и где хранить данные и т.д. Но ни у кого я не видел архитектуру предприятия as a service. Может инструменты не те используются, а может подход не те головы придумывают

Демистификация ИТ-архитектуры
В рамках одного корпоративного курса по ИТ-архитектуре началось обсуждение, которое мне хочется вынести на более широкую аудиторию

В ИТ-архитектуре есть много практик, которые при внешнем сходстве довольно сильно различаются между собой. Например, описание текущей архитектуры вещь более-менее формализуемая. Здесь подходят строгие нотации, всякие UML, archimate, формальные языки описания aka ADL, да и вызывающее все больший интерес architecture-as-a-code – тоже сюда. А вот проектирование, особенно верхнеуровневое и концептуальное, решительно восстает против всех этих скучных вещей. Здесь нужны эскизы, быстрые наброски для обсуждений и непрерывной переделки. Нотация здесь: boxes and arrow. Все это как-то более или менее понимают, ну или воспринимают на уровне ощущений.

Таких противопоставлений можно насобирать десяток, может больше. Кроме fact-decision (он же as is против to be), есть еще противопоставление контекста и внутренней структуры, анализа и проектирования и т.д.

Но самое интересное происходит дальше. В какой-то момент противоречивые практики начинают сливаться в единое целое. Так в архитектуре решений (solution architecture) мы делаем карандашные наброски, элементами которых является вполне себе реальные приложения из CMDB, документированные вдоль и поперек API и описанные источники данных. Если делать не так, а просто рисовать произвольные фигурки со стрелочками, то архитектура решения не сложится. Нельзя так делать. Архитектура решения - это набросок изменения, нарисованный от руки поверх строгих, актуальных и выверенных as-is диаграмм. При этом, специфицировать решение с точностью до последнего гвоздя, да еще в правильных нотациях тоже никто не будет…

Не это ли в ИТ-архитектуре самое интересное?

А кто-нибудь читает этот регулярно обновляемый (пополняемый) пост Мартина Фаулера? https://martinfowler.com/articles/branching-patterns.html (Посмотрите Significant Revisions внизу сообщения)

Мне стало совсем не интересно комментировать технологический радар https://www.thoughtworks.com/radar (на самом деле, еще с предыдущей версии). То ли технологическая граница уехала так далеко, что я уже не различаю её черты, то ли вектор у ThoughtWorks направлен так. Но я был бы рад комментариям. Вдруг кого-нибудь что-то зацепит из очередного списка

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

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