Comments 6
Учитывая, как глубоко у вас архитекторы влезли в разработку - не удивительно что понадобился аж целый директор ит архитектуры.
Если архитектор работает и вместо системного аналитика, и вместо разработчика решает как данные хранить и как ими обмениваться, а потом еще и картинки с документацией рисует, да еще на апруве каждый чих. И не забываем про архиком.
В итоге получается газпром с отделами и целыми блоками с десятками и сотнями архитекторов.
Вопрос только зачем?
Картинка из арчи со связям - да такое же автоматически рисуется на основании любого сервис-дискавери в современной разработке. Контракты на ручки зафиксировать? Зачем для этого архитектор?
ПС прочитал внимательно финал - у вас аутсорс. Ясно-понятно, системных аналитиков подняли в должности до архитекторов.
Возможно, нам стоит с газпромом организовать обмен опыта, т.к., к счастью, у нас нет "десятков и сотен архитекторов", ограничимся числом меньше 10 :)
В большинстве случаев наши архитекторы всегда с опытом разработки, поскольку иметь такой опыт очень важно, иначе как проектировать без понимания деталей и способов интеграций. И именно схема с детализацией должна стать руководством к действию при реализации, а не пустые квадратики, которые никому не нужны.
В итоге получается газпром с отделами и целыми блоками с десятками и сотнями архитекторов.
Ага, это точно, "бюрократический Газпром". Вот только не понятно, в чью профессию, в такой компании, входит обязанности следить за мелочами и процессом продаж?
Был такой диалог:
- Здравствуйте! Я бы хотел купить вот эту тумбочку.
- Отлично! Оформляю! (5 минут что то набирает на ПК в зале)
- Вот, держите, можете на кассе оплатить.
- Хорошо, сейчас оплачу. А с какой стороны подъехать, что бы забрать?
- Ни с какой. Она находится по (адрес).
- Дак это другой конец города!
- Ну да, у нас там склад.
- А можно купить ту, что в наличии у вас?
- Можно! Выбирайте!
- Вот эту!
- Её нет в наличии!
- А почему она тогда в торговом зале?
- Это выставочный образец.
- А эта?
- Нет в наличии ни где в городе, можем привезти через 2 недели.
- А эта?
- Эту сняли с продаж вообще.
- А почему она в зале тогда?
- Выставочный образец
Конец диалога.
Мы выстроили стратегию по описанию и документированию архитектуры исходя из зон ответственности и движения по слоям в развитии архитектуры:
Названия слоев напоминают ArchiMate, но у вас они переставлены местами (в оригинале: Strategy -> Business -> Application -> Technology -> Physical -> Implementation & Migration). Интересно, почему вы так сделали и какие преимущества это дало?
Все верно. Такая последовательность и выбор исходили из вопросов: с чего начать и как двигаться при внедрении архитектуры в компании с нуля; Как уже в первые месяцы приносить дивиденды и показать эффективность задуманного, а не просто квадратики рисовать.
Поскольку в компании на тот момент уже было направление, отвечающее за бизнес процессы – концентрироваться на этом не было смысла. Заниматься стратегией, не имея представления что под капотом и на что это может повлиять – не хотелось бы.
Поэтому концентрируемся именно на ИТ архитектуре. Начиная с Application и переходя к Technology, мы получаем инвентаризацию ИТ систем, поднимая в последующем вопросы прямых зависимостей, отказоустойчивости и утилизации ресурсов. Но ключевое, этот процесс не должен преследовать цель задокументировать для того чтобы задокументировать. Необходимо обслуживать новые активности от бизнеса и уже в рамках них поднимать AS IS, т.е. совмещать полезное с рутиной. А уже после такого покрытия уровней, переходить к интеграции с описанными процессами, и к остальным уровням имея всю полную картину – такова наша стратегия последовательности.
Многое зависит от специфики компании, текущей ситуации, ключевых точках и проблематиках, которые обозначаются – и отсюда уже формируется конкретные действия и зона ответственности.
А какой KPI у ваших сотрудников? И какая зона ответственности (иначе за что наказание)?
Зачем в Hoff Tech архитекторы или как мы строим и описываем ИТ-ландшафт