Роль ИТ-архитектора в организации

a5931_list_of_cell_phone_providers_6865783407_6023ee9464Несколько месяцев назад я написал заметку Когда, кому и зачем нужна Архитектура Предприятия Справедливости ради надо отметить, что полномасштабный проект по выстраиванию Enterprise Architecture  встречается достаточно редко. Намного чаще услуги архитектора бывают востребованы для решения более локальных задач: структурирование приложений, процессов и данных в рамках отдельного продукта, бизнес-функции или направления деятельности организации. В таких случаях обычно говорят об архитектуре ИТ-решения, а человека который её делает называют Solution architect. Одной из задач этого уважаемого эксперта является разработка архитектуры в ИТ-проекте. На прошлом месте работы мы называли эту деятельность High Level Design Но у Solution architect есть еще одна, не менее важная задача – подготовка вариантов решения. О том как это сделать можно почитать здесь Create a solution architecture А я напишу несколько слов о том, почему это важно.

Типичный ИТ-ландшафт организации представляет собой набор из нескольких десятков (иногда сотен) бизнес-приложений. Многие из этих систем остались организации в наследство от уволившихся сотрудников, но для большинства важных приложений, как правило, в организации есть команда разработки или системный интегратор, отвечающий за развитие и поддержку системы. Для «коробочных» решений где-то на горизонте еще существует вендор, который появляется в компании накануне Нового года, чтоб поздравить заказчика с приближающимся праздником и продлить контракт на поддержку на следующий год. С другой стороны, в компании работают сотрудники. Как мы выяснили на летнем аналитическом фестивале, работа у этих сотрудников не всегда ладится.  И в ряде случаев в этом виноват ИТ (см. Верните аналитика в бизнес начиная со слайда 9). Потому эти уважаемые люди регулярно хотят что-нибудь новое запустить или, в крайнем случае, что-нибудь старое улучшить. И сделать они это хотят при помощи ИТ.

Существует несколько сценариев организации этой деятельности:

  1. Чаще всего заказчики стремятся напрямую обратиться к ИТ-команде, осуществляющей развитие какого-то конкретного приложения, с просьбой что-нибудь доработать. И те с радостью идут им навстречу, добавляя в систему очередную ненужную фичу. Если таких обращений становиться много или же доработки требует некоторых дополнительных денег, то процесс развивается по сценарию номер два.
  2. Подключаются руководители ИТ или бизнес-заказчики. Обычно рассказ о том, почему нужно что-то доработать в системе выглядит довольно сумбурно и заканчивается фразой: «дай денег!». Руководители пытаются что-нибудь с этим сделать, например, внедрить проектное управление, организовать соответствующий комитет, в общем, как-нибудь упорядочить эту деятельность. Однако, после достижения данного уровня зрелости в голове ИТ-директора все чаще возникает вопрос: а что из этого мы, действительно, должны делать и почему делать следует именно так.
  3. Решение о варианте реализации той или иной бизнес-потребности осуществляется на основании рассмотрения альтернатив. Это как в процедуре закупок – никогда не надо покупать решение от единственного поставщика. Точно так же, прежде чем делать какой-то проект, полезно рассмотреть несколько вариантов реализации.

Собственно говоря, для подготовки альтернативных вариантов и организации процесса их рассмотрения и нужны ИТ-архитекторы. Делается это на этапе проекта, который в PMBOK называется «инициация». С точки зрения ИТ в этот момент все плохо: требования отсутствуют, заинтересованные лица между собой еще ни о чем не договорились, но кто-то уже настойчиво продвигает один из вариантов реализации. А еще, в компании в этот момент появляются вендоры новых систем и системные интеграторы. Причем обычно приходят они не с пустыми руками, а с утверждением, что у них все есть и их предложение самое лучшее.

Одним словом, работа архитектору предстоит сложная. Однако, это пожалуй единственный способ включить руководителей в процесс принятия решения. Потому что в сценариях 1 и 2 никто никаких решений, на самом деле, не принимает. Просто потому, что погружение в технические детали — задача для большинства руководителей не реализуемая. Не от того, что они не способны разобраться в «технике». Просто у них не хватает на это времени и, обычно, необходимой объективной информации. В общем, если ИТ-начальник хочет что-то решать, то ему стоит подумать об организации такого процесса.

Роль ИТ-архитектора в организации: 8 комментариев

  1. Максим, тут сразу хочется сказать. «Продано!». Ну а в целом всё очень доступно и понятно.

  2. Надо ли ИТ-начальнику что-нибудь решать? Невозможно ответить на этот вопрос, не определившись с ролью ИТ-начальника в компании.

    В своей записи Когда, кому и зачем нужна Архитектура Предприятия, вы упоминаете Карра и Захмана. Я бы вспомнил Майкла Портера. В своей работе «Конкурентное преимущество», Портер делит различные виды деятельности предприятия на основные — создающие стратегическое преимущество компании и ценность для потребителя, и вспомогательные — необходимые, но не влияющие на результат.

    Портер, как и Карр, считает ИТ вспомогательной активностью, такой же как, например, эксплуатация гаража компании. Будет ли руководитель предприятия уделять много внимания выбору между Тойотой и Нисаном в гараже компании?

    В упомянутой, вами работе «A Framework for Information Systems Architecture», Захман пишет: «Возрастающая зависимость издержек и успешности бизнеса от информационных систем, требуют организованного подхода к управлению ими». Говоря о зависимости бизнеса от информационных систем, Захман подчёркивает стратегическую значимость ИТ. Грамотное применение технологий позволяет создавать конкурентное преимущество для компании. ИТ из вспомогательной функции становится частью цепочки создания ценности, а ИТ-начальник становится CIO — одним из полноценных руководителей, отвечающим за формирование и реализацию стратегии предприятия.

    Архитектура предприятия — это инструмент, позволяющий раскрыть стратегический потенциал ИТ. Она позволяет систематизировать процесс выработки и реализации стратегии. Понимая стратегию и технологические потребности предприятия, CIO может найти такой набор технологий, который принесёт наибольшую отдачу бизнесу.

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

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

    Первыми это поняли производители решений для разработки архитектуры предприятия, такие, как Troux или Alfabet. От разработки инструментов для отрисовки статичным диаграмм, они перешли к созданию аналитических инструментов, которые, опираясь на принципы архитектуры предприятия, помогают CIO анализировать работу предприятия и выстраивать ИТ-стратегию в соответствии с потребностями бизнеса.

    Каждый ИТ-руководитель должен определить для себя, кем он хочет быть. «Технарём», который поддерживает работу серверов или полноправным руководителем, формирующим стратегию. И если его выбор — быть CIO, то он должен научиться говорить с бизнесом на языке финансовых показателей и разделять ответственность за финансовые результаты. Только в этом случае, он сможет по настоящему что-то решать.

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

      А относительно CIO и ИТ-директоров, то, думаю, они люди опытные и лучше нас понимают как разговаривать с другими СxO.

  3. Максим, в следующих статьях хотелось бы заглянуть в лицо уважаемому EA и SA. Кто он, какими компетенциями обладает, какой багаж опыта несёт за плечами, так ли для него важна специфика бизнеса компании(например: фикса, мобильная связь, банкинг, е-бизнес).

    1. Кратко, но интересно об SA: Anatomy of a Software Development Role: Solution Architect Сложно дать всеобъемлющее описание профессии. Но я с удовольствием готов ответить на какие-то отдельные конкретные вопросы. Можем попробовать сделать в формате небольшого интервью

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

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