Как правило, такой специалист, как IT-архитектор, активно участвует в действительно больших внедренческих проектах, которые осуществляют госкорпорации или торговые сети с множеством филиалов по всей стране. На проектах поменьше это часто номинальная роль, для галочки. Между тем, с точки зрения координации работ, решения и предотвращения проблем, IT-архитектор критично важен. На средних и крупных проектах это ключевая роль. Точнее, она должна быть таковой, чтобы риски не вышли из-под контроля.
Когда можно обойтись без IT-архитектора
Начнем с идеальной ситуации, при которой наличие IT-архитектора не требуется. Ключевые условия:
- Используются стандартные IT-продукты и сервисы, альтернативы и доработки без надобности, решения полностью устраивают.
- Бизнес-процессы прозрачны, они не пересекаются и могут быть автоматизированы изолированно – либо с помощью простой, очевидной интеграции.
- У руководителей бизнес-подразделений четкие, понятные и выполнимые требования. Они не противоречат друг другу, сотрудники всем довольны и слаженно работают.
- У компании разветвленная сеть филиалов.
- Используется несколько десятков IT-приложений, причем они не всегда идентичны в разных подразделениях и на разных проектах.
- На рынке нет коробочных решений для ваших бизнес-процессов, отвечающих специфике и требованиям.
- Интеграции по мере развития бизнеса становятся все более сложными и запутанными.
- Предполагается активное развитие IT-архитектуры.
- Необходима оптимизация и автоматизация бизнес-процессов.
- Предстоит внедрение комплексного IT-решения, которое включает более двух интегрированных систем и/или в котором задействовано несколько подрядчиков.
Как видите, определение «идеальная ситуация» не было преувеличением. Возможно ли такое на практике? Безусловно. Но отвечает ли ваша компания перечисленным требованиям?
Как понять, что IT-архитектор необходим
Можно просто сказать: во всех других случаях, кроме идеального. Но это слишком общее определение. Его легко конкретизировать. Без IT-архитектора не обойтись в нижеперечисленных случаях – одном или в нескольких:
- У компании разветвленная сеть филиалов.
- Используется несколько десятков IT-приложений, причем они не всегда идентичны в разных подразделениях и на разных проектах.
- На рынке нет коробочных решений для ваших бизнес-процессов, отвечающих специфике и требованиям.
- Интеграции по мере развития бизнеса становятся все более сложными и запутанными.
- Предполагается активное развитие IT-архитектуры.
- Необходима оптимизация и автоматизация бизнес-процессов.
- Предстоит внедрение комплексного IT-решения, которое включает более двух интегрированных систем и / или в котором задействовано несколько подрядчиков.
Для крупных международных компаний, у которых более половины систем являются глобальными и сама IT-структура глобализована, просто необходимо наличие штатной команды IT-архитекторов. Например, в нашей компании это целый отдел, распределенный по миру – и его сотрудники не скучают, несмотря на то, что вся разработка отдана на аутсорс. Более того, для узкоспециализированных локальных задач мы обычно привлекаем архитектора со стороны интегратора, подключая наших штатных архитекторов только в качестве экспертов. Зачем такое расточительство?
Чем опасны попытки сэкономить на IT-архитекторах
Здесь нужно оговориться, что название должности или роли не является решением проблем. Очень часто на крупных проектах или в больших организациях используют словосочетание «IT-архитектор», забывая наполнить его смыслом и содержанием. Если руководителю проекта или IT-директору добавить строчку на визитке, это ничего не изменит.
Настоящий IT-архитектор решает задачи, похожие на те, что выполняют строительные архитекторы. Название не случайно, оно во многом прямо транслирует ключевые функции:
- Определение архитектурной парадигмы.
- Выбор технических подходов и решений.
- Декомпозиция до уровня конкретных продуктов и модулей.
- Разработка интеграций – сценариев взаимодействия, протоколов обмена данными.
- Синхронизация хранилищ данных и форматов их передачи.
Как правило, для IT-директора это чересчур частные задачи. Дело не в наличии компетенций (хотя некоторые вопросы требуют специфических знаний, актуализировать которые параллельно выполнению административных обязанностей затруднительно). Просто это отдельный вид работы – трудоемкой, требующей полного погружения и внимания.
Архитектор не ограничивается разработкой «фундамента и чертежей», и его работа не заканчивается после завершения «строительных работ». Ничего подобного! Он несет ответственность за функционирование и развитие «объектов» на протяжении всего жизненного цикла. Точно так же, как строительные архитекторы осуществляют надзор за большими сложными конструкциями: следят за безопасностью, заказывают и проводят обследования, рассматривают варианты по дополнительным застройкам.
В некоторых случаях функции IT-архитектора могут выполняться кем-то «снизу». Например, опытным начальником подразделения или даже руководителем проекта. Но если они действительно справляются с этими задачами, то речь скорее идет о запаздывании с повышением. Не исключено, что после успешного завершения проекта или даже не дожидаясь этого, такие люди уйдут из компании. Уйдут сами, либо их переманят, потому что толковых IT-архитекторов мало, они на вес золота.
Почему IT-архитекторы так важны, что случится без них? Если в двух словах, то логично ожидать больших проблем. Конкретнее:
- Есть риск автоматизировать не то и не так. Будут потрачены большие средства, пройдет время, все успешно завершено и работает – только эффективность гораздо ниже ожидаемой. В реальной жизни это может означать отставание от конкурентов, потерю рыночной доли и даже банкротство компании.
- Второй важный риск – существенное затягивание сроков и раздувание бюджетов на автоматизацию, внедрение и особенно интеграции. Грубая, но наглядная аналогия со строительными работами: если неправильно рассчитать нагрузку, объект просто рухнет. Применительно к IT обрушений зданий и мостов можно не опасаться, к счастью, разве что «сервер упадет» или «грохнется база данных». Но на устранение проблем потребуются большие и дорогостоящие усилия.
- Если недостаточно проработаны и не сбалансированы зоны ответственности для всех участников сложных проектов, это практически неминуемо приведет к конфликтам. Минимум, чего можно ожидать – падение производительности. Максимум – крах проекта. В фатальных случаях помимо этого ожидается еще и вражда с прежними партнерами и/или клиентами.
- Другая угроза – недостаточно высокая производительность систем. Вроде все работает, только не очень быстро и надежно. Постоянно какие-то сбои, нужно дорабатывать, восстанавливать, переносить данные вручную, сверять их. Тут напрашивается фраза «лучше ужасный конец, чем ужас без конца». В вялотекущей агонии могут пройти годы – и они, в конечном счете, нанесут колоссальный урон.
Как выбрать IT-архитектора
При найме IT-архитекторов есть две основные сложности:
1. Прежде чем искать конкретного человека, нужно четко понимать поле деятельности для него. Это означает ситуацию, опасно близкую к «идеальной», потому что, как правило, IT-архитектора начинают искать не заранее, а когда уже начались проблемы, проект горит, и никто толком не понимает, что именно надо делать.
2. Когда и если сложилось понимание, какой именно IT-архитектор требуется, остается найти его и нанять. С такой задачей справится не каждое кадровое агентство, и «охота за головой» однозначно влетит в копеечку.
Погодите, а что значит «какой именно» IT-архитектор, они, что же, бывают разные? О да, еще какие разные! Вот всего несколько классификаций, по которым они различаются:
- Технические или функциональные.
- Системные архитекторы, архитекторы по направлениям или предметной области.
- По приложениям, серверам или сетевым технологиям.
- По интеграциям, бизнес-процессам, безопасности, инфраструктуре или системам.
- По различным платформам (SAP, Microsoft, 1C, Cisco, IBM Lotus...) или по конкретным приложениям.
Это далеко не полный, и, строго говоря, даже не совсем корректный перечень – потому что классификация видов IT-архитекторов огромная тема, исчерпывающее рассмотрение которой без знания конкретной ситуации невозможно. Нужно учитывать:
- Уже используемое программное обеспечение, уровень зрелости IT-архитектуры и IT-стратегию по развитию.
- Потребности бизнеса: что конкретно нужно автоматизировать, какие цели.
- Количество приложений (глобальных и локальных).
- Уровень интеграции систем.
- Если компания международная, то степень глобализации IT и, соответственно, возможность локального управления IT-архитектурой.
- Количество и состав участников по IT внутри компании и среди подрядчиков, партнеров.
- Бюджеты, человеческие (с учетом специализаций) и иные ресурсы, которые можно задействовать для решения задач.
Нужно также учитывать, что IT-архитектор – должность не столько техническая, сколько стратегическая и социальная. Он должен глубоко понимать бизнес-задачи и говорить с бизнесом на одном языке, уметь определять взаимосвязь бизнес-модели с моделью технологической, а также знать и понимать стратегию компании, участвовать в ее разработке и реализации.
Можно сказать, что архитекторы выступают в роли послов: они представляют интересы бизнеса в IT и, встречно, интересы IT перед руководством компании. Поэтому не годятся как явные «технари», так и чрезмерно «бизнесовые» кадры. Нужна золотая середина.
В качестве тестового задания кандидату можно предложить провести верхнеуровневый аудит IT-архитектуры отдельного компонента или всей компании, оценить зрелость и дать рекомендации по улучшению. Разумеется, потребуется как минимум два «сита» собеседований: со стороны IT и со стороны бизнеса.
Настоящей же проверкой станет первый большой проект. Рискованно ли доверять важные решения человеку, о котором известны только анкетные данные, результаты формальных технических тестов и собеседований на общую бизнес-эрудицию? Да, конечно. Однако, риски, связанные с отсутствием IT-архитектора, гораздо выше.
Некорректная статья. Тезисы в пункте "когда можно обойтись без" очень ошибочны и противоречивы, видимо предполагалось оставить только первые три пункта.
Очевидно же просто опечатка.
Статья логичная, но тяжело понять для человека, который не в курсе, кто такой IT-архитектор и что конкретно он делает.