Как заполнить позицию ИТ-архитектора

archСамая большая головная боль для руководителя отдела ИТ-архитектуры – нехватка кадров. Организовать архитектурную практику в организации не просто. Надо суметь объяснить, что же такое архитектура руководству, показать её пользу на нескольких значимых проектах. А еще убедить разработчиков, администраторов, руководителей проектов и функциональных заказчиков, что архитектор – это не еще один вахтер в лабиринте корпоративных предписаний и правил, а скорее проводник, сталкер – помогающий найти easy way в нагромождении корпоративных ИТ. Но выстроить архитектурную практику и завоевать доверие заинтересованных лиц, это только первый шаг. Настоящие вызовы случаются позже. Главный архитектор очень быстро попадает в административные ловушки. С одной стороны, функциональные заказчики инициируют все новые и новые проекты и хотят заполучить в них внятных архитекторов. С другой – корпоративный HR регулярно сжимает и без того скудные позиции, а рекрутеры рассказывают грустную историю о том, что ИТ-архитекторов не существует и проще найти покемона в дополненной реальности, чем архитектора информационных систем на рынке труда. С ними сложно не согласиться. Из четырех сотен вакансий ИТ-архитектора на HH.ru значительная часть остается открытой более полугода.

Я не думаю, что полностью этот разрыв можно устранить в рамках той или иной отдельной организации. Наши западные друзья пытаются что-то сделать, формируют профессиональные сообщества, создают ассоциации, типа IASA, пишут руководства и своды знаний (например, ITABoK), выстраивают программы обучения и сертификации. Но на эти активности уходят годы, а архитекторы нужны здесь и сейчас. К моменту, когда ассоциация достигает некоторой зрелости – публикует свою «главную книгу», налаживает процесс обучения и сертификации, многие их подходы уже безнадежно устаревают. Кроме того, главная проблема разного рода ассоциаций – невнятное ценностное предложение для своих участников. Ситуация меняется, ассоциации постепенно становятся другими. Профессиональная ассоциация нового типа – это не столько книжки, программы обучения и сертификации. Потенциальным заказчикам не нужны наукообразные рассуждения о том, как решить ту или иную задачу. Им нужны решения. Современная профессиональная ассоциация – это площадка, деятельное сообщество (community of practice), способная быстро и качественно создавать требуемые решения по запросу. Если угодно: интернет-магазин, в нашем случае – сервис разработки проектных решения в контексте конкретных корпоративных информационных систем. Но пока такие ассоциации только формируются.

Поэтому у меня появился более простой ответ рынку. Называется он “Мастерская проектирования ИТ-решений”. Это пятидневный очный учебный курс, workshop, на котором встречаются те, кто только постигает профессию ИТ-архитектора и опытные практикующие архитекторы, не первый год проектирующие ИТ-решения в известных компаниях. Именно они выступают в качестве постановщиков задач, наставников, готовых подсказать оптимальное решение, возможно, потенциальных работодателей. Таково первое преимущество нового учебного курса.

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

arch-roles

Опыт работы кандидата выясняется из резюме, знания проверяются на очном интервью, а практические навыки работы… Вот здесь возникают вопросы. Кто-то просит принести примеры предыдущих работ, другие – дают домашние задания, третьи верят на слово. Все это как-то сложно и не очень правильно. Я думаю, что у каждого профессионального ИТ-архитектора должно быть свое портфолио – набор материалов, демонстрирующий его навыки, стиль, наиболее продвинутые компетенции. И поэтому на протяжении пяти дней занятий слушатели не просто делают упражнения, а создают целостный портфель примеров своих работ. Такое портфолио, как минимум, включает:

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

Эту штуку можно потом расширять самостоятельно. Её можно упаковать в формат веб-сайта и выложить в Интернет. Надеюсь, что наши эксперты не откажутся дать короткий отзыв по представленным портфолио, который можно будет использовать в качестве рекомендации.

Чуть позже я расскажу о других особенностях «Мастерской…» в блоге и озвучу их в серии предшествующих обучению бесплатных вебинаров.

Как заполнить позицию ИТ-архитектора: 6 комментариев

  1. Slightly more “complex” solution – build an ecosystem of architects who you may use on demand and, even, remotely. In my experience, organisation can’t keep architects “busy” (i.e. doing real architecting work) all the time. Look at your enterprise-architecture services – are they continuous activities or demand-based?

    1. Для UX design, мобильных приложений и разработки чат-ботов проводятся hackatons. Заказа на проектирование ИТ-решений в подобном формате я пока не встречал. Наверное, это не очень модно 🙂

      1. Not as hackatrons but some remote work. For example from upwork.com
        “We are looking for experienced ECommerce Architect to guide a team of developers. The Architect should be well versed in eCommerce Technologies/SEO/CMS/Analytics etc and other leading ECommerce technologies. We are building enterprise Ecommerce website and the Primary viewport is Mobile. Performance, Scalability are very important. Pl share your resume with years of experince, any ecommerce site reference and other details”

  2. Мне кажется, что роль архитектора часто может быть выполнена коллективным органом – архитектурным комитетом. В таком виде явная позиция архитектора не нужна организации. Более того, учитывая, что долгие годы организации существовали без этой позиции, функции этой роли выполняли в разное время другие роли – начиная от ген.дира, менеджеров и заканчивая младшими кодерами. Другими словами, степень влияния “формального” архитектора на общий архитектурный процесс зависит от качества “неформализованной” архитектурной практики в компании.

    1. Возможно кому-то покажется удобным коллегиальное принятие решения: ответственность за него размазана по всем участникам – никто за него не отвечает.
      Из минусов – теряется преемственность – сегодня архитектурное решение принимали одним составом, завтра – другим. К тому же, из собственной практики, ген.дир и кодер разговаривают на существенно разных языках. Если основная деятельность организации не ИТ, то они друг друга просто не поймут. Возможно это приемлемо для небольших организаций ИТ профиля.

      Периодическое или удалённое привлечение ит-архитектора обладает всеми недостатками коллегиального. К тому же для принятия очередного решения необходимо изучать существующий ландшафт.

      У выделенной позиции архитектора тоже есть существенный недостаток – зависимость от конкретной персоны, но при достаточной заинтересованности (в идеале это ит-директор или его зам) и компетентности он может выстроить надёжную и эффективную ИТ инфраструктуру. Его роль как раз в том, что бы “неформализованную архитектурную практику” AsIs проанализировать и привести к ToBe, по маршруту, определённому стратегией информатизации.

      Думаю достаточно перспективно иметь штатного IT архитектора, возможно совмещённого с позицией руководителя отдела бизнес-анализа.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *