Комментарии 29
На эту встречу приглашаются все направления архитекторов. Проводится она два раза в неделю, длится два часа. Она носит рекомендательный характер. Во встрече одновременно участвуют 30-45 архитекторов
Можно только позавидовать людям, которые могут себе позволить иметь только архитекторов и собираться ДВА раза в неделю на ДВА часа :)
Ну и далее ... не знаю, выглядит честно говоря эпично
--------------
Плюс непонятно, зачем собираться и что там решать.
Условно, имея такую "банду" описать все возможные типовые решения можно за условные полгода. Вот реально, на всех уровнях. Дальше просто применять и все.
Ну к примеру, вы приняли, что используете "кубик" для деплоя и определенные стек для, к примеру пользовательских приложений. Ну расписали делали. Сетка, безопасность, скейлинг, мониторинг, ... Все. DevOps взял это в конкретном проекте и по готовому шаблому запихнул. На третий проект базовая инфраструктура залетать должна по надатию двух кнопок.
Базы - тоже самое. Расписали в зависимости от уровня критичности и еще чего-то как ее "растягивать" на серверные площадки, что у вас есть, как настроить безопасность, мультитенанси и еще что придумаете
Так и со всем остальным, тем более в нашем время большая ччасть инфраструктуры реально сделать как сервис.
Бизнес домены. Ну тут понятно, надо отслеживать функции и их маппинг на системы, связи между системами. Ну описали, как и кто с чем интегрируется. Как защищать, как обеспечивать транзакционность и разпределенные транзакции, требования к доке
Но это все такая банда может закрыть за полгода. Единственная причина, дальше эту ораву можно сократить раз в 5 :), поэтому наверное не пишут :)
-----------------
Далее ... солюшен. Банальный чек лист + проверка полноты помогут куда больше, чем какие-то совещания. Вот я недавно запилил описание на 70 страниц. Как его валидировать без чек листа? Вычитывать все буквы и задавать комментарии? НУ тоже можно, условно один написал - второй проверил. Смысл толпе читать, есть условно на вход пришло 50 (точнее 49) только нефункциональных требований (а в реальности 100+, просто пришлось ради экономии вписать основные)?
---------------
Я б в такую организация хотел на пенсию попасть. Уже рвать себе .опу и внедрять не надо, можно на совещания походить и накопленные мысли за до фига лет излагать :)
Не могу повысить карму. Но комментарий выше в точку. Уважаю за опыт. Таких хочу в компании.
Комментарий в стиле "Взять все и поделить". Во-первых, кубики, бдшечки, деплой - это не про EA. Они принимают решения на другом уровне.
Во-вторых, любопытно было бы в реальности (не в теории) увидеть организацию, которая бы взяла и построила идеальный ландшафт за полгода. 1 - осознала все потребности, 2 - выделила бюджет, 3 - предсказала будущее, чтобы сразу предусмотреть риски всех масштабов.
Теоретики такие теоретики)))
А что по вашему EA? Я вам расскажу
Business capability map - как основа понимая, чего делает организация и какими сервисами ИТ это покрывается
Инфа об as-is по слоям, иначе о чем вы хотите решения принимать и процессы его поддержания в актуальном состоянии
Технологические стандарты (это все, о чем вы отозвались пренебрежительно "кубики, бдшечки, деплой")
Практики solution architecture - гайдлайны, чек-листы, шаблоны, процессные документы
То, о чем пишете вы - относится ка ИТ-стратегии, которая как раз описывает это описывает. Но иметь банду на 35-40 человек писать ИТ стратегию - это даже не перебор, это классический случай:
---------------------------
Но как все это написано - открой страшный секрет, столько народу точно не надо. На организацию условно на 10+к людей и 200+ систем разной степени устаревания, , которая за год может делать 40-50 проектов вполне достаточно 3-4 человек в EA, и то - это жирно и не напряжно
Да и чтобы написать, столько народу не требуется. Из опыта, всеобемлющую ИТ-стратегию с большой долей бизнес стратегии для банка из ТОП-3 крупной страны делает команда человек на 10, из которых в проекте на 100% работает дай бог половина. При этом будет все, что я написал и даже немножко (даже на до фига) больше. Дальше с этим всем отлично живет "банда" человек на 5, и то - лично я бы половину выгнал, либо отправил внедрять в "поля"
На организацию условно на 10+к людей и 200+ систем разной степени устаревания, , которая за год может делать 40-50 проектов вполне достаточно 3-4 человек в EA, и то - это жирно и не напряжно
+-+-+
В организациях описываемого вами масштаба и с предлагаемой интенсивностью изменений, очевидно, не нужна выделенная команда EA. Потому что это не про Enterprise.
А можно пример организации сильно большего масштаба?
Просто стало интересно, можем вы имеет в виду условный Гугль?
--------------
К примеру, в профайле автора указано следующее:
3500+ специалистов по ИТ и большим данным
10.0 Пб объем хранения кластера больших данных
46 цифровых продукта и 109 проекта в работе
368 информационные системы в эксплуатации
1400 физических серверов
-----------------
Как вы понимаете, разница не на порядок. Тем более как считать :) Т.е. что считать системой или продуктом. Ну и надо понимать, что большой ритейл - это не так много ИТ по капотом, при всем желании.
Зашел посмотрел на сайт. Ничего космического там нет, стандартный набор плюс-минус
У них получается на 109 проектов только EA 40 человек
Сервера - вполне возможно, у них куча локальных серверных, отсяда и такое количество
Ну и надо понимать, что большой ритейл - это не так много ИТ по капотом, при всем желании.
Я поздравляю вас, вы в 21-м веке. Сейчас ИТ под капотом у всех, кто хочет и может себе позволить автоматизировать бизнес-процессы.
На какой сайт вы зашли и что вы там хотели увидеть, я не очень поняла. Но даю подсказку, чтобы оценить гипотетические возможности автоматизации в корпорации, нужно хотя бы примерно представлять BCM.
Я знаю что такое business capability map, и даже имею практический опыт в ее составлении :)
На сайт компании, которая указана у вас в профиле ;)
Про ИТ под капотом - есть разница, если клиент купил полбатона и кефир, и для этого надо поставить кассиру терминал, сервер с бэком для торгового зала и модуль "склад", и если вы делаете к примеру простой звонок ;) Там все будет сложнее на порядок
Но суть не в размере, а в том, используете вы стандартизированные решения иди нет. Есди да, то размер это просто чуток другие нефункциональные требования и все. Если нет - то я вас могу поздравить с тем, что EA не делает свою работу
Добрый вечер, подход, который Вы описываете, хороший и понятный, но, на мой взгляд, он работает или в маленьких организациях, или в отдельной обособленной бизнес-единице. Мы уже работаем в других масштабах, на сегодняшний день наш процесс полностью себя оправдывает. Повторюсь, на АрхРевью не принимаются решения, а коллеги обмениваются опытом, «подсвечивают» варианты решения с разных ракурсов, которые могли быть упущены.У нас около 150 архитектора разных направлений, 30-45 приходят на встречу – это не один и тот же состав, зависит от повестки встречи. И подключаются те архитекторы, которым интересны заявленные решения. Будем ждать ваше резюме, когда будете готовы делиться своим опытом с нами:)
Я писал выше
К примеру, в профайле автора указано следующее:
3500+ специалистов по ИТ и большим данным
10.0 Пб объем хранения кластера больших данных
46 цифровых продукта и 109 проекта в работе
368 информационные системы в эксплуатации
1400 физических серверов
Получается у вас 100+ проектов, на которых пасется 150+ архитекторов. По моему опыту, проект, где нужен больше чем один solution архитектор - это что-то типа внедрения SAP (модулей 5), или биллинга в телекоме. Или миграции кор-банкинга банка на что-то новое и непонятное. Я могу предположить, что это просто такой стиль наименования. Архитектор Java, Big data архитектор, архитектор безопасности.... тогда да, можно набрать 150 человек :)
Но то такое, нравится "быть" большими - я ж не могу запретить :)
-----------------------
Кстати, а МТС больше вас или меньше?
Самое веселое, что я поддался на обсуждение размера, хотя это не важно. Поэтому я дополнительно решил вам ответить по другому, как архитектор ответить
Поясню. К примеру у вас действительно 50 продуктов. Вау, круто. Экстенсивный путь говорит, что конечно. Столько продуктом, столько систем. Конечно нам надо по два архитектора на проект. Но это не так. И причем именно на уровне EA. Как раз solution более-менее пропорциональны количеству проектов, но мы про EA.
Что должен делать EA, чтобы их не было 40 и все проще жилось? Все просто. На помощь приходит замечательное словосочетание: reference architecture. Смысл крайне прост. Мы создаем архитектуру без функциональных требований. Но знаем, что у нас есть много end-users, им надо веб-интерфейс, возможно нативные мобильные приложения. Под "капотом" очевидно серверное прилодение, база, и там еще много чего. Задача EA выработать такую reference architecture. Она пишется относительно просто. Вы рисуете квадратики, их соединяете и далее методично под каждый квадратик определяете возможный технологический стек: язык программирования, допустимые/рекомендуемые фреймворки, механизмы обеспечения HA/DR, способ деплоя, и т.д. Для связей, они же интерфейсы, они же интеграции определяются допустимые протоколы, соглашения о форматах, и т.д. Сбоку описываются "поддерживающие" функции, логи, мониторинг, аудит и т.д. Это тоже квадратики и под каждый квадратик есть детальное описание. Что взять, как растянуть в "кластер", как не пролюбить данные, как накрутить безопасность.
Такая reference architecture закрывает сразу ВСЕ клиентские приложения. Все. Представляете, даже те, что еще не написаны :)
Аналогично. У вас много данных. Отлично. Рисуете свой data lake, первичные данные, data pipeline, на чем все это крутится и т.д.
Где-то ниже это все живет на железе, своем, арендованном, в облаке или микс. И там тоже свои детализации.
Вот задача EA. И самое приятное - размер не важет, так как если у вас 10 стеков под клиентские приложения - значит какого-то EA, либо группу надо гнать пинком под зад. Конечно бывают покупные решения, они часто имеют свои пасочки, но времена суровных деплоев "дорогих" решений со своим стеком уже в прошлом. Мир поменялся и упростился в каком-то смысле благодаря тому, что даже дорогие платформы пререшли на общий стек хотя бы для DevOps.
И, что интересно? как раз на такой набор референсных архитектур + инфрастурктура + рекомендации по портфелю приложений + план проектов на три года вперед + ... как раз достаточно команды человек на 10 на полгода. Хотите очень-очень детально. Ок, год.
Ключ в том, что задача EA не кричать, что нас 40, а всего 150 - що неоспоримо говорит о проблемах, а наоборот. Стандартизация должна упрощать решения.
И накопленные мысли за до фига лет излагать
За до фига денег излагать, вы имели ввиду. И я вас понимаю. :)
я работаю менеджером направления концептуального проектирования инициатив в дирекции по архитектуре Х5 Tech.
.. два раза в неделю, длится два часа. Она носит рекомендательный характер. Во встрече одновременно участвуют 30-45 архитекторов
Или каждый из них говорит по 2-3 минуты, или 90% людей там не нужны,а процесс развился в классическую бюрократию
Вовсе нет) нет такой задачи, чтобы в обязательном порядке каждый говорил. Архитектор представляет свое решение, а дальше высказываются/задают вопросы/предлагают альтернативные пути только те, кому есть, что сказать. Для тех, кто не выступает или не участвует в обсуждениях – это возможность принять информацию и не допускать в своих решениях недоработанных кейсов.
Теперь всё понятно, в Пятёрочку больше пойду...
У меня был печальный 2-х летний опыт работы корпоративным архитектором. Срок, конечно, небольшой, но мне хватило.
Первое, что меня неимоверно напрягало - совещания. Два часа в день - это, считай, никаких совещаний и не было. Обычно три-четыре по часу/полтора/два. Т.е. полдня минимум. Если на совещании присутствуют представители бизнеса - то все совсем печально. При всем уважении к ним как к заказчикам, общаться с ними непросто. Они мыслят своими категориями, постоянно сбиваются на посторонние (и важные с их точки зрения) темы; разговор все время уходит в сторону. А архитектору надо все это потом осознать, сложить в голове и перевести на язык, понятный аналитикам и разработчикам.
Второе: очень редко удается собрать все заинтересованные стороны - кто-то в отпуске, кто-то на другой встрече, кто-то в командировке, кто-то занят срочной работой, кто-то с бодуна, кто-то с женой поцапался и ему не до того. Приходится встречаться и обсуждать "по кускам". Вроде с одним договорился, но после встречаешься с другими людьми и оказывается, что нет - все не так. В результате на руках ворох порой противоречивых требований, которые надо между собой увязать, нарисовать и согласовать. Апофеоз наступает когда кто-то увольняется и на его место приходит новый человек. И понеслось все сначала.
Третье - проектов никогда не бывает один; их, как правило, 4-5-6. Разной степени сложности, запущенности, срочности (впрочем, с точки зрения любого заказчика только его проект, действительно, важный и сложный, а остальные - так, баловство). Вертишься между ними как (простите) сопля по сковородке. Не мудрено что-то забыть, перепутать. Работать приходится урывками между встречами. Чтобы хоть что-то оставалось, вел записи. Исписал три больших тетради - реально не раз выручало.
Четвертое - уже в сторону корпоративных архитекторов. Я заметил, что подавляющее большинство из них не имеют адекватного практического опыта системного анализа и разработки. Представление - да, опыта - увы. Может быть, мне не повезло - спорить не стану. Более того, может корпоративным архитекторам это и не нужно? Я этого так и не понял, но когда после разработки пробуешь себя в архитектуре - это сильно удивляет.
Пятое - я заметил, что корпоративные архитекторы любят потрещать о высоких материях, инструментах проектирования, методиках. Добро бы, если бы это находило свое воплощение, но нет - отвели душу и вернулись в свое болотце.
Короче, я мучался-мучался и сбежал обратно - в разработку. Все вышеизложенное - сугубо IMHO. Если кого обидел - простите великодушно.
Уверена, что никто не обиделся) И большое спасибо за Ваш комментарий. Еще раз показали, что работа корпоративного архитектора гораздо шире, чем может показаться. Более того, она часто выходит за рамки просто архитектуры, она еще и про объяснить, перевести на архитектурный язык, найти общий знаменатель и много чего еще.
А вот аналогии с обычными архитекторами вы зря написали. Мы ж тут не градостроители)
И кстати, что-то новости невеселые про Х5 приходят... Не в архитекторах ли дело?)
Добрый день, а вот здесь не соглашусь)) как показал лично мой опыт, далеко не все участники процесса понимают, чем занимается корпоративный архитектор((( не понимают его отличия от солюшн. от этого возникают сложности, теряется время. задача была простым и понятным языком объяснить на простом примере. и пример мой понятен даже не градостроителям (вы то поняли:)
На этом этапе работа корпоративного архитектора прерывается до момента, когда в работу её берёт солюшн архитектор. И далее корпоративный архитектор выступает в роли эксперта/консультанта, так как солюшн архитектору могут понадобиться разъяснения по утверждённой схеме. При глубокой проработке на данном этапе может выявиться необходимость её изменения. В этом случае солюшн архитектор создаёт задачу для корпоративного архитектора на согласование изменений концепт-дизайна.
команда реализации готовит детальную архитектуру, которую проверяет корпоративный архитектор. Вторая – когда инициатива реализована, её лидер передаёт корпоративному архитектору полную документацию того, что именно было передано в реализацию. Он сравнивает корпоративную архитектуру с тем, что было на концепт-дизайне. В случае расхождений корпоративный архитектор анализирует их причины.
Описанное деление ответственности между архитекторами "по слоям" приводит к тому, что ответственного за решение нет.
Классика.
"К пуговицам претензии есть?" https://www.youtube.com/watch?v=w8NfqKlYKl0
Согласен, должен быть всегда один ответственный. И это солюшен архитектор. Именно он проектирует решение, ЕА проверяет, чтобы не было дублирования функциональности и не нарушало чек-лист.
В общем когда какой то вкусный продукт хотят на себя несколько команд оттяпать, либо за страшное легаси нужно назначить ответственного.
Статья изумила и повеселила в одночасье)). Про корпоративных архитекторов всё и так ясно: Кто эти люди? Чем занимаются? По какому принципу работают? Комментарии по этому поводу расскрыли картину целиком и полностью. Не перевелись ещё на Руси здравомыслящие ребята. Прям зауважала). У меня вопрос к самому началу статьи, а именно к автору - Кто такой или такая менеджер направления концептуального проектирования инициатив в дирекции по архитектуре Х5 Tech? Чем заняты эти незаменимые люди? Что это за должность эдакая? В чём заключается бесценная помощь архитекторам от этого менеджера? Будьте любезны...
Добрый день))) с удовольствием отвечу: данное направление сформировано, как ресурсный пул, в него входят корпоративные архитекторы на временной основе, в зависимости от стратегических трендов. при изменении приоритетов архитекторы из данного направления могут перемещаться на более срочные задачи. На наш взгляд - это оптимизирует работы архитектуры, помощь и результат очевидны. Это не предмет дискуссии... просто отвечаю, как у нас сформировано. у вас может быть другой опыт)
Очень много абстракции, а хотелось бы конкретнее. На дискуссию это никоим образом не влияет. По вашему ответу видно, что данный "эффективный" менеджер ничем не занимается. Ну разве что немного "эффективной" манипуляцией, что КОНЕЧНО ЖЕ "оптимизирует" работу архитектуры. Уверен, я вас не обидел)))
Добрый день, конечно не обидели, отнюдь, повеселили))) 1. уровень абстракции ответа полностью соответствовал уровню абстракции вопроса)) 2. за эффективность моей работы тоже не стоит переживать, она контролируется и оценивается регулярно руководством; 3. менеджеры от определенного уровня хорошо владеют работой с различными манипуляционными методами. это не позволяет подчиненным применять их в работе) 4. благодарю за глубокий, экспертный комментарий по теме статьи. Хорошей нам рабочей недели)
Ну если руководство следит))) хотя... Всего психологического салата не уследишь))))Полагаю и даже уверен, что вы следите за руководством. И как следствие - статья, полная абстракционизма и лишённая напрочь любой профессиональной сути. Абсолютное преследование карьерного роста)))... И вам наилучшего)))
Короткий или длинный путь: зачем проекту корпоративный архитектор?