Нужен ли архитектор?

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

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

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

• знает стратегию развития организации и участвует в ее разработке и контроле;

• обладает глубокими познаниями в используемых технологиях;

• собрал команду, которая состоит из верных «узких» специалистов.

Это портрет Архитектора с большой буквы. Кто-то скажет, что если добавить в данный список понимание своей роли и ответственности, то получится описание CIO. С этим можно согласиться, но с небольшими оговорками. CIO —архитектор, но архитектор в рамках всей организации, архитектор, который стратегически определяет бизнес-сферы и обеспечивает их автоматизацию на должном уровне; CIO не просто говорит с бизнесом на одном языке, но и предлагает бизнесу новые возможности, иногда даже настаивает на трансформации бизнеса; CIO принимает принципиальные решения: необходимо ли, к примеру, специализированное ПО для оценки клиента, или этот функционал можно реализовать в уже используемом приложении фронт-офиса. Я же говорю про архитектора более низкого уровня, который напрямую не влияет на принятие решения, но всегда имеет на этот счёт свою обоснованную точку зрения. Нужен ли такой архитектор? Можно ли обойтись без него, и к чему готовиться в случае его отсутствия?

Если попробовать крупными мазками систематизировать различный подход ИТ-департаментов к обсуждаемому вопросу, то можно выделить три категории:

1. Архитектор есть, он активно участвует в проектах, принимает ответственные решения.

2. Архитектор есть формально, чаще всего это начальник ИТ-департамента и выделенный руководитель проекта.

3. Архитектора нет, есть представители бизнеса, которые занимают позицию: нам всё равно, как вы это сделаете, нам нужно, чтобы было вот так.

Обойтись без архитектора, конечно, можно, но надо быть готовыми к тому, что:

• не получится адекватно оценить соотношение стоимости-качества-сроков для альтернативных решений. Возможно, эти альтернативные решения не появятся вовсе;

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

• требования от различных бизнес-подразделений не будут гармонично дополнять друг друга, но будут конкурировать;

• и, пожалуй, самый лаконичный, но очень важный пункт — изящность полученного решения, скорее всего, будет страдать.

Хочу поделиться примерами из своей профессиональной жизни (а я уже 15 лет автоматизирую процессы в банках, энергетике, страховании, производстве), в которых ключевую роль сыграли именно архитекторы.

Однажды я участвовал в критически важном бизнес-проекте, который в определённый момент оказался в патовой ситуации: срок до реализации проекта на основании решения, которое предложили поставщики (четыре компании), оказался в ТРИ раза больше, чем оставалось по календарю, даже без учёта выходных. Бюджет в этом проекте играл второстепенную роль, но и он был существенным. Интересно отметить, что бюджет скорее бы выделили и такой, но сроки были просто недопустимыми.

В результате небольшой трансформации бизнес-требований, которые заказчики приняли безоговорочно и сразу, у нас получилось найти решение, оказавшееся примерно в пять (!) раз быстрее в реализации и в шесть (!) раз дешевле. Решение действительно получилось изящным. Реальностью эта история стала из-за того, что предыдущий архитектор (а он был) не уделил должного внимания ключевым характеристикам. Проект был реализован, успешно стартовал и просуществовал в неизменном виде более года. Потом обнаружилось, что принципы, заложенные в решении, имеют ограничение, которое могло стать препятствием уже в ближайшем будущем. Ситуацию усугубляло то, что к критическому для проекта моменту на этих принципах оказалось завязано очень много различных бизнес-процессов.

Другой пример. На комплексном проекте, без архитектора со стороны заказчика, столкнулся с требованиями, изначально показавшимися абсурдными. Смысл был в том, что требования, которые нам выдвигал один из бизнес-представителей, заведомо ухудшали клиентоориентированность системы по сравнению с тем, как она была реализована до этого. Для меня было очевидно, что бизнес-значения данные требования не несут. Но наши разъяснения по этому поводу остались без внимания, и требования не снимались. Сказать честно, мы пытались обжаловать требования не потому, что для нас их реализация значила дополнительные затраты/доработки, а именно потому, что они были явно неправильными — и технологически, и экономически. Единственной возможностью обжалования была последняя инстанция в лице топ-менеджмента. Судя по ответу, который мы получили, суть проблемы была пропущена, и нам даны были указания требования выполнять.

Буквально в первую неделю опытно-промышленной эксплуатации мы получили замечание от тех же лиц, что становится хуже, чем было, клиенты будут жаловаться, писать в надзорные органы, есть риски, нужно исправлять. Мы всё исправили, точнее, вернули к тому, как предлагали изначально, но это уже был дополнительный бюджет, новые сроки и т.п. Безусловно, комплексные проекты можно делать без архитектора. Если проект предполагает внедрение не более двух-трёх систем, и есть один поставщик, который предлагает рынку эти системы, то наличие архитектора в организации вряд ли принесёт столько же пользы, как в случае, если внедряются решения от разных поставщиков. Этому есть вполне понятное объяснение: поставщик комплексного решения изначально заинтересован в обеспечении качества, гибкости, удобства и т.п., поскольку только в этом случае бюджет проекта при внедрении и сопровождении будет оптимальным. Плюс у него, как правило, есть чёткое понимание, что результат проекта напрямую повлияет на дальнейшие партнёрские отношения.

Но в любом случае моя рекомендация для заказчиков, которые идут на проекты без собственного архитектора,— продумать точку и место для возможного обжалования требований, выдвигаемых бизнесом.

Есть ли у вас архитектор ИТ-решений? Кто исполняет эту роль?